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.

Sign up for GitHub

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

Jump to bottom

Streams initially show audio-only poster on Chromecast #969

Closed
theodab opened this issue Aug 14, 2017 · 3 comments
Closed

Streams initially show audio-only poster on Chromecast #969

theodab opened this issue Aug 14, 2017 · 3 comments
Assignees
@theodab
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone
v2.2.0

Comments

@theodab
Copy link
Contributor

theodab commented Aug 14, 2017

It looks like when the cast receiver is initially buffering, it mistakenly believes the asset is audio-only (presumably due to not having any streams loaded at all) and shows the audio-only poster. It plays the video as expected once it loads fully.
@theodab theodab added the type: bug Something isn't working correctly label Aug 14, 2017
@theodab theodab self-assigned this Aug 14, 2017
@joeyparrish
Copy link
Member

We should double-check this against the nightly build of the receiver. The introduction of isAudioOnly in #942 may have addressed this for v2.2, in which case we just need a quick fix for v2.1.x.

@joeyparrish
Copy link
Member

Looks like this just needs a quick fix for v2.1.x. The bug can't be reproduced on master.

joeyparrish added a commit that referenced this issue Aug 16, 2017
@joeyparrish
Add player.isAudioOnly()
104f1a7 
This simplifies detection of audio-only content and makes the process
a little more obvious.

Closes #942

Backported to v2.1.x for issue #969

Change-Id: I89b599fb8c8915c9e1b45d2f9b81a3ac7193e5ef
@joeyparrish
Copy link
Member

The original fix (isAudioOnly()) was trivial to cherry-pick to v2.1.x, so I went ahead with that.

The ready isAudioOnly() fixes this is because the old method was checking the number of tracks with a video codec. If the number of tracks with a video codec was 0, it was considered audio-only. But this would also be true if the content manifest wasn't fully parsed yet (0 tracks total). The implementation of isAudioOnly() returns false if there are no tracks at all.

The cherry-pick will be available in v2.1.8.

@joeyparrish joeyparrish added this to the v2.2.0 milestone Aug 22, 2017
@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@theodab theodab

Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Milestone
v2.2.0
Development

No branches or pull requests
3 participants
@joeyparrish @shaka-bot @theodab