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

Fix audio only streams with EXT-X-MEDIA tags (somewhat) #34

Merged
merged 4 commits into from
Feb 20, 2018

Conversation

mjneil
Copy link
Contributor

@mjneil mjneil commented Feb 9, 2018

This PR addresses an issue that prevented the player from firing ended event for two different audio only stream scenarios. One when an audio only stream has EXT-X-MEDIA tags with type=AUDIO and the uri attribute equal to the EXT-X-STREAM-INF stream url. The other is multiple MEDIA tags for alternate audio.

This issue was happening because if an alternate audio track is active, the assumption that the mainSegmentLoader contains is fetching video and should continue to operate. Because of this assumption, audio only streams with alternate audio was not supported. The assumption was also made that if the uri attribute was present on an EXT-X-MEDIA tag, then that stream is an alternate stream.

The spec mentions that the lack of a uri attribute means the audio is contained in theSTREAM-INF uri, however, the spec makes no mention of allowing the uri attribute to equal the uri of the STREAM-INF. This PR fixes that strange scenario by removing the uri attribute from tags that have a uri attribute matching that of their corresponding STREAM-INF.

To fix the issue with multiple alternate audio tracks, when deciding to call endOfStream, a check is made to see if the mainSegmentLoader has loaded any content with video, and if not, do not wait for it to be ended.

NOTE: Audio only streams with multiple alternate audio tracks is only partially supported with this PR. You will be able to switch to alternate audio tracks, and switch between the alternate tracks, but returning to the main audio track will result in infinite rebuffering because the mainSegmentLoader gets into a bad state. A fix for this is out of scope for this PR because it will require some sweeping changes to the way VirtualSourceBuffer handles ownership of the native audio buffer.

Note 2: I also included a bunch of useful logging statements for debugging in this PR. Its less than ideal to sneak these into this PR instead of their own, but I got distracted and forgot to checkout to a fresh branch before adding them while debugging an unrelated issue.

@mjneil mjneil force-pushed the fix/maat-audio-only branch from 2954c75 to f697f3b Compare February 12, 2018 19:20
@forbesjo forbesjo self-assigned this Feb 12, 2018
@forbesjo
Copy link
Contributor

Looks good to me

@forbesjo
Copy link
Contributor

Tested as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants