Calling detatchMedia() followed by attachMedia() causes audio to not play #2099
Comments
|
It's fMP4 HLS. |
|
@itsjamie Indeed it is. How is that an issue here though? The methods should still work here. |
|
Audio track on re-attaching does: |
|
Just it goes through a different code path because it doesn't run through the tsdemuxer. |
|
So I found a issue... In the buffer controller on first load However, if I just add a local variable to persist this alternate audio, so that it expects the same on detach/attach scenario it doesn't fix the issue. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Bot, this is still an issue. |
|
👍
…On Thu, Apr 4, 2019 at 07:37 Brandon Kalinowski ***@***.***> wrote:
Bot, this is still an issue.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2099 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEzwZKdb1plHhDtFH4rbRn-CTQ9D1tF3ks5vdeQVgaJpZM4aTsey>
.
|
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Still relevant |
… not play On re-attch the context of altAudio is not saved in buffer control so it doesn't know to create two source buffers. Also, in context of stream controller it doesn't reset the `altAudio` flag. I also noticed that stream controller is reloading the entire frags it has in `fragmentTracker` and it seems it needs to be reset on detach, otherwise there's a very long start delay where unncessery buffering occurs. based on #2110 and fixes #2099.
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
What version of Hls.js are you using?
0.12.2
What browser and OS are you using?
Chrome and Firefox for Mac
Test stream:
This is the stream:
https://demo.unified-streaming.com/video/tears-of-steel/tears-of-steel-fmp4.ism/.m3u8
And here it is on the demo page:
https://hls-js.netlify.com/demo/?src=https%3A%2F%2Fdemo.unified-streaming.com%2Fvideo%2Ftears-of-steel%2Ftears-of-steel-fmp4.ism%2F.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOnRydWUsImVuYWJsZVdvcmtlciI6dHJ1ZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xLCJ3aWRldmluZUxpY2Vuc2VVcmwiOiIifQ==
Checklist
Steps to reproduce
I am working on testing out midroll ads. Currently I must destroy the hls instance, play the ad (a simple mp4) and then reinitialize the hls streamer. I would prefer to avoid this method as it causes the buffer to be thrown out on the main HLS video.
However, calling
hls.detatchMedia()followed byhls.attachMedia(document.getElementById('video'))causes the audio to stop playing.Ocassionally this instead causes only the the audio to play when the hls is reattached and the video element will be black. However, this is hard to reproduce, and for the most part it is usually the case where the audio is the track that is missing. Of course, both cases I would consider to be a bug.
100% of the time.
Expected behavior
What you expected to happen
Attaching the hls to the player should not cause issues with playback.
Actual behavior
What actually happened
Audio did not play after reattaching media to the video element. Rarely, audio played but video did not. It was never the case that both played at once.
Console output
Paste the contents of the browser console here.
For media errors reported on Chrome browser, please also paste the output of chrome://media-internals
The text was updated successfully, but these errors were encountered: