> 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. Devin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
