[FFmpeg-devel] [PATCH] avformat/mxfenc: fix DNxHD GC ULs

[Marton Balint]

On Wed, 8 Dec 2021, Tomas Härdin wrote:

> fre 2021-12-03 klockan 09:38 +0000 skrev Nicolas Gaullier:
>> > Please add a reference to the relevant SMPTE document in the
>> > comment, or perhaps at the list of references at the start of the
>> > file
>> > 
>> > /Tomas
>> 
>> I have added the reference to ST2019-4 for "VC3 mapping", so that
>> should be ok for generic standard files.
>> It seems redundant for me, but if you want, I could add the link to
>> the online register where the container ul is public ?
>> https://registry.smpte-ra.org/apps/pages/
>> 
>> Concerning the essence key, it is more tricky because of AVID in the
>> place...
>> To start with, apart AVID, all frame-wrapped samples I have (I can
>> share them with you but not all of them publicly), do respect the
>> standard
>> - frame-wrapped : ARRI, Adobe Media Encoder, Harmonic : always 0x0C
>> ("DNxHD" frame-mapping)
>> There are up to date publicly available ARRI samples where 0x0C is
>> used here:
>> https://www.arri.com/en/learn-help/learn-help-camera-system/camera-sample-footage
>> 
>> But I also have an AVID Op1a file where the value 0x05 is used
>> ("MPEG" frame-mapping, ie. s381m).
>> And concerning OPAtom, Philip de Nier has an AVID sample where the
>> value 0x06 is used ("MPEG" clip-wrapping).
>> 
>> So, what is apparent at the end is that :
>> - apart from AVID, the standard values 0x0c/0x0d are used
>> - AVID uses the values from the older "MPEG mapping" (ie smpte 381m)
>> 
>> Now :
>> - currently ffmpeg uses 0x05 for OPatom which does not follow any
>> implementation and seems bad
>> - it seems there is a consensus (incl. AVID) to always use 0x05 or
>> 0x0C for frame-wrapping and 0x06 or 0x0d for clip-wrapping (OPAtom)
>> => follow either s381m or st2019-4
>> - it seems clear ffmpeg shall take the "standard-flavor" for generic
>> OP's, so 0x0C for frame-based wrapping
>> - it is less clear about OPAtom which is rather an AVID-hack-thing,
>> but it should be moved to either 0x06 or 0x0d
>> - I have discussed this with philip de nier, and bmx (a reference
>> software in my opinion) will stick to the AVID form, so 0x06. And I
>> think it is reasonable, since OPAtom/Avid are almost the same damn
>> thing
>> 
>> Note: no matter the essence key, the link between the tracks and the
>> body with the TrackNumber always work, so it seems there are not much
>> interoperability issues with it.
>
> Seems I missed the reference to the VC-3 spec somehow, sorry. Since it
> is Matthieu Bouron who added this initially, you should really talk to
> him. I care less about mxfenc than I do mxfdec, since the latter can
> more easily induce CVEs.
>
> That said, if we want this to work correctly for everyone then we need
> a proper set of tests. We also need to go over all the specs, and what
> all implementations are currently doing. Which is a lot of work. Or a
> lot of billable hours!

Nicolas already made a reasonable investigation, so I am not sure what 
else is required. FWIW there is also a trac ticket with this issue:

https://trac.ffmpeg.org/ticket/6380

>
> This is why I've said for years now that we should delete mxfenc and
> just bring in bmx. We don't need what little free software people there
> are who know MXF to keep maintaining two codebases.
>
> We could just bring in bmx as a subtree and be done with it. Delete all
> MXF code native to FFmpeg, put all effort into bmx. People in this
> project suffer from the belief that code is valuable rather than a
> liability. Worse is not better. Correct is better.

Tested and polished code is valuable, and I think you underestimate the 
work required to integrate bmxlib as an mxf muxer. If somebody starts 
working on it, great. I certainly won't oppose it to add it as an 
alternate way to mux MXF files.

But also keep in mind that ffmpeg tends to prefer native components, and 
the external library (and its integration to ffmpeg) has to be superior in 
every way to even think about dropping the native one...

Regards,
Marton