Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
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".

  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