[whatwg] video tag : loop for ever

[Silvia Pfeiffer]

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.