[FFmpeg-trac] #6975(ffplay:closed): Recent change to sync video output to screen refresh conflicts with -noframedrop

FFmpeg trac at avcodec.org
Tue Jan 23 09:33:53 EET 2018

#6975: Recent change to sync video output to screen refresh conflicts with
             Reporter:  Misaki      |                    Owner:
                 Type:  defect      |                   Status:  closed
             Priority:  normal      |                Component:  ffplay
              Version:  git-master  |               Resolution:  invalid
             Keywords:              |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |

Comment (by Misaki):

 Another update to this closed ticket that, like probably every other issue
 I've reported that wasn't already fixed (manual page was already fixed),
 won't get fixed!

 Setting vblank_mode=0 does not entirely fix everything. I still can't play
 1080p 60fps video in realtime, with -noframedrop.

 Why this won't get fixed:
 1) It only affects video playback at some border of performance. People
 with recent computers might be able to play 3840x2160 video at 60 fps
 without running into whatever issue I have.
 2) It only affects -noframedrop, which is not the default.

 A random, existing 1080p, 60fps h.264 video with High profile at 3200 kb/s
 performs slightly better than a completely black video at 28 kb/s.

 The random high bitrate video took 11.15 seconds to play with option '-t
 10', ending with A-V at 0.53. User CPU of 9.7 seconds, system CPU 2.3.

 The black video took 11.50 seconds to run, ending with M-V at 1.0, user
 CPU 6.2, sys 2.3.

 When tested again with CPUs at performance setting = locked to highest
 frequency, the high bitrate video was still ahead at 10.88 vs 11.08
 seconds, with A-V at 0.285 vs 0.635 for the black video. Black video user
 CPU down to 4.95.

 In this case, the CPU can't be the limiting factor. It doesn't even
 saturate one CPU core.

 Tested 3840x2160p video at 15 fps. This ran without the slowdown. The
 pixels per second is the same as the 1920x1080p 60fps video.

 3840x2160p at 30fps does have slowdown. With CPUs locked to high
 10.76 M-V:  0.813 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0

 real    0m11.339s
 user    0m10.104s
 sys     0m3.948s

 Completely black VP9 video at 1920x1080p 60 fps decodes slightly easier,
 with user=4.4 and sys=2.1, but is still delayed ending at M-V=0.356 in
 10.8 seconds.

 All the above results are with vblank_mode=0.

 Tested mpeg1video, mpeg2video, ffv1, and mpeg4. All of them had slowdown.
 mpeg4 was the fastest with only 0.08 seconds late after 10 seconds. For
 those tested, not setting vblank_mode=0 mode the slowdown worse; for
 mpeg4, M-V only went up to 0.238. (Also, all of these codecs had bitrate
 of 700~1500 kbps for completely black video.)

 There does seem to be something significant about the framerate, with the
 difference in 2160p ('4K') at 15 fps vs 1080p at 60 fps.

 3840x4320 at 30 fps played back in 18~20 sec after a slow first trial,
 with user CPU around 19.5~20 and sys around 7.9. Idle CPU as seen in top
 around 15% for this, compared to 27% idle for 3840x2160 30 fps and 55~60%
 idle for 1920x1080 60fps.

 This seems like it could be consistent with some kind of ~~rendering~~
 process referenced by ffplay being single-threaded. Correction, it takes
 ffmpeg 14 userspace seconds to decode the 4Kx4K video with '-f null -'. If
 ffplay is being limited by a single-threaded action, it would have to be
 decoding, though I'm not sure if that makes any sense if the decoding is
 done by the ffmpeg or libav libraries, and we assume that it isn't a
 change in ffmpeg/ffplay that's responsible for this issue.

 Even if there is a single-thread limitation, it doesn't explain the
 slowdown with vblank_mode=0 and no CPUs saturated. In fact, having
 randomly noticed that you can make 'top' show CPUs separately, load is
 distributed evenly between them, but this might not rule out a single-
 threading cause.

 I tried to test how many frames were being dropped with -framedrop
 (default), but first attempt failed. Adding {{{-vf
 seemed to be going well, with no obvious skipping and no M-V difference,
 but the numbers were actually going up much too slow and it was only
 around 190 when the video ended for VP9 video, instead of 600.

 So I encode VP9 again at 15 fps encoding speed, at fastest speed of
 '-speed 5 -quality realtime', and default bitrate. Expect VP9 to show more
 obvious frame dropping than H.264, unless maybe B-frames are disabled.

 Result: no obvious frame dropping from -framedrop. Without setting
 vblank_mode=0 but with -noframedrop, end delay is 0.972. With both set,
 end delay is 0.692. time is around 4.7 user, 2 sys, like before.

 -v trace doesn't list dropped frames. More precise testing of how many
 frames are dropping when the CPU isn't saturated needs a better method of
 visual detection. This might help diagnose the cause, if it turns out that
 in fact no frames are being dropped, but also could show the potential
 improvement of getting ffplay under whatever system configuration I have
 (drivers, etc.) to use all available CPU to prevent slowdown with

Ticket URL: <https://trac.ffmpeg.org/ticket/6975#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list