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

FFmpeg trac at avcodec.org
Mon Jan 22 22:17:03 EET 2018


#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):

 I used to able to play 1080p 60fps video with ffplay -noframedrop. Then I
 upgraded from Ubuntu 16.10 to Ubuntu 17.10, and now ffplay will only play
 at about 80% speed with -noframedrop. It won't even play a 720p 60fps file
 without gradually falling behind. It isn't lack of CPU resources.

 Many things changed other than ffplay. Older version of ffplay acting the
 same way (I would have tested myself, but static packages of ffmpeg don't
 include ffplay) isolates the change to elsewhere.

 Maybe this always happens with OpenGL-based rendering, and my system
 changed so that ffplay previously didn't use OpenGL, but now it does, or
 how OpenGL works changed.

 -noframedrop can be helpful when this issue doesn't occur, because dropped
 frames can look worse than changes in video speed. VP9 is particularly
 prone to jumps in decoding complexity upon movement, leading to sections
 that will never display no matter how many times you try it, unless you
 use -noframedrop. H.264 can just drop B-frames, but VP9 falls behind and
 drops whole sections (1+ second) of video.

 It would be possible to prevent this issue from occurring. Ignoring the
 environment variable, or as it seems assuming a different value for the
 default, would be making the judgement call that "the user intends for
 this variable to prevent unseen frames in 3D rendering, and does not
 intend for it to prevent 60fps video from being played correctly in some
 cases."

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


More information about the FFmpeg-trac mailing list