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 -- [email protected] To unsubscribe send an email to [email protected]
