Well, I tried your fix and indeed it seems to fix “every” issue. You are a genius. Thanks!!!
Files with 11mbit+: no problem
Seamless branching files: no problem
FW/RW: no problem
(It still logs the “unusual frame timing” thing but I guess we can now neglect this one)
The only somewhat strange behavior I got while testing (= mpv cli) is a drift on the A/V sync side, whenever the truehd bitrate goes up, the sync number goes up or down and a ct value comes up. With the old implementation, I have never seen this behavior. I will test with an upstream build, I guess I have seen it also there. (so no new “bug”)
Another thing where I´m not sure about is a very small audio dropout on seamless branching files, but not always, and when it occurs I´m not sure if it is part of the track or a real dropout. I will have an “eye” on that one. Maybe someone else can also check back?
Is this only when you perform a seek? Notice the log should now say assuming seek in it. If it’s only in a seek, then you can ignore it.
This is likely due to the way that the variable bitrate TrueHD wants to be sent to the AVR. It does send data faster than it can play at times so that it has space to use higher bitrate audio that is sent slower than it can play. This is part of the TrueHD standard (that’s what the input_timing field is for) Perhaps this is just showing that aspect?
I’d also like to hear if others hear this. Additionally, is the unusual frame timing logged during that?
No, it also appears on the seamless branching files, whenever such a spot is hit. For example, the file I sent you a while back also produces it. (well the original movie (=baywatch) file does, the sample file might be too short - have you tried the file?)
Ah! yes, didn´t notice it the first time!
Interesting, now I understand!
Update on that one, I just played my “benchmark - testing file” (=baywatch extended cut from german bd) which has two segments stitched together shortly after each other. The ct value also goes up quickly and is very high (0.08 to 0.110) - after the first segment its at about 0.06 and when it hits the second part it goes up to 0.110. There (shortly after) I noticed a “true dropout” - the audio was played but in a crippled manner - definitely not part of the track.
The ffmpeg message was not printed during this.
I will try. It is not a long continuous dropout, it’s a 0.1s dropout, then audio plays fine 0.1s, 0.1s dropout again, audio plays fine 0.1s, 0.1s dropout, and then audio continues to play fine - it’s somewhat (a hearable) stuttering.
To visualize this => = means audio is fine, + means dropout., | means seamless branching spot =|===+=+=+=+=====
This could be a buffer underrun (or overrun) in terms of the data sent to the AVR around the branch point. In the past you tried other software; does it exhibit the same?
I had stepped away from this thread for a while because it looked like it was solving an issue I wasn’t having (TrueHD breaking on seek) without addressing the issue I WAS having (TrueHD tracks exhibiting small drop outs that would present correctly when replaying the same section, making them very difficult to reproduce).
I have had a few logs mention buffer underruns, but not with any consistency; if the audio drops has happened to me 100 times, I maybe have seen 3 log entries stating the buffer underrun.
With that being said, I will download this most recent patch and see if it solves my issue and report back.
Edit 1: Well, first thing I ran into trying to swap the mpv-2.dll file like I’ve done with Mitzch’s previous stuff, I get
Kodi 19.5/20 => not playing the file at all (others work…) ##EDIT: reinstalled Kodi 20 and 20.1 and the file plays now but with audible dropouts
lavfilter => no dropouts (except for one case, where I rewinded and played at a new spot, there I got a dropout lasting 0.5s - I was never able to recreate this - I guess my external USB HDD (almost full and slow) was causing this)
PC to LG TV
mpv upstream => audible dropouts
mpv fix => no dropouts (maybe some, which can be easily missed if not focusing on hearing/trying to hear them)
Kodi 19.5/20 => no dropouts (maybe behave like mpv fix)
lavfilter => no dropouts (maybe behave like mpv fix)
Yes, it was the cacert.pem line. I recently changed drives and hadn’t added that line back like I’d done previously. I can begin testing to see if this new build fixes my issues with intermittent audio drops.
I’ve been using the same fix (mpv-dev-x86_64-v3-20230114-git-6cdce9e-old-truehd-spdifenc+commits.zip) since last posting and ive had no audio issues until tonight when i was watching the Avengers 2012. Towards the later half of the film i experienced plenty of audio drop outs.
Ill give the new fix a go and see how that works for me.
EDIT:
Just tried the latest version with GOTG2 and The Avengers
FF/RW works fine
GOTG2 Freeze is fine
Audio dropping out - happening in both GOTG2 and The Avengers. Again random and not repeatable if you rewind and replay the same section.
That’s all I did, yes. And made sure the cacert.pem line was present in my mpv.conf file.
Initial testing of build-15.02.2023-gbooker02-truehd-fix.zip has been positive. I have been watching Dragon Ball Super. Since I started trying to fix the issue, I have been keeping track of how long different troubleshooting configurations go without issue, and generally had hiccups every 3-6 episodes (meaning nothing I was changing within Windows or Plex was having an effect; Atmos vs 7.1, bios settings for performance CPU modes vs not, adding a buffer to mpv.conf, etc). With the build-15.02.2023-gbooker02-truehd-fix.zip DLL, I have watched 20 episodes and believe I have not had any audio drops.
While troubleshooting build-15.02.2023-gbooker02-truehd-fix.zip, I have actually taken to recording my viewing so that if something sounds weird I can go back and see if it is just the audio track itself or an actual gap, because I’m not certain if I’m actually hearing an error or just weeks of very critical listening has made me overly sensitive to audio track oddities haha. So far so good?
Edit: Clarifying which build I’m using per gbooker02’s request
That sounds great. I didn’t ever really have any terrible issues, but I occasionally had some dropouts. Never anything too bad or frequent, but I would certainly notice them. Always thought it was the soundbar, but maybe this will help.
Everyone, when mentioning you are trying this fix or that, please be explicit as to which one you are running. The changes across them are very different.
The build-15.02.2023-gbooker02-truehd-fix.zip is the only one that really has a chance of being merged into FFmpeg proper (because all others were reverting code that was intended to fix other issues).
Unfortunately there aren’t public spec on how to handle the edge cases so much of this is guess/check.
Log when using mpv-dev-x86_64-v3-20230114-git-6cdce9e-old-truehd-spdifenc+commits.zip playing The Avengers. (are you looking for anything specific in the log at the time the drop out happens?)
There was 2 random audio drop outs in around a minute.
I watched Edge of Tomorrow last night which had zero drop outs. (same build as above).
I just tried playing Star Trek 2009 with the same build and it drops outs a lot. That also has a DTS HD track so I tried that and it also drops out?
I switched to the latest build (build-15.02.2023-gbooker02-truehd-fix.zip) and it also was dropping out.
If you also have dropouts with DTS-HD there is probably something additional “wrong” with your System. On my end, I never had dropouts with DTS-HD with my very low-end AVR… (well, I did, but this was on linux and the kernel driver for that gpu was wip - a long time ago… different topic…) (it sounds more and more that this low-end AVR is the culprit for all the issues… but I mean when we can fix it there, it’s probably also fine/working on higher-end AVR hardware)
one additional note to mpv upstream, there the sync and ct value also drift, so nothing new is introduced with the patch.
Well, I encountered an audio drop out after 26 episodes, which amounts to a little over 9 hours of run time, compared to happening every 20 minutes to ~3 hours previously with either the vanilla build or any of Mitzsch’s reversions. Build-15.02.2023-gbooker02-truehd-fix.zip is definitely an improvement, but I don’t think it completely solves the issue yet. Is there any more guess and check work that can be done to improve, or any other data or test cases those experiencing the issue can provide?
For science, I have included a recording of what the error presents as for me. When the wolf guy gets dragged away, the word obliterated drops audio. Upon seeking backwards, it plays through fine. This error presents the same across two computers with different hardware. I do not have a second AVR to test on (Yamaha RX-A8A). I have not experienced this audio drop issue using VLC 3.0.4, which is the only other video software I will use on occasion (I haven’t updated due to a subtitles issue with HDR movies). VLC did garble the audio in the GOTG2 test clip earlier, so there’s clearly imperfections all around.
