[whatwg] video tag : loop for ever

[Dr. Markus Walther]

anybody noticed the discussion starts mimicking the title, looping
forever... ;-)

I think that, when taking into account earlier responses to this
list/thread carefully, it is clear that recent responses don't quite fit
the legitimate use cases that Jonas, I and other have presented.

Let me try to summarize again:

The way I see it, the discussion is about the need for 'start' and 'end'
attributes for <audio>, both in conjunction with looping (hence the
title) and without (e.g. my use case of audio editor in a browser).

Any proposed solution that ignores the use case where 'start' and 'end'
values are not known in advance is not satisfactory IMHO (see my
previous posts for details). That rules out jar or other container
files, for there the audio snippets would have to be statically known.
It also rules out multiple audio elements pointing statically to
different files or fragments of files. The use case is dynamic, so
static won't work. You need to be able to set 'start'/'end' e.g. on user
mouse input in the browser!

Any proposed solution that requires a server roundtrip just to reselect
a different section of the same audio material seems inadequate for
latency-sensitive applications (see my previous posts for details).
Latency issues will also likely kill the idea of a callback triggered by
a cue range ending - the audio will likely stop playing too late (and
yes, there are apps requiring that kind of accuracy).

Last but not least audio can also be dynamically generated or modified
in the browser using data URIs - I have done it for the PCM WAVE format.
In the absence of an 'audio canvas' (see my earlier posts) or an
interface like what Flash 10 recently provided, there is not much else
you can do. If audio can originate from the client, however, no
server-side proposal will help in selecting sections from it for playback.

Question: In the light of the combined evidence for the usefulness of
'start'/'end' for <audio> (implemented in Safari already), why insist
further on avoiding those?

--Markus

Jonas Sicking wrote:
> On Oct 29, 2008, at 18:34, "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
> wrote:
> 
>> On Thu, Oct 30, 2008 at 11:52 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>> Eduard Pascual wrote:
>>>>
>>>> On Wed, Oct 29, 2008 at 6:16 PM, Jonas Sicking <jonas at sicking.cc>
>>>> wrote:
>>>>>
>>>>> 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.
>>>>
>>>> Wouldn't multiple <audio> elements be better here? They'd point to the
>>>> actual same file, but different fragments. That would even make the
>>>> script less bloated (just selecting each element, instead of
>>>> explicitly getting the appropriate fragment from the "master" file
>>>> each time you need it). This brings the additional advantage that, in
>>>> the event the server does support file fragments, only the actually
>>>> required fragments will be downloaded.
>>>
>>> The whole idea was to make a single HTTP request to the server.
>>> Doesn't seem
>>> like your proposal accomplishes that.
>>>
>>> As I said, I'm fine with not satisfying this use case (of allowing
>>> multiple
>>> sound effects downloaded in a single request). But that was the use case
>>> that was cited.
>>
>> No, that's not a use case - that's a proposed solution for the use
>> case of having multiple small audio files required for playback of one
>> larger audio presentation. If another solution can satisfy this need
>> with appropriate qos, then I don't think we need to worry further.
> 
> That's exactly what proposal 3 was.
> 
> / Jonas
>