Skip to content
This repository has been archived by the owner on Jan 12, 2019. It is now read-only.

Seeking event never fires #175

Closed
heff opened this issue Oct 16, 2014 · 6 comments
Closed

Seeking event never fires #175

heff opened this issue Oct 16, 2014 · 6 comments

Comments

@heff
Copy link
Member

heff commented Oct 16, 2014

For some reason with the interaction between the HLS plugin and the swf, the seeking event never fires. It looks like it should, or at least we think it should.

I'm wondering if it has something to do with the source buffer calling abort() before updating the time. Or if NetStream.SeekStart.Notify just never fires in appendBytes mode. Anyone have any ideas?

The current workflow after HLS.setCurrentTime is called appears to be:

  1. intercept the new time
  2. tell the swf to abort the current playback (via sourceBuffer.abort())
  3. buffer the new data
  4. tell the swf the new currentTime
  5. append the new data (sourceBuffer.appendBuffer())

The ideal workflow I'm trying to work towards (to mimic the video element) I believe would be more like:

  1. tell the swf the new currentTime (immediately -- without intercepting)
  2. the swf fires a seeking event (and probably aborts playback internally)
  3. the HLS plugin picks up the seeking event
  4. checks the currentTime (which should be reporting the target time, and currently appears to)
  5. buffers and appends the new data

Are there any other challenges in getting there that anyone can see?

@tomjohnson916
Copy link
Contributor

@heff - I don't know that we ever actually seek inside the SWF. When we set currentTime in the tech I thought we purged the buffer, grab the new content, and force it in/ update time values. If that is correct, I would say we should fire seeking in the tech.

@gkatsev
Copy link
Member

gkatsev commented Oct 17, 2014

This is related to #170.
But I agree with @seniorflexdeveloper, we don't actually seek in flash other than setting a currentTime on flash so flash knows where we are now playing.

@tomjohnson916
Copy link
Contributor

We may want to look at doing an 'in buffer' seek where we calculate if the seekTarget is within the buffered range then netstream.seek to that value else standard purge/grab/set routine. Just a thought.

@gkatsev
Copy link
Member

gkatsev commented Oct 17, 2014

@seniorflexdeveloper that will not be an option with the tagbuffer work since the flash buffer will be barely 2 seconds long.

@heff
Copy link
Member Author

heff commented Dec 2, 2014

Actually, I think the issue here is that with Flash, we don't actually trigger the events on the tech itself. We bypass the tech and trigger them directly on the player.
https://github.com/videojs/video.js/blob/76e662a75678f46b8c900e1c0842a2a0858537c1/src/js/media/flash.js#L318

I was only checking the tech events, so it's possible seeking is actually firing, just not where I need it to be. This could be an easy change in the Flash tech.

@forbesjo
Copy link
Contributor

I think it fires now.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants