search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
26.71k stars 2.84k forks source link

Small skip every 9 seconds playback #6037

Open David-Else opened 5 years ago

David-Else commented 5 years ago

mpv version and platform

Fedora 28 using X session and MPV from RPM Fusion repo

mpv 0.28.2 (C) 2000-2017 mpv/MPlayer/mplayer2 projects
 built on UNKNOWN
ffmpeg library versions:
   libavutil       56.14.100
   libavcodec      58.18.100
   libavformat     58.12.100
   libswscale      5.1.100
   libavfilter     7.16.100
   libswresample   3.1.100
   ffmpeg version: 4.0.2
sudo lshw -C video
  *-display                 
       description: VGA compatible controller
       product: Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 06
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:29 memory:f7800000-f7bfffff memory:e0000000-efffffff ioport:f000(size=64) memory:c0000-dffff

Reproduction steps

play this sample video from the official test repo

https://github.com/haasn/interpolation-samples/raw/master/60.000.mkv

Expected behavior

smooth playback

Actual behavior

a small jump every 9 seconds

It happens whatever settings I try to use, I have tried combinations of all these:

profile=gpu-hq video-sync=display-resample interpolation tscale=oversample

Strangely if I use a X session:

xrandr
...
   1920x1080     60.00*+
...

and wayland:

xrandr
...
   1920x1080     59.96*+
...

and the problem looks much more subtle on Wayland, but is definitely there.

In Gnome Video player in X it does not happen, but it has constant awful looking screen tearing instead.

xantoz commented 5 years ago

I can reproduce this on Sandy Bridge. 

sudo lshw -C video
  *-display                 
       description: VGA compatible controller
       product: 2nd Generation Core Processor Family Integrated Graphics Controller
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 09
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:24 memory:f0000000-f03fffff memory:e0000000-efffffff ioport:5000(size=64) memory:c0000-dffff

X11 with ratpoison WM and compton as compositor (compton --glx-no-stencil --backend glx --opengl --paint-on-overlay --vsync opengl-swc), using modeset as the Xorg DDX driver. w/o any X11 compositor it's slightly more subtle, but I can find it still happening every 9 seconds (full-screen, otherwise it tears).

I typically see about 2 delayed frames in the statistics for every hiccup.

I could not see any hiccups with gpu-context=drm however (if there were any, they were very subtle), possibly due to how it handles page flips differently.

Versions: mpv (personal build, a few patches on top of master) mesa 18.1.5 linux 4.17.8 ffmpeg 4.0.2

xantoz commented 5 years ago

Switching X11 to the intel DDX driver instead of generic modesetting (xf86-video-intel instead of xf86-video-modesetting) seems to fix this on my HW. I now suspect some sort of interaction with the modeset driver.

Also, when testing on GNOME Wayland: did you use --gpu-context=wayland? I imagine going/not going through XWayland might have some effect. (Also note that typing "xrandr" itself to get the refresh rate under Wayland will also go through XWayland. You should try to find some more direct way of getting the refresh rate of your monitor under Wayland. Maybe the compositor logs it somewhere?)

David-Else commented 5 years ago

Thanks for looking into this.

I am no Linux/video expert, so don't know how to change x11 drivers in Fedora, or find compositor logs. If there is anything I can add to mpv.conf to aid testing, or give any results from the command line let me know.

I tried gpu-context=drm and got constant tearing in the bottom third of the screen in full screen mode.

xantoz commented 5 years ago

How to change X11 drivers

Make sure xf86-video-intel (or whatever name it is packaged under on your distro) is installed. Then you will need to edit /etc/X11/xorg.conf to something like the following (only posting relevant section):

...
Section "Device"
        Identifier  "Card0"
        Driver      "intel"
        BusID       "PCI:0:2:0"
EndSection
...

If you do not have any /etc/X11/xorg.conf you can run Xorg -configure as root (run it on a bare VT without X11 active) and one will be generated at /root/xorg.conf.new you can then copy that into /etc/X11/xorg.conf and edit it.

Logs/refresh rate from the GNOME Wayland compositor

I do not know exactly, as I do not use GNOME myself. Maybe you can just find this reported in some preference pane related to setting resolution somewhere?

Tearing with gpu-context=drm

That is very strange. Tearing is the last thing it should do. Also it can only run in fullscreen. It is completely standalone from either X11, Wayland or any compositor or window system and needs to be run without X11 or Wayland being active. Did you run mpv from a bare VT (press Ctrl+Alt+Fx if in an X11 session to switch the active VT). If you don't run it like that, gpu-context=drm usually doesn't work at all.

David-Else commented 5 years ago

Tearing with gpu-context=drm

I just added gpu-context=drm to my mpv.conf file and double clicked the test file in the file explorer to run it. I am in X not wayland. It also runs not in full screen! Heavy....

I tried to do a gnome screen-cast but turning it on made the video jumpy. My mpv.conf is:

profile=gpu-hq
fullscreen=yes
gpu-context=drm

and I turn the fullscreen on and off with the 'f' button. It does not tear in windowed mode, but still has the skip problem.

Thanks for the other info,but I don't want to mess with my settings right now, this is my work computer too, and I lost a morning due to a software update regression only a few days ago!

xantoz commented 5 years ago

It would appear that you somehow end up not using gpu-context=drm (maybe it falls back) then, even though AFAIK it should not fall back if you've specified a context explicitly like that; it should loudly fail.

As far as workarounds go, I would give gpu-context=wayland on GNOME Wayland one last try however (Note: You will not have any window decorations due to how Wayland is implemented).

Finally, I would consider opening a bug with Xorg, seeing as this might be a problem with xf86-video-modesetting.

David-Else commented 5 years ago

I triedgpu-context=wayland on wayland, and it was the best yet. It would not exit fullscreen even when pressing 'f'. When I added video-sync=display-resample the screen went crazy :(

I can't use Wayland anyway as my Wacom controller I use for a mouse does not work properly. Wayland is just not ready, it's a real shame. I think it will be great one day.

I will just forget smooth video on Linux for now, I tried everything. I will keep coming back to this test 60fps video on big updates and see if things change.

xantoz commented 5 years ago

Screen went crazy. [with video-sync=display-resample]

I think that is an old bug w.r.t. the wayland backend. It's been fixed in mpv 0.29 (the latest release). I highly recommend running 0.29, as 0.28 is over 6 months old now.

I tried everything

You still haven't tried switching X11 over to xf86-video-intel.

Back on topic

To summarize. This bug can be restated:

aufkrawall commented 5 years ago

There is no reason to prefer modesetting driver over xf86-video DDX driver with amdgpu because unlike Intel, they manage to get out stable releases without drawbacks over the modesetting driver. Video playback is completely stutter free on Polaris (apart from a general issue of amdgpu.dc + xorg hardware cursor and page flipping).

tholin commented 5 years ago

I have a similar but probably different bug. You might be interested in how I diagnosed that problem.

About 6 months ago I updated to the 4.14-lts kernel branch and started getting frame drops every 5 sec. Using latencytop I noticed the X process was stalled for 16.6ms every time the framedrop happened. Latencytop's backtrace always contained "drm_atomic_helper_legacy_gamma_set".

The problem was caused by this commit for atomic page flips.

https://github.com/torvalds/linux/commit/4c01ded5732d6533a2858fae30c197f734745062

The commit description mention several cases when the new code "block" (drop a frame) like when it's "Showing/hiding cursor". Changing gamma also blocks so the frame drops were caused by redshift. Redshift will always set a new gamma value every 5 sec.

I tried to convince the Intel developers this was a regression but failed. At least I got a patch to work around some of the problem.

diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 0028591f3f95..370fb6647c90 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3611,6 +3611,8 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
        replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
        replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
        crtc_state->color_mgmt_changed |= replaced;
+       state->legacy_cursor_update = true;

        ret = drm_atomic_commit(state);

This patch makes gamma updates use the "cursor hack" as mentioned in the atomic page flips description. Hiding the cursor still cause frame drops though.

I use xf86-video-intel and the modesetting driver might use different code paths for mouse, gamma and page flips. Check if latencytop shows anything interesting on your system.

Recent git versions of xf86-video-intel also got massive amounts of frame drops because of this commit. I had to bisect the code to figure that out.

commit af36a4ab78cc0e2a85fa40d442bfb92df75dd217
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Apr 1 13:13:19 2018 +0100

    sna: Defer submission of the next shadow frame until halfway through

    Do not immediately post the next shadow flip on completion of the
    current flips, but instead queue a timer for half way through the next
    vblank so that try to we keep the additional input-output lag to less
    than a frame.

I've reported the problem but Intel's bugzilla is basically a black hole.

aufkrawall commented 5 years ago

Does this also affect situation with Gen9 GFX and latest non-lts kernels? Sounds really terrible.

xantoz commented 5 years ago

It seems like https://github.com/wm4/mpv_backup/commit/8816e1117ee65039dbb5700219ba3537d3e5290e actually ameliorates this slightly, or at least that is what a quick bisect told me. However, it seems it might just be due to dumb luck (butterfly effect-like), as I see no obvious reason for why it should fix it.

xantoz commented 5 years ago

This problem seems to be gone for me now with: linux 4.19.0 xorg-server 1.20.2 (running on modeset driver) mesa 18.2.3 mpv 0.29.1

David-Else commented 5 years ago

@xantoz would you share your .config file? I am now using hwdec=auto which selects VAAPI, not sure if that would change things.

With Fedora 29 the problem seems much better, but there is still a tiny glitch.

X.Org X Server 1.20.3
mpv 0.29.1 Copyright © 2000-2018 mpv/MPlayer/mplayer2 projects
 built on UNKNOWN
ffmpeg library versions:
   libavutil       56.14.100
   libavcodec      58.18.100
   libavformat     58.12.100
   libswscale      5.1.100
   libavfilter     7.16.100
   libswresample   3.1.100
ffmpeg version: 4.0.3
xantoz commented 5 years ago

@David-Else The options I'm using amount to pretty much: /usr/bin/mpv --vo=gpu --ao=alsa --video-sync=display-resample --gpu-context=x11egl --hwdec=vaapi ~/Video/60.000.mkv

It's more stable with VAAPI than with software decoding.

$ /usr/bin/mpv --version
mpv 0.29.1 Copyright © 2000-2018 mpv/MPlayer/mplayer2 projects
 built on UNKNOWN
ffmpeg library versions:
   libavutil       56.22.100
   libavcodec      58.35.100
   libavformat     58.20.100
   libswscale      5.3.100
   libavfilter     7.40.101
   libswresample   3.3.100
ffmpeg version: 4.1
David-Else commented 5 years ago

@xantoz I tried it with your settings and the 9 second skip is still there, but from memory it seems a lot less dramatic than it was, but the same as my settings. That is not very scientific, but I had/have no real way to quantify it.

Maybe this system info is useful?:

lspci -k

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
    DeviceName:  Onboard IGD
    Subsystem: ASUSTeK Computer Inc. Device 8534
    Kernel driver in use: i915
    Kernel modules: i915
xantoz commented 5 years ago

@David-Else So it's still every 9 seconds? I can't completely rule out that there's still a slight error for me, but if there is it must be slight enough to have passed me by, or even non-existent.

What is your version of:

1) Mesa (glxinfo -B) 2) Kernel (uname -r) 3) Xorg (Xorg -version)

David-Else commented 5 years ago

@xantoz Yes, every 9 seconds (approx), but a very slight skip. You need to keep your eye on one line and follow it along...

 glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Haswell Desktop  (0x412)
    Version: 18.2.4
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Desktop 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.4
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 18.2.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.2.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

uname -r
4.18.17-300.fc29.x86_64

X.Org X Server 1.20.3
X Protocol Version 11, Revision 0
Build Operating System:  4.18.10-200.fc28.x86_64 
Current Operating System: Linux gigabot 4.18.17-300.fc29.x86_64 #1 SMP Mon Nov 5 17:56:16 UTC 2018 x86_64
Build ID: xorg-x11-server 1.20.3-1.fc29 
Current version of pixman: 0.34.0
xantoz commented 5 years ago

@David-Else can you try with a 4.19.x kernel? I think it went away for me after upgrading to 4.19 (not completely sure, due to multiple variables)

David-Else commented 5 years ago

@xantoz I just checked with 4.19.2, and it seems to glitch slightly more on the same interval point... oh dear!

xantoz commented 5 years ago

@David-Else Hmm. I don't see much of anything any longer. Have you tried disabling your NTP daemon, if you have any?

aufkrawall commented 5 years ago

With amdgpu.dc=1, I experience the regular stutter with daemonized RedShift as well. I also experience stutter with amdgpu.dc=1 + Compton vsync in mpv. I'm free of stutter (fingers crossed) with single RedShift gamma adjustment without daemon and TearFree instead of Compton's vsync modes.

(Or with trusty old legacy amdgpu.dc=0, which doesn't cause any problems at all.)

kevmitch commented 5 years ago

This sounds similar to #3792. I was seeing this on IvyBridge, however was able to get rid of it by going back before torvalds/linux@ea0000f0d369a59c2086fe9c489e0a2a86e080ba which first went into linux-4.8. This is significantly earlier than the torvalds/linux@4c01ded commit (linux-4.12) mentioned by @tholin. It does however also relate to atomic page flipping.

I am now also seeing this symptom on my new Coffee Lake UHD 630 GPU and that can't be reverted to linux-4.7 because it only starts working at all on linux-5.0.

log stats image

However, the issue seems to go away if I switch to the intel ddx. Thankfully, I'm not seeing any tearing so far on the new GPU with the intel ddx, so this seems to be an acceptable workaround.

log stats image

mattia-b89 commented 4 years ago

Can't reproduce this issue.

CPU: i5-5200U os: Arch Linux kernel: 5.2.7 mesa: 19.1.4 modesetting driver (Xorg server): 1.20.5

aufkrawall commented 4 years ago

Was that with --video-sync=display-resample? Issue still exists here with Gemini Lake, xorg-git and modesetting, I can clearly see stutter in intervals. xf86-video-intel is not affected.

mattia-b89 commented 4 years ago

Yes, mpv --no-config --video-sync=display-resample 60.000-fps.mkv.
Further testing shows me an opposite behaviour compared to you;
for both, I attached a screenshot:

modesetting

xf86-video-intel-EDITED

NB: screenshot (using both mpv and GNOME screenshot tool) does not catch the glitch, thus I edited the one with the issue in order to show you what I effectively see.

EDIT: for completeness, I recap my specs:

aufkrawall commented 4 years ago

There are/were some issues with xorg 1.20.5 that broke vsync of xf86-video-intel driver. That's why I use xorg-git and xf86-video-intel must be compiled against xorg-git for ABI changes compatibility. It might fix your tearing issue.

dpirch commented 3 years ago

I'm also having the frameskip issue every 9 seconds with the modesetting driver (Pentium Silver J5005, Intel UHD Graphics 605). It also happens at 23.976 frame rate (source and display), where it is much more visible and annoying.

OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.0.4 OpenGL shading language version string: 4.60 OpenGL context flags: (none) OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.0.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

* `uname -r`: `5.4.0-40-generic`
* `/usr/lib/xorg/Xorg -version`:

X.Org X Server 1.20.8 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.4.0-177-generic x86_64 Ubuntu Current Operating System: Linux nuc 5.4.0-40-generic #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-40-generic root=UUID=63f1bcd6-f8b5-4d0c-a94f-75fd2165e0d7 ro quiet splash Build Date: 06 April 2020 09:39:29AM xorg-server 2:1.20.8-2ubuntu2 (For technical support please see http://www.ubuntu.com/support) Current version of pixman: 0.38.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version.


Switching from the default modesetting driver to the intel driver apparently solves the problem (in Ubuntu by creating a `usr/share/X11/xorg.conf.d/99-local.conf` with

Section "Device" Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" Option "TearFree" "true" EndSection

), although this causes segfaults in the iris dri driver (apparently this bug: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1876219); this can be solved either by running mpv with `MESA_LOADER_DRIVER_OVERRIDE=i965 mpv ...`, or by creating a `/usr/share/drirc.d/99-local.conf` with


With that, I don't have any framedrop issues and also no tearing.
David-Else commented 2 years ago

I finally switched to intel drivers from modesetting on Rocky Linux 8.4 with:

# cat > /usr/share/X11/xorg.conf.d/10-intel.conf << "EOF"
Section "OutputClass"
        Identifier "Intel"
        MatchDriver "i915"
        Driver "intel"
EndSection

EOF

and the 9 second glitch is gone!

I tried Option "TearFree" "true" as well, but it seemed to make things more glitchy, I have an old Haswell chipset and it is known to have issues, so that is probably why.

aufkrawall commented 2 years ago

TearFree has been broken forever with Intel (also Gen 9 and probably everything else), ~every fullscreen window that triggers page flipping breaks it. Reported it to Intel, nothing happened. Forget about it, it should not be needed for mpv fullscreen without compositor & single display. :)

aufkrawall commented 2 years ago

I can still reproduce the issue with modesetting DDX Gemini Lake. However, the issue is gone on Wayland (tested with Plasma and least aggressive input lag reduction setting).

tholin commented 1 year ago

I'm back with an update for my old comment from 4 years ago. https://github.com/mpv-player/mpv/issues/6037#issuecomment-414134691

I've got a new desktop build with a raptor lake i7-13700K cpu. I tried using the IGPU on X only to realize xf86-video-intel is completely broken and unmaintained. Instead I had to use xf86-video-modesetting patched with the out of tree TearFree patch.

It works ok except for constant frameskips. I've chased down the source of them all and here they are:

If I avoid all things mentioned above I get no frameskips at all. The kernel's atomic modesetting is just broken and there is no practical way to avoid all frameskips when using the X-server.