From: Jerome Martinez <jerome@mediaarea.net>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v2] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket
Date: Wed, 24 Apr 2024 13:20:02 +0200
Message-ID: <309dc932-eca9-42a6-a0b8-97827065647c@mediaarea.net> (raw)
In-Reply-To: <e4f6cc0d-948a-49ab-bf03-6a4191d85975@mediaarea.net>
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-request@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-request@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-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2024-04-24 11:20 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 15:55 [FFmpeg-devel] [PATCH] " Jerome Martinez
2024-02-03 10:00 ` Tomas Härdin
2024-02-03 10:51 ` Jerome Martinez
2024-02-03 19:58 ` Tomas Härdin
2024-02-03 20:04 ` Tomas Härdin
2024-02-04 0:20 ` Pierre-Anthony Lemieux
2024-02-05 0:19 ` Tomas Härdin
2024-02-15 15:02 ` Jerome Martinez
2024-02-16 0:02 ` Vittorio Giovara
2024-02-16 2:17 ` Kieran Kunhya
2024-02-18 23:14 ` Tomas Härdin
2024-02-19 11:08 ` Tomas Härdin
2024-02-19 11:19 ` Jerome Martinez
2024-02-16 10:32 ` Anton Khirnov
2024-02-18 23:43 ` Marton Balint
2024-02-19 8:22 ` Hendrik Leppkes
2024-02-19 16:14 ` Devin Heitmueller
2024-02-19 11:05 ` Tomas Härdin
2024-02-19 11:07 ` Tomas Härdin
2024-02-05 2:25 ` James Almer
2024-02-05 14:28 ` Tomas Härdin
2024-02-20 15:07 ` [FFmpeg-devel] [PATCH v2] " Jerome Martinez
2024-02-21 13:11 ` Tomas Härdin
2024-02-21 14:27 ` Jerome Martinez
2024-02-24 12:26 ` Tomas Härdin
2024-02-25 4:14 ` [FFmpeg-devel] [PATCH v3] " Jerome Martinez
2024-03-01 22:29 ` Tomas Härdin
2024-03-03 17:07 ` Jerome Martinez
2024-04-24 11:20 ` Jerome Martinez [this message]
2024-04-24 22:54 ` [FFmpeg-devel] [PATCH v2] " Tomas Härdin
2024-04-25 0:59 ` Michael Niedermayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=309dc932-eca9-42a6-a0b8-97827065647c@mediaarea.net \
--to=jerome@mediaarea.net \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git