-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Fast Audio track switching #2411
Conversation
@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 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 Would it be possible to have a third option (maybe |
@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? |
@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. :) |
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..
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. |
@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. |
@epiclabsDASH I've been doing some more testing and I'm seeing a couple of issues with
|
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. |
@aj-r, could you share your stream with me? |
I'm not sure if I can - I will need to check with the legal guys. I'll see
if I can reproduce it with Big Buck Bunny or something.
…On Feb 8, 2018 4:19 PM, "Jesús Oliva" ***@***.***> wrote:
@aj-r <https://github.com/aj-r>, could you share your stream with me?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2411 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGpesw4oR5BwVW8rgTIABQBeKdC_LjnYks5tS2TwgaJpZM4R8tor>
.
|
@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 |
Thanks for the feedback. I will continue trying to look a resource in which I can reproduce this issue. Thanks! |
@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? |
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.