Event for switch requested and switch complete.

[dsparacio]

We need a reliable way to know when a switch request is finally being rendered or at least when the fragments being loaded match the pending bitrate.

Essentially we need external player events for "switch request" and "switch complete"

[jeroenwijering]

Dan, I presume this is for manual switching? So when an external script requests a manual A/V bitrate, there will be an event this manual bitrate is "delivered"? Or do you also want something internally, for ABR heuristics?

[dsparacio]

Jeroen,

We need a way to differentiate when a switch is requested vs the new idx being rendered. This is useful for analytics, heuristics and generally nice to have in a support player. For instance we show current and pending bitrate. At this point current and pending change together but ideally current would remain on the currently rendered bitrate, pending will show what we are switching to and current will update once that switch is complete AND being rendered. Not sure if possible but trying for parody with flash runtime.

[wilaw]

@jeroen - I made a picture to illustrate what we need. This shows a sample fetch scenario where the player is rendering a 400kbps segment, fetching a 600kbps segment and planning to retrieve a 900kbps segment. Today we have metrics for the latter two. We do not have an idea of what the player is rendering. This is confusing for end-users because the time lag between what is being retrieved and what is being rendered is the forward buffer, which is often 30s. This means that the player UI says the current index is 2 and the bitrate is 600kbps, but the user will only see that quality 30s later. There is no current API to retrieve the quality being rendered by the videoElement/sourceBuffer, so we’ll need to keep a map of what was added to the source buffer and try to figure out what is being rendered by examining the media time.

Cheers

Will

On Feb 2, 2015, at 1:29 PM, Dan Sparacio notifications@github.com wrote:

Jeroen,

We a way to differentiate when a switch is requested vs the new idx being rendered. This is useful for analytics, heuristics and generally nice to have in a support player. For instance we show current and pending bitrate. At this point current and pending change together but ideally current would remain on the currently rendered bitrate, pending will show what we are switching to and current will update once that switch is complete AND being rendered. Not sure if possible but trying for parody with flash runtime.

—
Reply to this email directly or view it on GitHub.

[jeroenwijering]

Hey Will, Dan,

Agreed this will be very useful. In addition to the use case I described (showing "pending" icon for manual switches), this metric is indeed key for quality of service heuristics, to log what quality a viewer actually saw. Let me write down a quick API proposal for that.

Will, your image seems to not be loading. Could you include it?

[wilaw]

Image re-attached.

On Feb 3, 2015, at 6:57 AM, Jeroen Wijering notifications@github.com wrote:

Hey Will, Dan,

Agreed this will be very useful. In addition to the use case I described (showing "pending" icon for manual switches), this metric is indeed key for quality of service heuristics, to log what quality a viewer actually saw. Let me write down a quick API proposal for that.

Will, your image seems to not be loading. Could you include it?

—
Reply to this email directly or view it on GitHub.

[wilaw]

[smedegaard]

Hi. we're at version 1.5.1 now. Is there any progress on this?

[JibberJim]

I have been recently looking at how it might be accomplished, it's a feature we very much need too, but haven't started any work on it, would be interested in hearing if anyone has other wise I may well pick it up shortly.

[smedegaard]

I'm not quite sure how to fix this issue, but I'm going to have a look.

@wilaw wrote

There is no current API to retrieve the quality being rendered by the videoElement/sourceBuffer, so we’ll need to keep a map of what was added to the source buffer and try to figure out what is being rendered by examining the media time.

After looking at the files I assume that SourceBufferExtensions.js and BufferController.js are the relevant files for this issue.

If anyone have more advise or clues I'd appreciate it.

[JibberJim]

Hi Anders,

So if you look in the BufferController - in the onAppended method, that's
where new chunks are pushed into the stream, the virtual buffer keeps
tracks of the chunks. You'll want to store something in this area that
checks to see if the previous chunk quality was the same as the new one,
and if it is store an event somewhere that you can later dispatch when the
playback time hits. The EventController provides something around this
event scheduling, but doesn't actually dispatch it, I'm not sure anywhere
does, but it could be easily modified too.

So basically, extend BufferController to store the transition events
against timestamps, and then having something like EventController dispatch
those events when the playback time hits those times.

There are certainly other approaches, and I'm not positive that's the best
or easiest, but it's certainly possible and should work and as it's
pre-refactor probably not worth spending too much time on it.

Cheers,

Jim.

On Mon, Nov 16, 2015 at 12:54 PM, Anders notifications@github.com wrote:

I'm not quite sure how to fix this, but I'm going to have a look. If
@JibberJim https://github.com/JibberJim or any others have more advise
or clues I'd appreciate it.

—
Reply to this email directly or view it on GitHub
#382 (comment)
.

[dsparacio]

Please be careful spending time on fixing this based on the 1.5.1 release. If you are working in the dev branch it would be much closer to the post refactor code then in the current release.

Please not all PR for enhancements like this will not be pulled in until the refactor is complete. At which time you will have to manually merge the changes into the refactored code.

To be honest I would completely wait on something like this until post refactor.

[JibberJim]

The onAppended and eventController are pretty much equivalent between 1.5.1
and Dev branch, any change to either to implement this will likely merge
easily on to the other, obviously it will be more complicated to merge
after refactor, but that's the same for every feature.

Cheers,

Jim.

On Mon, Nov 16, 2015 at 8:43 PM, Dan Sparacio notifications@github.com
wrote:

Please be careful spending time on fixing this based on the 1.5.1 release.
If you are working in the dev branch it would be much closer to the post
refactor code then in the current release.

Please not all PR for enhancements like this will not be pulled in until
the refactor is complete. At which time you will have to manually merge the
changes into the refactored code.

To be honest I would completely wait on something like this until post
refactor.

—
Reply to this email directly or view it on GitHub
#382 (comment)
.

[smedegaard]

@AkamaiDASH , what is the time frame on the refactor process?

[smedegaard]

@JibberJim thanks for the help!

[dsparacio]

@smedegaard I do not have a firm date yet when we can start adding in new features but It will not be too long. We are almost done with the major part after which we may be able to start to pull in things like this. If you were to work out the solution in the dev branch it may no be too hard to pull into the new version but will have to be done manually. It will not merge or rebase.

[rofeifei]

Hello,I apologize if this topic is not appropriate for this issue,I would greatly appreciate it if you kindly give me some suggestions on how to calculate the duration of the event BUFFER_EMPTY (bufferStalled)& correct me if i am wrong in #857
best regards,

[smedegaard]

Hi Dan, @AkamaiDASH
I've had a look at 2.1.0 and I see that the QUALITY_CHANGED event has been added. I gave it a spin but as of now it seems like the event is dispatched as soon as you request a new quality, not when the new quality is actually playing. Am I missing something?

Is the general idea about the implementation something like what @JibberJim wrote on Nov 16th?

regards,
Anders

[dsparacio]

@smedegaard We still have a functionality gap here. You are not missing anything. We still do not have a way to tell when the new quality is actually being rendered. We have some ideas, but none of them have been implemented yet.

[dsparacio]

@smedegaard Just to note I have implemented quality start and complete events where complete is synced with new quality render time. Will be part of 2.2.

[dsparacio]

Added with PR #1434