[FFmpeg-devel] Re: [GSoC 2026] Qualification Task – SubViewer Decoder Patch

[Yalda via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

Thank you, Devin.
Here is my current unprioritized laundry list (This is a very rough
version, I will move it to a document and try to articulate it better
and also I probably missed some things)

Refactoring:
- Migrate the MPEG-2 user data DVD/DISH/SCTE/etc to A53 translator
code, and any similar conversion if it exists to CodedBitstream (CBS)
API.
Outcome: Processing of bitstream wrapping is no longer crammed in
MPEG-2 encoder, and with CBS API possibility of encoding the wrapping
in the future is more clear.
Limit: Do not alter algorithms in such a way that causes difference in
input/output especially output to A/53 part 4 (the current
intermediate in ffmpeg).
Benefit: In this way, this parsing logic is made independent (the
formats are respected as actual coding formats) and we can test it
independently as well as open the door to cross-translation between
formats.

- Identify common functions if any (parity checks, etc.) and move to
shared utility file
Outcome: Inventory common functions especially those that are
stateless and centralize them
Benefit: Remove redundancies

API cleanup:
- Create AV_CODEC_ID_CEA_708 and AV_CODEC_ID_WRAPPED_CC , and update
current AV_CODEC_ID_EIA_608 references to AV_CODEC_ID_WRAPPED_CC
Justification: Right now, all CC bitstream in FFmpeg is classified as
EIA-608 but this is not really what is being passed around. Also it
does not consider CEA-708.
1, CEA-708 is its own codec and if we ever support it we should treat it as one.
2, Within FFmpeg, we carry CC bitstream that can contain both but are
wrapped in A53 format and can contain 608 or 708. So we should
identify that accurately as "wrapped CC".

ccaption_dec fixes:
- Fix odd naming inconsistency and name it for what it actually is: an
EIA-608 decoder (eia608dec).
Justification: File is "ccaption_dec", class is "cc_dec", description
suggests CEA-708 support (not true, this data is skipped).
Complement with the API polish fix above, and the decoder will now
actually be honest and clear about what it does

- Add an option to trim whitespace
Justification: Besides archivists, it is generally undesirable to have
whitespace which is rampant in CC due to positioning methods which can
be "tricks"
While the decoder produces decent ASS, many people want simplicity such as SRT
This IMO a massive output usability improvement, though long term
belongs in subtitle filtering facilities (we do not have it now)

- Fix ASS resolution to be NTSC based, not PAL
Justification: Right now, decoder uses ASS_DEFAULT_PLAYRESX and
ASS_DEFAULT_PLAYRESY as the ASS resolution base
This would make it 384x288 (PAL multiple) respectively, but I think it
should be 360x240 (NTSC multiple)
360x240 scales cleanly to 720x480
IIRC this can cause inaccurate alignment in 16:9 outputs (where
positioning is retained in ASS) but I have to go back and check why I
flagged this

- Make cropping text off screen width an option
Justification: Right now, decoder always cuts off columns that it
thinks are past the screen width
I am not sure this is correct behavior to enforce, I have seen samples
where the CC are authored oddly (squished from 16:9 to 4:3), or just
slightly off to push limits

- Recently reported issues
https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/21332
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org