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

Fire playing on buffer full only when we are not pending a pause. #90

Merged
merged 3 commits into from
May 23, 2014

Conversation

bclwhitaker
Copy link
Contributor

No description provided.

@bclwhitaker
Copy link
Contributor Author

As the code is now, a 'playing' event fires off as soon as an hls src is provided and using videojs-contrib-hls plugin.

@heff
Copy link
Member

heff commented May 5, 2014

I think this makes sense, I'm not sure what the playing event has to do with the buffer filling up, unless netstream gives us no other indication that the video is ready to play. But I really don't have enough experience with this function to say if this would break anything. This would need to be tested with both HLS and the standard MP4 playback to see if there's any side effects.

@seniorflexdeveloper, can you add your thoughts on this?

@tomjohnson916
Copy link
Contributor

My only concern with this is if the buffer fills multiple times per playback will this cause a misreport. For example, if during a single playback my buffer empties and then refills, will this fire twice?

@bclwhitaker
Copy link
Contributor Author

Wouldn't it fire multiple times with the existing code? The intention of this change was to limit the number of times it fires not increase it. Perhaps there should also be a check for !_isPlaying?

case "NetStream.Buffer.Full":
   _isBuffering = false;
   _model.broadcastEventExternally(ExternalEventName.ON_BUFFER_FULL);
   _model.broadcastEventExternally(ExternalEventName.ON_CAN_PLAY);
   if (!_pausePending && !_isPlaying) {
      _pausedSeekValue = -1;
      _isPlaying = true;
      _model.broadcastEventExternally(ExternalEventName.ON_START);
   else {
      _pausePending = false;
      _ns.pause();
      _isPaused = true;
   }
break;

In any case, I agree with @heff. 'playing' and buffer full event don't seem like they should be tied together conceptually. So maybe that should be addressed as a larger change rather than trying to hack it out here.

@gkatsev
Copy link
Member

gkatsev commented May 6, 2014

what does the ON_START event represent specifically?

@heff
Copy link
Member

heff commented May 7, 2014

I'm not sure where the term 'ON_START' comes from, but the var equals 'playing'. The 'playing' event is supposed to be triggered when paused=false and there's enough buffer to start playing. So not just when play() is called. I guess that kind of explains the buffer full part.

@gkatsev
Copy link
Member

gkatsev commented May 7, 2014

Thanks. Based on that, I think we should be checking the value of _isPlaying.

@bclwhitaker
Copy link
Contributor Author

Im still working on this. I don't think _isPlaying is the right thing to look at cause it appears to almost always be true under normal circumstances when the Buffer.Full event fires. I've changed it to look at the _isBuffering property since I think that's pretty close to what we want.

_isBuffering is set true when:
NetStream.Buffer.Empty fires.
NetStream.Play.Start fires.
seekBySeconds is called.

and set false when:
The player is initialized.
NetStream.Buffer.Full fires

I'm still working through this change though.

@bclwhitaker
Copy link
Contributor Author

OK, changed the code to only fire if we were buffering. I had to add conditionals to the other places where we fire this event to prevent it from firing twice (once on the play request and again when the buffer filled). My manual tests of playback with an mp4 using the contrib-hls plugin look good. Wish there was a bit more automation already in place around these events.

dmlap added a commit that referenced this pull request May 23, 2014
Fire playing on buffer full only when we are not pending a pause.
@dmlap dmlap merged commit 8a98910 into videojs:master May 23, 2014
@bclwhitaker bclwhitaker deleted the bugfix/bufferPlaying branch April 23, 2015 12:52
@bclwhitaker bclwhitaker restored the bugfix/bufferPlaying branch April 23, 2015 12:52
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.

5 participants