[FFmpeg-devel] [PATCH]lavf/mxfdec: Export EIA608 Closed Captions by default

Marton Balint cus at passwd.hu
Sun Feb 17 17:28:26 EET 2019



On Sun, 17 Feb 2019, Marton Balint wrote:

>
>
> On Sun, 17 Feb 2019, Carl Eugen Hoyos wrote:
>
>> 2019-02-17 1:40 GMT+01:00, Marton Balint <cus at passwd.hu>:
>>>
>>> On Sat, 16 Feb 2019, Carl Eugen Hoyos wrote:
>>>>
>>>> I am not sure why there is an option to disable Closed Captions export,
>>>> but disabling the export by default seems like a bad idea to me.
>>>
>>> SMPTE 436M can be any kind of ancillary data, not only closed captions.
>>> That is why the default behaviour (pass all the data to userspace so a
>>> userspace app can parse it properly) makes sense.
>>
>>> Some applications might depend on this.
>>
>> Wouldn't it still make more sense to change the default?
>
> Sorry, no. We should not change existing behaviour for this.
>
>> The application that knows it needs the ancillary data, well, knows
>> it while the average user who reads the mxf file has no idea that
>> there is a subtitle stream and has no idea that FFmpeg can read
>> the subtitle stream.
>>
>> I would bump micro in any case and the option also works fine
>> with older FFmpeg versions so I don't really see the issue.
>
> Issue is that you are removing a data stream which was previously 
> provided. Also CC extraction in MXF decoder is a hack. It should be 
> deprecated after the API will be capable of bitstream filtering between 
> different codecs. And the VANC data can be parsed to multiple 
> subtitle/data streams. Why eia608 has the perference? Why not teletext, or 
> SCTE messages? All in all, it is better to keep hacks under the 
> option until we come up with better API.

One more thing is that the fact that a file has VANC data does not mean 
that it actually has Closed Captions data. It might, or it might not, so 
unconditionally advertising a CC stream just because there _might_ be CC 
data would also be bad.

Regards,
Marton


More information about the ffmpeg-devel mailing list