Re: [whatwg] Firefox 4 Beta 1
The problem is that YouTube's fullscreen button doesn't actually make the video full screen, so it doesn't take advantage of the hardware accelerated fullscreen video in Firefox 4. There's no generic API for allowing web pages to create skinned HTML 5 players with a "click to fullscreen" button. On Wed, Jul 7, 2010 at 6:43 AM, Schalk Neethling wrote: > Ah, ok. I see but then I wonder what the problem is with regards to Youtube > and full screen as their full screen mode is fully user driven. > > -Original Message- > From: Adam Barth [mailto:w...@adambarth.com] > Sent: Wednesday, July 07, 2010 1:22 PM > To: Schalk Neethling > Cc: whatwg > Subject: Re: [whatwg] Firefox 4 Beta 1 > > I'm sure they keep using HTML5 video in full screen. The issues around > full > screen relate to letting the page trigger full screen. > It's fine for the user to trigger it directly. > > Adam > > > On Wed, Jul 7, 2010 at 3:38 AM, Schalk Neethling < > sch...@ossreleasefeed.com> > wrote: > > Hi there everyone, > > > > > > > > Downloaded and installed the first beta of Firefox 4. To the folks at > > Mozilla that is on here, what an awesome job. Love the new look and it > > IS very fast. The reason I mention Firefox 4 is because, on the > > welcome screen you get after installing the browser, you have the > > option to view a video introduction to Firefox 4, nothing strange here > > but, first the video format is WebM, which is awesome, the other > > thing, and this is the main reason for this mail, if you right click > > on the video there is a context menu option for full screen. > > > > > > > > Upon clicking that, the video goes into full screen mode and it does > > this, I must say, very nicely. I also noted that in full screen right > > clicking is disabled. With the discussions around full screen HTML5 > > video as well as content protection, it seems Mozilla has made some > > progress. Am I correct in saying that they keep running HTML5 video > > 'mode' when going to full screen or do they somehow switch to Flash? > > > > > > > > Would be pretty amazing if they do switch to Flash as the video > > continues playing from the same frame and does not start from the > beginning. > > > > > > > > Looking forward to your feedback, > > > > Schalk Neethling > > > > > >
Re: [whatwg] More YouTube response
On Mon, Jul 5, 2010 at 3:46 PM, Shane Fagan wrote: > > Internet Explorer 9 will not support VP8 unless the user manually > > installs the codec. This puts it at the same level of support as > > Safari has for Theora, as far as I know. So even if we assume every > > user upgraded to the latest alphas of the browser they used, H.264 is > > supported by about 65% of users' browsers, and VP8 by about 40%. Of > > course, in reality, less than half of users' browsers support > > at all right now, and given IE uptake rates, that's only going to > > change slowly. > > For windows maybe there should be a .exe/.msi with the entire package of > VP8+Theora+Vorbis or just VP8+Vorbis to make it easier to install but > adoption isnt really our issue thats Microsoft's issue if WebM takes > off. I dont foresee it being any harder than Adobe Flash to install for > the regular user so websites could just direct users to the download if > they dont have it already. > > Oh and IE is dropping in use according to the media over the past 3 > months ever since the browser selection screen came so its becoming less > of an issue in time. > > --fagan > > The marketshare drop has been very small, about a percentage point a month. And Ian and other people in WHATWG made it our issue if Microsoft or Apple doesn't fully adopt WebM. He made it clear that unless all the browser vendors adopted a video format, it would never be specified in the spec as the baseline format to support. We do need a baseline format in the spec. Supporting video will be difficult unless content providers can be certain that a single format will be supported across the board
Re: [whatwg] forwarded: Google opens VP8 video codec
On Thu, May 20, 2010 at 4:27 AM, David Gerard wrote: > On 20 May 2010 00:38, David Gerard wrote: > > > x264 don't think much of VP8, they think it's just not ready: > > http://x264dev.multimedia.cx/?p=377 > > OTOH, that may not end up mattering. > > > Greg Maxwell thinks it's only about as much of a car crash as VP3 was > when it was released: > > http://lists.wikimedia.org/pipermail/wikitech-l/2010-May/047795.html > > "You should have seen what VP3 was like when it was handed over to > Xiph.Org. The software was horribly buggy, slow, and the quality was > fairly poor (at least compared to the current status)." > > What it needs, of course, is a plugin for *current* browsers, more > than the Chrome/Chromium dev channel. > > In any case - interesting times :-D > > > - d. > Opera has already made a GStreamer plugin for VP8 and released it in their gstreamer git repository, and Firefox already has support integrated into the trunk. The real problem is getting libvpx included into distros. The buildsystem doesn't currently build shared libraries, only static ones. Yay for custom buildsystems... In any case, it looks like Fedora has hacked around that issue and will hopefully soon include it in the distro package lists.
Re: [whatwg] forwarded: Google opens VP8 video codec
2010/5/19 Silvia Pfeiffer > 2010/5/20 Sir Gallantmon (ニール・ゴンパ) : > > On Wed, May 19, 2010 at 6:38 PM, David Gerard wrote: > >> > >> On 20 May 2010 00:34, Nils Dagsson Moskopp > >> wrote: > >> > James Salsman schrieb am Wed, 19 May 2010 > >> > 14:58:38 -0700: > >> > >> >> > Container will be .webm, a modified version of Matroshka. Audio is > >> >> > Ogg Vorbis. > >> > >> > You mean Vorbis. ;) > >> > >> > >> *cough* > >> > >> x264 don't think much of VP8, they think it's just not ready: > >> > >> http://x264dev.multimedia.cx/?p=377 > >> > >> OTOH, that may not end up mattering. > >> > >> > >> - d. > > > > Given that the main reason against Theora was the fact that hardware > devices > > supported baseline profile H.264 (which looks terrible compared to the > other > > profiles), I think VP8 may be fine. VP8 already has hardware decoder chip > > support, so that isn't an issue. Patents aren't an issue, since Google > has > > dealt with that. > > > Apologies, but how has Google dealt with patents? They make the ones > they bought from On2 available for free - which is exactly the same > situation as for Theora. They don't indemnify anyone using WebM. > > However, I do appreciate that for any commercial entity having to > chose between the patent risk on Theora and the one on WebM, it is an > easy choice, because Google would join such a courtcase for WebM and > their massive financial status just doesn't compare to Xiph's. ;-) > > Google's patent license states that anyone that attempts to sue over VP8 will automatically lose their patent license. That's a huge deterrent. AFAIR, the VC-1 codec didn't have that kind of clause, which caused the debacle that led to the VC-1 patent pool...
Re: [whatwg] forwarded: Google opens VP8 video codec
On Wed, May 19, 2010 at 6:38 PM, David Gerard wrote: > On 20 May 2010 00:34, Nils Dagsson Moskopp > wrote: > > James Salsman schrieb am Wed, 19 May 2010 > > 14:58:38 -0700: > > >> > Container will be .webm, a modified version of Matroshka. Audio is > >> > Ogg Vorbis. > > > You mean Vorbis. ;) > > > *cough* > > x264 don't think much of VP8, they think it's just not ready: > > http://x264dev.multimedia.cx/?p=377 > > OTOH, that may not end up mattering. > > > - d. > Given that the main reason against Theora was the fact that hardware devices supported baseline profile H.264 (which looks terrible compared to the other profiles), I think VP8 may be fine. VP8 already has hardware decoder chip support, so that isn't an issue. Patents aren't an issue, since Google has dealt with that. Nevertheless, Firefox already has support for it in the trunk, Opera released a labs build that adds a GStreamer plugin for WebM to their builds, and Chrome trunk added support for it. Adobe announced support for VP8 in a future version of Flash, and probably Silverlight will have it too. Whether they'll include complete WebM support is unknown, though.
Re: [whatwg] Video Tag Proposal
On Sun, Mar 28, 2010 at 10:49 AM, Ashley Sheridan wrote: > On Sun, 2010-03-28 at 10:29 -0700, Kelly Clowers wrote: > > 2010/3/28 Sir Gallantmon (ニール・ゴンパ) : > > > > When the img tag was made, all browsers initially supported BMPs, didn't > > they? Nobody complained about implementing support for an image format. The > > GIF format made things hairy later, but with JPEG and PNG, the issues > > eventually resolved themselves. But the img tag was made at a time when > > there was no format soup for images... Or at least, not one nearly as > > serious a problem as the video tag. > > Also, image formats are less complicated to implement than video, both in > the codec itself and the fact that images don't have to worry about subtitles, > containers, seeking, sound, etc. > > > Without a baseline codec, there is no guaranteed usefulness to the audio or > > video tags. As for audio, I suggest supporting at least WAV (or FLAC) and > > Vorbis at least. > > That was the recommendation before all codec references where removed. > Currently among HTML5 browsers, I believe only Safari does not support Vorbis > (they all support pcm wav). Safari uses QuickTime, so if Apple would bundle > XiphQT, Safari would be set. Who knows what MS is planning for IE9, but I > don't > think they would object too much to having Vorbis as an option, > especially if they > are using DirectShow. A great many high-profile games have used Vorbis, > including MS-published Halo and Fable. > > Really, the audio situation seems fairly manageable. Vorbis even has an > advantage in size/quality over most other codecs, especially the so-common > MP3. > > > For video, our best shot is either Dirac or Theora. Unless > > somebody else has any other decent reasonably available open source, > > royalty-free codec that can be used for the video and audio tags? > > Well, if Google frees VP8... > > > Cheers, > Kelly Clowers > > > I was under the impression that Apple were one of the main opposers to > using free codecs in-place of their proprietary QuickTime. > > Also, when was the last time you ever knew Microsoft to go with standarised > formats when they can just as easily push one of their own? > > Even the image formats in the early days were an area of debate. Does > anyone remember the time when there was still the threat of the licensing > issue surrounding the Gif format? It was this very issue that cause the PNG > format to be created. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > I remember the Unisys LZW patent issue. The problem is that the situation surrounding GIF at the time and the situation we have now is totally different. Technically, LZW compression didn't have to be used with GIFs, though that practically didn't happen. And now we have a situation that companies like Apple and Microsoft themselves created, with the crazy redundant and overly broad patents. None of the companies on the MPEG-LA want to fix the situation because over half of them only make money through patent licenses. Additionally, most patents covering the video formats are unfortunately core to the implementation of the codecs. As an earlier mail said, video codecs are hard to design, much less implement. Video codec companies that spend a lot of R&D time do deserve to make money on their hard work. However, when every single codec is in trouble because of overly broad patents, we have problems. I've said it earlier that I'd like to have some baseline codecs specified. Can we at least add Vorbis and WAV (and/or FLAC) to the baseline codecs for the audio tag? Nobody has really complained about it, so why not put that back? At least then, one issue with codecs is resolved. Finally, spending time on if's is not going to do anything. For the purposes of these discussions should assume that Google will not open up VP8 or any other codec owned by On2. We need to work with what we have NOW, not what we MAY have LATER. If Google announces tomorrow that they open up VP8 in the same way that Theora was, then great! But if we focus on if's like that, we'll never get anywhere.
Re: [whatwg] Video Tag Proposal
On Sat, Mar 27, 2010 at 9:06 PM, Gregory Maxwell wrote: > On Sat, Mar 27, 2010 at 9:45 PM, Aaron Franco wrote: > > I can see how it is counter productive in the creation of the > specification, > > but the fact that such licensing is being considered for what is supposed > to > > be "open & free" is counter productive to the advancement of web > > technologies. I feel we cannot allow companies like Microsoft and Apple > to > > take advantage of such patents. Allowing the H.264 to be a part of the > spec > > without it being royalty free only gives those corporations more control > [snip] > > Ah! > > Now I understand. H.264 is not under consideration as part of spec, > and I don't believe that anyone has ever even tendered a serious > proposal that it be considered as part of the specification for > exactly the reasons that you've enumerated. > > It wasn't clear to me that you were unaware of this, I thought you > were attempting to propose a way— though, sadly, an unworkable one— in > which it could be considered. > > > Cheers! > That's certainly news to me. I see a lot of people talking up having H.264 as the standard for HTML 5 video. The codec problem is a serious one though. There needs to be a good solution to this... other than NOT specifying a codec (which I think is a bad idea, anyway). The problem with not specifying a codec is that it is already sort of a codec hell dealing with downloadable videos, with WMV, Dirac, Theora, XviD, DivX, H.264, 3GPP, etc. When the img tag was made, all browsers initially supported BMPs, didn't they? Nobody complained about implementing support for an image format. The GIF format made things hairy later, but with JPEG and PNG, the issues eventually resolved themselves. But the img tag was made at a time when there was no format soup for images... Or at least, not one nearly as serious a problem as the video tag. Without a baseline codec, there is no guaranteed usefulness to the audio or video tags. As for audio, I suggest supporting at least WAV (or FLAC) and Vorbis at least. For video, our best shot is either Dirac or Theora. Unless somebody else has any other decent reasonably available open source, royalty-free codec that can be used for the video and audio tags?
Re: [whatwg] Fullscreen for HTML5 Video element
On Mon, Mar 8, 2010 at 6:48 AM, Tim Hutt wrote: > 2010/3/8 Ashley Sheridan > > Also, I've never seen anything built in Flash that started up in > full-screen mode automatically. I had to trigger it explicitly every time by > an action from me. > > That was his point - despite the fact that it *can* be done in flash, > it isn't. Hence the argument in the spec is invalid. > > I don't really see what's wrong with having an API for fullscreen. If > they want, user agents could have a preference to disable the > full-screen API if people ever start doing annoying things. > > As for the security issue, the 'Press Escape to exit fullscreen mode' > banner works for flash. > And if you're really paranoid, an option could be available in the browser to disable having videos start up in fullscreen mode automatically, even if there is an API to do it. Flash certainly doesn't offer that. By not offering a standard way to handle full screen videos, it gives a reason to NOT use HTML 5 video over Flash or Silverlight. That's not what we want.
Re: [whatwg] Fullscreen for HTML5 Video element
On Mon, Mar 8, 2010 at 4:40 AM, Ashley Sheridan wrote: > On Mon, 2010-03-08 at 14:35 +0530, balachandar muruganantham wrote: > > Hi, > > I have heard from people that there have been a discussion on supporting > the fullscreen mode for HTML5 video element. can anyone share the > information on the conclusion we arrived at? i searched in the archive but i > could not come to any conclusion. > > -bala > > > Not according to the spec: > > "User agents should not provide a public API to cause videos to be shown > full-screen. A script, combined with a carefully crafted video file, could > trick the user into thinking a system-modal dialog had been shown, and > prompt the user for a password. There is also the danger of "mere" > annoyance, with pages launching full-screen videos when links are clicked or > pages navigated. Instead, user-agent-specific interface features may be > provided to easily allow the user to obtain a full-screen playback mode" > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > I don't know if I completely agree with that. If that were the case, people would have done it with Flash years ago. Flash can be started in full screen mode, and yet nobody's done it
