gpu-context=wayland/hwdec=drm smoothness regression

jpalus commented 1 year ago

Important Information

Provide following Information:

mpv version: 0.37.0
Linux Distribution and Version: PLD 3.0
Source of the mpv binary: distribution
If known which version of mpv introduced the problem: 0.37.0
Window Manager and version: sway 1.8.1
GPU driver and version: Mesa/panfrost 23.2.1

Reproduction steps

Play video with rkvdec based stateless v4l2 hwdec acceleration and --vo=gpu --gpu-context=wayland.

Expected behavior

Playback is smooth.

Actual behavior

It's a bit hard to explain. It's like one frame moves "forward" while next is from the past? making impression like it moves backward, then again move forward (compared to last most forward step) and again backward. I do sometimes see like color tinting, slightly pink/magenta? I my try to get video of this if it's not clear.

--vo=dmabuf-wayland is very smooth and has no issues but as before I think it suffers from poor upscaling (like edges in video are not antialiased).

It might be an issue with my rather dated v4l2 request patches and ffmpeg 4.4 but it was all fine in previous version 0.36.0.

Log file

http://0x0.st/HwNb.txt

jpalus commented 1 year ago

I will try to bisect it unless someone have an idea already.

llyyr commented 1 year ago

Bisection would help. Can you also try --vo=gpu-next?

--vo=dmabuf-wayland is very smooth and has no issues but as before I think it suffers from poor upscaling (like edges in video are not antialiased).

Not related, but by default sway uses nearest scaling, you can force it to use linear which is a massive improvement by putting output [something] scale_filter linear in your output config

Dudemanguy commented 1 year ago

What ffmpeg fork were you using? It's been a couple of months or so since I last tried this, but when I was testing with the v4l2 request fork on the ffmpeg 6 branch, it was OK.

jpalus commented 1 year ago

Can you also try --vo=gpu-next?

Same outcome.

--vo=dmabuf-wayland is very smooth and has no issues but as before I think it suffers from poor upscaling (like edges in video are not antialiased).

Not related, but by default sway uses nearest scaling, you can force it to use linear which is a massive improvement by putting output [something] scale_filter linear in your output config

Indeed linear makes it way nicer, wouldn't think of that. Thanks a lot!

What ffmpeg fork were you using?

It's a stock ffmpeg 4.4.4 with old time v4l2-request patches floating around on top. Would have to dig which repo it was taken from exactly, jernej's? If needed I can search which git repo it was exactly.

Anyway bisected it down to:

71cf360e33e8347d38079c99c90827d95c8d9cda is the first bad commit
commit 71cf360e33e8347d38079c99c90827d95c8d9cda
Author: Philip Langdale <philipl@overt.org>
Date:   Sun Oct 15 12:41:26 2023 -0700

    hwtransfer: handle hwcontexts that don't implement frame constraints

    Some ffmpeg hwcontexts do not implement frame constraints. That means
    they cannot report which formats are support for given configurations.

    My previous changes to make hwupload more capable relies on the
    constraints to be provided to accurately describe what combinations are
    supported, so we will currently see a bunch of errors failing to
    configure the hwupload filter on platforms such as v4l2 SoCs with
    drmprime. This doesn't break playback, but it's confusing.

    To bridge the gap, this change uses the static format metadata that we
    include for hwdecs to build a fake constraints struct to keep all the
    other code working.

 filters/f_hwtransfer.c | 52 +++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 49 insertions(+), 3 deletions(-)

Though not sure what it changes exactly.

philipl commented 1 year ago

You should use the ffmpeg 6 branch from jernejsk (see the wiki: https://github.com/mpv-player/mpv/wiki/V4L2-drmprime-support). That's what I tested with.

Anyway, in terms of the juddering you are seeing, I would see that periodically in my rockchip testing. Trying to play the file again a few times would usually make it go away, so I doubt it's a regression. I expect that what happened here is you tried it a bunch of times as part of your bisect and then it worked.

It might be due to a lack of explicit synchronisation after decoding - I don't know how you'd do that with v4l2, but we definitely don't attempt it.

mpv-player / mpv