- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 27 Oct 2008 07:55:35 +1100
On Sat, Oct 25, 2008 at 6:18 PM, Jonas Sicking <jonas at sicking.cc> wrote: >>>> After thinking about this, I'm not sure that limiting playback to a >>>> section of a media file will be used very often. A developer can easily >>>> script the same functionality as long as they don't use the default >>>> controller, so it seems to me that attributes for this aren't warranted. >>> >>> I think they are useful if you want to: >>> >>> a) Loop a fragment (might be useful for audio for the same reason people >>> chop up a single large image to use multiple background images) >> >> Does having a boolean loop attribute (also included in the DOM) >> satisfy your needs? >> >> >>> b) Use the default controls and get the right behavior. This is pretty >>> important, I don't think we should require writing a full custom set of >>> media controls just to be able to play a fragment without getting clearly >>> bogus UI. >> >> I think controlling a video or audio player requires a decent >> javascript API. Mabye we are still lacking in that respect. But I >> don't think start and end should be a feature of html elements, >> because if they are mainly used for dynamic stuff, they are not well >> expressed as attributes. > > It sounds to me like there are 3 proposals: > > 1. Have 'start' and 'end' as content attributes. This means that they > are accessible though getAttribute/setAttribute and <video start=... > end=...> in the markup). > They are also available as DOM attributes, i.e. myVideo.start = ... > myVideo.end = ... > > 2. Allow a fragment identifier to be specified in the src that specifies > a part of the file to be played. > Expose DOM attributes to control the start and the end, i.e. > myVideo.start = ..., myVideo.end = ... > Setting these attributes would change the value of the fragment > identifier in the src attribute and thus which part is being played > > 3. Allow a fragment identifier to be specified in the src that specifies > a part of the file to be played. > Don't expose myVideo.start or myVideo.end DOM attributes. Instead > address the use case of having multiple sound effects in a single > downloaded file in some other way (for example using zip files, > playlists, or simply letting people set the fragment identifier > manually using the src attribute) > > > There is also the somewhat orthogonal issue of if the default UI should only > display the selected range (be it if the selection happens through content > start/end attributes or a fragment identifier). > > I would personally be fine with all three proposals. The risk with proposals > 1 and 2 that I see is that a implementation might be expected to download > the whole file even if just part of it is specified to be played so that > transitions can happen rapidly. Just to clarify: the specification of a media fragment in a URI is supposed to enable receiving of just the specified fragment, not only the full resource. The media fragments Working Group is creating a specificaton that will enable that. I actually think that your options 2 and 3 are orthogonal. 2 is about playing (and looping over) a media fragment, while 3 is about creating a playlist of multiple media resources (potentially also having a fragment specifier). The first one (your number 2) can clearly be solved through the URI fragment specification. I would prefer not to create DOM attributes though because I don't see setting "start" and "end" times for playback as a state, but rather as a control function. I would prefer to use "seek" and "play" and "stop" javascript functions to achieve the same aims. I think we need to work on the javascript API for video and audio elements. As for the second case (your number 3), there are playlist specifications such as xspf (http://xspf.org/specs/) or SMIL 3.0 server playlist profile (http://www.w3.org/TR/2006/WD-SMIL3-20061220/smil-serverplaylist-profile.html) that can tell the user agent which media resources to get in order. The UA can of course decide to pre-buffer the next resource such as to enable transitions to happen rapidly. Regards, Silvia.
Received on Sunday, 26 October 2008 13:55:35 UTC