> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Mark Thompson > Sent: Wednesday, August 21, 2019 04:49 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavf/vf_deinterlace_vaapi: flush > queued frame in field mode > > On 02/08/2019 10:53, Linjie Fu wrote: > > Add deint_vaapi_request_frame for deinterlace_vaapi, send NULL frame > > to flush the queued frame. > > > > Fix the frame drop issue in field mode: > > > > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -v verbose -c:v > > h264 -i ./input.h264 -vf 'format=nv12|vaapi,hwupload, > > deinterlace_vaapi=mode=bob:rate=field,hwdownload,format=nv12' > > -pix_fmt yuv420p -f rawvideo -vsync passthrough -y dump.yuv > > > > Signed-off-by: Linjie Fu <linjie...@intel.com> > > --- > > libavfilter/vf_deinterlace_vaapi.c | 46 > ++++++++++++++++++++++++++++++++------ > > 1 file changed, 39 insertions(+), 7 deletions(-) > > Can you explain in more detail what the problem is here? What frame is > being dropped?
For DeinterlacingBob mode with rate=field, the frame number of output should equal 2x input total since only intra deinterlace is used. Currently for "pipeline_caps.num_backward_references, rate = field", extra_delay is introduced. Due to the async without flush, frame number of output is [expected_number - 2]. Specifically, if the input only has 1 frame, the output will be empty. For 1 frame input in Bob mode with rate=field, before patch: 0 frame; after patch: 2 frames; > > I already get the expected number of frames out with both rate settings > (input total - forward references - backward references, all multiplied by 2 > for field rate output). E.g. for 100 frames/field-pairs of input: > > $ ./ffmpeg_g -hwaccel vaapi -hwaccel_device /dev/dri/renderD129 - > hwaccel_output_format vaapi -i f100.mp4 -an -vf > deinterlace_vaapi=rate=frame -f null - > ... > frame= 97 > > $ ./ffmpeg_g -hwaccel vaapi -hwaccel_device /dev/dri/renderD129 - > hwaccel_output_format vaapi -i f100.mp4 -an -vf > deinterlace_vaapi=rate=field -f null - > ... > frame= 194 > > (With forward = 2, backward = 1.) Which driver is used for this test? I've verified with i965 and iHD on linux and failed to find the matched pipeline_cap with num_forward_reference = 2, num_backward_reference = 1; For iHD: #define DDI_CODEC_NUM_FWD_REF 0; #define DDI_CODEC_NUM_BK_REF 0; num_forward_reference = DDI_CODEC_NUM_FWD_REF; num_backward_reference = DDI_CODEC_NUM_BK_REF; https://github.com/intel/media-driver/blob/b9606584bf3dc6937047b4f19e08c75f88bd95a4/media_driver/linux/common/ddi/media_libva.cpp#L5687 For i965: num_forward_reference ++; (if working on MotionAdaptive or MotionCompensated) num_backward_reference = 0; https://github.com/intel/intel-vaapi-driver/blob/9bc30a0231e55f17afed50589669d11e844d0bb9/src/i965_drv_video.c#L7158 > > With this patch applied, the filter always segfaults for me at the end of the > stream when set to field rate: > > $ gdb --args ./ffmpeg_g -hwaccel vaapi -hwaccel_device > /dev/dri/renderD129 -hwaccel_output_format vaapi -i f100.mp4 -an -vf > deinterlace_vaapi=rate=field -f null - > ... > Thread 1 "ffmpeg_g" received signal SIGSEGV, Segmentation fault. > 0x0000555555755fb1 in deint_vaapi_filter_frame (inlink=0x555559092300, > input_frame=0x555558d42000) at src/libavfilter/vf_deinterlace_vaapi.c:227 > 227 ctx->frame_queue[current_frame_index + i + 1]->data[3]; > (gdb) bt > #0 0x0000555555755fb1 in deint_vaapi_filter_frame (inlink=0x555559092300, > input_frame=0x555558d42000) at src/libavfilter/vf_deinterlace_vaapi.c:227 > #1 0x00005555557565d2 in deint_vaapi_request_frame > (link=0x5555590928c0) at src/libavfilter/vf_deinterlace_vaapi.c:342 > #2 0x00005555556ce950 in ff_request_frame_to_filter (link=0x5555590928c0) > at src/libavfilter/avfilter.c:458 > #3 0x00005555556d0cd0 in forward_status_change (filter=0x555559088940, > in=0x555559092300) at src/libavfilter/avfilter.c:1243 > #4 0x00005555556d0eaf in ff_filter_activate_default (filter=0x555559088940) > at src/libavfilter/avfilter.c:1274 > #5 0x00005555556d0fec in ff_filter_activate (filter=0x555559088940) at > src/libavfilter/avfilter.c:1430 > #6 0x00005555556d5d29 in ff_filter_graph_run_once (graph=0x55555908ff00) > at src/libavfilter/avfiltergraph.c:1456 > #7 0x00005555556d71d8 in push_frame (graph=0x55555908ff00) at > src/libavfilter/buffersrc.c:187 > #8 0x00005555556d77a9 in av_buffersrc_close (ctx=0x555559091ac0, > pts=300300, flags=4) at src/libavfilter/buffersrc.c:275 > #9 0x000055555569356a in ifilter_send_eof (ifilter=0x5555580d0e40, > pts=300300) at src/fftools/ffmpeg.c:2213 > #10 0x00005555556949fd in send_filter_eof (ist=0x5555580f3ac0) at > src/fftools/ffmpeg.c:2562 > #11 0x0000555555695336 in process_input_packet (ist=0x5555580f3ac0, > pkt=0x0, no_eof=0) at src/fftools/ffmpeg.c:2701 > #12 0x000055555569a9db in process_input (file_index=0) at > src/fftools/ffmpeg.c:4313 > #13 0x000055555569c5f9 in transcode_step () at src/fftools/ffmpeg.c:4638 > #14 0x000055555569c726 in transcode () at src/fftools/ffmpeg.c:4692 > #15 0x000055555569cfb6 in main (argc=15, argv=0x7fffffffe488) at > src/fftools/ffmpeg.c:4894 > (gdb) p current_frame_index > $1 = 2 > (gdb) p i > $2 = 0 > (gdb) p ctx->frame_queue[current_frame_index + i + 1] > $3 = (AVFrame *) 0x0 > The last frame required a backward_reference which is not existed. It seems that the flush is redundant under this condition (pipeline_caps.num_backward_reference > 0). A possible solution is to flush the queue only when extra_delay is needed for timestamps.(Not verified yet since couldn't got the same pipeline_caps environment ) New patch will be sent later. - linjie _______________________________________________ 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".
