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

Alternative audio level buffers inconsistence after changing audio tracks #764

Closed
4 tasks done
sergiojm opened this issue Oct 23, 2016 · 6 comments
Closed
4 tasks done
Labels

Comments

@sergiojm
Copy link
Contributor

sergiojm commented Oct 23, 2016

Environment
  • The stream has correct Access-Control-Allow-Origin headers (CORS)
  • There are no network errors such as 404s in the browser console when trying to play the stream
  • The issue observed is not already reported by searching on Github under https://github.com/dailymotion/hls.js/issues
  • The issue occurs in the latest reference client on http://dailymotion.github.io/hls.js/demo and not just on my page
  • Link to playable M3U8 file:
  • Hls.js version:
  • Browser name/version: All
  • OS name/version: All

When changing alternative track, bitrate selector becomes inconsistence(even worst when main has audio).

  1. choose a bit rate
  2. change audio track
  3. load a level

It will take "huge" amount of time to change.
On demo page we can see the impact on the quality controls.

@sergiojm
Copy link
Contributor Author

sergiojm commented Oct 23, 2016

When changing audio track it gets a BUFFER_FLUSHING and on onBufferFlushed

if appending always the newRange.push(range) and not only on
if (BufferHelper.isBuffered(this.media,(range.start + range.end) / 2))

then becomes stable and switch as normal.

Debugging why...

@sergiojm
Copy link
Contributor Author

sergiojm commented Oct 23, 2016

When buffer reset on audio track switch(onBufferFlushed) its also reseting video element leaving level quality to "init"...

@mangui, Don't know if I understood the perfectly the logic but submitting a patch.

Leaving a suggestion...

One thing I would consider for future is to handle the audio of the main as an alternative track and work the logic of stream-control and audio-control as a key pair(main video + selected audio).

When main pushing to demuxer should only push video and the current selected audioTrack(main, track 1,track 2,etc). Instead of keeping track of values of the PTS/DTS...

Currently if we switch from alternative to main audio, it re downloads the entire main track, when shouldn't cause its "heavy" and we have it already.

Most of the production teams(live that then becomes vod) send main with audio so something to consider I would say...

@sergiojm
Copy link
Contributor Author

#768

mangui added a commit that referenced this issue Oct 24, 2016
fix FRAG_CHANGED not triggered appropriately after audio track change
related to #764 #768
@mangui mangui added the Bug label Oct 24, 2016
@mangui
Copy link
Member

mangui commented Oct 24, 2016

Hi @sergiojm well spotted, should be fixed

@sergiojm
Copy link
Contributor Author

Tested and works for me :)

Thanks for fixing it. For alternative audio(VOD and LIVE) was crucial!

@mangui
Copy link
Member

mangui commented Oct 25, 2016

great, closing as fixed

@mangui mangui closed this as completed Oct 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants