[FFmpeg-devel] [PATCH] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

[Tomas Härdin]

mån 2024-02-19 klockan 00:14 +0100 skrev Tomas Härdin:
> tor 2024-02-15 klockan 16:02 +0100 skrev Jerome Martinez:
> > On 05/02/2024 01:19, Tomas Härdin wrote:
> > > [...]
> > > Which entry in the table would the provided file correspond to?
> > > To
> > > me
> > > it seems none of them fit. There's two fields, meaning two j2k
> > > codestreams, in each corresponding essence element KLV packet (I
> > > think,
> > > unless CP packets get reassembled somewhere else). Entry I2 seems
> > > closest but it specifies FULL_FRAME. I1 is otherwise tempting,
> > > but
> > > there SampleRate should equal the field rate whereas the file has
> > > SampleRate = 30000/1001.
> > 
> > Other examples I have (not shareable) with 2 jp2k pictures per KLV
> > have 
> > identification from an old version of AmberFin iCR, I have no file
> > with 
> > the I2 correctly signaled, with my first example it isI2 (2 fields
> > per 
> > KLV) with I1 Header Metadata Property Values **but** with I2
> > essence 
> > container label which has a content byte (byte 15 of the UL) of
> > 0x04
> > = I2.
> > The AmberFin iCR files have the generic essence container label
> > with 
> > content byte of 0x01 = FU (Unspecified) so for my main use case we
> > could 
> > activate the search of the 2nd jp2k only if I2 is explicitly
> > signaled
> > by 
> > the essence container label but it would prevent to catch the 2nd
> > field 
> > when this signaling is unspecified and buggy Frame layout + sample
> > rate 
> > + edit rate.
> 
> I'm not super stoked about implementing support for broken muxers.
> Instead these companies should fix their code. But either way we at
> the
> very least need a reliable way to detect these kinds of files if we
> are
> to do this. There was no Software + Version information in the sample
> provided, which is otherwise a reliable method to deal with shitty
> muxers.

Correction: there is Identification metadata, but it's at the end of
the header metadata so I missed it.

    Identifications
      Identification = {fb8e5be0-1fc5-11e9-8263-7062b8a31e5c}
      Identification -> Strong Reference to Identification
        Identification
          InstanceUID = {fb8e5be0-1fc5-11e9-8263-7062b8a31e5c}
          ThisGenerationUID = {fb8e5be0-1fc5-11e9-8264-7062b8a31e5c}
          CompanyName = OpenCube
          ProductName = MXFTk Advanced
          ProductUID = {3a4fe380-0d01-11e4-869f-3cd92b5c1dfc}
          VersionString = 2.7.0.20190123
          ProductVersion = Major="2", Minor="7", Patch="0", Build="0",
Release="VersionReleased"
          ToolkitVersion = Major="2", Minor="7", Patch="0", Build="0",
Release="VersionReleased"
          Platform = Microsoft Windows 7 Professional Service Pack 1
(Build 7601)
          ModificationDate = 2019-01-24 11:51:37.884
    LastModifiedDate = 2019-01-24 11:51:37.884
    GenerationUID = {fb8e5be0-1fc5-11e9-8264-7062b8a31e5c}

This at least (maybe) allows us to detect these broken files. But does
MXFTk *always* write interlaced files like this?

/Tomas