#6975: Recent change to sync video output to screen refresh conflicts with -noframedrop ------------------------------------+----------------------------------- 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 performance, {{{ 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 "drawtext='fontcolor=white:fontsize=96:x=(W-tw)/2+4:y=(H-th)/2+4:text=%{n}:alpha=0.5',boxblur,drawtext='fontcolor=white:fontsize=96:x=(W-tw)/2:y=(H-th)/2:text=%{n}'"}}} 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 -noframedrop. -- Ticket URL: <https://trac.ffmpeg.org/ticket/6975#comment:4> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker _______________________________________________ FFmpeg-trac mailing list FFmpeg-trac@avcodec.org http://ffmpeg.org/mailman/listinfo/ffmpeg-trac