Skip to content
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

Kodi 18.4 crashes with high bitrate TrueHD+Atmos audio stream #16704

Closed
2 of 7 tasks
HomerJau opened this issue Oct 3, 2019 · 55 comments · Fixed by #20339
Closed
2 of 7 tasks

Kodi 18.4 crashes with high bitrate TrueHD+Atmos audio stream #16704

HomerJau opened this issue Oct 3, 2019 · 55 comments · Fixed by #20339
Assignees
Labels

Comments

@HomerJau
Copy link

HomerJau commented Oct 3, 2019

Bug report

Describe the bug

When playing either an MKV or MKA file containing high bitrate (16,000kps) audio stream with HDMI pass-through Kodi 18.4 crashes: after a couple of seconds and audio begins to stutter.

I can replicate on Intel NUC8i3 (LibreElec 9.2), Odroid N2 (CoreElec latest nightly) and Windows 10 Pro (Kod 18.4 x64).

I have been playing Atmos music blu-ray rips to MKA and MKV successfully (actually I have had very occasional audio dropouts). These Atmos+TrueHD streams are usually around 7000kbps max. I have just converted the new The Beatles - Abbey Road 50th Ann. Blu-ray Audio and the Atmos stream is 16,000kbps. These files crash Kodi.

The same file playback without issue in Foobar2000.

Expected Behavior

Here is a clear and concise description of what was expected to happen:

These files should bitstream via HDMI to my Denon AVR and play in full Atmos without crashing Kodi and without any audio dropouts.

Actual Behavior

After selecting a file (in the library or simply a file), Kodi starts playing the crashes after a couple of seconds and after audio is heard for a few microseconds or so. Kodi in Windows crashes back to Windows. Kodi on Linux crashes then re-starts at the main Kodi menu.

Possible Fix

Reading the logs it looks like there's a cache reading problem?

The the Kodi Crash log for the MKV I see this:

2019-10-01 10:50:30.682 T:140475424659200 DEBUG: CDVDInputStreamFile::SetReadRate - set cache throttle rate to 3123413 bytes per second

Is this cache throttle rate too small for 16,000kbps file?

To Reproduce

Steps to reproduce the behavior:

Change Audio Settings to use HDMI Pass-through and set the AVR Surround format to TrueHD enabled

Download the two small 30 second sample files here:
https://drive.google.com/drive/folders/1E1EGkP-Kv5IbPufU1ByMFHBf0MYqaCv0?usp=sharing

  1. Copy the sample mka to a Kodi audio source

  2. Play the file (from Music menu)

  3. Kodi crashes

  4. Copy the sample mkv to a Kodi video source

  5. Play the file (from Video menu)

  6. Kodi crashes

Debuglog

The debuglogs can be found here:

LibreElec 9.2 on NUC8i3 playing MKA file:
https://paste.kodi.tv/efoqikuhax.kodi

LibreElec 9.2 on NUC8i3 playing MKV file (same audio stream)
https://paste.kodi.tv/konunolupo.kodi

Kodi 18.2 on Windows x64 palying MKA file:
https://paste.kodi.tv/qibofewuja.kodi

Screenshots

Here are some links or screenshots to help explain the problem:

Additional context or screenshots (if appropriate)

Here is some additional context or explanation that might help:

Your Environment

Used Operating system:

  • Android

  • iOS

  • Linux

  • OSX

  • Raspberry-Pi

  • Windows

  • Windows UWP

  • Operating system version/name:

  • Kodi version:
    18.4 latest official (LibreElec 9.2 and Windows 10 Pro x64)
    18.4 CoreElec Nightly dated 1 Oct 2019

note: Once the issue is made we require you to update it with new information or Kodi versions should that be required.
Team Kodi will consider your problem report however, we will not make any promises the problem will be solved.

@xbmc-gh-bot xbmc-gh-bot bot added the Triage: Needed (managed by bot!) issue that was just created and needs someone looking at it label Oct 3, 2019
@HomerJau
Copy link
Author

HomerJau commented Oct 3, 2019

Here's the audio codec info from mediainfo:

Audio

ID : | 1
Format : | MLP FBA 16-ch
Format/Info : | Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : | Dolby TrueHD with Dolby Atmos
Codec ID : | A_TRUEHD
Duration : | 30 s 73 ms
Bit rate mode : | Variable
Bit rate : | 11.9 Mb/s
Maximum bit rate : | 16.3 Mb/s

Channel(s) : | 8 channels
Channel layout : | L R C LFE Ls Rs Lb Rb
Sampling rate : | 48.0 kHz
Frame rate : | 1 200.000 FPS (40 SPF)
Compression mode : | Lossless
Stream size : | 42.7 MiB (99%)
Title : | Surround 7.1
Language : | English
Default : | No
Forced : | No
Number of dynamic objects : | 15
Bed channel count : | 1 channel
Bed channel configuration : | LFE

@KarellenX KarellenX added Component: Audio Component: Music Component: Video Triage: Confirmed issue has been reproduced by a team member v18 Leia and removed Triage: Needed (managed by bot!) issue that was just created and needs someone looking at it labels Oct 3, 2019
@KarellenX
Copy link
Member

I was able to confirm this issue using the posted sample files.

System Win10; v18.4 passthrough enabled into Denon amp.

mkv file played via video library. Log line 1459... https://paste.kodi.tv/udimihedoz.kodi

mka file played via music library. Log line 1581... https://paste.kodi.tv/gazorimahe.kodi

@MilhouseVH
Copy link
Contributor

I know this mentions Atmos in addition to TrueHD, but I wonder if the underlying issue (whatever that may be) is also the cause of #16096

@KarellenX
Copy link
Member

KarellenX commented Oct 3, 2019

I did wonder that also and it is quite possible, but from my limited knowledge the errors in the log seem different, but you would know better than me :)

anssih added a commit to anssih/xbmc that referenced this issue Oct 20, 2019
CAEBitstreamPacker and CDVDAudioCodecPassthrough copy TrueHD frames into
buffers without checking for overruns.

Fix that.

This should fix crashes of issue xbmc#16704.

However, audio dropouts still remain. To fix those, the TrueHD packet
offsets will need to be dynamically scaled based on the input_timing
field (TrueHD bytes 2-3) which allows determining the amount of time
required between the previous frame and the current frame.
anssih added a commit to anssih/xbmc that referenced this issue Oct 20, 2019
CAEBitstreamPacker and CDVDAudioCodecPassthrough copy TrueHD frames into
buffers without checking for overruns.

Fix that.

This should fix crashes of issue xbmc#16704.

However, audio dropouts still remain. To fix those, the TrueHD packet
offsets will need to be dynamically scaled based on the input_timing
field (TrueHD bytes 2-3) which allows determining the amount of time
required between the previous frame and the current frame.
@anssih
Copy link
Member

anssih commented Oct 20, 2019

I created PR #16813 that should fix the crash.

Audio dropouts still remain. Those will be much harder to fix. I do have a WIP patch for ffmpeg that makes the audio work, but will still have to clean it up and get the fix in Kodi codebase as well.

@HomerJau
Copy link
Author

Thanks for the update Anssi.

Hopefully the crash fix and the ffmpeg update to fix Atmos skipping when complete can be merged back into Kodi 18.

@danieldjewell
Copy link

I think I found a related issue -- Kodi 18.4 on Android (NV Shield TV) doesn't crash but the audio does cut out during what I presume to be high bitrate parts.

I'll see if I can't test some more but thought it might be related to this.

@V33m
Copy link

V33m commented Nov 6, 2019

How is the feedback over at OSMC given it has been pushed to general release? There are three samples with stuttering over at CoreELEC forum if you guys need any more samples for debugging: TrueHD with Dolby Atmos 7.1 sound skipping (11Mbps audio bit rate)

anssih added a commit to anssih/xbmc that referenced this issue Dec 21, 2019
CAEBitstreamPacker and CDVDAudioCodecPassthrough copy TrueHD frames into
buffers without checking for overruns.

Fix that.

This should fix crashes of issue xbmc#16704.

However, audio dropouts still remain. To fix those, the TrueHD packet
offsets will need to be dynamically scaled based on the input_timing
field (TrueHD bytes 2-3) which allows determining the amount of time
required between the previous frame and the current frame.

(cherry picked from commit 0e76bd0)
@anssih
Copy link
Member

anssih commented Dec 29, 2019

The TrueHD passthrough crashes should now be fixed in Kodi master as of 2019-12-22 d29c84c, and on Kodi 18.x (Leia) nightlies as of 2019-12-26 51eff91.

I'm sorry for the delays.

However, as noted previously, audio dropouts still remain, so I'll keep this issue open.
The needed changes are known but they will unfortunately take some time to implement.

@danieldjewell
Copy link

So, to add what I can: I've noticed dropouts on TrueHD/Atmos high bitrate streams only (and only during what I would assume are higher than normal levels of audio data -- I haven't researched if TrueHD/Atmos streams are ultimately a variable bitrate [i.e. during particularly "noisy" sections the amount of audio data goes up, but I'm thinking yes?]....) I initially thought that it was my A/V receiver not being able to process the stream but it's TrueHD/Atmos certified so...

@dabl2
Copy link

dabl2 commented Feb 6, 2020

However, as noted previously, audio dropouts still remain, so I'll keep this issue open.
The needed changes are known but they will unfortunately take some time to implement.

As I understand it the needed changes that are known to fix the audio dropouts are related to ffmpeg correct?

Might you (or anyone else) have a link to the status and/or discussion on what stage the version of ffmpeg with those changes is at?

@HomerJau
Copy link
Author

HomerJau commented Feb 9, 2020

@anssih
Copy link
Member

anssih commented Feb 11, 2020

Yep, that link is good.

I have also some very rough work-in-progress code for FFmpeg here which seems to work, but doesn't trivially port over to Kodi as we have completely different code doing that.

@KarellenX
Copy link
Member

KarellenX commented Feb 11, 2020

Is this a related issue?
https://forum.kodi.tv/showthread.php?tid=351405

I have been able to replicate the reported problem on my setup.
log is here...
https://privatebin.net/?8f42f222610c9699#F66gbYFddjAwnDn6XP49NGEhdViFbUj51mVhrNUeo7gi

@anssih
Copy link
Member

anssih commented Feb 20, 2020

I've just applied a fix for this in FFmpeg: https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/36e156bef02566d70cea46cc5e00b3e5d5ed3286

I intend to port it over to Kodi next.

@KarellenX It is not - this is a TrueHD-only issue.

@anssih
Copy link
Member

anssih commented Feb 20, 2020

I pushed some initial work into https://github.com/anssih/xbmc/tree/truehd-wip.

It doesn't work yet (or at least I still got dropouts) - I suspect one of the "BUG" comments I added in ActiveAESink.cpp describe the cause (and they might be non-trivial to fix due to the assumptions in the existing code).

@budtz
Copy link

budtz commented Jul 17, 2020

Any news on this? Is kodi just not gonna work with disney Blu-ray anymore? Very sad but I guess there isnt the time.

@Krobar
Copy link

Krobar commented Aug 24, 2020

Also interested in this. Am I right in saying this is too big of a change for a patch release and not currently scheduled for Matrix either?

@fritsch
Copy link
Member

fritsch commented Aug 24, 2020

No, you are wrong. The fix can go in every time, but as of now no one has the time working on it and as we have seen it's not trivial for the way kodi implements packing and syncing of PT, which is currently fixed size for truehd.

@dshokouhi
Copy link

Is it a huge change to do if we wanted to do a quick and dirty fix for the shield only? I know Kodi wants to support all platforms but if we can help a handful of users that would be really great. If anything just as a proof of concept that it can be fixed in one place. I don't know much of the Kodi architecture but thought I would ask. It does seem like a big change but wanted to ask the experts :)

@fritsch
Copy link
Member

fritsch commented Aug 25, 2020

If it's done for the shield it's done for the rest as well, as they share the code.

But as you talk about the WE, go ahead and let's see what WE can come up with.

@bendavid
Copy link
Contributor

@anssih I was going to take a look at this, but actually your commit ( anssih@2a21581 ) already fixes the audio drops in the clips I was testing. Can you point me to some content which still had issues?

@hugepants
Copy link

This discussion mentions some example scenes in Frozen 2 and The Incredibles. I believe several Disney movies are affected.

@depechefan
Copy link

If you are able to find a sample from The Beatles, Abbey Road in Dolby Atmos then that is a great way to test. Let me know if you need me to put something together for you to test with.

@bendavid
Copy link
Contributor

Ok, so anssih@2a21581 makes the situation SIGNIFICANTLY better. There are still occasional skips in Abbey Road, and I confirmed by counting invocations of CAEPackIEC61937::PackTrueHD that the two "BUG" comments at anssih@2a21581#diff-05e1b56df10155e0212d39b1d73fe66aa0712448de99811146e47688c9614b3bR944 and anssih@2a21581#diff-05e1b56df10155e0212d39b1d73fe66aa0712448de99811146e47688c9614b3bR952 are related in that both of those issues appear right around where the skipping occurs. (e.g. cases with 2 or 0 invocations of CAEPackIEC61937::PackTrueHD adjacent to each other.)

I'll need to understand the code a bit better before I can fix it properly.

If it takes a while it's probably worth already taking the existing commit for the moment since that will likely raise the bitrate threshold at which problems occur.

@HomerJau
Copy link
Author

HomerJau commented May 18, 2021

Apologies. I had removed the original samples with issues. The link in my OP is now changed:

https://drive.google.com/drive/folders/1E1EGkP-Kv5IbPufU1ByMFHBf0MYqaCv0?usp=sharing

30 sec samples: MKV and MKA file with Atmos
at Maximum bit rate : | 16.3 Mb/s:
Frame rate : | 1200.000 FPS (40 SPF)

@dabl2
Copy link

dabl2 commented May 18, 2021

Bless you anssih and bendavid for picking up the flag on this. Would love to see this bug get squashed.

@apguy
Copy link

apguy commented May 18, 2021 via email

@Deamaed
Copy link

Deamaed commented May 26, 2021

Ok, so anssih@2a21581 makes the situation SIGNIFICANTLY better. There are still occasional skips in Abbey Road, and I confirmed by counting invocations of CAEPackIEC61937::PackTrueHD that the two "BUG" comments at anssih@2a21581#diff-05e1b56df10155e0212d39b1d73fe66aa0712448de99811146e47688c9614b3bR944 and anssih@2a21581#diff-05e1b56df10155e0212d39b1d73fe66aa0712448de99811146e47688c9614b3bR952 are related in that both of those issues appear right around where the skipping occurs. (e.g. cases with 2 or 0 invocations of CAEPackIEC61937::PackTrueHD adjacent to each other.)

I'll need to understand the code a bit better before I can fix it properly.

If it takes a while it's probably worth already taking the existing commit for the moment since that will likely raise the bitrate threshold at which problems occur.

Hi there. I am not a coder, but am using 17.7 DS Player with MadVR (and external LAV filters) to get everything working properly, and it's finicky. I'd prefer to use Kodi 19.

If there is a way to test this, including in Kodi 19 - I'd be happy to test it. I have several of the usual suspects to test, for example, Frozen 2, Zootopia, that have repeatable dropouts at set spots. EDIT: I mean to clarify that I have no idea how to integrate and rebuild the code with these test fixes.

Let me know. I think the user group that has Atmos setup is likely fairly low relative to the total userbase.

@apollolucas
Copy link

@anssih @bendavid Any update on this bug? How about bendavid’s suggestion to use the existing commits of anssih to remedy the situation somewhat? As more and more BD movies use higher bitrates this will become a major problem for Kodi users. I’ve been experiencing the bug on many more of my ripped movies lately (not limited to Disney anymore).
I really appreciate your efforts and help!

@Deamaed
Copy link

Deamaed commented Jul 3, 2021

@anssih @bendavid Any update on this bug? How about bendavid’s suggestion to use the existing commits of anssih to remedy the situation somewhat? As more and more BD movies use higher bitrates this will become a major problem for Kodi users. I’ve been experiencing the bug on many more of my ripped movies lately (not limited to Disney anymore).
I really appreciate your efforts and help!

In my post above - I was just trying to get guidance on how you can actually integrate ansshi's commits into the current Kodi to test? It appears bendavid did this - I just don't know enough to do this, but would be willing to test as I have several movies that I know the spots that skip and would be able to test the impact.

@Deamaed
Copy link

Deamaed commented Jul 30, 2021

Just as a follow-up, I decided to try an amateur job of making a new build of Kodi using the changes proposed by anssih. I was using the current version of Kodi and that version would cause no audio, or the video to freeze. Perhaps I made an error in making the changes or just in creating the exe.

I'm curious if @bendavid incorporated this code into an older version of Kodi, or the newest one. I'd be happy with even a half reduction in the dropouts.

@apguy
Copy link

apguy commented Oct 2, 2021

Still having this problem. Normally it's tolerable. One or two dropouts per movie.

Today I watched free guy. So many dropouts it was unwatchable. Had to turn off bitstreaming and therefore listen to straight 7.1 instead of atmos

@R0000
Copy link

R0000 commented Oct 2, 2021

Today I watched free guy. So many dropouts it was unwatchable. Had to turn off bitstreaming and therefore listen to straight 7.1 instead of atmos

Yes I had the same issue with Free Guy (on an nvidia shield). However VLC on it actually worked well (had judder in a couple of scenes though). My version was Dolby Digital+ 7.1.

@C4Wiz
Copy link

C4Wiz commented Oct 2, 2021

yep, this siiue is very old and getting worse! the bad news is KODI drvs just don't care about such a core feature. new versions with the same issue is more importaint!

it started in 18, still present in 19, and guess what......still present in 20.

what a joke......my advise is to move to a player with a native player that does not have this issue. look at zidoo

@apollolucas
Copy link

Free Guy is indeed unwatchable with Atmos. Been noticing this problem more and more lately with newer movies. Kind of starts to make Kodi obsolete now.
Hoping that if more people post here the Devs will show mercy and pick it up again.
As others have suggested I’d be willing to donate to get this problem fixed.

@simonk83
Copy link

simonk83 commented Oct 6, 2021 via email

@xbmc xbmc locked and limited conversation to collaborators Oct 6, 2021
@lrusak
Copy link
Contributor

lrusak commented Oct 6, 2021

+1's and me too's don't help here so I'm going to lock the thread to devs only.

No one is actively working on this from Team Kodi that I'm aware of so I'll leave it open for now.

For the non devs please take your conversation to the forum. Thanks.

@thexai thexai added v19 Matrix v20 Nexus Triage: Has proposed fix Issue has been reproduced and has a pending proposed fix and removed Triage: Confirmed issue has been reproduced by a team member labels Oct 18, 2021
@thexai thexai added the Resolution: Fixed issue was resolved by a code change label Oct 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet