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

[Jerome Martinez]

On 19/02/2024 12:08, Tomas Härdin wrote:
> 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.

Same.


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

Beside the fact we don't know the version, I have files from other 
muxers having the same issue.

In practice:
- For the example file, no need to check identification, as said 
previously essence container label provides I2 tip, so I could propagate 
I2 tip to the jp2k decoder
- But if we limit to that, some other files in the wild won't be 
recognized because essence container label stipulates (legally) 
unspecified and (out of spec but it is real) have the same issue with 
frame layout.

If I understood correctly the other comments an AVPacket should be a MXF 
element so the MXF parser should not split the packet.
I am preparing a v2 patch which does not include the extra probe, 
relying on current jp2k parser for catching the 2nd field, so in my 
opinion there is not value added to try to catch I2 including buggy 
muxers in MXF.

Jérôme