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

[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.

Always inserting a parser worsens performance, and dealing with j2k is
already very taxing. I've been working hard on ||izing j2kdec, and
adding more serial code would make that harder.

> On 03/02/2024 20:58, Tomas Härdin wrote:
> > The fastest way, in a player, is probably to do it with a shader.
> > That
> > should be the least amount of copies and the most cache coherent.
> 
> As far a I know the player is not aware that the AVFrame actually 
> contains a field so it can not apply a shader or something else,
> which 
> AVFrame field indicates that this is a a field to be interleaved with
> the next AVFrame before display?
> Currently for I1 files ffplay or VLC show double rate half height so
> it 
> seems that they don't catch that AVFrame contains a field.

There might be no way to do this at present, as Anton's reply
indicates.

Proper support for FrameLayout may require adding a bunch of fields to
AVFrame and/or AVCodecContext.

We could of course always convert to MIXED_FIELDS and just say that's
the way FFmpeg does things. Anyone who wants to do anything more fancy
is free to provide a patch or sufficient money. The present situation
where the other field is just discarded entirely is of course not
satisfactory either.

/Tomas