1206719 - [B2G] Throttle the seek command from videocontrols.xml.

Status: RESOLVED WONTFIX

(Core :: Audio/Video: Playback, defect)

Description

[Benjamin Chen [:bechen]]

On B2G platform, the seek operation usually takes a lot of time.
So I'm trying to add throttle mechanism in videocontrols.xml to reduce the seek commands when user dragging the progress bar.

Comment 1

[Benjamin Chen [:bechen]]

Attachment: bug-1206719.v01.patch

Simply set a 50ms timer to throttle the seek commands. But since video app doesn't use the control, the patch doesn't affect it.

Comment 2

[Benjamin Chen [:bechen]]

Comment on attachment 8664664 [details] [diff] [review]
bug-1206719.v01.patch

How do you think about the 50ms timer?

Comment 3

[Alfredo Yang (:alfredo)]

Comment on attachment 8664664 [details] [diff] [review]
bug-1206719.v01.patch

Review of attachment 8664664 [details] [diff] [review]:
-----------------------------------------------------------------

It looks like workaround to me.
When lot of seeking happening, it should run to the latest seek point when current seek is completed. So, I don't see the reason we need a throttle for seeking.

Comment 4

[John Lin [:jhlin][:jolin]]

Comment on attachment 8664664 [details] [diff] [review]
bug-1206719.v01.patch

Review of attachment 8664664 [details] [diff] [review]:
-----------------------------------------------------------------

It's always difficult to pick a good value for throttling that works on different devices. How about listen to 'seeked' event?
That is, if it's already 'seeking', remember the scrubber position and call fastSeek() in 'seeked' handler.

Comment 5

[Benjamin Chen [:bechen]]

(In reply to John Lin [:jolin][:jhlin] from comment #4)
> Comment on attachment 8664664 [details] [diff] [review]
> bug-1206719.v01.patch
> 
> Review of attachment 8664664 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> It's always difficult to pick a good value for throttling that works on
> different devices. How about listen to 'seeked' event?
> That is, if it's already 'seeking', remember the scrubber position and call
> fastSeek() in 'seeked' handler.

Seems that listen an event is better than a fixed 50ms value, I'll try it.

Comment 6

[Jean-Yves Avenard [:jya]]

(In reply to John Lin [:jolin][:jhlin] from comment #4)
> That is, if it's already 'seeking', remember the scrubber position and call
> fastSeek() in 'seeked' handler.

when you queue quickly multiple seek, all seeks but the last one become "fast seek" (this was done in bug 1159343)

Comment 7

[John Lin [:jhlin][:jolin]]

Comment on attachment 8664664 [details] [diff] [review]
bug-1206719.v01.patch

Review of attachment 8664664 [details] [diff] [review]:
-----------------------------------------------------------------

It's always difficult to pick a good value for throttling that works on different devices. How about listen to 'seeked' event?
That is, if it's already 'seeking', remember the scrubber position and call fastSeek() in 'seeked' handler.

Comment 8

[Benjamin Chen [:bechen]]

Attachment: bug-1206719.v02wip.patch

wip patch.