On Thu, Mar 08, 2018 at 07:13:57AM +0000, Aman Gupta wrote: > On Wed, Mar 7, 2018 at 10:35 AM Devin Heitmueller < > dheitmueller at ltnglobal.com> wrote: > > > > > > From what I've seen in US broadcast television, scte20 is only used on > > > standard-def content and everything else uses normal a53. > > > > A53 is definitely the more popular standard, and all that is approved for > > distribution in digital over the air broadcasts. SCTE-20 would only be > > found further up the distribution chain, and perhaps in distribution to > > some cable boxes (although it’s becoming less and less common that it can > > be decoded since most of the content is encrypted nowadays). > > > > > > > > > > I'm not sure how we would export both since there's only one type of side > > > data. > > > > We would have to add a new side data type, and encoders would have to be > > changed to look for both. > > > > > > >> > > >> also turning one off for ever seems problematic for concatenated > > >> sequences. not every sequence would need to contain both I guess > > > > Funny enough, I spent my entire morning debugging some issues with playing > > concatenated TS streams. If anyone thinks that’s supposed to be working > > today in ffmpeg, there’s a ton of work to be done in that area. > > > > > > > > > > > > > Yea that's theoreticaly possible, but I'd rather wait to add support > > until > > > someone actually sees it in the wild. > > > > > > Before I added scte20 support a few months ago no one even noticed it was > > > missing. It doesn't seem to have wide spread use. > > > > It’s not really that nobody noticed - it’s that most people in the > > broadcast space until recently had ruled out the ability to use ffmpeg for > > production because of it’s lack of good support for ancillary data such as > > captions. That situation is improving of course, but it’s not so much that > > “no one even noticed it was missing”. > > > > > > If changing the framework to support the extra side data format isn’t > > viable, then certainly prefering A53 over SCTE-20 would be the right way to > > go. I would make it configurable though. > > > Thanks for the background on SCTE-20. I don't really know much about it. > > I'm not opposed to adding new side data, but it doesn't sound like it's > worth it in this particular case. Atleast to me; if someone else wants to > pursue that approach I will happily help review and test any patches. > > > > To make my patch configurable, I could change the ignore flag I added into > a new option called parse_scte20: default to "prefer a53" like I have now, > but can be set explicitly to "always" or "never". Wdyt?
I tried to use ffmpeg to transcode some TV recordings I have where I need to keep the closed captions. When I finally got the ffmpeg options right to copy the captions, the captions were a garbled, unrecognizable mess. I eventually worked around the problem with ffmpeg be using ccextractor to first extract the captions separately. I then muxed them back in later with the transcoded video and audio using ffmpeg. With ccextractor, I initially got garbled captions too until I used the --noscte20 option. After that, I got perfectly clean captions. When I looked to see if ffmpeg had a comparable switch, I found this thread. I build ffmpeg myself with this patch and sure enough I got perfectly clean captions too without having to use ccextractor. I see this patch hasn't been included in ffmpeg yet. Please reconsider including it in some form as it is definitely needed out here in the real world. Please note that I am not subscribed to the ffmpeg-devel list. Please copy me on any replies that you need me to see. David -- David Engel da...@istwok.net _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
