• 1
  • 5
  • 6
  • 7(current)
  • 8
  • 9
  • 11
Release TrueHD passthrough Test Builds - New MAT Packer implementation
#91
(2024-05-15, 19:32)Draconix Wrote: Both of those workarounds aren't worth it for me. I think Kodi is way better than VLC and I don't want to lose Atmos or Dolby Vision.
Totally understandable, my understanding however is those AC3 compatibility tracks will mean you lose the clarity of TrueHD, rear channels of 7.1 and the Atmos data anyway, so at least this way you're only losing the Atmos, although still not ideal.
Reply
#92
(2024-05-16, 02:20)RedTwenty50 Wrote: Totally understandable, my understanding however is those AC3 compatibility tracks will mean you lose the clarity of TrueHD, rear channels of 7.1 and the Atmos data anyway

It's an E-AC3 compatibility track (Dolby Digital Plus with Atmos) and it sounds pretty good to be honest. Still it would be nice to fix this issue, but it's not super important.
Reply
#93
(2024-05-16, 02:26)Draconix Wrote: It's an E-AC3 compatibility track (Dolby Digital Plus with Atmos) and it sounds pretty good to be honest. Still it would be nice to fix this issue, but it's not super important.

Yeah, didn't know you meant the E-AC3 compatibility track, that pretty much works for the most part then until hopefully the issue is fixed (albeit it looks like your one may have another issue in the background on top)
Reply
#94
New build that "compensates" TrueHD error instead of change threshold. Also includes log code to track error all the time (will be removed in the final version).

ARM64:
https://mirrors.kodi.tv/test-builds/andr...64-v8a.apk

ARM:
https://mirrors.kodi.tv/test-builds/andr...bi-v7a.apk

Windows x64:
https://mirrors.kodi.tv/test-builds/wind...ga-x64.exe


Is recommended test it without any <maxpassthroughoffsyncduration> in advancedsettings.xml (self-learning)

Test with Cars 5m .mkv and post debug log.

If the error does not exceed +-100 at any time then there should be no a/v adjust or dropout.

If in the first round works, change <maxpassthroughoffsyncduration> to desired value e.g. 96  (personally I'm using 62)
Reply
#95
(2024-05-16, 16:58)jogal Wrote: New build that "compensates" TrueHD error instead of change threshold. Also includes log code to track error all the time (will be removed in the final version).

ARM64:
https://mirrors.kodi.tv/test-builds/andr...64-v8a.apk

ARM:
https://mirrors.kodi.tv/test-builds/andr...bi-v7a.apk

Windows x64:
https://mirrors.kodi.tv/test-builds/wind...ga-x64.exe


Is recommended test it without any <maxpassthroughoffsyncduration> in advancedsettings.xml (self-learning)

Test with Cars 5m .mkv and post debug log.

If the error does not exceed +-100 at any time then there should be no a/v adjust or dropout.

If in the first round works, change <maxpassthroughoffsyncduration> to desired value e.g. 96  (personally I'm using 62)

I did a single quick test for Cars mkv using sync value 62, looks promising: I did not experience any clear frame or audio drop outs, a/v corrections only 1 when start/enabling debug OSD.

This is better than any previous versions where its mkv or m2ts I get every time at least one frame/audio drop & more corrections no matter of settings.

EDIT: Without setting maxpassthroughoffsyncduration also perfect: no frame/audio drops, no corrections
Reply
#96
(2024-05-16, 16:58)jogal Wrote: New build that "compensates" TrueHD error instead of change threshold. Also includes log code to track error all the time (will be removed in the final version).
Awesome! Thank you for making this, hopefully the error logging code can help pinpoint where the issue is for my setup.
 
(2024-05-16, 17:56)Koder123 Wrote: I did a single quick test for Cars mkv using sync value 62, looks promising: I did not experience any clear frame or audio drop outs, a/v corrections only 1 when start/enabling debug OSD.

This is better than any previous versions where its mkv or m2ts I get every time at least one frame/audio drop & more corrections no matter of settings.
Thats really great to hear, I think @jogal is definitely on the right track with this build!

Here are the logs from my test:
no maxpassthroughoffsyncduration: https://paste.kodi.tv/ovicogocen.kodi
96 maxpassthroughoffsyncduration: https://paste.kodi.tv/wamecudisu.kodi

I still hear the 3 dropouts that happen at the exact spots as usual (the first dropout always happens right after the Cars logo). If I rewind after a dropout, it plays that part fine.
So it seems likely that there's some issue with my specific Shield or AVR. Still I'm hoping that the new error tracking code can help @jogal see what's happening on my end.
Reply
#97
Thanks Jogal for the new build and your continued efforts, I definitely appreciate your hard work in trying to fix this issue. I have tried Cars as suggested and here is my error log.
 
(2024-05-16, 22:20)Draconix Wrote: I still hear the 3 dropouts that happen at the exact spots as usual (the first dropout always happens right after the Cars logo). If I rewind after a dropout, it plays that part fine.
So it seems likely that there's some issue with my specific Shield or AVR. Still I'm hoping that the new error tracking code can help @jogal see what's happening on my end.
I can confirm that this part right after the Cars logo at 2:12 - 2:22 minutes in, cut out for me as well but a rewind doesn't solve it and I have to restart the file. This was occurring with the 20240513 build as well, but while the second time running Cars on that build got past this point with a skip, on this build it will still cut out. The log has these two attempts, and then I fast-forwarded past that point, in which then it seemed to work smoothly.

I have only been using the self-learning option and not any advancedsettings in the past as well, and also didn't use it now due to the first round not working out as directed.

Again recorded some timestamps:
Sometime at 12:53 - Cutout on first attempt
12:55:45 - Cutout on second attempt
Reply
#98
I am pretty sure that after Cars logo at 2:22 there is no audio drop - it is a pause/silent part in the actual song, just saying lol. https://www.youtube.com/watch?v=X3HlFewKByw 1:00 - 1:01
Reply
#99
(2024-05-17, 09:52)Koder123 Wrote: I am pretty sure that after Cars logo at 2:22 there is no audio drop - it is a pause/silent part in the actual song, just saying lol. https://www.youtube.com/watch?v=X3HlFewKByw 1:00 - 1:01

It is 100% an audio dropout for me, its very very noticeable and even makes a slight popping sound. I can immediately rewind it so that part plays without the drop, the difference is very obvious.
Reply
I am very satisfied with the last build and logs says all sync adjustments has been eliminated: CDVDClock::ErrorAdjust or ActiveAE::SyncStream and all debug logs posted are very similar.

There no dropouts exist that can be explained with debug log, then only can be attributed to external causes (different Shield settings, AVR, TV, etc.) maybe bitstrem generated is not compatible with some AVRs (in Denon AVR-X1600H for sure it works).

Also is confirmed that large padding blocs not cause a/v sync issues. At contrary, stream starts with -70 ms error and ends after 5 minutes with +5 ms error (with zero AE adjustments).

The same users who are having problems now were having problems with the previous MAT code. This alone rules out the MAT code itself.

I have done some more testing with MakeMKV v1.17.7 and now there are no problems when converting Cars Blu-Ray to MVK, it plays just as well as m2ts. This rules out MakeMKV (at least the latest version and I don't think they have changed anything right now).

The problems when playing from USB have also been solved (I can no longer reproduce the issues under these conditions, even with maxpassthroughoffsyncduration 96).

The seek has also improved considerably, that is, the audio returns much faster after seek because there is less error and no additional corrections are necessary.

It is true that there was a problem with the error calculation simply because the AE code does not aware that it is working with compressed data that is not distributed regularly in time. That is, the error in TrueHD MAT data does not corresponds to the real error (A/V ms diff) that it has once decoded to PCM.

Image

e.g. when are 5 MAT frames in queue this is 5 * 20 = 100 ms of error that is not real, aditionally 100ms due maxpassthroughoffsyncduration

100 + 100 ms = 200 ms of error which are equivalent to 100ms (max. threshold) in real life. This is the reason of apply a correction factor of /2.

This factor will probably have to be raised to ~2.25 to leave a margin of safety but this is not going to change things for those who have problems now.

This is the only thing that has been fixed now, i.e. before with TrueHD it was working all the time at the limit of stability with an error very close to 100 or -100 threshold. Any small variation caused unnecessary corrections that seconds or minutes later were repeated in the opposite direction. This also explains the randomness of the issues.

This fix can also be applied to Omega since in fact it is an independent thing that has no relation with the new TrueHD MAT code.
Reply
(2024-05-15, 12:22)Draconix Wrote: Can it really be the AVR even though the dropouts show up as errors in the debug log? I'd assume that if it's only the AVR's fault, I'd hear dropouts even if there are no errors in the log.

We have already reached this point: there are no longer visible errors in the log but you still have the same dropouts. Especially log with 96 ms:

96 maxpassthroughoffsyncduration: https://paste.kodi.tv/wamecudisu.kodi

The part of interest is: https://paste.kodi.tv/gegikowodu

Starts with -86 ms and ends with +5ms, all the time inside threshold (-100 to +100) with no AE corrections.

Additionally, MAT packing warning events (detected a stream discontinuity / large padding block) do not correlate with relevant A/V error variations.
Reply
(2024-05-17, 18:14)jogal Wrote: We have already reached this point: there are no longer visible errors in the log but you still have the same dropouts.

After reading your detailed explanation of the results, I definitely agree that it's very likely an issue with my specific AVR (Sony STR-DN1080). If I had a Denon AVR like the majority of people it would most likely play perfectly, especially with the changes that you made in this new test build.

I can say that this new test build is definitely a big improvement even with my flawed AVR. Before I would hear 4-5 dropouts in Cars (3 at the same spots and 1-2 random ones), now I only hear the ones in the 3 usual spots. These changes should definitely be merged into the nightly builds, as it looks like it should completely solve audio issues for 99% of people. Until I get a new AVR, I will just have to set Kodi to use the E-AC3 compatibility track on these kinds of problematic Blu-Rays (which are pretty rare anyways).

Thank you @jogal for all your hard work in making Kodi the ultimate media player!
Reply
jogal Wrote:It is true that there was a problem with the error calculation simply because the AE code does not aware that it is working with compressed data that is not distributed regularly in time. That is, the error in TrueHD MAT data does not corresponds to the real error (A/V ms diff) that it has once decoded to PCM.

Thanks for that. Makes sense.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
Things has not ended yet Sad

While in Free Guy the error is constant (with normal oscillations now attenuated with /2.25 factor) in Cars this error progressively increases... so with long playback duration 10 min - 20 min reaches the threshold  and corrections (frame skip / audio dropout happens again).

Graphics are 20 minutes playback time:

Image


Image


Even that, correction factor seems a valid improvement in all cases although something more will be needed for Cars.....
Reply
Interesting discovery, I'm ready to test any new builds if needed!
Reply
  • 1
  • 5
  • 6
  • 7(current)
  • 8
  • 9
  • 11

Logout Mark Read Team Forum Stats Members Help
TrueHD passthrough Test Builds - New MAT Packer implementation0