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

[Cameron Gutman]

On Wed, Aug 21, 2024 at 12:02 PM Kieran Kunhya via ffmpeg-devel
<ffmpeg-devel at ffmpeg.org> wrote:
>
> On Mon, Aug 19, 2024 at 7:31 PM Timo Rothenpieler <timo at rothenpieler.org> wrote:
> >
> > On 19.08.2024 16:23, Araz Iusubov wrote:
> > > From: Evgeny Pavlov <lucenticus at gmail.com>
> > >
> > > This commit increase precision of Sleep() function on Windows.
> > > This fix reduces the sleep time on Windows to improve AMF encoding
> > > performance on low resolution input videos.
> > >
> > > Fix for issue #10622
> > >
> > > We evaluated CreateWaitableTimerExW with
> > > CREATE_WAITABLE_TIMER_HIGH_RESOLUTION flag. In fact, this function has
> > > the same precision level as the Sleep() function.
> > >
> > > Usually changing the time resolution will only affect the current
> > > process and will not impact other processes, thus it will not cause a
> > > global effect on the current system. Here is an info from
> > > documentation on timeBeginPeriod
> > > https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod
> > >
> > > "Prior to Windows 10, version 2004, this function affects a global
> > > Windows setting. For all processes Windows uses the lowest value (that
> > > is, highest resolution) requested by any process. Starting with
> > > Windows 10, version 2004, this function no longer affects global timer
> > > resolution. For processes which call this function, Windows uses the
> > > lowest value (that is, highest resolution) requested by any process.
> > > For processes which have not called this function, Windows does not
> > > guarantee a higher resolution than the default system resolution."
> >
> > Even modifying the current process is not acceptable, since lavc is
> > frequently embedded in other applications, which might not expect
> > this/be aversely impacted by it.
> >
> > Why does the AMF wrapper need to sleep at all?
>
> Agreed, we can't have things like this in FFmpeg. This might be
> acceptable in a binary blob but not in an open source project.

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