> 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 firstname.lastname@example.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel