Degradation in Closed Captions decoding

[ValeryKot]

Summary of the bug: in some cases, FFmpeg fails to extract Closed Captions (A/53 Part 4 format). This is a degradation: same file can be processed correctly with FFmpeg 4.0, but also with VLC.
How to reproduce:

% ffmpeg.EXE -f lavfi -report -i "movie=CC720p60_10sec.mp4[out+subcc]" -map 0:1 output_10sec.srt
ffmpeg version N-118422-g1fbe9deee3-20250204
built on 2025-02-04 17:56

Relevant error is:

[Closed Captions Decoder @ 000002f8b063dec0] Data ignored due to columns exceeding screen width.

I will (try to) attach original file, and reports and output by latest master and by 4.0

[ValeryKot]

FFmpeg report, latest master

[ValeryKot]

output SRT file, latest master

[ValeryKot]

FFmpeg report, version 4.0

[ValeryKot]

output SRT file, version 4.0

[ValeryKot]

I uploaded cropped (CC720p60_10sec.mp4) and longer (CC720p60.mp4) video files which trigger the issue to ​https://streams.videolan.org/upload/

[Marth64]

Your sample has actual text on field 1 (odd) instead of field 2. But field 2 is transmitting bits before field 1, the CC decoder is choosing it as the default field to decode. This command works for your sample:

ffmpeg -data_field first -f lavfi -i "movie=CC720p60_10sec.mp4[out+subcc]" -map 0:1 output_10sec.srt

This is similar to #11263

[ValeryKot]

With explicit -data_field first it works indeed, thanks! So it is not a degradation, but change in functionality and default behaviour. Before 4.4, CC decoder was always processing first data field. Since 4.4 it has an option to select first or second, but default is "auto", which in 50% might get wrong and non-deterministic. In my view, "first" would be a better default. But of course it is now too late to discuss.

Thanks for the explanation, ticket can be closed.

[MasterQuestionable]

͏    Exact duplicate?
͏    ​https://trac.ffmpeg.org/ticket/11263#comment:12