Preview while seeking in a paused state.

[wilaw]

Today if you pause the player and then seek, the image that is rendered remains the image that was playing when paused. This gives an unnatural behavior to the rendering surface. A preferred implementation is that the static image reflects the new position of the scrubhead in the video.

The image should only change when the seek is complete (and the scrub handle dropped) and not while scrubbing. This is not a request for fast-forward scrub.

Under the covers, the player should build up at least it's starting buffer, so that when play() is called again playback is instant.

[LloydW93]

I find that MediaPlayer.setScheduleWhilePause(true) solves this in most cases (there's still one browser I think that doesn't update until you play)

[JibberJim]

As Lloyd notesm, scheduleWhilePaused to true updates it appropriately in most browsers, particularly desktop ones, mobile ones are tougher, but that's true about their underlying non MSE video implementations too. I'm not sure we need a distinct API behaviour for this, unless we want to have more adaptive mode where there's a scenario where seeking only downloads a single fragment regardless of other buffer targets. I'd suggest that's unwarranted complexity at this stage.

[wilaw]

Thanks @JibberJim and @LloydW93 - scheduleWhilePaused() does satisfy the requirement for this issue. It's default value is off however. Any objections to me turning it on by default for 2.0? I think it's a more natural behavior for the player. If the concern was the player building a buffer out to 30s when paused, we could quite easily add a maxBufferWhilePaused value to the buffering rule to keep the buffer at something reasonable like 6s if the player is in a paused state?

[wilaw]

Actually, some additional testing with scheduleWhilePaused(true) shows that it does not preserve the paused state. (at least under Chrome/OSX with native videoElement controls). The moment you complete the seek it begins playback and breaks pause.

[dsparacio]

@wilaw darm, you are correct , it does not remained paused post seek!! That will need to be fixed.

Question, should we only render a frame if scheduleWhilePaused is true?
Personally I would like to see it render a single frame on a seek independently of scheduleWhilePaused.

[wilaw]

Ideally it should just render one frame. The scheduling could be decoupled. However, I don't believe there is any practical way to constrain it to just that. Only the MSE pipeline knows when it has enough data to render the first frame and there isn't a sourceBuffer event for that. So practically, you can just add a segment or more of data to the source buffer but pause it before it plays through them. If we pause too early, we may not see the desired frame. Pause too late and the user will see motion. Will take some experimentation and the behavior may also differ across browsers.

[LloydW93]

Actually, some additional testing with scheduleWhilePaused(true) shows that it does not preserve the paused state. (at least under Chrome/OSX with native videoElement controls). The moment you complete the seek it begins playback and breaks pause.

Indeed ,this is one of the things we noticed with 1.5.1 and fixed in 1.6.0, although it only happens with autoplay enabled - haven't gotten around to merging the change yet, but it's a one liner.