Skip to content
This repository has been archived by the owner on Dec 10, 2020. It is now read-only.

Expose buffered time ranges #180

Merged
merged 3 commits into from
Aug 26, 2015
Merged

Conversation

dmlap
Copy link
Member

@dmlap dmlap commented Aug 22, 2015

Returning just the latest buffered position ignores the fact that the back buffer is limited in many cases. Instead, return an array of arrays that can be mapped onto time range objects in javascript. Stop sending the "seeked" event immediately on Netstream.Seek.Notify. Flash defines the seek as complete as soon as the buffer has been flushed from the previous playback position but HTML waits to trigger "seeked" until enough data is available to being playback. Trigger "seeked" from Netstream.Buffer.Full, when a seek was in progress, to match HTML behavior.

Returning just the latest buffered position ignores the fact that the back buffer is limited in many cases. Instead, return an array of arrays that can be mapped onto time range objects in javascript. Stop sending the "seeked" event immediately on Netstream.Seek.Notify. Flash defines the seek as complete as soon as the buffer has been flushed from the previous playback position but HTML waits to trigger "seeked" until enough data is available to being playback. Trigger "seeked" from Netstream.Buffer.Full, when a seek was in progress, to match HTML behavior.
@@ -597,10 +600,8 @@ package com.videojs.providers{

case "NetStream.Seek.Notify":
_playbackStarted = true;
_isSeeking = false;
_hasEnded = false;
_model.broadcastEvent(new VideoPlaybackEvent(VideoPlaybackEvent.ON_STREAM_SEEK_COMPLETE, {info:e.info}));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still want to broadcast the stream seek complete event here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That event is internal-only so I didn't think it was necessary to rename/refactor it. Its definitely a little weird to see here, I just didn't want to have to track down all the usages and update them.

The values returned from NetStream.bufferLength seem to be less than, or very close to, NetStream.bufferTime for standard progressive download content. By default, NetStream.bufferTime seems to be a very small number, 0.8 seconds on my machine. This conflicts with the numbers coming back from NetStream.bytesLoaded so despite the fact that seems like an inaccurate calculation, it's better than the alternative.
@@ -546,6 +554,11 @@ package com.videojs.providers{
break;

case "NetStream.Buffer.Full":
if (_isSeeking) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice. It's probably worth a code comment here so we don't have to dig up the issue later to know why this is here instead of Seek.Notify.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point.

Emitting "seeked" is in location you might not expect. Explain why.
@dmlap
Copy link
Member Author

dmlap commented Aug 25, 2015

@heff added that comment.

dmlap added a commit to dmlap/video.js that referenced this pull request Aug 25, 2015
Requires videojs/video-js-swf#180. Pick up changes from the SWF that expose the start time of the current buffered region.
dmlap added a commit that referenced this pull request Aug 26, 2015
@dmlap dmlap merged commit 50e5838 into videojs:master Aug 26, 2015
@dmlap dmlap deleted the buffered-accuracy-and-seeked branch August 26, 2015 18:15
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants