- From: Spartanicus <mk98762@gmail.com>
- Date: Sun, 24 Jun 2007 14:00:16 +0100
"Silvia Pfeiffer" <silviapfeiffer1 at gmail.com> wrote: >A <video> element that is natively part of html and has a standard set >of API functions will enable applications that are impossible today, >even with embedded elements such as flash. > >Imagine e.g. a mash-up of video extracts from several video hosting >sites where you take an offset from each and put them together in a >new video without having to manually edit that content. Only if all >videos are in the same format and all hosting sites provide the same >API will such a mashup be possible. > >I for one see the <video> and <audio> elements as one of the main >novelties that make html5 important. You get no argument from me against the basic value of native browser support for video and audio, although imo the example you use is an edge use case and might not work in practice (with my limited knowledge of modern video encoding techniques I'm inclined to believe that the key frame nature of video formats will make it very difficult to splice encoded videos together). What I question is the practical value of specifying something that afaics will end up being useless for web deployment (controlled intranet usage could be possible). >If we put a requirement into the spec for a common baseline codec and >the value of that can be demonstrated through several hosting sites - >e.g. wikipedia, archive.org - and new applications will be >demonstrated with the new <video> element - then I think there is a >reason to go forward. I'm uncomfortable with having a baseline codec. Even if IE would support a baseline codec, they are likely to also include a codec with a considerably better quality vs bitrate. Given their market share I fear that could result in a considerable number of content providers choosing to use the proprietary format. This would result in a schism in the availability of web content. I feel passionately that all public web content, be it text, images, audio, video or any other form should exclusively be made available using open, rights free encoding formats and transport protocols. This would result in lower quality encoding formats given the absence of commercial incentives to develop such formats and protocols, but the benefits far outweigh this drawback imo. >In any case: plugins can be written for IE and for Safari that make >them support Ogg Theora and the <video> tag, even if neither Microsoft >nor Apple will be distributing them. Imo for content providers to choose <video> over Flash, client support needs to be close to Flash. Requiring IE and Safari users to go and download and install third party software to play content would imo be considered too much of a hindrance when Flash "simply works". >Where there's a will, there's a way. We have to do what is right, not >what is politically acceptable. Frustrated as I am with the current state of affairs, I don't see any point in taking a principal stance if it will result in being ignored. -- Spartanicus
Received on Sunday, 24 June 2007 06:00:16 UTC