Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
mpv drops frames at VO for specific AV1 WebM #6001
mpv version and platform
Arch Linux x86_64
Don't drop frames, like vlc, Chromium and ffplay do.
Severe VO framedrops
@aufkrawall: Try the latest one.
@CounterPillow: Well. Consider the following:
I was able to reproduce the judder on my system with my own Windows builds until I changed the build options. For the record, see this spec file:
Small nit, don't want to open an issue for this:
PS F:\Tools> mpv --V mpv 0.29.0 Copyright © 2000-2018 mpv/MPlayer/mplayer2 projects built on UNKNOWN ffmpeg library versions: libavutil 56.18.102 libavcodec 58.22.100 libavformat 58.17.101 libswscale 5.2.100 libavfilter 7.26.100 libswresample 3.2.100 ffmpeg version: 4.1+809.g269daf5985 PS F:\Tools> mpv mpv 0.29.0 Copyright © 2000-2018 mpv/MPlayer/mplayer2 projects built on UNKNOWN ffmpeg library versions: [...] [...]
Not sure, but probably not intentional? Older builds definitely had their date in that place..
Since this didn't go through last night when I tried to post it:
Some years back there was a bug report that wanted it to be more comprehensive and if the
EDIT: I went ahead and opened a pull request.
Seems rather finicky about dropped frames. The linked vid was pretty short so did some local encodes of a bit longer. Seems minor changes to encoding options can create more or less dropped frames in mpv, don't have any other player to compare.
$ mpv --version mpv 0.29.0-30-g6eb59fea2f-dirty Copyright © 2000-2018 mpv/MPlayer/mplayer2 projects built on Sun Sep 16 23:58:12 MSK 2018 ffmpeg library versions: libavutil 56.19.101 libavcodec 58.30.100 libavformat 58.18.101 libswscale 5.2.100 libavfilter 7.32.100 libswresample 3.2.100 ffmpeg version: N-91961-g5109c38162 $ aomdec --help | grep av1 av1 - AOMedia Project AV1 Decoder 1.0.0-590-g6fa400604
As you can see, it takes only 4.2 seconds to decode 10 seconds of video (25 fps) on my machine but when I'm trying to play it with mpv I get a lot of VO frame drops.
added a commit
Oct 13, 2018
I have a theory that AV1 decoding is limited to a single thread since FFmpeg doesn't support multithreaded encoding for AV1 either. So there's a precedent there.
To test it, download a 1080p AV1 video from Youtube:
Then play it with mpv and record the CPU use of the process with
Playback was stuttery with a large number of dropped frames and took 3 minutes 20 seconds to complete for a 2 minute 38 second video. And as you can see, CPU usage was only 89% of the 400% maximum on a 2-core 4-thread CPU. While observing with
Now that the latest version of Firefox (v. 63) also supports AV1 decoding we can test that too. The
If you can't replicate the test result, then you probably aren't using a dual-core laptop CPU from 7 years ago (mine is an i3-2520M) and can just brute-force through the threading issue. In that case you can try one of Elecard's Holi festival AV1 test files. I'd imagine even the beefiest CPU will run into issues when trying to play the 2160p version on one thread. I can't even play the 720p 3.9 mbps file without dropped frames on mpv, while Firefox is again able to play it just fine.
At least here mpv & ffplay are ok with av1 files encoded with libaom0, particularly if done thru ffmpeg, higher rez's can have some dropped frames (I'm ok to 1080p. )
However the youtube ones don't, neither in mpv or ffplay. They do in vlc but vlc does not use use ffmpeg libs for decoding av1. What's the difference between local, elecard & youtube I've no idea..
As far as mt encoding in ffmpeg, that is quite possible, ie. with -tile-columns & -tile-rows , ffmpeg needs to be patched for -tile-rows.
Maybe by next year there will be a better decoder & mpv/ffmpeg will perform better. (dav1d
Closing this, since it's probably a combination of the following:
With dav1d I still get stutters but they're less severe, so I guess it is just the decoder after all.