This is unacceptable behavior for maintainer. On Wed, Dec 8, 2021 at 12:13 AM Tomas Härdin <tjop...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ 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".
