[whatwg] video tag : loop for ever

I believe your use case of creating an adio editor through using the
"audio" tag is a bit far fetched. I don't think it lends itself to
that kind of functionality. You would not use the "img" tag to
implement a picture editor either.

As for start/end attributes - I still believe that a javascript API
towards changing start and end times for playback is much more
appropriate than changing attributes and expecting the media framework
to react to the changed attribute values. If the main usecase for you
is dynamic and not static, then you should have an interface that has
direct access to the video controls (i.e. directly run a function)
rather than going through an attribute indirection (i.e. change state,
which needs to trigger a function). Note that this does not imply a
roundtrip to the server.

Regards,
Silvia.

On Thu, Oct 30, 2008 at 10:13 PM, Dr. Markus Walther <walther at svox.com> wrote:
> 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
>>
>

Received on Thursday, 30 October 2008 05:08:57 UTC