W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2011

[Bug 14851] <video> Add seek() function for non-exact (fast) seeking

From: <bugzilla@jessica.w3.org>
Date: Thu, 17 Nov 2011 10:40:02 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RQzNy-0004y0-Il@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14851

--- Comment #1 from Philip Jägenstedt <philipj@opera.com> 2011-11-17 10:40:01 UTC ---
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029806.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033845.html

Background:

Compressed video streams are seldom truly random access, as most frames depend
on the preceding or following frames. Seeking to a key frame is always faster,
as any other frame requires decoding more than one frame. How slow depends on
the distance between key frames. (Somewhat simplified. Frames with multiple
reference frames and rolling intra without any key frames also exist, but is
not really relevant here.)

Use cases:

* In scripted controls, while dragging the seek head ("scrubbing") you want to
show a frame as fast as possible, not necessarily one at the exact time the
seek head is at.

* Seeking relative to the current position should guarantee that the direction
of seeking is correct even when using non-exact seeking. You need this for fast
forward/backwards skip.

Proposed solution:

Introduce a seek() function with two parameters:

* a reference point: initialTime or currentTime

* an accuracy: exact or fast

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 17 November 2011 10:40:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 17 November 2011 10:40:06 GMT