Re: [whatwg] Corrections for examples in section 3.14.10
On 12/30/07, Ralph Giles [EMAIL PROTECTED] wrote: I don't think it's a good idea to suggest people to start using .oga for Ogg Vorbis files. The plan where Ogg Theora - .ogv, Ogg FLAC - .oga, Ogg Ghost = .oga, but we keep Ogg Vorbis = .ogg as before makes more sense to me. I'm not sure what speex should do, and the presense of skeleton should be a major determiner between the old and new regimes. Exactly. The proposed corrections make sense. They are also in line with the I-D submited to the IETF regarding the issue. -Ivo
Re: [whatwg] Corrections for examples in section 3.14.10
For those not aware of what issue this thread is discussing, Xiph is implementing a set of file extensions to make sure implementations work as well as possible with different content encapsulated in Ogg. Those are: .ogx for applications .ogv for video .oga for audio Ogg files should use those file extensions with a notice that there is a requirement (for the first) and a recommendation (for the other two) that those files carry an Ogg Skeleton bitstream. Ogg Skeleton is an extension of Ogg to make it easier for implementations to demux content inside Ogg containers. However, as Ralph Giles mentioned, this is not entirely the case with Vorbis and Speex. If those codecs go alone in the container without the Skeleton bitstream, which has been the behavior for the past years since their conception they should use their legacy file extensions (.ogg and .spx respectively) to make sure backwards-compatibility is not broken. This is then the desired way to serve those files and why I proposed the corrections in the original post of this thread. Nothing prevents files or implementations dealing with Vorbis and Speex to use .oga, as long as the Skeleton recommendation is noticed and .oga is not used as the default extension of those two codecs. Any other type of data encapsulated in Ogg, multiplexed or not, should use the new set of extensions. I hope this information was useful. -Ivo
[whatwg] Corrections for examples in section 3.14.10
On the examples: Vorbis audio alone in Ogg container source src=audio.oga type=audio/ogg; codecs=vorbis Speex audio alone in Ogg container source src=audio.oga type=audio/ogg; codecs=speex This should be: Vorbis audio alone in Ogg container source src=audio.ogg type=audio/ogg; codecs=vorbis Speex audio alone in Ogg container source src=audio.spx type=audio/ogg; codecs=speex Rationale: While Vorbis and Speex files (in Ogg) may use the .oga extension, it is far more common to see them using .ogg and .spx respectively. Right below this section: Flac audio alone in Ogg container source src=audio.oga type=audio/ogg; codecs=flac Should be: FLAC audio alone in Ogg container source src=audio.oga type=audio/ogg; codecs=flac Rationale: The file extension is correct in the example. The error is in how FLAC is written, as FLAC is an acronym. May be worth fixing for correctness sake. -Ivo
Re: [whatwg] Patent on VP3 / Apple
On Dec 14, 2007 2:22 AM, Dave Singer [EMAIL PROTECTED] wrote: We are not trying to be obstructive but rather the reverse. We want a solution which is effective and we are willing to work to that end, but some things are probably better done at arm's length or by a neutral party. Mr. Singer, are you perhaps in a position to state if Apple may embrace Theora as the baseline codec for video if Theora does come out clean after a patent search by an independent entity? -Ivo
Re: [whatwg] Video codec requirements changed
On 12/11/07, L. David Baron [EMAIL PROTECTED] wrote: # is not an additional submarine patent risk for large companies Is this something that can be measured objectively, or is it a loophole that allows any sufficiently large company to veto the choice of codec for any reason it chooses, potentially including not wanting the video element to succeed in creating an open standard for video on the Web? I agree as well that that sentence is in need of better wording as to avoid what may be an ambiguous statement. -Ivo
Re: [whatwg] Give guidance about RFC 4281 codecs parameter
On 10/13/07, Ian Hickson [EMAIL PROTECTED] wrote: Recent discussion at Xiph around http://www.ietf.org/rfc/rfc4281 suggests the use of the following parameters: # application/ogg; codecs=theora, vorbis for Ogg Theora/Vorbis files # application/ogg; codecs=theora, speex for Ogg Theora/Speex files # application/ogg; codecs=vorbis for Ogg Vorbis files and also use the disposition parameter: # application/ogg; disposition=moving-image; codecs=theora, vorbis # application/ogg; disposition=sound; codecs=speex Skeleton and the use of these MIME parameters should make things clear for the application developers. This information is not accurate anymore according to the Internet Draft[1] Xiph is working on to help solve the mess. video/ogg should be used for any kind of visual material inside Ogg. audio/ogg should be used for audio material in Ogg. These media types have a SHOULD requirement for Skeleton to help interoperability. There is one exception in audio/ogg for that requirement, which is related to serving Vorbis- or Speex-only files that need backward compatibility. This separation is explained in the I-D. application/ogg is to be used in special cases where video/ogg or audio/ogg are not recommended. Imagine scientific applications that require dozens of multiplexed signals. Content served under application/ogg MUST have a Skeleton logical stream. -Ivo [1] https://trac.xiph.org/browser/experimental/ivo/drafts/draft-xiph-rfc3534bis.txt
Re: [whatwg] Video, Closed Captions, and Audio Description Tracks
On 10/9/07, Dave Singer [EMAIL PROTECTED] wrote: If the delivery is streaming, or in some other way where the selection of tracks can be done prior to transport, then there isn't a bandwidth hit at all, of course. Then the ask this resource to present itself in the captioned fashion is a reasonable way to do this. Alternatively, as you say, one might prefer a whole separate file select this file if captions are desired. The way I see it, the browser is working like a video player. Modern video players allow users to configure if they would like to see the first subtitles track by default or not. And if the user wishes to turn subtitles on, off, or switch to another subtitles track (e.g. another language) s/he right clicks the video screen and modifies the subtitles options. Not elegant, but it works. -Ivo
[whatwg] May style have an id value?
Hello, HTML 4.01 and XHTML 1.1 do not allow id= in style. Does HTML 5 allow it? If not, that would be something I would like to request. -Ivo
Re: [whatwg] The issue of interoperability of the video element
I would like to make clear one more thing: When I attended the iCommons Summit earlier this month, I have met the project manager of the OLPC project, you know the $150 laptop for children in developing nations, and the information that I have right now is that it will not support proprietary media formats. If all goes well, there will be a large public using Theora video in their daily-life. Shouldn't they be able to see Theora video online? Do we not agree that the video element will be a great tool for online education? This won't happen if the video element becomes a failure, a failure if every vendor tries to set a different standard for video. Not to mention that patented formats will not work for the large public using the OLPC systems. See it as you want. Mozilla, Opera, and the KDE team have agreed that Theora and Vorbis are perfect for media over the web. We do not know the official position of Microsoft, although we can imagine. We do know, however, the official stance of Apple. Should everyone change their plans because of Apple's decision? I think not, but then again I work for none of those companies. -Ivo
Re: [whatwg] The issue of interoperability of the video element
According to Wikipedia, ATT is trying to sue companies such as Apple Inc. over alleged MPEG-4 patent infringement.[1][2][3] I would be fascinated to see a statement from Apple, Inc. regarding this. It's also quite interesting that different portions of MPEG-4, including different sections of video and audio are licensed separately, so what this means is that any vendor willing to support MPEG-4 for video and audio has to locate every patent holder and pay them. Oh, and will you look at this, Apple, Inc. holds one the patents! US 6,134,243 [4]. So Apple gets money for every single license sold. How nice. They are attempting to lock vendors into MPEG-4 and get money from licenses in the process. Apple, Inc. is no better than Microsoft. [1] http://www.engadget.com/2006/02/10/atandt-claims-mpeg-4-patent-infringement-wants-apple-to-pay-up/ [2] http://www.theinquirer.net/?article=29679 [3] http://www.pcmag.com/article2/0,1895,1923218,00.asp [4] http://www.mpegla.com/m4s/m4s-att1.pdf
Re: [whatwg] The issue of interoperability of the video element
On 6/24/07, Silvia Pfeiffer [EMAIL PROTECTED] 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. 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. 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. And as a work-around at the beginning, java applets such as cortado enable Ogg Theora support even without a need for native support. Where there's a will, there's a way. We have to do what is right, not what is politically acceptable. I could not possibly put it in better words than this. Thank you, Silvia. The video and audio elements are one of the best things to have come out of HTML 5. If veiled interests from Microsoft and Apple may turn those elements useless, then something is clearly wrong. Are one or two corporations the ones who decide what will work and what will not work on the web? If so, then, there's no point to joint-ventures from the public and browser developers to create something like HTML 5, because it will never work unless Microsoft and Apple say so. If you people believe that, you may as well just forget about it. HTML 5 will never work. However, if we do try to get HTML 5 working on every browser, either by demand, or through programming those features ourselves (in the case of free software browsers) it's a step in the right direction. The more browsers supporting HTML 5, the more web designers/programmers will try to implement its new features on their work. We have to go against the tide. The faster we see some support of the HTML 5 features on browsers, the faster this process will work. And you have to keep in mind that video and audio are one of the most desired features for the general public. The same way they can show images, they can also show video and audio files? That's just a feature too awesome to let it go to waste! And the only way to make it work is for as many browsers as possible to choose a de facto standard for video and audio over the web. A consensus was reached in this list during the discussion of the video and audio elements. The majority ruled in favor of Theora and Vorbis. So should you. One or two corporations, in spite of their size, are not the ones running the web: we are. We can have video and audio working outside of Flash. We can have anyone host video or audio on their web site and make it work without the middle man, being it YouTube or any other video hosting web site. And you can only get this in the real world by having as many vendors supporting the Theora and Vorbis standards. Best regards, Ivo Emanuel Gonçalves
[whatwg] The issue of interoperability of the video element
Dear WHATWG members, It has come to my attention that Apple developers behind the WebKit platform, which powers the web browser Safari, apparently intend to support the video element of the HTML 5 spec, section 3.14.7. It's all fine and well, but not a victory for web interoperability, as they do not intend to follow the User agents should support Theora video and Vorbis audio, as well as the Ogg container format part. In their own words: should support in a spec does not denote a requirement. We could have a perfectly suitable implementation of audio and video as seen in this draft spec without having theora/vorbis codecs available.[1] What this means, in my opinion, is that they will push for QuickTime video, in spite of the effort of the Opera developers to push Theora forward as the de facto standard for web video. Even if Mozilla and the KDE team prepare their web browsers to support Theora, by choosing to alienate it, Apple is allowing Microsoft to put WMV support alone in their Internet Explorer, for if Apple, one of the big players, shuns Theora, so will Microsoft. Considering the statistics, Internet Explorer being currently the web browser with bigger market share, it will force pretty much every web designer/programmer to stick to WMV only. As everyone is aware, WMV is not an open specification, nor a proper documented video format. Instead, it is heavily patented and locked in one single vendor: Microsoft. This will force vendors to either pay a license to legaly use WMV in their platforms, or to reverse engineer support for it, infriging on software patents in certain nations. This message is mostly an open letter to the Apple developers behind WebKit and to every other browser/UA developer. Please, do not shun Theora, or one of the following two things will happen: 1) either the video element will become unrelevant and non-successful, which is a shame considering its potential to revolutionize the web, 2) or everyone will be locked in whatever new version of WMV Microsoft releases in the following years--and expect some of these to be incompatible between each other. Best regards, Ivo Emanuel Gonçalves [1] http://bugs.webkit.org/show_bug.cgi?id=13708
Re: [whatwg] noscript should be allowed in head
I'm not in favor of this. As Anne pointed out, noscript is used to display alternative content that script would have shown. The kind of content that goes only in body, usually block elements, and never in head. If the WebKit developers want to follow IE's broken model on parsing even basic HTML like noscript, be my guest, but don't try to force this into HTML 5 and make it a standard. -Ivo
[whatwg] Proposal: Changing Section 3.14.8.1 to Recommend Support of Speex
Hello all, Section 3.14.7.1. of the HTML 5 specification (regarding the video element) recommends that user-agents should suport both Theora and Vorbis. This, I believe, is a great idea for interoperability between the different platforms out there, to make sure that video will work on as many user-agents as possible. I would like to propose that section 3.14.8.1, regarding the audio element, be changed to recommend that user-agents should support the Speex voice codec, as Speex seems perfectly suited for podcasts, as well as for pages read aloud. These situations seem to be one of/the aim of the audio element, hence it appears that Speex, due to its quality, patent-free status, open specification, and architecture reflecting the needs of the Internet seems to be the natural choice for interoperability of the audio element. Feedback welcome. Best regards, Ivo Emanuel Gonçalves
Re: [whatwg] Drop UTF-32
For all its worth, I'm in favor of this suggestion and most arguments provided by Michael Day. -Ivo
