On 5/8/2018 8:49 PM, Mark Thompson wrote: > Ah. I should have thought of this problem earlier - testing this patch, it > this breaks the VAAPI encoders because the parameter set structures there are > not reference counted (and shouldn't be - they are pointers to substructures > of the encoder context). > > $ gdb --args ./ffmpeg_g -y -i in.mp4 -an -vaapi_device /dev/dri/renderD128 > -vf 'format=nv12,hwupload' -c:v h264_vaapi out.h264 > ... > Thread 1 "ffmpeg_g" received signal SIGSEGV, Segmentation fault. > 0x00005555569bf65a in av_buffer_ref (buf=0x0) at src/libavutil/buffer.c:100 > 100 *ret = *buf; > (gdb) bt > #0 0x00005555569bf65a in av_buffer_ref (buf=0x0) at > src/libavutil/buffer.c:100 > #1 0x00005555564cd2ec in cbs_h264_replace_sps (ctx=0x555558dbee40, > unit=0x555558dbde40) at src/libavcodec/cbs_h2645.c:700 > #2 0x00005555564ce12f in cbs_h264_write_nal_unit (ctx=0x555558dbee40, > unit=0x555558dbde40, pbc=0x7fffffffcf90) at src/libavcodec/cbs_h2645.c:1006 > #3 0x00005555564ce943 in cbs_h2645_write_nal_unit (ctx=0x555558dbee40, > unit=0x555558dbde40) at src/libavcodec/cbs_h2645.c:1258 > #4 0x000055555649fd96 in ff_cbs_write_fragment_data (ctx=0x555558dbee40, > frag=0x5555590da450) at src/libavcodec/cbs.c:284 > #5 0x0000555556016784 in vaapi_encode_h264_write_access_unit > (avctx=0x5555581ce800, data=0x7fffffffd0c0 "\020\321\377\377\377\177", > data_len=0x7fffffffd4c0, au=0x5555590da450) at > src/libavcodec/vaapi_encode_h264.c:109 > #6 0x00005555560169f8 in vaapi_encode_h264_write_sequence_header > (avctx=0x5555581ce800, data=0x7fffffffd0c0 "\020\321\377\377\377\177", > data_len=0x7fffffffd4c0) at src/libavcodec/vaapi_encode_h264.c:171 > #7 0x00005555566e87e3 in ff_vaapi_encode_init (avctx=0x5555581ce800) at > src/libavcodec/vaapi_encode.c:1533 > #8 0x00005555560194f1 in vaapi_encode_h264_init (avctx=0x5555581ce800) at > src/libavcodec/vaapi_encode_h264.c:971 > #9 0x0000555556006218 in avcodec_open2 (avctx=0x5555581ce800, > codec=0x555557937300 <ff_h264_vaapi_encoder>, options=0x5555581d0a18) at > src/libavcodec/utils.c:923 > #10 0x000055555567a655 in init_output_stream (ost=0x5555581d08c0, > error=0x7fffffffd8c0 "", error_len=1024) at src/fftools/ffmpeg.c:3485 > #11 0x000055555567269e in reap_filters (flush=0) at src/fftools/ffmpeg.c:1442 > #12 0x000055555567e88e in transcode_step () at src/fftools/ffmpeg.c:4587 > #13 0x000055555567e955 in transcode () at src/fftools/ffmpeg.c:4631 > #14 0x000055555567f1e5 in main (argc=12, argv=0x7fffffffe498) at > src/fftools/ffmpeg.c:4838 > > > Maybe if content_ref isn't set inside cbs_h26n_replace_xps() then make a new > buffer with that reference? That still has the dangling pointer problem, > though no current user will set any of those fields.
Figures. I knew content_ref could technically be NULL, but i couldn't find any such case within cbs or the bsfs, nor test vaapi. I'll implement your suggestion, then. > > Thanks, > > - Mark > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
