Shaka-player: selectVariantTrack on 'streaming' doesn't work

[kocoten1992]

Have you read the FAQ and checked for duplicate issues: yes

What version of Shaka Player are you using: 2.2.5

Can you reproduce the issue with our latest release version: yes

Can you reproduce the issue with the latest code from master: not try it yet

What browser and OS are you using: Chrome latest, ubuntu 17.10

What did you do?
Here a demo: http://jsbin.com/rajebopeni/1/edit?html,console,output

What did you expect to happen?
I try to make shaka load 1080p manually

What actually happened?
But it doesn't work, quality is low

[vaage]

Was able to reproduce this. The error message "'Mistakenly ignoring deferred variant from the same period!'" appears. It looks like trying to set the variant at the start causing problems with our deferred switching.

[vaage]

I have looked a little into this. Just to add a note so that we all know this, even if we wait for the load to succeed and then set the variant, this still does not work. However we avoid the error/assert when we do it this way.

[vaage]

@kocoten1992 I was able to get this to work. As you will see I have changed the label from bug to question as things are working as intended but we have not properly explained how to work with this feature. To ensure this does not cause anyone else any problems I will write a tutorial explaining how to work with this feature.

To help you get unblocked I will attempt a condensed explanation here. I had to make a couple small changes to your code:

player.configure({abr: {enabled: false}});

player.addEventListener('error', onErrorEvent);

player.load(manifestUri).then(function() {
  var track = player.getVariantTracks().filter(function(track) {
    return track.width === 1920 &&
               track.videoCodec === 'vp9' && 
               track.audioCodec === 'opus';
  }).pop();

  if (track) {
    console.log('Selecting variant track ', track);
    player.selectVariantTrack(track, true);
  }
}).catch(onError);  // onError is executed if the asynchronous load fails.

The first change was to move the configure before streaming starts. I did that just because there is no reason to wait and if anything it ensures that everything is set-up the way you want before the player starts working with the configuration.

Second, instead of waiting for the streaming event, I moved the "core" logic to a promise pending on load.

Thirdly, I had to pass true along with selectVariant to force streaming engine to drop the segments it had loaded. If you don't do this, it will continue to use the segments it had already loaded (which were the lower abr option).

Does that help?

[joeyparrish]

It was intended that the streaming event allow changes to be made before the player starts streaming anything. What you tried to do, @kocoten1992, should have worked.

The buggy part of the system in this case is a little challenging to modify, so I am going to schedule the work for v2.4 right now.

In the mean time, waiting for load() to complete is one possible workaround. It doesn't get you the timing you wanted, though.

Another workaround is to use the streaming event to configure the restrictions object, which can restrict the system to one particular track. This is how we imagined the event being used, and this should work.

But we will look into fixing selectVariantTrack during streaming event.

[kocoten1992]

Wow, thank for all the effort guys

@vaage you go as far as trying all that, :heart_eyes:

I'll use your work around until 2.4, hope it will help other too

[joeyparrish]

I have a working fix locally. I need to write regression tests and clean everything up for review, but I expect to be able to put this into a v2.3.x bug fix release.

[joeyparrish]

This turned out to be several bugs layered on top of each other.

First, we would fire the "streaming" event too early, before our final stage of filtering. This meant that for multicodec content, you might be selecting a track which will be subsequently filtered out. If the track was no longer available after filtering, we would effectively ignore your selection. This bug would only be triggered by multicodec content (VP9 & H.264, for example).

Second, there was a code path in which we could ignore your track selection. This was very easy to trigger with the "streaming" event, and in an uncompiled build, would result in a failed assertion.

Third, once the second bug was fixed, we could fail some assertions in StreamingEngine and still effectively ignore your track selection.

[joeyparrish]

Cherry-picked for v2.3.3.