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 _______________________________________________ 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".
