[FFmpeg-devel] [PATCH] avcodec/mpeg12dec: ignore scte20 captions when a53 data is also present

[David Engel]

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
david at istwok.net