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

[Jerome Martinez]

Hi, I'm bumping this patch proposal for avoiding a situation where 
FFmpeg skips half the visual content when 2 jpeg2000 codestreams are 
present in one frame. I re-reviewed this discussion and think I answered 
all concerns. I'm hesitant with patch v3 because I consider that 
touching frame_worker_thread for this feature is not so useful but I am 
ok with either patch v2 or v3.
Thanks much,
     Jérôme

On 20/02/2024 16:07, Jerome Martinez wrote:
> Attached is an updated version of the patch proposal.
>
> About the idea to keep separate fields in the output AVFrame, I note 
> from the discussion that it is commonly accepted that up to now it is 
> expected that the AVPacket contains what is in the MXF element and 
> that the AVFrame contains a frame and never a field, and additionally 
> I see in e.g. mpeg12dec.c that the decoder interleaves separate fields:
> mb_y <<= field_pic;
> if (s2->picture_structure == PICT_BOTTOM_FIELD)
>     mb_y++;
> And mpegvideo_parser.c creates a AVPacket with both fields in AVPacket 
> even if they are separated, this patch keeps the AVPacket from e.g. 
> MXF with both fields in it and does something similar to what do other 
> decoders with separate fields in the output AVFRame.
>
> About the detection of the 2 separated fields in 1 packet in the MXF 
> file (I2 mode), it is doable in the example file provided in the first 
> patch proposal to catch it by checking the essence label but other 
> files I have don't have the specific essence label (they use the 
> "undefined" essence label, legit) so IMO we should not rely on it and 
> there is actually no practical advantage in catching that from the 
> container.
>
> In practice this new patch proposal is slightly more complex, with one 
> recursive call to jpeg2000_decode_frame() when there are 2 codestreams 
> in 1 AVPacket, but it has a negligible performance impact (few 
> comparisons and bool checks) when there is only one codestream in the 
> AVPacket (the currently only supported method, remind that currently 
> FFmpeg completely discards the 2nd codestream present in the AVPacket) 
> and it relies on the current jpeg2000_read_main_headers() function for 
> catching the end of the first codestream (safer than the quick find of 
> EOC/SOC in the first version).
>
> It also changes the jpeg2000_decode_frame return value to the count of 
> bytes parsed, it seems that it was what is expected but in practice it 
> was not doing that, fixing the return value could be a separate patch 
> if preferred.
>
> Jérôme
>
> On 02/02/2024 16:55, Jerome Martinez wrote:
>> Before this patch, the FFmpeg MXF parser correctly detects content 
>> with 2 fields in 1 AVPacket as e.g. interlaced 720x486 but the FFmpeg 
>> JPEG 2000 decoder reads the JPEG 2000 SIZ header without 
>> understanding that the indicated height is the height of 1 field only 
>> so overwrites the frame size info with e.g. 720x243, and also 
>> completely discards the second frame, which lead to the decoding of 
>> only half of the stored content as "progressive" 720x243 flagged 
>> interlaced.
>>
>> Example file:
>> https://www.digitizationguidelines.gov/guidelines/MXF_sampleFiles/RDD48-sample12-gf-jpeg2000-ntsc-4.2.zip 
>>
>>
>> Before this patch:
>> Stream #0:0: Video: jpeg2000, yuv422p10le(bottom coded first 
>> (swapped)), 720x243, lossless, SAR 9:20 DAR 4:3, 29.97 tbr, 29.97 
>> tbn, 29.97 tbc
>>
>> After this patch:
>> Stream #0:0: Video: jpeg2000, yuv422p10le(bottom coded first 
>> (swapped)), 720x486, lossless, SAR 9:10 DAR 4:3, 29.97 fps, 29.97 
>> tbr, 29.97 tbn
>>
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".