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

Atmos Audio Dropouts #3803

Closed
Balthazar2k4 opened this issue Feb 5, 2018 · 13 comments
Closed

Atmos Audio Dropouts #3803

Balthazar2k4 opened this issue Feb 5, 2018 · 13 comments
Assignees

Comments

@Balthazar2k4
Copy link

Balthazar2k4 commented Feb 5, 2018

Issue:
During playback of titles with higher than average (exceeding 11mbps on average) Dolby Atmos TrueHD-based bitrates, ExoPlayer v2 on the Nvidia Shield is dropping packets leading to moments of brief silence. This is a reproducible issue and is not a problem with the source material because when played back on a UHD-BD player or a certified software such as PowerDVD the dropouts do not occur.

Reproduction:
Playback linked content within Exo Player to an Atmos capable AV receiver.

Linked Content:
https://mega.nz/#!oJVzDDiZ
Decryption key: !VZSnDiayjtDl2RDCzNOV-kw6R3MV8bMwX3YXLMuXamg

Device: 2015 and 2017 Nvidia ShieldTV (firmware 6.3) on Android 7.0

Bug report forthcoming

@andrewlewis andrewlewis self-assigned this Feb 6, 2018
@andrewlewis
Copy link
Collaborator

Please could you try increasing the buffer size in DefaultAudioSink and let us know if that fixes the issue?

If that does fix it, we should probably just set the buffer size to the maximum allowed bitrate, assuming it's not too large. I haven't been able to find a specification saying what this value is, though. Do you or @drhill have any ideas about this? Thanks!

(Side note: I guess https://forum.kodi.tv/showthread.php?tid=327153 is your report too? I thought Kodi didn't use ExoPlayer. That makes me wonder if this is an issue with the passthrough implementation on these devices, or maybe they just use a too-small buffer size too.)

@Balthazar2k4
Copy link
Author

Yes, that is my post over at the Kodi forum. I decided to post the issue here, as well, since I also use Plex and they use ExoPlayer (albeit a modified version). I have asked the Plex devs to make the change you requested to the DefaultAudioSink to see if that works. There has been some discussion on the issue around the possibility that it is a Dolby MAT problem. Please see here for additional information: https://club.myce.com/t/atmos-audio-drop-outs-details-thread/399840

@IanDBird
Copy link
Contributor

Just wanted to confirm that we (Plex) had seen this GHI and discussing how to best test the suggested changes.

@drhill
Copy link
Contributor

drhill commented Feb 14, 2018

I have few Atmos tracks and no Atmos system to test with. I never had drop outs on TrueHD tracks though, only DTS-MA tracks prior to upping the buffer size.

@Balthazar2k4
Copy link
Author

Balthazar2k4 commented Feb 14, 2018 via email

@heccoder
Copy link

I have tested and was able to reproduce the issue with Atmos tracks (with Atmos capable receiver) and HEVC 4K video via Plex on Nvidia Shield. It does happen with Kodi as well on Android TV.

@IanDBird
Copy link
Contributor

It's worth noting that in Plex, we actually still use our own implementation of True HD passthrough, since official support was added only last month. We'll likely drop our version to adopt the one recently added. However, it does appear that we use a smaller buffer than the one add in 8e8e53c.

One question about the buffer calculation though:

bufferSize = (int) (PASSTHROUGH_BUFFER_DURATION_US * 192 * 6 * 1024 / C.MICROS_PER_SECOND);

Am I missing something, but the * 6 is for 6 channels, at a maximum of 192 Khz audio. But for True HD and DTS-HD, shouldn't that be * 8 If you really want to try and handle the "maximum"?

@andrewlewis
Copy link
Collaborator

@IanDBird There was some discussion on #2960.

@andrewlewis
Copy link
Collaborator

Apparently the maximum bitrate for DTS MA is 24.5 Mbit/s, which I think would require a buffer size of about 800 KB for our usual buffer duration of 250 ms (we currently request about 300 KB).

@jmone1
Copy link

jmone1 commented Jun 4, 2018

FYI - Nevcairiel has fixed this in the latest release of LAV - Nevcairiel/LAVFilters#208 (comment)

@Balthazar2k4
Copy link
Author

I can concur that Nevcairiel's fixes do work on PC.

ojw28 pushed a commit that referenced this issue Aug 1, 2018
There is some risk associated with this change, as audio track buffers come from
shared memory and limits may be device-specific. I've tested these sizes on
Nvidia Shield TV and Nexus Player on various builds. The maximum size allocated
is about 800 KB. We could implement support for retrying creating the audio
track if it fails to initialize, but it seems preferable to avoid the extra
complexity required to do that unless we know it's necessary to work around
device-specific limitations.

Issue: #3803

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=206749222
@ojw28
Copy link
Contributor

ojw28 commented Nov 5, 2018

@andrewlewis - Can this be closed now?

@andrewlewis
Copy link
Collaborator

I think we can close this on the assumption that the buffer sizes were too small before 7ead310. I tested the change using high bitrate content in various encodings on Nexus Player and Nvidia Shield.

@Balthazar2k4, @IanDBird, @drhill, @hjtech If you see issues with underruns after including the fix above please provide some sample content and a bug report on a new issue and we'll take a look. Thanks!

@google google locked and limited conversation to collaborators May 16, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants