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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
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".
_______________________________________________
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".