Track New API Needs for 2.0

[dsparacio]

Hi Everyone,

I have learned that some users are directly setting some items that were meant to be internal constant values as a workaround which is fine. In the new code we are actually using the const keyword so these values need to have API layer added. So now is the time to get in your requests ;)

Here are some examples.

MediaPlayer.dependencies.BufferController.BUFFER_TO_KEEP = YOUR_VALUE;
MediaPlayer.dependencies.BufferController.BUFFER_PRUNING_INTERVAL = YOUR_VALUE;
MediaPlayer.dependencies.BufferController.BUFFER_TIME_AT_TOP_QUALITY = YOUR_VALUE;
MediaPlayer.dependencies.AbrController.ABANDON_TIMEOUT = YOUR_VALUE;
MediaPlayer.dependencies.FragmentLoader.RETRY_ATTEMPTS = YOUR_VALUE;
MediaPlayer.dependencies.FragmentLoader.RETRY_INTERVAL = YOUR_VALUE;

Can you please identify what you set in your player add that info to this git issue!

[bwidtmann]

maybe also the followings:

MediaPlayer.dependencies.BufferController.RICH_BUFFER_THRESHOLD
MediaPlayer.dependencies.BufferController.LOW_BUFFER_THRESHOLD

[dsparacio]

I could just expose all the buffer values. The only problem is that may adversely affect heuristics. Need to get the Buffer Based ABR stuff in to really tell. Thanks for the additional input @bwidtmann

[bwidtmann]

I don't really know what you mean with exposing?

What I thought about is something like this:

var player = MediaPlayer().create({
bufferToKeep: 30,
bufferPruningInterval: 30
});

the whole config object has default values defined in MediaPlayer.js so you do not need knowledge of these if you do not want to fine tune the player heuristics:

var player = MediaPlayer().create();

We adapted this pattern from jQuery UI Widget: https://api.jqueryui.com/jquery.widget/ (see the options section)

Options

Because progressbar() was called with no parameters, the widget was initialized with its default options. We can pass a set of options during initialization to override the defaults:

$( "#elem" ).progressbar({ value: 20 });
We can pass as many or as few options as we want during initialization. Any options that we don't pass will just use their default values.

You can pass multiple options arguments. Those arguments will be merged into one object (similar to $.extend( true, target, object1, objectN )). This is useful for sharing options between instances, while overriding some properties for each one

[dsparacio]

The context object is for creation mapping and overriding but not to set simple properties. What we should do is create a set of buffer values as default buffer collection and you can change any value inside and pass the object to override the others. This way its not a bunch of single API calls on mediaplayer for each value. I think this works well and easy for dev on player side. What do you think @bwidtmann

[bwidtmann]

I agree on not having a bunch of single API calls for each value. But it is not only buffer values we want to change. It should be rather one setter for each "Controller" in MediaPlayer.js where you can pass an object with the corresponding values you want to override.

for example:

var player = MediaPlayer().create();

player.setBufferConfigs({
bufferToKeep: 30,
bufferPruningInterval: 30
});
player.setABRConfigs({
abandonTimeout: 30
});
player.setFragmentConfigs({
retryAttempts: 999999,
retryInterval: 3000
});

or you just create one setter for all "configs"?

[dsparacio]

I will finish this soon. Final choice was to have individual API for each setting mapped to mediaplayer model for consistency so that we can have nice JSDocs for all API . But we will also add ability to set all properties in mediaPlayerModel with config object passed to MediaPlayer and we may use es6 deconstruct to mapped values.

[dsparacio]

Fixed by PR #1047