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-requ...@ffmpeg.org with subject "unsubscribe".
