[whatwg] video tag : loop for ever

Silvia Pfeiffer wrote:
> 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).

Sorry, I think I was being unclear.

Maciej (and I think others) have suggested that it would be useful if it 
was possible to allow <audio> to be used such that a single file can be 
downloaded that contains multiple sound effects, and then use javascript 
to play different sound effects contained in that file at various times.

For example someone creating a shoot-em-up game might create a file that 
contains the sound for "shoot weapon", "enemy exploding", "player 
dying", and "player finishes level". It can then when appropriate use 
javascript to play any one of these sound effects.

I have heard three proposed "solutions" for this use case:

1. Have start=".." and end=".." content attributes.  This means that
    they are accessible though getAttribute/setAttribute and
    <audio start=... end=...> in the markup).
    They are also available as DOM attributes, i.e. myAudio.start = ...
    myAudio.end = ...
    So to play a specific sound effect script would do:
    myAudio.start = enemyExplodingStart;
    myAudio.end = enemyExplodingEnd;
    myAudio.play();

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.
    myAudio.start = ..., myAudio.end = ...
    Setting these attributes would change the value of the fragment
    identifier in the src attribute and thus which part is being played.
    To play a specific sound effect script would do:
    myAudio.start = enemyExplodingStart;
    myAudio.end = enemyExplodingEnd;
    myAudio.play();

3. Not add specific support to <audio> for now. Instead rely on
    specifications such as xspf playlists or jar protocols.
    It would still be possible for a page to do:
    myAudio.src = audioURL + "#start=" + enemyExplodingStart +
                  ";end=" + enemyExplodingEnd;
    myAudio.play();

My concern with 2 (and 3 if people use the .src=... hack) is that it'll 
work as long as the server doesn't support downloading just a range 
since then the browser sucks down the whole file and can quickly jump to 
any part. However it stops working smoothly once servers support 
fragment downloads since then the browser will only have part of the file.

/ Jonas

Received on Wednesday, 29 October 2008 11:16:55 UTC