-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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) #11910
Comments
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. |
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? |
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 |
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. |
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. |
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. |
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. |
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. |
It's not just one user, it's anybody who is bitstreaming. From AVS forum a couple of days ago: MidnightWatcher said: 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. We'll see what happens I guess. |
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. 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. |
https://trac.ffmpeg.org/ticket/10948 editing ffmpeg spdifenc.c and commenting out: |
Important Information
Provide following Information:
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
The text was updated successfully, but these errors were encountered: