JFYI: Shaka 2 coming soon

[joeyparrish]

JFYI, Shaka team is hard at work on Shaka 2, which will have a new API. You can see a preview of the work-in-progress on the preview branch. We also published a redesign doc with a roughed-out version of the new APIs and diagrams of the new architecture.

I'll update this ticket once we go into beta so that you have a chance to give feedback on the API and start working on updates to your clappr plugin to support Shaka 2. We expect the official release of Shaka 2.0.0 by end of March. Thanks!

[leandromoreira]

Congrats @joeyparrish and the team, I'm looking forward for this, thanks for all the work! 🍻

[leandromoreira]

Fixed links: redesign and it already points to master 😀

[joeyparrish]

Yes indeed! We recently merged to master and hope to release beta soon.

[joeyparrish]

We've just released v2.0.0-beta on github & npm. Let us know what you think.

We're still working on the v2 upgrade guide, but we have tutorials on several other topics already. Hopefully that will be enough to get you started, and you can always reach out via email or github if there's anything we can do to help with the transition.

Thanks!

[leandromoreira]

Thanks @joeyparrish and all the team, soon I'll be trying it.

[leandromoreira]

It's looking pretty cool, although I just read the first two pages from the tutorial. But it was enough to make it work.

The only thing I think we'll need to overcome is that, now the checking if the Browser/Device is able to play become an async method Player.support which returns a Promise.

And on Clappr, we have a sync static method canPlay (that must use the player.support) that all the playback must implement, therefore we'll need to think about solutions for this.

Anyway, I think the full integration will be seamless, thanks once again. I'll try to dig deeper in the design and general changes. (looking forward to test a replace plugin for network request using WebRTC to offer P2P)

[leandromoreira]

I'm noticing a lot less "rebuffering" maybe it's because now the example stream is hosted in a better place http://storage.googleapis.com/shaka-demo-assets/angel-one/dash.mpd

[leandromoreira]

I ran a basic profile (on chrome) oriented to CPU and HEAP-wise and notice that both versions seem to work almost equally (shaka 2.0.0-beta vs shaka 1.6.4):

[joeyparrish]

We have always tried to avoid doing anything CPU-heavy in Shaka, and we took extra care with destroy() in v2 to clean up after ourselves, so I'm glad to hear that it profiles well for you.

Regarding Player.support() being async, unfortunately, this is the only way we can return a map of supported key systems. The EME API is Promise-based. Is key system information useful to you?

[leandromoreira]

Is key system information useful to you?

Yeah, there was one guy that opened an issue for that and I think it's very useful.

I was thinking about offering a sync basic implementation (which will work for most cases) and postpone the final decision based on Player.support

[leandromoreira]

Yet on the feedbacks, the code is easier to read and extend :)

[joeyparrish]

Glad to hear it!

[leandromoreira]

• adds support to canPlay asynchronously
• handles adaptation
• handles video tracks
• accepts configuration object
• enables drm configuration
• handles buffering
• one way to implement the async canPlay is to popstone the support check using a static method (DashShakaPlayback.supportedStatus) then check that on the player. But that might force a polling or check on onError listen.

[leandromoreira]

New configuration with that many options to fine tune is pretty cool!

[leandromoreira]

@joeyparrish I'm listening to player.addEventListener('buffering', this._bufferingHandler.bind(this)) and the parameter received has not buffering property, what's the way to check weather is the start or the end?

The same for the 'adaptation' event, I'm not seeing any size or other details about the new level.

[leandromoreira]

Despite the canPlay and adaptation/buffering event I released a beta version.

[joeyparrish]

With regard to buffering events, there should definitely be a buffering property:

shaka.Player.prototype.onBuffering_ = function(buffering) {
  // Before setting |buffering_|, update the time spent in the previous state.
  this.updateStats_();
  this.buffering_ = buffering;

  var event = new shaka.util.FakeEvent('buffering', { buffering: buffering });
  this.dispatchEvent(event);
};

AdaptationEvent in v2 does not contain details about the adaptation decision, which may have applied to multiple tracks. You can call player.getTracks() and see which tracks have active: true when you receive the event.

Does this help?

[leandromoreira]

Thanks @joeyparrish , it does help!

About the 'buffering' event, what I did was to add a listener for 'buffering' player.addEventListener('buffering', (e) => console.log(e)), I noticed that it fires twice but none with buffering property.

[joeyparrish]

Ah, it looks like a renaming bug in the compiled version. The property has been renamed, but it shouldn't have been. I filed shaka-project/shaka-player#361 to track.

[leandromoreira]

I see, I bet is that GB value.

About the adaptation: I needed to offer separated tracks for each type, doing a simple filter type === 'audio...', because people often will build UIs to offer Subtitle, Video or Audio switch.

[joeyparrish]

We will have another beta release (v2.0.0-beta2) this week if possible. I will try to have the event properties (shaka-project/shaka-player#361) fixed in that release.

Regarding adaptation, from your link it seems that you already have a solution. Or perhaps I don't fully understand the problem. Can you clarify, please? Do you need track information in the AdaptationEvent? Or is it inconvenient that getTracks() returns all three types?

[leandromoreira]

Regarding adaptation, from your link it seems that you already have a solution. Or perhaps I don't fully understand the problem. Can you clarify, please? Do you need track information in the AdaptationEvent? Or is it inconvenient that getTracks() returns all three types?

Yes, it's a solved problem, I'm just sharing what I did, I personally think it's best to offer a generic and extensible component.

[leandromoreira]

@joeyparrish yet on the adaptation event, it seems that when you call selectTrack passing the track (not only the id but the object) it doesn't fire 'adaptation' again:

    // turn on or off (depends on the user selection)
    this._player.configure({abr: {enable: !isAuto}})
    this._player.selectTrack(track)

I logged the events and I got:

• adaptation id 10 // normal flow
• adaptation id 13 // normal flow
• selectTrack id 9 // user forced to fix at lower level

But there is no adaptation id 9 as reaction to this._player.selectTrack(track) am I missing something?

[joeyparrish]

That's correct. AdaptationEvents are for changes made by the AbrManager. When you call selectTrack, presumably, you know you've called it. Also note that selectTrack() for audio and video tracks disables ABR.

[leandromoreira]

you know you've called it.

is this sync? I mean, right after I call selectTrack the track was already changed?

[leandromoreira]

@joeyparrish do you have a slacker channel or other way (irc...) to communicate?

[joeyparrish]

Yes, it's synchronous, with the understanding that the StreamingEngine may not request a new segment right away. But the next time it does, it's from the new track.

Sorry, I'm not available for live chat at the moment. We don't have an IRC or slacker channel for the team, either. If email works for you, you can find my email address in CONTRIBUTORS.

[leandromoreira]

Thanks , then I'll use it as sync method.

I'm having some ideas (mostly about extensibility) but maybe the better place to discuss them it's here.

[joeyparrish]

Yes, please give us feedback on the API while we are still in beta and can make API changes more easily. The best place for feedback is either the mailing list or github issues. Thanks!

[leandromoreira]

I tried to access these "methods" (support at Manifest and MediaSource) and they weren't there, are they private?

    var manifest = shaka.media.ManifestParser.support();
    var media = shaka.media.MediaSourceEngine.support();

I saw you using it like a static method.

[joeyparrish]

Those methods are not exported from the library. They are "public" within the library (class-to-class), but "private" with respect to the application.

[leandromoreira]

The new version fixed the buffering issue (among tons of other), thanks!

[joeyparrish]

@leandromoreira, we've just released v2.0.0-beta3 on github & npm. The upgrade guide is available here. Let us know what you think!

[leandromoreira]

@joeyparrish thanks :) I'll take a look later!

[leandromoreira]

It took so long because I was busy with olympic games but @joeyparrish with minimal effort, everything is working just fine! Kudos again to everyone!

Pretty neat the new content protection configuration.

player.configure({
  drm: {
    servers: {
      'com.widevine.alpha': '//widevine-proxy.appspot.com/proxy'
      'com.microsoft.playready': '//playready.directtaps.net/pr/svc/rightsmanager.asmx'
    }
  }
});

The getStats

I found that the Player events documentation can mislead people, the idea of contentType (string) => (no v2 equivalent) could be replaced with two chunks of documentation (I can PR if you want), anyway my idea is:

Player events

v1

• error => error
  • detail (various types)
  • type (vague string)
  • message (vague string) => code (number, unambiguous error code)

v2

• error => error
  • detail (shaka.util.Error)
  • category (number, unambiguous error category)
  • code (number, unambiguous error code)

But that's my own preference though. Plus the tutorial plugin is a great addition too. I'm really looking forward for the 🤘 2️⃣

[joeyparrish]

Cool, thanks for the feedback!

[leandromoreira]

@joeyparrish are any plans to add support to the DRM solution Adobe Access?

[joeyparrish]

We don't not support Adobe Access. We support EME, so as long as Adobe Access is interoperable with other EME key systems, I see no reason it shouldn't just work. That said, we currently have no public DASH test vectors using Adobe Access, so we can't confirm.

[leandromoreira]

Thanks @joeyparrish I got it.

[joeyparrish]

Just wanted to let you know that v2.0.0 is officially out of beta. Thanks again for your involvement and feedback!

[leandromoreira]

@joeyparrish you're welcome, btw we (the company I'm currently working) are planing to use Shaka very soon ! (actually we use clappr therefore we'll use this wrapper (dash-shaka-playback) but for sure Shaka is the ⭐ while playing dash)

[joeyparrish]

Nice!