[whatwg] Codecs for <audio> and <video>

Kristof Zelechovski wrote:
> Audible mouse feedback is an OS thing, not an HTML thing.
>   
While users will certainly have applications and os-level accessibility 
tools,
web designers may have their own unique methods of presenting feedback,
and I believe, given enough easy-access, innovative interfaces will come 
from it.
> I would rather have programmatic access to the MIDI synthesizer rather than
> be able to simulate it with a beep.
>   
There is no guarantee that a host system will have a MIDI synthesizer,
and MIDI itself can quite simply be implemented with a series of audio 
clips, a sound font.
Given a very constrained environment (think old cell phone ring tones), 
you can still
"simulate it, with a beep", to provide some form of fall back.

> How do you detect that the client mixer is too slow?
>   
How do you detect that the client player is too slow with the current 
audio tag?
> Why can't you just get the premixed jingles from the server?
>   
You can get pre-mixed jingles from the server, but that may mean high 
bandwidth
in an otherwise resource constrained environment.
> Isn't the reading voice a CSS thing?  
>   
Yes. So?
> Isn't sound transformation hard enough to deserve a complete API?  I think
> allowing playing with binary audio data is not going to help most
> programmers who do not have the slightest idea of how to deal with it.
>   
Sound transformation does not need a "complete" API, but there are
certainly a few common filters which would make things easier on 
end-developers.
Given any amount of support, you'll soon see programmers developing
their own libraries.
> Imagine a Canvas interface with PutPixel only.
>   

I've imagined Canvas with putPixel (and setPixel) and that's enough to 
support
arbitrary drawing, and arbitrary image formats, and that's better than 
nothing.

Most programmers will be able to use a Javascript library, just as 
they've done in the past.

If you have particulars you'd like to see in an initial API, do share.

I could think of FFT/inverse FFT as a particular function which might 
make sense in an initial API,
as they're very particular functions, they're resource intensive, and 
they're in common use.

> IMHO,
> Chris 
>
>

Received on Tuesday, 7 July 2009 08:39:56 UTC