[FFmpeg-devel] [PATCH, v2] avcodec/amfenc: increase precision of Sleep() on Windows

[Cameron Gutman]

On Mon, Sep 9, 2024 at 6:48 PM Cameron Gutman <aicommander at gmail.com> wrote:
>
> On Mon, Sep 9, 2024 at 11:05 AM Araz <primeadvice at gmail.com> wrote:
> >>
> >> > I took a look at this using AMD's AMF EncoderLatency sample and found that
> >> > setting the QUERY_TIMEOUT option to 50 ms (as is default for the new AMF
> >> > HQ and HQLL usage values) results in latency that is better than the
> >> > current AMF code in FFmpeg *and* this patch without having to touch
> >> > the process's timer precision.
> >> >
> >> > Here are the results from QUERY_TIMEOUT=0, amf_sleep(1), 1ms timer period:
> >> > Encoder: AMFVideoEncoderVCE_AVC
> >> > Total  : Frames = 500 Duration = 1157.16ms FPS = 432.09frames
> >> > Latency: First,Min,Max = 7.12ms, 1.53ms, 3.73ms
> >> > Latency: Average = 1.99ms
> >> >
> >> > and the results from QUERY_TIMEOUT=50, default timer period:
> >> > Encoder: AMFVideoEncoderVCE_AVC
> >> > Total  : Frames = 500 Duration = 933.03ms FPS = 535.89frames
> >> > Latency: First,Min,Max = 5.80ms, 1.49ms, 2.50ms
> >> > Latency: Average = 1.58ms
> >> >
> >> > This seems to clearly demonstrate that QUERY_TIMEOUT is a better approach
> >> > than adjusting timer resolution. It avoids process-wide effects *and*
> >> > it even performs better on top of that.
> >> >
> >> >
> >> > Cameron
> >
> >
> > Thanks everyone and Cameron,
> > TIMEOUT might be a possible solution.
> > Need some time for evaluating the performance impact of using it.
> > The problem is that FFmpeg calls SubmitInput and QueryOutput
> > from the same thread and if B-frames and/or look-ahead enabled, initially
> > not enough input submitted and QueryOutput will wait till timeout value.
>
> Ah I see, I guess we can just replace the fixed 1 ms sleep with a fixed
> 1 ms QUERY_TIMEOUT. We won't get the full power gains of waking exactly
> once per frame when encoding is complete, but it should solve the issue
> of having to wait a full 15.6ms to realize output data is available.
>
> How about something like this?
>

Ugh, email client mangled it. Let's try that again.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: application/octet-stream
Size: 3750 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240909/1174f053/attachment.obj>