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.rheinha...@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.
signature.asc
Description: PGP signature
_______________________________________________ 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".