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

Fast Audio track switching #2411

Merged

Conversation

epiclabsDASH
Copy link
Contributor

Fixes #2239 and enables fast switch of tracks. Whenever a request for track change is received, and if track switching mode is set to TRACK_SWITCH_MODE_ALWAYS_REPLACE, BufferController will remove its buffer completely so track change is effective immediately.

@epiclabsDASH epiclabsDASH added this to the v2.6.6 milestone Feb 7, 2018
@epiclabsDASH
Copy link
Contributor Author

@aj-r, would you have some time for testing this? We have been testing it quite exhaustively but given our set of streams with multi tracks is limited, any additional test with your own streams will be really appreciated

@epiclabsDASH epiclabsDASH merged commit 892dccc into Dash-Industry-Forum:development Feb 7, 2018
@nweber
Copy link
Contributor

nweber commented Feb 7, 2018

@epiclabsDASH I just did some testing with the multitrack streams I'm working with. The two track switch modes seems to work, in so far as they are described.

With that said, this appears to completely eliminate "fast switching" when changing tracks. When using TRACK_SWITCH_MODE_ALWAYS_REPLACE playback halts and waits for the buffer. I understand why that is valuable (particularly for language tracks), but it is not always desired for non-critical content types.

Would it be possible to have a third option (maybe TRACK_SWITCH_MODE_FAST_REPLACE or something) that utilizes the normal "fast switching" method?

@epiclabsDASH epiclabsDASH deleted the audio-tracks branch February 7, 2018 22:23
@epiclabsDASH
Copy link
Contributor Author

@nweber, sure, this is something we can evaluate. In fact, that was the way it worked before. Instead of clearing completely the buffer when switching, we kept a few seconds (2-3 seconds) to make the transition smooth. However, that created some inconsistencies when working with different audio tracks: after a track switch there were content in the buffer for two different audio languages so when seeking back and play again the content around the switch, you heard a mix of two different audio languages.

Although I discarded that approach because that issue, as you pointed out the described problem could be too much related to audio tracks. Let me take a look. In the mean time, do you have any stream with more than one track that we could use for testing?

@nweber
Copy link
Contributor

nweber commented Feb 7, 2018

@epiclabsDASH That makes sense. With that said, I think in an ideal world, this "third option" would do a "fast switch" but then clear all the buffer once the new track is rendered. This would fix issues with seeking backwards and seeing the old track. That is obviously more complicated though.

I'll check with my content folks to see if we have a stream with multiple video tracks that I can give you.

I was testing with this stream yesterday, which has two audio tracks. It's not ideal, since it's harder to work with, but it does do the job so long as listening to the poem a couple hundred times doesn't kill the drive for development. :)
http://dash.akamaized.net/dash264/TestCases/10a/1/iis_forest_short_poem_multi_lang_480p_single_adapt_aaclc_sidx.mpd

@nweber
Copy link
Contributor

nweber commented Feb 7, 2018

Also, I'll flesh out the use case I'm thinking about some more. It's probably all retreading, but I'd rather be more exhaustive if possible.

Let's say that we have a video of a concert and there are two video tracks..

  1. Concert Stage
  2. Crowd

Let's assume that there's only one audio track which will persist while the user changes video tracks.

When the user changes video tracks, we want a smooth viewing experience with minimal (hopefully no) interruptions. The goal would be to initiate a track switch and see the minimum amount of the old track while we buffer the new track. As you pointed out, that is the "fast switching" algorithm that ABR uses.
Additionally, once the user has started viewing the new track, all old content should be dumped from the buffer so that if the user seeks they will see the new/current track that they have selected.

@epiclabsDASH
Copy link
Contributor Author

@nweber, that's the approach I have in mind: smooth switch and "schedule" a clean of previous buffer after it being played. Anyway, my plan for this is first having a simpler logic that works, and then, on top of something stable, build more logic that improve UX/player behavior.

@nweber
Copy link
Contributor

nweber commented Feb 7, 2018

@epiclabsDASH I've been doing some more testing and I'm seeing a couple of issues with ALWAYS_REPLACE.

  1. Sometimes after initiating a track switch it's taking 60+ seconds for the video to start playing again. A lot of video files are getting loaded before it starts back up. I haven't look into it yet, and it could be because I'm playing long form content.
  2. Pretty much 100% of track switches are dropping to the lowest quality on the new track instead of maintaining the quality.

@aj-r
Copy link
Contributor

aj-r commented Feb 8, 2018

Sorry I just got around to testing this. This works well for me, except while the first segment is playing. If we are playing the second segment or later, and I switch tracks, the switch is basically instant. However, if I try to switch segments during the first segment, no switch occurs until the second segment starts playing.

Additionally, if I switch tracks during the first segment, then after the second segment starts playing, I switch tracks again, it does not work. But if I then try to switch to a third track, it works.

But again, all is fine if I avoid any track switching during the first segment.

Tested using http://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html (development, commit: 892dccc). I only noticed this because my test clip has 15-second segments. In production, our segments will be much shorter (~2 seconds), so this isn't a show-stopper issue.

@epiclabsDASH
Copy link
Contributor Author

@aj-r, could you share your stream with me?

@aj-r
Copy link
Contributor

aj-r commented Feb 8, 2018 via email

@aj-r
Copy link
Contributor

aj-r commented Feb 9, 2018

@epiclabsDASH I should note that I see the same behaviour in 2.6.5, so at least this PR doesn't seem to have broken anything.

I'm working on building a DASH sample of sintel with multiple audio tracks

@epiclabsDASH
Copy link
Contributor Author

Thanks for the feedback. I will continue trying to look a resource in which I can reproduce this issue. Thanks!

@nweber
Copy link
Contributor

nweber commented Feb 16, 2018

@epiclabsDASH Would you like me to make a new enhancement issue for the task of adding the third "fast switching" track mode option, so that we can track specifically related to that task?

@dsander dsander mentioned this pull request Feb 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants