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

[Tomas Härdin]

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!

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.

/Tomas