Closed CounterPillow closed 8 years ago
Does it happen with --hwdec=vaapi-copy
?
Yes
Okay, --hwdec=vaapi
may have been a red herring. While I could initially reproduce the issue reliably, I now managed (using the same mpv version, and the current git master) to reproduce the issue without using --hwdec=vaapi
.
However, now I fail to reproduce the issue at all. This might be related to some powersaving options or a different part of the driver which in some way affects vsync, as I've seen my display clock down to 40Hz, though forcing it to 60Hz also failed to produce the dropped frames.
I'm going to attempt to reproduce this again. As for how the playback log compares to the one I posted here, it looks pretty much the same minus the dropped/missed frames.
EDIT: By the way, forcing mpv's perceived display fps to a purposefully wrong number using --display-fps=60
when the refresh rate is at 40Hz produces framedropping/missing with the same symptoms (i.e. at the same rate, in the same spots), so my current hypothesis is that my driver decides to reclock the display after mpv has read the display frame rate.
Tested with DRI3 ? or i915 lvds_downclock=1 ?
i915 lvds_downclock=1
This, along with weird system freezes and crashes when disk IO is involved (wtf), happens to me when using the intel X.org DDX. It’s perfectly fine with the modesetting DDX on recent systems. Screw Intel.
If hardware-decoding is done through vaapi and
--video-sync=display-resample
is used, the video output is extremely choppy and mpv reports of many missed and dropped frames.With
--video-sync=audio
, this is not the case.Output of
mpv --no-config --hwdec=vaapi --vo=opengl-hq --video-sync=display-resample -v --length=+20 file.mkv
: