[FFmpeg-devel] [PATCH v2] libavformat: add RCWT closed caption muxer

[Stefano Sabatini]

On date Saturday 2024-01-06 15:41:05 -0600, Marth64 wrote:
> Signed-off-by: Marth64 <marth64 at proxyid.net>
> 
> Thank you for the good feedback and review. Most feedback is addressed.
> 
> >  nit: no need to shift
> I left this alone only since I see it being done this way in lavf/ccfifo
> and other documentation. I assumed it could be doing the shift for a reason,
> but I can study further why if you think it shouldn't shift.
> 
> > I don't remember if new elements addition entails a minor library bump (probably it should)
> I reviewed APIchangelog and didn't see similar type of bumps for adding to allformats.
> The publically exposed codec ID has been in ffmpeg for a long time.
> But I am happy to patch in a version bump with your confirmation.
> 
> Much appreciated,
> Marth64
> 
> ---
>  Changelog                |   1 +
>  doc/muxers.texi          |  40 ++++++++++
>  libavformat/Makefile     |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/rcwtenc.c    | 166 +++++++++++++++++++++++++++++++++++++++
>  tests/fate/subtitles.mak |   3 +
>  tests/ref/fate/sub-rcwt  |   1 +
>  7 files changed, 213 insertions(+)
>  create mode 100644 libavformat/rcwtenc.c
>  create mode 100644 tests/ref/fate/sub-rcwt
> 
> diff --git a/Changelog b/Changelog
> index 5b2899d05b..3d60f688ca 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -18,6 +18,7 @@ version <next>:
>  - lavu/eval: introduce randomi() function in expressions
>  - VVC decoder
>  - fsync filter

> +- Raw Captions with Time (RCWT) closed caption demuxer

demuxer -> muxer?

>  
>  version 6.1:
>  - libaribcaption decoder
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 7b705b6a9e..0bdeaeeaf3 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -2232,6 +2232,46 @@ Extensions: thd
>  
>  SMPTE 421M / VC-1 video.
>  
> + at anchor{rcwt}
> + at section rcwt
> +
> +Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
> +used open source tool for processing 608/708 closed caption (CC) sources.
> +It can be used to archive the original, raw CC bitstream and to produce
> +a source file for later CC processing or conversion. As a result,
> +it also allows for interopability with ccextractor for processing CC data
> +extracted via ffmpeg. The format is simple to parse and can be used
> +to retain all lines and variants of CC.

> +This muxer implements the specification as of 2024-01-05, which has
> +been stable and unchanged for 10 years as of this writing.
> +
> +This muxer will have some nuances from the way that ccextractor muxes RCWT.
> +No compatibility issues when processing the output with ccextractor
> +have been observed as a result of this so far, but mileage may vary
> +and outputs will not be a bit-exact match.
> +
> +Specifically, the differences are:
> + at enumerate
> + at item
> +This muxer will identify as "FF" as the writing program identifier, so
> +as to be honest about the output's origin.
> + at item
> +ffmpeg's MPEG-1/2, H264, HEVC, etc. decoders extract closed captioning
> +data differently than ccextractor from embedded SEI/user data.
> +For example, DVD captioning bytes will be translated to ATSC A53 format.
> +This allows ffmpeg to handle 608/708 in a consistant way downstream.
> +This is a lossless conversion and the meaningful data is retained.
> + at item
> +This muxer will not alter the extracted data except to remove invalid
> +packets in between valid CC blocks. On the other hand, ccextractor
> +will by default remove mid-stream padding, and add padding at the end
> +of the stream (in order to convey the end time of the source video).
> + at end enumerate

This part is probably a bit too technical for user documentation,
especially for the details related to the implmentation (which might
change), so probably can/should be left out.

You might keep the link to the file format below though.

[...]

LGTM otherwise.