Bug 23663 - Section 2.4.4 is not clear about whether it runs while seeking.
Section 2.4.4 is not clear about whether it runs while seeking.
Status: RESOLVED FIXED
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions
unspecified
PC Linux
: P2 normal
: LC
Assigned To: Adrian Bateman [MSFT]
HTML WG Bugzilla archive list
: a11y, a11ytf
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-28 22:45 UTC by Aaron Colwell
Modified: 2013-11-14 00:47 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Colwell 2013-10-28 22:45:06 UTC
Placeholder bug for a concern raised by individual participants in the HTML Accessibilty Task Force during the LC period.

Quoted text from http://lists.w3.org/Archives/Public/public-html-media/2013Oct/0022.html

"The second is that while it appears that the purpose of section 2.4.4 is
to ensure that all "necessary" tracks render in synch, and it appears that
this also applies when the user e.g. seeks to a new position in a
"primary", i.e. controlling track, it doesn't say anywhere that this
happens. Reading the algorithms is a very complex way to understand what
is actually happening, and a simple informative paragraph explaining the
effects would be appreciated - especially for this use case, but possibly
in other parts of the specification as well."
Comment 1 Aaron Colwell 2013-10-28 23:55:48 UTC
Section 2.4.4 does not run during seeking. It only runs during playback as the first sentence in the section states. One thing that might make the seeking behavior a little more obvious is to to change the "The media element waits for the necessary media segments to be passed to appendBuffer() or appendStream()." step in Section 2.4.3 to something more along the lines of "The media element waits until an appendBuffer() or appendStream() call causes the coded frame processing algorithm to set the HTMLMediaElement.readyState attribute to a value greater than HAVE_METADATA." I think this would make it easier for the reader to figure out how the element gets out of the HAVE_METADATA state during a seek.

As for adding more informative paragraphs around the spec, the concensus in the task force to similar requests in the past has been to keep the spec primarily algorithmic when it comes to specifying behavior. There have been discussions about creating a primer that includes more informative descriptions of the behavior for folks that are not implementing MSE in a UA, but no one has stepped forward to take on that work yet.
Comment 2 Aaron Colwell 2013-11-14 00:27:08 UTC
Change committed.
https://dvcs.w3.org/hg/html-media/rev/306bb395f94e

Updated section 2.4.3 with the text proposed in comment 1.
Comment 3 Aaron Colwell 2013-11-14 00:47:47 UTC
Just for reference here are some of the various discussions that have occurred in the past around informative text and the primer. This is not an exhaustive list since there have also been many minor discussions within bug comments and on the conference calls.

Mailing list discussion on the amount of non-algorithmic text in the spec: 
http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0065.html
http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0000.html

Primer discussed in April 2013 F2F minutes:
http://www.w3.org/2013/04/23-html-wg-minutes.html#item10

Primer call for volunteers:
http://lists.w3.org/Archives/Public/public-html-admin/2013May/0002.html

Telecon minutes where primer was discussed.
http://lists.w3.org/Archives/Public/public-html-media/2013May/0084.html
http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0057.html