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

[Paul B Mahol]

This is unacceptable behavior for maintainer.

On Wed, Dec 8, 2021 at 12:13 AM Tomas Härdin <tjoppen at acc.umu.se> 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!
>
> 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
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>