This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13435 - Editorial changes to The Video element (3 of 5)
Summary: Editorial changes to The Video element (3 of 5)
Status: CLOSED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: John Foliot
QA Contact: HTML WG Bugzilla archive list
URL: http://www.w3.org/TR/2011/WD-html5-20...
Whiteboard:
Keywords: a11y, a11ytf, media
Depends on:
Blocks:
 
Reported: 2011-07-28 21:50 UTC by John Foliot
Modified: 2014-03-08 22:11 UTC (History)
10 users (show)

See Also:


Attachments

Description John Foliot 2011-07-28 21:50:25 UTC
"When a video element is paused at any other position, and the media resource has a video channel, the element represents the frame of video corresponding to the current playback position, or, if that is not yet available (e.g. because the video is seeking or buffering), the last frame of the video to have been rendered.

recommended  change:

"When a video element is paused at any other position, and the media resource has a video channel, the element represents the frame of video corresponding to the current playback position, or, if that is not yet available (e.g. because the video is seeking or buffering), the last frame of the video to have been rendered.  If synchronized text (e.g., captions or subtitles) or sign-language tracks are present, those tracks must be represented in the paused frame as well."

filed on behalf of the a11yTF
Comment 1 Philip Jägenstedt 2011-07-29 09:57:11 UTC
This appears to be something that MediaController does, but the details are still unclear to be.
Comment 2 Michael[tm] Smith 2011-08-04 05:01:40 UTC
mass-moved component to LC1
Comment 3 Ian 'Hixie' Hickson 2011-08-09 23:42:16 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale:

Doing this would be massively complicated. By the time we reach the point where the right video frame is not being rendered, the events have already fired on the cues to tell them that they're no longer active (that has to be the case so that pauseOnExit cues can work). This means the cues might have been changed (e.g. if the script is preparing cues behind the scenes in preparation for going back to play the segment of video, etc). I really don't see how we could cause the cues to display regardless — the captions might be being rendered by the script itself, so we'd have to do something crazily complicated like fake the currentTime back to the time of the last frame, but only for the captions not the buffering... It would be a huge gnarly mess.

However, all is not lost — indeed things here are nowhere near as bad as it may seem. In practice, there are two cases where this might happen: if the video runs out while playing, and if the user has seeked.

In the normal playback case, the only way this could be visible is if the very next frame after the last frame displayed was the one at which the captions would have gone away anyway. In that case, it really is not an accessibility problem, unless one is going to argue that there is some big accessibility difference between a video stalling at frame 302923 or at frame 302924, which seems unlikely.

In the seek case, the user probably explicitly moved the video playhead, so IMHO it's really hard to argue that the user still needs the captions in that case. If the user wanted the old captions, he could just have seeked to the point where those captions were present. Indeed if anything it makes the captioned experience better than the non-captioned experience since it means a user can scrub the seek bar and quickly scan through all the subtitles without having to wait for the video to load.
Comment 4 Silvia Pfeiffer 2011-08-10 00:10:54 UTC
(In reply to comment #3)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Change Description: no spec change
> Rationale:
> 
> Doing this would be massively complicated. By the time we reach the point where
> the right video frame is not being rendered, the events have already fired on
> the cues to tell them that they're no longer active (that has to be the case so
> that pauseOnExit cues can work). This means the cues might have been changed
> (e.g. if the script is preparing cues behind the scenes in preparation for
> going back to play the segment of video, etc). I really don't see how we could
> cause the cues to display regardless — the captions might be being rendered
> by the script itself, so we'd have to do something crazily complicated like
> fake the currentTime back to the time of the last frame, but only for the
> captions not the buffering... It would be a huge gnarly mess.
> 
> However, all is not lost — indeed things here are nowhere near as bad as it
> may seem. In practice, there are two cases where this might happen: if the
> video runs out while playing, and if the user has seeked.
> 
> In the normal playback case, the only way this could be visible is if the very
> next frame after the last frame displayed was the one at which the captions
> would have gone away anyway. In that case, it really is not an accessibility
> problem, unless one is going to argue that there is some big accessibility
> difference between a video stalling at frame 302923 or at frame 302924, which
> seems unlikely.
> 
> In the seek case, the user probably explicitly moved the video playhead, so
> IMHO it's really hard to argue that the user still needs the captions in that
> case. If the user wanted the old captions, he could just have seeked to the
> point where those captions were present. Indeed if anything it makes the
> captioned experience better than the non-captioned experience since it means a
> user can scrub the seek bar and quickly scan through all the subtitles without
> having to wait for the video to load.


I think you're over-interpreting this bug to be asking for more than it is. The request is actually very simple: when the video is paused and displays a video frame, it should also display the associated caption text with that frame. I.e. the request is that when pausing the video, the captions will not suddenly disappear from the screen. If there is no caption text associated with the time of that frame, then naturally there won't be any overlayed text.

I think this should be possible, even if we disregard potential slight timing glitches between the video and the text track. This is more about not removing the caption text when pausing than it is about getting the timing absolutely correct.
Comment 5 John Foliot 2011-08-10 02:12:32 UTC
(In reply to comment #4)
> 
> I think this should be possible, even if we disregard potential slight timing
> glitches between the video and the text track. This is more about not removing
> the caption text when pausing than it is about getting the timing absolutely
> correct.

Agreed. There is no need to have micro-second syncing here, it is, as Silvia states, sufficient that when a video is stopped or paused that the timed caption file continue to render text on screen (in an equivalent stopped or paused state).
Comment 6 Ian 'Hixie' Hickson 2011-08-15 04:51:17 UTC
That's not at all what the original description was talking about. It specifically was talking about the timing difficulty case.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: no spec change
Rationale: 

When the video is paused, the current captions do keep showing. What makes you think otherwise?
Comment 7 John Foliot 2011-09-06 19:29:23 UTC
(In reply to comment #6)
> 
> Status: Accepted
> Change Description: no spec change
> Rationale: 
> 
> When the video is paused, the current captions do keep showing. What makes you
> think otherwise?

What makes you assume that this will be the default behavior? This is not yet specified, and I wonder aloud why being more specific in a specification is a bad thing? 

Is there a technical reason for not adding the additional sentence: "If synchronized text (e.g., captions or subtitles) or sign-language
tracks are present, those tracks must be represented in the paused frame as
well."?
Comment 8 Ian 'Hixie' Hickson 2011-09-21 20:08:16 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: It is specified already: "The video element also represents any text track cues whose text track cue active flag is set and whose text track is in the showing or showing by default modes."
Comment 9 Mark Sadecki 2014-03-08 22:11:07 UTC
Discussed during HTML Accessibility TF Meeting on 27 FEB 2014
http://www.w3.org/2014/02/27-html-a11y-minutes.html#item04

And on list:
http://lists.w3.org/Archives/Public/public-html-a11y/2014Mar/0000.html

RESOLVED to CLOSE
RATIONALE: Spec has changed and sufficiently addressed the issue