About the "forward seeking" freeze issue.

[RandomGuy456]

Can you try running mpv with any video/audio filter? like this :
mpv.exe video.mkv --af=lavfi=[extrastereo]

I'm 100% sure that you will be able to reproduce the problem now. (it doesn't always happen at the first "jump", but two o three times it's enough)

These freezes occur using the two latest 20190622 and 20190630 version.

[shinchiro]

Still cannot reproduce. Try test with today build, 20190707 since I updated the mingw-w64 toolchain. See if that fix it or not

[RandomGuy456]

Still doesn't fix the issue :/, i'm not the only one, also the creator of Smplayer and some users/friends have verified the issue since the 20190622 version.

[JonnyThree]

Hello i have found this issue, and i can confirm that i have exactly the same problem. Freezing when i forward, seeking in the progress bar. The last version that doesnt have this issue is mpv 0.29.0-338-g6aecd10eba. I'm on Win 7 X64, mpv x64. No a/v filters loaded.
My mpv.conf:
vo=gpu
gpu-api=d3d11
hwdec=dxva2
interpolation=yes
video-sync=display-resample
tscale=triangle
fs=yes
autofit=970
no-osd-bar
osd-font=Calibri
osd-font-size=38
osd-border-size=1.5
sub-font=Trebuchet MS
sub-font-size=30
blend-subtitles=yes
save-position-on-quit
force-seekable=yes
force-window=yes
idle=yes
cache=yes
cache-secs=30
demuxer-max-bytes=400000000
load-unsafe-playlists

[xnoreq]

Can confirm. It's simply stuck after some random seek:

[vd] Decoder format: 1920x1080 [0:1] yuv420p bt.709/bt.709/auto/limited/auto CL=mpeg2/4/h264 (auto 0.000000/0.000000/0.000000)
[vd] Using container aspect ratio.
[cplayer] Run command: seek, flags=73, args=[10.000000, relative, unused]
[cplayer] first video frame after restart shown
[mkv] queuing seek to 514.400000
[mkv] execute seek (to 514.400000 flags 4)
[ao/wasapi] Thread Reset
[mkv] seek done

when it should continue with something like:

[ffmpeg/video] h264: Reinit context to 1920x1088, pix_fmt: yuv420p
[vd] Decoder format: 1920x1080 [0:1] yuv420p bt.709/bt.709/auto/limited/auto CL=mpeg2/4/h264 (auto 0.000000/0.000000/0.000000)
[vd] Using container aspect ratio.
(Paused) AV: 00:55:38 / 01:31:27 (60%) A-V:  0.000
[cplayer] first video frame after restart shown
[cplayer] starting audio playback
[cplayer] playback restart complete @ 3340.440000

The window itself is still responsive (move, resize works) but the render thread seems to be stuck.

[xnoreq]

I found the trigger for the hangs. A simple audio filter will do:
--no-config --af-add="lavfi=[extrastereo=m=0]"

Then just seek wildly and it should get stuck.

[RandomGuy456]

Can confirm. It's simply stuck after some random seek:

I think it's better to reply also in this thread: mpv-player/mpv#6794

EDIT: @shinchiro this issue it's fixed thanks to this:

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

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

(thanks to @onomatopellan)

Can you implement this fix for future updates?

[xnoreq]

The issue is not really fixed though. Any idea why it hangs with winpthreads since the aforementioned version?

[onomatopellan]

@xnoreq @shinchiro After looking at it more closely these last 2 commits, especially this one, are the culprits of the freezes when using pthreads in ffmpeg. I just tried a build reverting those commits and have no more freezing using pthreads.

[NotTsunami]

@shinchiro @onomatopellan The offending change has now been reverted in the winpthreads library as of September 2nd: https://github.com/mirror/mingw-w64/commits/master/mingw-w64-libraries/winpthreads/src/cond.c

We should be safe to reenable pthreads now if we're using master branch.