Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Video output often freezes on 60fps VP9 video #3758

Closed
ivan opened this issue Nov 1, 2016 · 12 comments
Closed

Video output often freezes on 60fps VP9 video #3758

ivan opened this issue Nov 1, 2016 · 12 comments

Comments

@ivan
Copy link

ivan commented Nov 1, 2016

mpv version and platform

# mpv --version                                                    
mpv 0.21.0 (C) 2000-2016 mpv/MPlayer/mplayer2 projects
 built on Sun Oct 23 02:59:47 UTC 2016
ffmpeg library versions:
   libavutil       55.33.100
   libavcodec      57.63.103
   libavformat     57.53.100
   libswscale      4.1.100
   libavfilter     6.64.100
   libswresample   2.2.100
ffmpeg version: N-82090-g728ccae

xubuntu 16.04.1 with Intel video, no compositor, no TearFree or any other unusual options, 4K display

Reproduction steps

  1. Download https://ludios.org/tmp/WipEout%20HD%20-%20Supersonic%20in%201080p%2060FPS-uQqRIX1RMtE.webm
  2. Play it in mpv
  3. Fullscreen (optional)
  4. Skip to 10:10 and play the video for about a minute
  5. Observe that video output freezes, while audio keeps playing

Note that it will freeze at many other locations in the video, but it is not always reproducible at the exact same locations.

Expected behavior

mpv frame skips where needed, but does not stop video output permanently

Actual behavior

video output frozen permanently (until leaving and re-entering fullscreen, or sending other events)

Log file

Nothing special seems to happen when the video output freezes.

http://sprunge.us/WhQi

Sample files

https://ludios.org/tmp/WipEout%20HD%20-%20Supersonic%20in%201080p%2060FPS-uQqRIX1RMtE.webm

@haasn
Copy link
Member

haasn commented Nov 1, 2016

Happens to me on that clip as well, although I don't have any problems when e.g. playing 60 fps youtube videos (which I request in VP9 format)

Also, it always happens in exactly the same positions for me (i.e. exactly around 10:12 or so), which is pretty suspect.
EDIT: Actually, that's just because I was starting at the same spot every time. If I -start 10:00 instead, it freezes a few seconds after that.

@haasn
Copy link
Member

haasn commented Nov 1, 2016

Can you reproduce it with e.g. mpv --ytdl-format=302 ytdl://SXZ3qWAvbVs? (I can't) Also, why 10:10? Can you reproduce it for earlier timestamps? (It might be a length thing)

For me, it seems to happen always a few seconds after starting playback. After running for a while, however, it seems to play fine.

@ivan
Copy link
Author

ivan commented Nov 1, 2016

Nothing special about 10:10, it can happen much earlier as well.

I see this on SXZ3qWAvbVs as well (I downloaded it with youtube-dl -f 302 SXZ3qWAvbVs to eliminate network buffering issues.) In my last two viewings, it froze at 3 seconds, then at 14 seconds.

@haasn
Copy link
Member

haasn commented Nov 1, 2016

Hmm, I'm getting it too now for youtube videos. Must be a recent thing. I can try bisecting it.

@haasn
Copy link
Member

haasn commented Nov 1, 2016

@wm4

17733bd5b84a7bb8caf497aa9ea35efd657e967a is the first bad commit
commit 17733bd5b84a7bb8caf497aa9ea35efd657e967a
Author: wm4 <wm4@nowhere>
Date:   Tue Nov 1 13:06:48 2016 +0100

    vo_opengl: make frame reupload logic more robust

    It's not that easy to decide whether a frame needs to be
    reuploaded/rerendered. Using unique frame IDs for input makes it
    slightly easier and more robust. This also removes the use of video PTS
    in the interpolation path.

    This should also avoid reuploading the video frame if it's just redrawn
    in paused mode, or when using OSD/subtitles in cover art mode.

:040000 040000 c7c28786af21da74cb866779ad7168628c38a725 bb5a130f466ce5eaa26fa0844e116ddc6db2af29 M  video

@ivan
Copy link
Author

ivan commented Nov 1, 2016

I think this has been going on for a long time, because it also happened with mpv 0.14.0-1build1 on xenial.

@haasn
Copy link
Member

haasn commented Nov 1, 2016

@ivan That must have been a different bug. mpv 0.14.0 is basically from the stone age, so it wouldn't surprise me.

@mc4man
Copy link

mc4man commented Nov 2, 2016

@ivan
Using same build here (which does not include 17733bd), somewhat similar hardware, (Haswell, using Intel) & your file plays perfectly. Main diff may be that here on a 1080p display vs. 4k.
I've a 4k display machine but not available till next week or so.

@Jj0YzL5nvJ
Copy link

Jj0YzL5nvJ commented Nov 3, 2016

Plays perfect to me, except in 12:47-12:48, but that happens with ffplay too.

mpv git-6e143ff (C) 2000-2016 mpv/MPlayer/mplayer2 projects
 built on Sun Oct 23 17:00:17 MDT 2016
ffmpeg library versions:
   libavutil       55.28.100
   libavcodec      57.48.101
   libavformat     57.41.100
   libswscale      4.1.100
   libavfilter     6.47.100
   libswresample   2.1.100
ffmpeg version: 3.1.5

Xubuntu 16.04.1 LTS x86_64

  GL_VERSION:  3.0 Mesa 13.1.0-devel - padoka PPA
  GL_VENDOR:   X.Org
  GL_RENDERER: Gallium 0.4 on AMD JUNIPER (DRM 2.43.0 / 4.4.0-45-generic, LLVM 4.0.0)

cat /usr/share/X11/xorg.conf.d/xorg.conf

Section "Device"
   Identifier "Radeon"
   Driver "radeon"
   Option "Accel" "on"
   Option "ColorTiling" "on"
   Option "ColorTiling2D" "on"
   Option "DRI" "2"
   Option "EnablePageFlip" "on"
   Option "AccelMethod" "EXA"
   Option "EXAVSync" "on"
   Option "EXAPixmaps" "on"
EndSection

I've been testing with an i915, with SNA acceleration see many glitches using OpenGL (glx*, mpv, pcsxr, mupen64plus, etc). But with UXA works "well"...

@wiiaboo
Copy link
Member

wiiaboo commented Nov 4, 2016

I can also confirm reverting the commit fixes freezes with 60 fps VP9 on Windows 10 x64 with GTX 1060.

@Jj0YzL5nvJ
Copy link

Jj0YzL5nvJ commented Nov 5, 2016

I tried again with a new compilation and still works the same. The commit 17733bd makes no difference to me.

mpv git-7c9f326 (C) 2000-2016 mpv/MPlayer/mplayer2 projects
 built on Sat Nov  5 00:45:20 MST 2016
ffmpeg library versions:
   libavutil       55.34.100
   libavcodec      57.64.100
   libavformat     57.56.100
   libswscale      4.2.100
   libavfilter     6.65.100
   libswresample   2.3.100
ffmpeg version: 3.2

haasn added a commit to haasn/mp that referenced this issue Nov 6, 2016
The logic seems to have been flipped around for some reason. (Judging by
the comment, the intent was to force a redraw when using blend-subtitles
so that a changed subtitle would still register on a redrawn frame.
Although I doubt the legitimacy of this intent, this fix simply makes
the logic match the comment)

The second check that was in gl_video_upload_image was removed because
it was self-defeating: by duplicating the check from is_new, it skipped
the upload entirely even in cases where it was necessary (e.g. due to
is_new being set to true by this branch, or by the output FBO being
invalid). The skip logic is supposed to be handled in
gl_video_render_frame, not gl_video_upload_image.

Fixes mpv-player#3758 and mpv-player#3764.
@ghost
Copy link

ghost commented Nov 18, 2016

Probably fixed...

@ghost ghost closed this as completed Nov 18, 2016
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants