https://drive.google.com/file/d/1C1AVHp5LclV5jrNGwA4YX3mmZKJRjvfB/view?usp=sharing
https://drive.google.com/file/d/1yzPgEbLw4TyoQTnAiBdNWvMMiuBVNiNK/view?usp=share_link
https://drive.google.com/file/d/1C1AVHp5LclV5jrNGwA4YX3mmZKJRjvfB/view?usp=sharing
https://drive.google.com/file/d/1yzPgEbLw4TyoQTnAiBdNWvMMiuBVNiNK/view?usp=share_link
Did either build rectify the situation? I don’t experience the original issue so I can’t test myself.
i have the true hd audio issue using plex htpc and using one of the earlier posted mpv builds above sorts this for me.
I can test my build in about a week when I´m back at home again. I will report back.
Which one? Are you referencing a build in Dolby TrueHD passthrough - modified mpv build - #61 by Mitzsch? If so, it’d be helpful to know which sorted it for you and whether the other one had any effect.
I tried the 2560.zip and it fixed the GOTG V2, 18:27 audio-related frame freeze but I lost the fast forward, pause, etc. pop-up controls within the movie.
I then tried the non-2560 which also did not have controls within the movie so I didn’t test the audio.
Unfortunately, I don’t have the logs, but can recreate and send them later if you need them
Just checked my downloads and its this one that im using.
mpv-dev-x86_64-v3-20230114-git-6cdce9e-old-truehd-spdifenc+commits.zip
Was this by any chance HDR content and using HDR metadata passthrough? Could be its missing the MPV patch to add arguments to overlays.
Can you test the builds in Dolby TrueHD passthrough - modified mpv build - #61 by Mitzsch? This is important because if these builds work for you, this is a patch that we can get into FFmpeg properly and remove the need to use a custom build just to fix a passthrough case.
The builds indeed are missing the mpv patch. It was faster for me to provide those builds without any mpv modifications. I should have stated that.
[quote=“gbooker02, post:68, topic:802742”]
Was this by any chance HDR content and using HDR metadata passthrough? Could be its missing the MPV patch to add arguments to overlays.
Yes and yes - GOTG V2. I also use the same daily build as Billybobm1. Let me know if you want any further testing.
OK, the UI will work with the modified builds if you turn off HDR Metadata Passthrough.
Won’t turning off HDR metadata passthrough negatively impact the HDR experience?
Right, but for testing (those also very experimental mpv builds) please turn it off and let us know how it behaves. ![]()
both the builds from post 61 have the same audio issue for me when skipping.
they will initially play true hd audio but skipping back and forth the audio will vanish and reappear on another skip.
(i grabbed the libmpv-2.dll file from both builds, and replaced the mpv-2.dll in my C:\Program Files\Plex\Plex HTPC directory).
switching back to the earlier build restores true hd audio for me with skipping.
i did not turn off the hdr metadata option. (the overlay vanished but skipping worked still)
im not sure who has this issue or what information is relevant.
ive only just started using plex htpc (long time plex media player user) to watch 4k hdr content on a new tv.
my old amp doesnt support 4k60 so im dual outputting from pc to tv and amp.
i first noticed this issue when true hd audio started dropping out while playing video and when skipping video.
originally i was using a hdmi splitter to connect to the amp. now im using a display port to hdmi adapter. the issue happens with both connection types.
lg oled 2022 tv.
pc with a nvidia 1080 gpu > tv at 4k60
pc > sony str dn1050 amp
I tested both and they fixed the audio bitstream barrier on GOTG V2. Also, no issue scrubbing back and forth. That’s the only test case I know of. If you have others and I have the movie, I’ll be glad to test them.
Update: The new build (2560) also fixed a screen freeze in GOTG V2 at 1:09:23. Didn’t test the other but assume it will also.
I watched GOTG 2 last night and had the film freeze issue at multiple points in the film. (4 i think)
this was using the mpv-dev-x86_64-v3-20230114-git-6cdce9e-old-truehd-spdifenc+commits.zip build.
I’ve retested this morning with the original included file and the padding.zip and padding-2560.zip.
On all 3 I still get audio drops occasionally and the FF/RW issue. The FF/RW issue is repeatable. The audio dropping in and out seems random.
The mpv-dev-x86_64-v3-20230114-git-6cdce9e-old-truehd-spdifenc+commits.zip build still works perfectly for me apart from in GOTG 2 at the high audio bitrate positions.
@Mitzsch
So I looked at some other implementations of spdif encoding and noticed a change with the size of the gap which is allowed between two TrueHD packets’ input_timing values. FFmpeg only allows 1/2 a MAT frame where others allow a gap of 2 MAT frames. So I created a patch to allow the larger gap. Doing so also requires an increase from 2 buffers to 3 to prevent data dropping in some circumstances (something the other implementation DID NOT do).
Additionally the other implementations treated the large gap different by throwing out the partially made MAT frame and start anew. They also throw out the new packet completely in this case (something my change does not do).
Anyway, give this patch a shot:
My test file, from a 4K BD rip of Incredibles 2, causes audio dropouts very consistently with the unmodified code. The above ceases the dropouts. I think seeks are faster but I may be imagining that. If I seek directly to one of the problem areas, I sometimes hear very tiny dropouts but only for the first second or so after that seek.
Thanks! I will give this one a shot tomorrow and will provide a build here.
As a side note, I also tested the two “modified padding” builds on my end and they behave the same as described by Billybobm1, skipping breaks everything. Well, let’s hope your patch will fix this!
There is a lot more hope that the above patch does indeed fix it. The difference is:
input_timing field means and its intended purpose. This field is the one responsible for determining the padding between access units and the Unusual frame timing.ffmpeg -i input.mka -c copy -f spdif output.ddwav for the curious) without the real-time playback requirements.Where as previously I was just making guesses as to what the code should be doing in this situation. There is still some guesswork as to what exactly is going wrong but the data does fit the theory. It’s likely a buffer overflow in the receiver (not the crash kind; the kind where it gets more data than it can store so it throws some out) because the spdifenc was ignoring the padding when the bitstream requested more padding than it expected.