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

Matthieu Bouron matthieu.bouron at gmail.com
Tue Dec 14 12:54:24 EET 2021


On Tue, Dec 14, 2021 at 10:41:27AM +0100, Matthieu Bouron wrote:
> On Tue, Nov 30, 2021 at 10:22:20AM +0100, Nicolas Gaullier wrote:
> > Fix GC container ul.
> > Fix GC element type both for the generic case and for OPAtom.
> > 
> > Thanks to Philip de Nier <philip.denier at bbc.co.uk>
> > for checking the values, especially for OPAtom.
> > ---
> >  libavformat/mxfenc.c      | 8 ++++++--
> >  tests/ref/lavf/mxf_opatom | 2 +-
> >  2 files changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > index fcd9afda2a..38de3d1ab5 100644
> > --- a/libavformat/mxfenc.c
> > +++ b/libavformat/mxfenc.c
> > @@ -32,6 +32,7 @@
> >   * SMPTE 379M MXF Generic Container
> >   * SMPTE 381M Mapping MPEG Streams into the MXF Generic Container
> >   * SMPTE 422M Mapping JPEG 2000 Codestreams into the MXF Generic Container
> > + * SMPTE ST2019-4 Mapping VC-3 Coding Units into the MXF Generic Container
> >   * SMPTE RP210: SMPTE Metadata Dictionary
> >   * SMPTE RP224: Registry of SMPTE Universal Labels
> >   */
> > @@ -181,8 +182,8 @@ static const MXFContainerEssenceEntry mxf_essence_container_uls[] = {
> >        { 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x00,0x00,0x00 },
> >        mxf_write_cdci_desc },
> >      // DNxHD
> > -    { { 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00 },
> > -      { 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00 },
> > +    { { 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00 },
> 
> Can the chunk fixing the container UL be put in a separate commit (I just
> checked the spec and it is fine) ?
> 
> > +      { 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x0C,0x00 },
> 
> It only have access to ST2019-4 (2008) and it mentions two possible value
> for the essence element type:
> - 0x05 frame wrapped picture element
> - 0x06 clip wrapped picture element
> 
> Is 0x0C introduced in a later revision of ST2019 ?

So after an offline discussion with Nicolas and Philip, it turns out, the
values for the essence element type were updated from 0x05/0x06 to
0x0C/0x0D in the 2009 revision of ST2019-4 (and they are still current as
of the latest revision of the spec).

So I'm fine with the change from 0x05 to 0x0C and the AVID hack (using
0x06 instead of 0x0D) as it is what BMX is doing. Can you please add a
comment regarding the AVID hack and why we are not using 0x0D ?

[...]

Thanks,
Matthieu


More information about the ffmpeg-devel mailing list