[whatwg] Javascript API to query supported codecs for video and audio
Hi, 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? j
Re: [whatwg] Javascript API to query supported codecs for video and audio
On Wed, 18 Jun 2008 12:01:13 +0200, [EMAIL PROTECTED] 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. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Javascript API to query supported codecs for video and audio
On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote: Why is that needed? The elements provide a way to link to multiple codecs of which the user agent will then make a choice. 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. j
Re: [whatwg] Javascript API to query supported codecs for video and audio
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 doesn't seem great On Wed, 2008-06-18 at 12:18 +0200, [EMAIL PROTECTED] wrote: On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote: Why is that needed? The elements provide a way to link to multiple codecs of which the user agent will then make a choice. 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. j -- Philip Jägenstedt Opera Software
Re: [whatwg] Javascript API to query supported codecs for video and audio
Sorry, my reply was cut short. Again: 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? Philip On Wed, 2008-06-18 at 17:34 +0700, 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 doesn't seem great On Wed, 2008-06-18 at 12:18 +0200, [EMAIL PROTECTED] wrote: On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote: Why is that needed? The elements provide a way to link to multiple codecs of which the user agent will then make a choice. 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. j -- Philip Jägenstedt Opera Software
Re: [whatwg] Javascript API to query supported codecs for video and audio
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 2008/6/18 Philip Jägenstedt [EMAIL PROTECTED]: Sorry, my reply was cut short. Again: 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? Philip On Wed, 2008-06-18 at 17:34 +0700, 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 doesn't seem great On Wed, 2008-06-18 at 12:18 +0200, [EMAIL PROTECTED] wrote: On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote: Why is that needed? The elements provide a way to link to multiple codecs of which the user agent will then make a choice. 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. j -- Philip Jägenstedt Opera Software
Re: [whatwg] Javascript API to query supported codecs for video and audio
On Wed, 2008-06-18 at 17:38 +0700, Philip Jägenstedt wrote:
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?
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.
j
Re: [whatwg] Javascript API to query supported codecs for video and audio
On Jun 18, 2008, at 13:34, Philip Jägenstedt wrote: 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 Are MIME types the right way of identification in HTML5 if the well- known frameworks use something other than MIME types? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
