On Mon, Nov 27, 2023 at 3:05 PM Henrik Gramner via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote: > > On Mon, Nov 27, 2023 at 2:42 PM Mark Thompson <s...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
