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

[Evgeny Pavlov]

On Mon, Nov 27, 2023 at 3:05 PM Henrik Gramner via ffmpeg-devel
<ffmpeg-devel at ffmpeg.org> wrote:
>
> On Mon, Nov 27, 2023 at 2:42 PM Mark Thompson <sw at jkqxz.net> wrote:
> > Is it reasonable to set this global state from a library without the parent program knowing?  We'd really prefer not to affect the global state unexpectedly.
>
> CreateWaitableTimerExW() with the
> CREATE_WAITABLE_TIMER_HIGH_RESOLUTION flag might be an alternative?
>

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."

We provide the following measurement to show performance improvements
with this patch.

1. Performance tests show that this high precision sleep will improve
performance, especially for low resolution sequences, it can get about
20% improvement.

Frames Per Second (FPS) being encoded by the hardware encoder (Navi 31
RX7900XT ):

Source Type: H.264 ,  Output Type: H.264
(Sorry for bad formatting)
No. |   Sequence Resolution | No. of Frames|    FPS Before patch    |
FPS after patch   | Difference    | Improvement %
----|-----------------------|--------------|------------------------|-------------------|---------------|----------
1   |   480x360             | 8290         |        2030            |
     2365        | 335           | 16.5%
2   |   720x576             | 8290         |        1440            |
     1790        | 350           | 24.3%
3 |     1280x720            | 8290         |        1120            |
     1190        | 70            | 6.3%
4   |   1920x1080           | 8290         |        692             |
     714         | 22            | 3.2%
5   |   3840x2160           | 8290         |        200             |
     200         | 0             | 0.0%

The sample ffmpeg command line:
$ ffmpeg.exe -y -hwaccel d3d11va -hwaccel_output_format d3d11 -i
input.mp4 -c:v h264_amf out.mp4
where input.mp4 should be changed to corresponding resolution input
H.264 format bitstream.

2. The power tests show an increase in power is within limit scope.

The purpose of the power test is to examine the increase in CPU power
consumption due to the improvement in CPU time resolution after using
this patch. We were testing a product from AMD called Phoenix, which
we refer to as an APU. It combines a general-purpose AMD CPU and a 3D
integrated graphics processing unit (IGPU) on a single die. Only the
APU has a DAP connector to the board's power rails.

We got the power test data shown below:

|                        | 480x360   |  720x576   | 1280x720 |
1920x1080 | 3840x2160 | average
|------------------------|-----------|------------|----------|-----------|-----------|--------
|CPU  power change       |  1.93%    |  2.43%     | -1.69%   | 3.49%
  | 2.92%     | 1.82%
|APU power total change  |  0.86%    |  1.34%     | -0.62%   | 1.54%
  | -0.58%    | 0.51

When using a high precision clock by applying the patch, the average
power consumption for CPU increases 1.82%, and the APU total increases
0.51%. We can see the power increase in power not very significant.