sön 2024-02-04 klockan 23:25 -0300 skrev James Almer: > On 2/3/2024 7:00 AM, Tomas Härdin wrote: > > fre 2024-02-02 klockan 16:55 +0100 skrev Jerome Martinez: > > > 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. > > > > Is the decoder really the right place to do this? Surely this > > happens > > with more codecs than just j2k. Isnt it also a parser's job to do > > this > > kind of stuff? > > An AVParser must not split (or assemble) a packet in a form that is > not > meant to be encapsulated in a container.
This is two independent packets that are concatenated. A bsf changes the bits, right? Whereas in this case no changes in the actual data is necessary. Parsers are typically used to split raw essence into packets, right? This is a similar case. A use-case for this kind of splitting could be upping EditRate to 60000/1001 (SampleRate still being 60000/1001), allowing for field- level editing. The resulting MXF would still be SEPARATE_FIELDS. This is mode F1 in the table that pal posted. This ties into the work Anton is doing on interlacing I suspect. /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".
