Re: [FFmpeg-devel] what AVCodecID to use for copying full vanc data between .mxf and .mcc

["Tomas Härdin" <git@haerdin.se>]

mån 2025-07-07 klockan 21:12 -0700 skrev Jacob Lifshay:
> I'm currently writing a .mcc muxer, it currently translates from eia-
> 608/708 to full vanc packets before outputting a .mcc file:
> https://github.com/programmerjake/FFmpeg/tree/add-mcc-mux
> 
> I want to add the ability to the mxf and mcc muxers/demuxers to keep
> the full vanc data when doing stream copies, what do you think is the
> best way to do that?

Stream copy should be easy enough. I'm not sure whether BSFs is the way
to go in the long run, since full ANC support may require dealing with
full uncropped frames and the ability to encode/decode VBI data. We
also currently lack proper 608/708 support, so I'm not sure what the
utility of converting from 436M to 608 is as things stand at the
moment. Also horizontal ANC data exists. Stream copying 436M sounds
reasonable enough.

Consider some potential use cases:

* copying 436M data from MXF to MXF
* decoding 8-bit 436M data to 1-bit data
* "encoding" (rendering) 1-bit 436M data to 8-bit data
* extracting teletext data from 436M and rendering it
* combining 436M and video essence to a full frame for playout
* embedding/de-embedding 608/708 CC:s and transcoding to/from regular
subtitles
* "encoding" subtitles as teletext, then embedding the resulting ANC
data in whatever way is appropriate (as video samples, as 436M data or
whatever)
* possibly some cursed combination of all of the above, like doing
teletext and closed captions at the same time

> * add a new AVCodecID for mxf vbi_vanc_smpte_436M
> * change the muxers/demuxers to be able to use AV_CODEC_ID_SMPTE_KLV
> or AV_CODEC_ID_SMPTE_2038 (they hold the full vanc packets, right?)

Having key and length as part of the "essence" for these types of
streams sounds wrong and cursed. Shouldn't we do the same thing we do
for audio and video, and convert either to some common format?
Otherwise, wouldn't we need to write BSFs for the outer product of
every type of ANC "codec"? Perhaps the way subtitles are handled is the
way to go, where there are two categories of subs (text and bitmap).

> additionally, it'd be nice to be able to output a eia-608/708 stream
> to mxf, so that would either need a codec/filter of some sort to
> translate to full vanc data in whatever format the mxf muxer ends up
> supporting, or to have that translation built-in to the mxf muxer,
> like it is built-in to the mxf demuxer (with eia608_extract).

There's more than one way to skin this cat with MXF. You can either put
the 608/708 data in the video essence and set the cropping information
appropriately, or as 436M packets, or inside the H.264 packets as SEI
messages. Or all three at the same time.

It's unfortunate that libav* has chosen to separate audio and video,
rather than carrying them as combined edit units as libmlt does, into
which we could also slip ANC data, subtitles or whatever.

/Tomas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".