Opened 8 months ago

Last modified 6 months ago

#10476 new defect

Regression: vpp_qsv and scale_qsv issues maintaining pts

Reported by: Steve Browne Owned by:
Priority: normal Component: avfilter
Version: 6.0 Keywords: scale_qsv vpp_qsv
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Summary of the bug:
After upgrading from ffmpeg 5.1.3 to ffmpeg 6.0 the pts values from our calls to av_buffersink_get_frame are always 0. We're expecting the output pts values to match input pts values since we don't do any framerate or time_base conversion.

How to reproduce:

Graph Desc: scale_qsv=w=640:h=360
Input Args: video_size=1920x1080:pix_fmt=114:time_base=1/90000

Simplified psuedo-code:

// Setup the graph

// Input frames

// Recieve output frames

I was able to workaround this, but it's a bit gross in my opinion. Basically you need the outlink time_base in vf_vpp_qsv.c to match your input time_base, but there's no way to set that. It's hard-coded to always be the inverse of the vpp framerate. So instead you have to set the framerate in your graph description to the inverse of your input time_base. Ours happens to match the hard-coded default_tb (1/90000) in qsvvpp.c, but if it didn't then it may potentially have rounding errors converting to default_tb then back to your desired time_base.

The conversion happens in qsvvpp.c on this line:

out_frame->frame->pts = av_rescale_q(out_frame->surface.Data.TimeStamp,
                                             default_tb, outlink->time_base);

The modified parameters with the framerate to workaround this are:

Graph Desc: vpp_qsv=w=640:h=360:framerate=90000
Input Args: video_size=1920x1080:pix_fmt=114:time_base=1/90000:frame_rate=90000

Change History (2)

comment:2 by Steve Browne, 6 months ago

Yes I can confirm that patch resolves the issue I was seeing.

Note: See TracTickets for help on using tickets.