Mpv: 20190622:From this version, mpv(using a video or audio filter) sometimes freezes when seeking.

Created on 8 Jul 2019  路  27Comments  路  Source: mpv-player/mpv

mpv-x86_64-20190622-git-c9e7473.7z (windows 10 pro 64bit)

From this version, mpv(enable the audio equalizer) sometimes freezes when seeking.
(other user's reports: using a video or audio filter)

command:

mpv-x86_64-20190707-git-c379950.7z

mpv --af-add=lavfi=[firequalizer=gain='cubic_interpolate(f)':zero_phase=on:wfunc=tukey:delay=0.027:gain_entry='entry(0,0);entry(62.5,0);entry(125,0);entry(250,0);entry(500,0);entry(1000,0);entry(2000,0);entry(4000,0);entry(8000,0);entry(16000,0)'] test.mp4

Most helpful comment

Mystery solved. It was this commit from winpthreads. @qyot27 build didn't have freezes because the toolchain used has an old version of winpthreads.

All 27 comments

i am not a fan of the way this issue was reported, but so be it.

i am not a fan of the way this issue was reported, but so be it.

I've done something wrong?, i'm the one who reported the issue on shinchiro repository and Smplayer Forum.

no. i am talking about how this issue was reported here. we have the issue template for a reason, so reported issues have a certain 'standard', have all the informations we need in and that in a way it's easily readable. no one really likes to look at a mess.

no. i am talking about how this issue was reported here. we have the issue template for a reason, so reported issues have a certain 'standard', have all the informations we need in and that in a way it's easily readable. no one really likes to look at a mess.

ah okay!, anyway i think this is an important issue on Windows, i hope you can solve it ^^, i'm sticking with an older version for now. (20190616)

@Akemi Sorry for insisting but other reports are coming (in other forums/threads), the bug really exist and the Windows version it's pratically inusable since the 2019/06/22 version (using a video/audio filter), i hope you are at least aware of this ^^.

I know that all should use the stable version ecc... , but i just want to make sure that you guys acknowledge the problem for a future fix.

@Akemi Sorry for insisting but other reports are coming (in other forums/threads), the bug really exist and the Windows version it's pratically inusable since the 2019/06/22 version (using a video/audio filter), i hope you are at least aware of this ^^.

I know that all should use the stable version ecc... , but i just want to make sure that you guys acknowledge the problem for a future fix.

yes i confirm. i have the freeze issue simply adding
af lavfi=[volume=-5dB]

dunno why you insist by mentioning me. i reopened the issue and that's about as much as i can do. this is apparently a windows problem(?), then there is nothing i can do about it since i solely do macOS things.

Can't reproduce this on Windows 10 Pro 64-bit running on a J3455 and 8GB of RAM (personal build used: http://www.mediafire.com/file/9sthgs108b1o7ev/mpv_r46949.7z/file). Software decoding or hardware decoding, no difference: seeks work, and fast (well, unless I'm seeking in a 4K backup, but that's a separate issue that specifically has to do with HEVC in MPEG-TS, and those issues also happen in ffplay, so that's definitely on libavformat's end). No amount of seeking back and forth causes it to freeze.

What CPU, GPU are being used here?

Superficially, the fact that [in the SMPlayer thread] the 'last known good' build was 6aecd10, but broke as of c9e7473, it would point to being something concerning the compute shader error diffusion commits on June 16 (that doesn't mean it's a bug in mpv; it could be a bug or simple limitation of the graphics driver being used). If you switch the --vo to something other than gpu - direct3d or sdl, for example - does it still happen?

i've done a new test just now, after i have instelled latest amd graphic driver with differente video files by resolution and fps types, all h264, used latest windows build (git-65b1c2d).
seems to be that the freeze bug is now gone, i havent had any problem with random seeks with any video file. with and without audio filters

What CPU, GPU are being used here?

@qyot27
CPU: Intel Celeron CPU 1007U 1.50GHz
GPU integrated: Intel HD Graphics

It's a low end pc, but the graphic drivers are updated to the latest version 2018/12/27 and i don't have problems even reproducing 1080p h265 videos using older versions of mpv.

If you switch the --vo to something other than gpu - direct3d or sdl, for example - does it still happen?

Yes, same problem using a different vo. =(

EDIT: Using your version (mpv_r46949.7z) there's no problem, all perfect (don't know what it means ^^')

mpv_r46949.7z is no problem.

What CPU, GPU are being used here?

Intel Core i3 540

Intel HD Graphics
2012/11/26
8.15.10.2900

If you switch the --vo to something other than gpu - direct3d or sdl, for example - does it still happen?

It happens but mpv_r46949.7z does not happen.

mpv_r46949.7z
gpu: error
direct3d: no problem
sdl(Using direct3d): no problem

gpu's error
[vo/gpu] The OpenGL driver does not support OpenGL 3.x
[vo/gpu/opengl] Suspected software renderer or indirect context.
[vo/gpu] The OpenGL driver does not support OpenGL 3.x
[vo/gpu/vulkan/libplacebo] Failed creating instance: VK_ERROR_INITIALIZATION_FAILED
[vo/gpu/vulkan/libplacebo] Failed initializing vulkan instance
[vo/gpu] Failed initializing any suitable GPU context!

mpv-x86_64-20190714-git-65b1c2d.7z
gpu: freeze
direct3d: freeze
sdl: not found

The codec does not matter. It also happens with WMV1, VP9. (container mp4 mkv webm wmv ts)

This bug has not been fixed in the latest version.

mpv-x86_64-20190804-git-69c93b6.7z

I have uploaded more detailed log files.

https://tokaimusen.com/cabinet/?file=f0289.txt&mode=download

I just compiled latest build from @shinchiro repo but first I removed this line: https://github.com/shinchiro/mpv-winbuild-cmake/blob/9f5d9229b4fec1add68730a396eea36c51b41f20/packages/ffmpeg.cmake#L73

After compiling ffmpeg with w32threads I don't have more freezes and I can seek with enable audio filters again.

To confirm this you can test this build if you had any freezes:
https://www.mediafire.com/file/7w7hpcjfb2nwc1u/mpv-x86_64-20190807-git-639ee55.zip/file

@onomatopellan Now it works without freezing!, please notify @shinchiro about this, so he can fix it for all the future updates! :)

@principealex1 He is notified every time his name is mentioned. :)

Thanks for testing, this is just a workaround though, it doesn't explain why winpthreads did stop working well since June 16. I suspect it was a Windows update. What exact Windows build are you running? Mine is 18362.267.

@onomatopellan same, 18362.267 build (Windows 10 Home x64)

So it's something that Microsoft should fix or MPV developers?

It's hard to say. I just tested latest mpv on my laptop (build 17763) and it also freezes so dunno what really happened.

I also tried qyot27 build which doesn't use w32threads either and it doesn't freeze. So it will be hard to know the real cause.

If that's a case, its a shame since pthreads-enabled ffmpeg is needed for streaming like udp,rtp. But, I never use those streaming features and not having any freezes, so I dont really care whether its compiled with win32thread or pthread

@shinchiro Then I vote for win32thread. Freeze is really annoying and totally random. BTW which Linux distro are you running?

As was pointed out, the actual mpv-related change at the point where the supposed failure starts to occur has to do with error diffusion in the gpu vo, and the platforms that seem to have this freezing problem have all been stated to be older (pre-Skylake-era) Intel GPU setups.

Concurrently with those changes was mpv's switch to libplacebo and dropping crossc in favor of using SPIRV directly.

The build I provided has those changes, and that's especially telling because the one report was that --vo=gpu was failing because it was looking for Vulkan when an Intel setup from that long ago would not have that available (similar to the problem I was encountering with Apollo Lake's HD Graphics 500 and the video being just a blue screen under certain circumstances - it had something to do with the driver reporting support for something the GPU wasn't actually capable of, or vice-versa?).

The most likely explanation, AFAICT, is that the freezing behavior is only happening in the graphics driver, on a 5+ year old Intel stack, possibly excerbated by however shaderc (and crossc, if still there) and SPIRV interact on something that old. Unless of course some issue with winpthreads is arising from a git build of MinGW-w64, whereas I have my cross environment set up to use point releases (and is currently using v6.0.0 because that's what was current when I built GCC 9.1.0).

Maybe I should do it again but I remember trying to compile a build from June 15 (with GIT tag for mpv, shinchiro's repo and ffmpeg from that day) and the resulting build still froze so I discarded any mpv or ffmpeg commit being the culprit.

@qyot27 I forgot to say my GPU is a GT710 (and i5-9400F as CPU) and updating the drivers didn't help. It happens with totally different configurations.

This is the shinchiro build I'm using everywhere to test if it freezes. Just drop any video and press 'n' and 'right' keys simultaneously and repeatedly until it freezes. Seeking+enabling filters is the death combo it makes in every PC I tried to freeze after a few seconds.
Please try again with this one:
https://www.mediafire.com/file/oha864gpictaz1n/mpv-x86_64-20190804-git-69c93b6.zip/file

So... next @shinchiro builds are going to work on my pc? ^^

This bug has been fixed in this version. Thank you very much!
mpv-x86_64-20190810-git-639ee55.7z

Just to add to qyot27 and other peoples statements, my laptop is circa 2011 stuff, an intel i7 2nd gen (Sandy bridge) with an HD3000.

Had same bug and had to roll back to mpv-x86_64-20190616-git-6aecd10.7z.

Shinchiro's build of mpv-x86_64-20190810-git-639ee55.7z works for me.

Mystery solved. It was this commit from winpthreads. @qyot27 build didn't have freezes because the toolchain used has an old version of winpthreads.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lightonflux picture lightonflux  路  4Comments

yuvadm picture yuvadm  路  3Comments

xanadupark picture xanadupark  路  3Comments

sant527 picture sant527  路  4Comments

ghost picture ghost  路  3Comments