Intermittent audio dropouts when bit streaming using Dolby ATMOS audio occur some time after seeking or chapter skipping. Also incorrect frame rate detected (23.953)

[movieperson]

Important Information

Provide following Information:

• mpv version: mpv-x86_64-20230709-git-fc3e28f
• Windows Version: Win 10 Pro 22H2 19045.3086
• Source of the mpv binary: https://github.com/zhongfly/mpv-winbuild
• If known which version of mpv introduced the problem: Unknown
• Possible screenshot or video of visual glitches: N/A

Reproduction steps

Describe the reproduction steps as precise as possible:

When playing a BD or UHD disc with a Dolby ATMOS audio track selected and using bit-streaming, any seeks or chapter skips will cause intermittent audio dropouts. These do not occur immediately after the chapter skip or seek, but usually begin several minutes later and with varying frequency.

Playing the same disk without any seeks or chapter skips does not show this issue. I also don't believe that this occurs when bit-streaming is disabled.

The movie used for the attached log files was "Mamma Mia, Here We Go Again" although I have seen the same issues occur on many different Dolby ATMOS titles after I have performed a chapter skip or seek.

Expected behavior: Normal playback

Actual behavior: Intermittent audio dropouts when bit-streaming Dolby ATMOS tracks.

Log files: I have provided two log files

TrueHD_audio_drops_no seek_chapters.txt was created by doing a complete showing of the movie with no user intervention.

TrueHD_audio_drop_seeks_chapters.txt was created by starting the movie, then performing several chapter skips and also several timed seeks just after starting playback. Playback was ended after a few occurrences of the audio dropouts.

Please note that the refresh rate which should be 23.976 is incorrect starting here in the TrueHD_audio_drop_seeks_chapters.txt log file:
71.253][v][vo/gpu-next/libplacebo] Estimated source FPS: 23.953, display FPS: 23.953
This may be the actual cause of the audio dropouts.

Make a log file made with -v -v or --log-file=output.txt, paste it to
https://0x0.st/ or attach it to the github issue, and replace this text with a
link to it.

The issue will be closed for ignoring the issue template.

Sample files

Sample files needed to reproduce this issue can be uploaded to https://0x0.st/
or similar sites. (Only needed if the issue cannot be reproduced without it.)
Do not use garbage like "cloud storage", especially not Google Drive.

TrueHD_audio_drops_no seek_chapters.txt
TrueHD_audio_drop_seeks_chapters.txt

[movieperson]

ffmpeg says they referred the incorect frame rate issue (23.952 vs 23.976) to MPV developers to fix as it is a bug in the SPDIF code.

https://trac.ffmpeg.org/ticket/9569

[movieperson]

I had this show up on another player on the same PC and this is what I found to be the cause in that scenario:

The only recent change on the PC was installing LAV Filters version 77.1. So basic PD, right - what has recently changed?
Downloaded, installed, and registered LAV Filters 76.1, and, like magic, no more audio drops with Atmos on Zoom Player.

[mitzsch]

Lav filters have a different truehd passthrough logic, that does not show the issue.

The ffmpeg issue is discussed here => https://forums.plex.tv/t/dolby-truehd-passthrough-modified-mpv-build/802742. There we also provided test build with possible fixes

[movieperson]

Isn't it about time this issue was addressed?

The test builds referenced there don't do anything for those of us with systems that cant support the V3 builds. Combine that with all the recent tone mapping improvements and going back to an earlier build is not an option.

What I likely will be doing is going back to a Directshow based player and using MadVR for tone mapping.

[mitzsch]

Isn't it about time this issue was addressed?

Well, it's more of a ffmpeg issue. I keep the modified code in a fork of ffmpeg here => https://github.com/mitzsch/FFmpeg. branch master-2 is the old truehd logic and master-3 the new patched one. (the one, discussed in the plex forum thread).

If you want to recompile it yourself this is possible with the https://github.com/mitzsch/mpv-winbuild-cmake repo. With the current version, it will compile mpv with the old logic. (there you can also build it yourself without the v3 extensions) I´m currently experimenting with making it selectable whether you want to compile ffmpeg/mpv with the old truehd (based on master-2) or with the new truehd code (based on master-3). I will upstream it as soon as possible.

[movieperson]

That's just the point. Recently, on AVS forum I've seen several other people complain about this issue. I'm pretty sure that they are not going to want to create a dedicated build environment and run it frequently as MPV is a moving target these days particularly with all the libplacebo tone mapping updates. Neither do I, though having an IT background I could probably do it.

IMHO, it's up to MPV to address this issue somehow. Maybe release another daily build version with all the latest source except for using the modified version of ffmpeg.

I certainly don't have the answers, but I certainly would like to be able to use MPV when I have guests in my HT, knowing that if a guest tells me "Wait, I missed that, can we go back a few minutes?" that I have to either tell him no or restart the movie with a Directshow based player to accommodate their request, particularly now that Atmos is used on most UHD discs.

[llyyr]

IMHO, it's up to MPV to address this issue somehow. Maybe release another daily build version with all the latest source except for using the modified version of ffmpeg.

How much are you willing to pay?

I looked into it a bit more to be a bit more helpful, here's the related ffmpeg ticket where you could request for the linked patch to be merged. It doesn't seem like the patch is a complete fix, but it doesn't appear to regress anything so it should still be fine. I don't think mpv can do anything about this, certainly not another daily build just for one user.

[Dudemanguy]

Seems upstream? Not sure what can be done. This is the kind of setup not too many developers have which makes it even harder to try and deal with.

[movieperson]

It's not just one user, it's anybody who is bitstreaming. From AVS forum a couple of days ago:

MidnightWatcher said:
Well, I tried audio-exclusive=yes last night but Atmos tracks still cut out while seeking during playback. I thought maybe Windows had "Allow applications to take exclusive control of this device" disabled but it's enabled. I also tried ao=wasapi but still the same issues on my end.

I posted the following on the ffmpeg site:

Are you ever going to address this issue?

The issue has been addressed in LAVFilters, why is it still an issue in ffmpeg?

I opened a ticket with MPV, they say they cannot fix an issue caused by an issue in ffmpeg.

The response from MPV follows:

"...looked into it a bit more to be a bit more helpful, here's the related ffmpeg ticket where you could request for the linked patch to be merged. It doesn't seem like the patch is a complete fix, but it doesn't appear to regress anything so it should still be fine. I don't think mpv can do anything about this, certainly not another daily build just for one user.'

Could you please consider merging the patch into the daily releases so others can take advantage of the existing workaround / fix.
Modify Ticket

We'll see what happens I guess.

[dyphire]

Could you please consider merging the patch into the daily releases so others can take advantage of the existing workaround / fix.

This is an issue with ffmpeg and should be fixed there. I don't understand why you strongly demand that MPV developers provide repair patches.
If you don't have the conditions to build your own MPV version with patches, what you should do is open a request on https://github.com/shinchiro/mpv-winbuild-cmake to add ffmpeg patches.

By the way, not long ago I added the relevant ffmpeg patch to the compilation script: dyphire/mpv-winbuild-cmake@1875b52. And build it on Github Action, you get it in https://github.com/dyphire/mpv-winbuild/releases.

[adolfotregosa]

https://trac.ffmpeg.org/ticket/10948

editing ffmpeg spdifenc.c and commenting out:
/* sanity check */
//if (padding_remaining < 0 || padding_remaining >= MAT_FRAME_SIZE / 2) {
// avpriv_request_sample(s, "Unusual frame timing: %"PRIu16" => %"PRIu16", %d samples/frame",
// ctx->truehd_prev_time, input_timing, ctx->truehd_samples_per_frame);
// padding_remaining = 0;
// }
Afterwards compiling ffmpeg and mpv with that change to ffmpeg seams to be fixing two issues for me. Spdif/passthrough to the AVR audio no longer cuts on the problematic spot and when seeking movie, audio is not going silent whereas it was becoming silent most of the time having one to keep seeking until audio eventually recovered.
Since I know very little of what am I doing hopefully someone who actually knows what they are doing has a look at this and implements a proper fix.