On Wed, Mar 7, 2018 at 10:35 AM Devin Heitmueller <
> > 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
> > 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?
> ffmpeg-devel mailing list
ffmpeg-devel mailing list