Re: [media] progress on multitrack api - issue-152

Are you in particular referring to a change of the following sentence
in the video element section 4.8.6:
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video or
http://dev.w3.org/html5/spec/Overview.html#video

"A video element is used for playing videos or movies."

Would you prefer this to read something like:

"A video element is used for playing videos, movies, or sound files."

Further a change of:

"The video element is a media element whose media data is ostensibly
video data, possibly with associated audio data."

to something like:

"The video element is a media element whose media data is ostensibly
video data, possibly with associated audio data. This includes
audio-only resources that may be displayed with a representative image
in @poster or with captions or subtitles for visual representation."

Maybe something of this sort can be achieved?

I would, however, suggest to take this up as a separate bug in the
bugtracker, since it doesn't effectively have any relation to
multitrack - it's a broader issue on video elements in general.

Cheers,
Silvia.


On Tue, Apr 19, 2011 at 1:32 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
> If the clarifications I proposed last week are included (i.e. to indicate expressly that the <video> element operates on audio only data, and has a display rectangle to renders captions into, even if there is no video data supplied), then I would formally withdraw my CP in favor of Proposal 4 as amended.
>
> -----Original Message-----
> From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Silvia Pfeiffer
> Sent: 18 April 2011 12:49
> To: HTML Accessibility Task Force
> Subject: Re: [media] progress on multitrack api - issue-152
>
> Note that I have certainly missed issues, so do speak up if you've
> noticed anything.
> Cheers,
> Silvia.
>
> On Mon, Apr 18, 2011 at 12:05 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> Hi all,
>>
>> In the last media subgroup meeting we further discussed the different
>> change proposals that we have for issue-152.
>>
>> A summary of all the submitted change proposals is at
>> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposals_Summary
>> .
>>
>> We discussed that Proposal 4 can, with a few changes, provide for the
>> requirements of in-band and externally composed multitrack resources.
>> Proposal 4 introduces an interface for in-band audio and video tracks,
>> and a Controller object to maintain the shared state between the
>> individual media elements that together make up a composed multitrack
>> resource.
>>
>> This email serves two purposes:
>>
>> Firstly it asks others on the accessibility task force whether there
>> are any objections to going with proposal 4 (Philip?, Geoff?). The
>> people present at the meeting agreed that they would be prepared to
>> withdraw their change proposals in favor of proposal 4. This include
>> all proposals numbered 1 to 3 on the summary page.
>>
>> Secondly it summarizes the remaining issues that we would like
>> addressed for proposal 4.
>>
>> The remaining issues are:
>>
>> (1) videoTracks should be MultipleTrackList, too:
>>
>> The current HTMLMediaElement has the following IDL to expose in-band
>> media tracks:
>>  readonly attribute MultipleTrackList audioTracks;
>>  readonly attribute ExclusiveTrackList videoTracks;
>>
>> The objection is to the use of ExclusiveTrackList on videoTracks. It
>> should be allowed to have multiple in-band video tracks activated at
>> the same time. In particular it seems that MP4 files have a means of
>> specifying how multiple video tracks should be displayed on screen and
>> Safari is already able to display such.
>>
>> In contrast, proposal 4 requires that only one in-band video track can
>> be active and displayed into the video viewport at one time. If more
>> than one video track is to be displayed, it needs to be specified with
>> a media fragment URI in a separate video element and connected through
>> a controller.
>>
>> Some questions here are: what do other browsers want to do with
>> multiple in-band video tracks? Does it make sense to restrict the
>> display to a single video track? Or should it be left to the browser
>> what to do - in which case a MultipleTrackList approach to videoTracks
>> would be sensible? If MultipleTrackList is sensible for audio and
>> video, maybe it could further be harmonized with TextTrack.
>>
>>
>> (2) interface on TrackList:
>>
>> The current interface of TrackList is:
>>  readonly attribute unsigned long length;
>>  DOMString getName(in unsigned long index);
>>  DOMString getLanguage(in unsigned long index);
>>           attribute Function onchange;
>>
>> The proposal is that in addition to exposing name and language
>> attributes - in analogy to TextTrack it should also expose a label and
>> a kind.
>>
>> The label is necessary to include the track into menus for track
>> activation/deactivation.
>> The kind is necessary to classify the track correctly in menus, e.g.
>> as sign language, audio description, or even a transparent caption
>> track.
>>
>>
>> (3) looping should be possible on combined multitrack:
>>
>> In proposal 4 the loop attribute on individual media elements is
>> disabled on multitrack created through a controller, because it is not
>> clear what looping means for the individual element.
>>
>> However, looping on a multitrack resource with in-band tracks is well
>> defined and goes over the complete resource.
>>
>> In analogy, it makes sense to interpret loop on a combined multitrack
>> resource in the same way. Thus, the controller should also have a
>> muted attribute which is activated when a single loop attribute on a
>> slave media element is activated and the effect should be to loop over
>> the combined resource, i.e. when the duration of the controller is
>> reached, all slave media elements' currentTime-s are reset to
>> initialPlaybackPosition.
>>
>>
>> (4) autoplay should be possible on combined multitrack:
>>
>> Similar to looping, autoplay could also be defined on a combined
>> multitrack resource as the union of all the autoplay settings of all
>> the slaves: if one of them is on autoplay, the whole combined resource
>> is.
>>
>>
>> (5) more events should be available for combined multitrack:
>>
>> The following events should be available in the controller:
>>
>> * onloadedmetadata: is raised when all slave media elements have
>> reached at minimum a readyState of HAVE_METADATA
>>
>> * onloadeddata: is raised when all slave media elements have reached
>> at minimum a readyState of HAVE_CURRENT_DATA
>>
>> * canplaythrough: is raised when all slave media elements have reached
>> at minimum a readyState of HAVE_FUTURE_DATA
>>
>> * onended: is raised when all  slave media elements are in ended state
>>
>> or said differently: these events are raised when the last slave in a
>> group reaches that state.
>>
>> These are convenience events that will for example help write combined
>> transport bars. It is easier to attach just a single event handler to
>> the controller than to attach one to each individual slave and make
>> sure they all fire. Also, they help to maintain the logic of when a
>> combined resource is loaded. Since these are very commonly used
>> events, their introduction makes sense.
>>
>> Alternatively or in addition, readyState could be added to the controller.
>>
>>
>> (6) controls on slaves control the combined multitrack:
>>
>> Proposal 4 does not provide any information on what happens with media
>> elements when the @controls attribute is specified. Do the controls
>> stay in sync with the controls of the other elements? Do they in fact
>> represent combined state? Do they represent the state of the slave
>> resource? What happens when the user interacts with them? Is the
>> information on the interaction - in particular seeking, muting, volume
>> change, play/pause change, rate change - handed on to the controller
>> and do the others follow?
>>
>>
>>
>> Hopefully we can move forward on all of these issues before the 22nd
>> April deadline for issue-152.
>>
>> Best Regards,
>> Silvia.
>>
>
>
>

Received on Tuesday, 19 April 2011 01:29:21 UTC