Since commit 89ffcd1, the status pts of the output link is set to a value in the input link time base, not in the output link time base when EOF is reached. Usually this pst value is larger than the required one because the output link time base is more greater than the input link time base. When "-vf vpp_qsv,fps" is used, user has to wait a long time for the ending of the pipeline because fps filter output a huge number of frames until the wrong status pts is hit. The issue can be triggered with the command below (use a clip with 1000 frames in this case): $> time ffmpeg -hwaccel qsv -c:v hevc_qsv -i input.h265 -vf "vpp_qsv=w=1920:h=1080,fps=fps=30" -f null - ... [out_0_0 @ 0x564ccd27e020] 10000000 buffers queued in out_0_0, something may be wrong. frame=40119596 fps=88080 q=-0.0 Lsize=N/A time=371:28:39.96 bitrate=N/A speed=2.94e+03x video:17238889kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown real 9m7.451s user 2m34.102s sys 0m39.734s In order to avoid the above issue, the same time base for input and ouput links is used in this patch. Fixes ticket #9286
Showing the changes to libavfilter (1 of 1 file). Show all
Unified · Split
| @@ -303,7 +303,7 @@ static int config_output(AVFilterLink *outlink) · 302 unmodified lines | ||
| 303 | 303 | outlink->w = vpp->out_width; |
| 304 | 304 | outlink->h = vpp->out_height; |
| 305 | 305 | outlink->frame_rate = vpp->framerate; |
| 306 | − outlink->time_base = av_inv_q(vpp->framerate); | |
| 306 | + outlink->time_base = inlink->time_base; | |
| 307 | 307 | |
| 308 | 308 | param.filter_frame = NULL; |
| 309 | 309 | param.num_ext_buf = 0; |