Open ghost opened 3 years ago
The only time I've experienced this is when I've increased the audio buffer, and I was using a receiver to bitstream to.
Well here , don't even need a receiver...
I have just tested release build mpv-x86_64-20201220-git-dde0189 by Shinchiro, unfortunately the bug is still here :-(
Can someone please be so kind as to fix this, it really should be very easy to reproduce and to fix...
I can take a look at it soon'ish. The part of "Pass-through enabled but you don't actually want it" is a weird one, but if it starts working after a seek it makes sense to at least take a look at it.
The log of posted by @hatharry at least seems to make sense:
audio-spdif
.[ 0.598][v][ao] Trying audio driver 'wasapi'
[ 0.598][v][ao/wasapi] requested format: 192000 Hz, stereo channels, spdif-eac3
[ 0.598][d][ao/wasapi] Init wasapi
[ 0.598][d][ao/wasapi] Find device ''
[ 0.603][v][ao/wasapi] No device specified. Selecting default.
[ 0.605][v][ao/wasapi] Selecting device '{0e1984b3-225f-4ccb-9cf4-60a3b7b7a97c}' (Speakers (Realtek High Definition Audio))
[ 0.605][v][ao/wasapi] Monitoring changes in device {0.0.0.00000000}.{0e1984b3-225f-4ccb-9cf4-60a3b7b7a97c}
[ 0.612][d][ao/wasapi] Init wasapi thread
[ 0.612][d][ao/wasapi] Activating pAudioClient interface
[ 0.614][d][ao/wasapi] Probing formats
[ 0.638][v][ao/wasapi] Trying stereo spdif-eac3 (16/16 bits) @ 192000hz (exclusive) -> unsupported
[ 0.638][v][ao/wasapi] Retrying as AC3.
[ 0.639][v][ao/wasapi] Trying stereo spdif-ac3 (16/16 bits) @ 192000hz (exclusive) -> unsupported
[ 0.639][d][ao/wasapi] Thread shutdown
[ 0.639][d][ao/wasapi] Thread uninit done
[ 0.639][d][ao/wasapi] Uninit wasapi
[ 0.639][d][ao/wasapi] Thread return
[ 0.639][d][ao/wasapi] Uninit wasapi done
[ 0.711][e][cplayer] Passthrough format unsupported.
The output with seek file I did not check since I am this late in the evening lazy and do not want to download and extract a zip :P
The part of "Pass-through enabled but you don't actually want it" is a weird one
It's not weird. It simply means "Pass-through enabled but spdif hardware temporarily not selected in Windows or disconnected". It's a very powerful feature, available in mpv before september 2020, and in other players and DS filters.
This feature allows you to on-the-fly change the audio device in use, without having to remove "audio-spdif = AC3, DTS" from mpv.conf. Use it on your laptop. When Laptop is "docked" in your house to your digital receiver, set the spdif device as playback device in Windows. When you're out with your laptop, select the "speakers" device in Windows, and everything works. No need to change anything in mpv. You can even do that while playing, the playback continues without stopping.
If this powerful feature is lost, then this would be a very sad regression.
I noted that just to say that if you just read that bit of the report, you would gain raised eyebrows :) .
As I then noted, if it then works after you seek, then it makes sense to check it out. Similarly if this used to work.
Similarly if this used to work.
I do confirm that!
And I forgot to say Thanks for looking into it ;-)
Well, just to follow up, this is still not fixed in latest build as of Feb, 14 2021... 😕
In spite of commits https://github.com/mpv-player/mpv/commit/3f7d3d5804ef3dd76eb1aa76210619f96244920d and https://github.com/mpv-player/mpv/commit/fce994bdc473e73873fb8e9f4841004d073f43b4 this bug is still there :-(
BTW this issue still exists and it's not Windows specific either (can reproduce with ao=pulse
)
The responsible code is here:
https://github.com/mpv-player/mpv/blob/4c3ed843dc8bde419d8c08565159a83cee9e3b9b/player/audio.c#L468-L479
The issue is that after the reset it's in STATUS_SYNCING
with no ao created so the following code
https://github.com/mpv-player/mpv/blob/4c3ed843dc8bde419d8c08565159a83cee9e3b9b/player/audio.c#L921-L930
never does anything, causing audio to not advance.
A partial fix is to add ao_c->filter->ao_needs_update = true;
to the first linked code block. Then playback won't get stuck however upon reinit the AO chain is somehow still outputting spdif-ac3 (out_fmt
) so the AO fails again and it finally falls back to no audio.
(haven't debugged that last part or I would've pushed a fix)
Important Information
Provide following Information:
Reproduction steps
Expected behavior
It is expected that the file plays. It is expected that audio-spdif have no effect because it detects that the device is not S/PDIF.
Actual behavior
It remains stuck at 00:00:00.000. You can have it unstuck by simply seeking forward. After that, playing continues smoothly.
Things to know: With the exact same config and files, if you select an S/PDIF device, everything works smoothly, no bug If you remove audio-spdif=ac3,dts, everything will work smoothly, no bug (and no S/PDIF obviously). So it is the combination of audio-spdif=ac3,dts with NO S/PDIF device that is causing this issue.
With the exact same config and files, if you use an older version (before 20200906), everything works smoothly, no bug, in all the cases mentioned above.
Log file
Here is a log where I drop the file and keep it stuck 00:00:00.000 (meaning: I did not attempt to seek), then I close mpv: output with no seek.zip
Here is a log where I drop the file, it's stuck at 00:00:00.000, then I seek forward a bit, it's unstuck and the file is playing. Then I close mpv: output with seek.zip
Sample files
No need, any standard file with AC3, DTS, DTS-HD streams. It is possible also E-AC3 and True-HD show same behavior, but I have none of that kind to test.
Thank you!!