> On Mar 7, 2018, at 12:49 PM, Michael Niedermayer <mich...@niedermayer.cc> 
> wrote:
> 
> On Tue, Mar 06, 2018 at 02:25:12PM -0800, Aman Gupta wrote:
>> From: Aman Gupta <a...@tmm1.net>
>> 
>> Some streams include both a53 and scte20 data. Before this commit,
>> the scte20 data would be used instead of the a53 data.
>> 
>> See https://s3.amazonaws.com/tmm1/ccaptions/scte20plusa53.ts,
>> which produced garbage captions since 3f1a540204a8c187f77b3805d.
>> ---
>> libavcodec/mpeg12dec.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
> 
> why does the combination produce garbage ?
> why should not both be exported or it be user selectable?

I suspect part of the issue is that the SCTE-20 data gets jammed into the 
a53_caption member.  It may make sense to have it put into it’s own field, so 
that if both are present the encoder can decide which to insert into the final 
stream.  But having both of them putting data into the same field is likely to 
produce indeterministic output.

I’ve got basically the same issue in the decklink input where both EIA-608 and 
EIA-708 VANC can arrive in the same frame, and will need to either implement a 
similar change (i.e. prefer 708 if both are present), or be prepared to add a 
new side_data type for 608 so both can be sent and the downstream can choose 
which to include in the output.

Devin

> also turning one off for ever seems problematic for concatenated
> sequences. not every sequence would need to contain both I guess

It would certainly be good if it were configurable.  I am certain there are 
users who will say “I know the X format is broken and I want to always send 
through the Y format", and that may not correspond to the heuristic implemented 
in the decoder (in this case, to always prefer 708 data over SCTE-20).

Devin


_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to