[FFmpeg-devel] [PATCH 31/57] avcodec/mpegpicture: Split MPVPicture into WorkPicture and ordinary Pic

Michael Niedermayer michael at niedermayer.cc
Tue Apr 30 21:57:42 EEST 2024


On Mon, Apr 29, 2024 at 11:14:12PM +0200, Andreas Rheinhardt wrote:
> There are two types of MPVPictures: Three (cur_pic, last_pic, next_pic)
> that are directly part of MpegEncContext and an array of MPVPictures
> that are separately allocated and are mostly accessed via pointers
> (cur|last|next)_pic_ptr; they are also used to store AVFrames in the
> encoder (necessary due to B-frames). As the name implies, each of the
> former is directly associated with one of the _ptr pointers:
> They actually share the same underlying buffers, but the ones
> that are part of the context can have their data pointers offset
> and their linesize doubled for field pictures.
> 
> Up until now, each of these had their own references; in particular,
> there was an underlying av_frame_ref() to sync cur_pic and cur_pic_ptr
> etc. This is wasteful.
> 
> This commit changes this relationship: cur_pic, last_pic and next_pic
> now become MPVWorkPictures; this structure does not have an AVFrame
> at all any more, but only the cached values of data and linesize.
> It also contains a pointer to the corresponding MPVPicture, establishing
> a more natural relationsship between the two.
> This already means that creating the context-pictures from the pointers
> can no longer fail.
> 
> What has not been changed is the fact that the MPVPicture* pointers
> are not ownership pointers and that the MPVPictures are part of an
> array of MPVPictures that is owned by a single AVCodecContext.
> Doing so will be done in a latter commit.
> 
> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at outlook.com>

segfaults

[vc1 @ 0xa0c81c0] Failed to open codec in avformat_find_stream_info
==840294== Invalid read of size 4
==840294==    at 0xDB91F4: ff_vc1_mc_4mv_chroma4 (vc1_mc.c:893)
==840294==    by 0xDA4FD8: vc1_decode_p_mb_intfr (vc1_block.c:1661)
==840294==    by 0xDAD9CD: vc1_decode_p_blocks (vc1_block.c:2831)
==840294==    by 0xDAE6A4: ff_vc1_decode_blocks (vc1_block.c:2996)
==840294==    by 0xDC5EFB: vc1_decode_frame (vc1dec.c:1304)
==840294==    by 0x99B6D2: decode_simple_internal (decode.c:412)
==840294==    by 0x99BBFB: decode_simple_receive_frame (decode.c:582)
==840294==    by 0x99BD7F: decode_receive_frame_internal (decode.c:611)
==840294==    by 0x99C135: avcodec_send_packet (decode.c:702)
==840294==    by 0x66BE65: try_decode_frame (demux.c:2156)
==840294==    by 0x66EB84: avformat_find_stream_info (demux.c:2840)
==840294==    by 0x24F991: ifile_open (ffmpeg_demux.c:1707)
==840294==    by 0x278387: open_files (ffmpeg_opt.c:1206)
==840294==    by 0x27854A: ffmpeg_parse_options (ffmpeg_opt.c:1246)
==840294==    by 0x28CBF7: main (ffmpeg.c:941)
==840294==  Address 0x9c is not stack'd, malloc'd or (recently) free'd

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Some people wanted to paint the bikeshed green, some blue and some pink.
People argued and fought, when they finally agreed, only rust was left.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240430/37f0e91e/attachment.sig>


More information about the ffmpeg-devel mailing list