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

[Tomas Härdin]

ons 2021-12-08 klockan 02:18 +0100 skrev 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

I suppose we should just try to get a hold of Matthieu then, see if it
breaks any of his stuff

> > 
> > 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.

Perhaps next time I get a major MXF job I'll look into it. Because what
I don't like is the hacks upon hacks that will need to be implemented
in multiple places.

> 
> 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...

Of course. There must at the very least be feature parity. But I will
keep pointing out that we should aim to have less code, not more.
Especially in lavf. The NIH runs deep, and it must be combatted.

For lavc this is less clear because sometimes we get codec
implementations that are better in some aspect. This isn't the case
with lavf.

/Tomas