W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2008

[whatwg] Identifying supported codecs

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 8 Jul 2008 22:41:45 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0807082232550.11215@hixie.dreamhostps.com>
On Wed, 18 Jun 2008, Anne van Kesteren wrote:
> On Wed, 18 Jun 2008 12:01:13 +0200, <j at oil21.org> wrote:
> > as it looks like there will not be a common base codec any time soon,
> > there is a need to be able to detect the supported codecs in javascript.
> > are there any plans to provide such an interface or is this already
> > possible?
> 
> Why is that needed? The elements provide a way to link to multiple 
> codecs of which the user agent will then make a choice.

On Wed, 18 Jun 2008 j at oil21.org wrote:
>
> i do not intend to provide multiple codecs since that would require 
> multiple backend implementations for playing files form an offset, 
> encoding files in multiple codecs on the server, more disk space etc,
> 
> instead i would only use the <video> tag if the codec i use is supported 
> and fall back to other means via <object> / java / flash or whatever to 
> playback the video or indicate that the user has to install a 
> qt/dshow/gstreamer plugin. in an ideal world i could use <video> like i 
> can use <img> now and be done with it, but since this is not the case we 
> need tools to make the best out of <video>, not knowing what the browser 
> supports and just hoping that it could work is not an option.

On Wed, 18 Jun 2008, Philip J?genstedt wrote:
> 
> ???It seems to me that it's a good idea to wait with this until we know 
> more about what will happen with baseline codecs etc. 
> Implementation-wise it might be less than trivial to return an 
> exhaustive list of all supported mime-types if the underlying framework 
> doesn't use the concept of mime-types, but can say when given a few 
> bytes of the file whether it supports it or not. Allowing JavaScript to 
> second-guess this seems like a potential source of incompatibility. 
> Isn't it sufficient to look for MEDIA_ERR_DECODE and add fallback 
> content when that happens?

On Wed, 18 Jun 2008, Jo?o Eiras wrote:
>
> The spec clearly says the following
> http://www.whatwg.org/specs/web-apps/current-work/#video1
> "User agents should not show this content to the user; it is intended 
> for older Web browsers which do not support video,"
>
> Although we fully understand the reasoning behind this, there's an use
> case missing.
> The user agent may support video but might not support the file format.
> So in this case, <video> should do fallback, because:
> a) <video> tags are markup and therefore its error handling is not
> available to scripts
> b) the author may not want to use scripts, or may want to make the
> page fully usable with scripting
> c) it's a predictable scenario without any written solution

On Wed, 18 Jun 2008 j at oil21.org wrote:
>
> i imagined something that would use the ???type string used in <source>
> so i can do:
>  canDecode('video/mp4; codecs="avc1.42E01E, mp4a.40.2"')
> ???or
>  canDecode('video/ogg; codecs="theora, vorbis"')
> 
> while waiting for ???MEDIA_ERR_DECODE might be an option, it sounds to 
> me that that would involve a network connection being made, the video 
> being buffered and after that the media engine failing, this takes to 
> long to make a presentation decision based on it.

Actually MEDIA_ERR_DECODE will only fire if the advertised codec is 
supported but the media stream doesn't use it.

If none of the advertised codecs are supported, then load() will fire 
INVALID_STATE_ERR.

Anyway, the net effect is that you can already tell if any of the 
advertised codecs are supported.

Since the goal is to just have one codec, I don't want to add new stuff 
just to handle the case where the codec isn't supported.


On Wed, 18 Jun 2008, Henri Sivonen wrote:
> 
> Are MIME types the right way of identification in HTML5 if the 
> well-known frameworks use something other than MIME types?

I'm happy to use whatever implementors want to use. So far MIME types have 
been what has been suggested.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 8 July 2008 15:41:45 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:03 UTC