×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

VP8 Decoder Implemented In Flash Using Alchemy

Soulskill posted more than 3 years ago | from the dark-sorcery dept.

Google 94

An anonymous reader writes "Mozilla's Chris Double has an interesting post on his blog about a port of the VP8 decoder to Flash. He writes, 'Ralph Hauwert has been posting on twitter about work he's done on getting WebM decoding to work by compiling the libvpx source code using Adobe's Alchemy technology. Alchemy is a research project that allows compilation of C and C++ libraries into code that runs on the ActionScript virtual machine used by Flash.' Of course, it's very slow and Adobe says that they'll bring native VP8 support to Flash in due course, but implementing a VP8 decoder in ActionScript is an interesting project nonetheless."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

94 comments

Flash? (-1)

Anonymous Coward | more than 3 years ago | (#34879140)

Flash? Isn't that some sort of proprietary software from the 00's that was slow and buggy and didn't run on iOS? I almost remember that...

Re:Flash? (1)

MichaelKristopeit340 (1967534) | more than 3 years ago | (#34879476)

i think they're talking about "Flash"... brand new proprietary software from the 10's that is even more slow and buggy and is emulated by iOS to be even slower and buggier still.

So let's see: (1, Offtopic)

commodore64_love (1445365) | more than 3 years ago | (#34879178)

WebM is the container
--- VP8 is the video
--- Vorbis is the audio

Why didn't Google use Ogg for the container? I see Google's also developed a WebP format for pictures, also based on VP8.

Re:So let's see: (2)

Samantha Wright (1324923) | more than 3 years ago | (#34879268)

I'm too busy to look up the details exactly, but two possibilities:

1. The container, as well as the codecs, are potentially patent-encumbered, so it's easier to steer clear.

2. The container isn't part of the patent concern, but there are companies who aren't sure of that (see #1). So it's easier to get adoption if they steer clear.

Re:So let's see: (1)

Sylak (1611137) | more than 3 years ago | (#34882424)

OGG container is patent-free, but it's probably the issue with most open-source adoption, where because it's pre-existing and has is open-source, they don't trust it

Re:So let's see: (1)

davester666 (731373) | more than 3 years ago | (#34887402)

Well, you can say it's "patent-free", but that's a meaningless phrase.

To legally be able to say "X is patent-free", you would need to, in every different patent/legal jurisdiction[the matrix of where a patent can be registered and the areas where different laws apply to that patent], you proactively go through court proceedings and prove EVERY single current and pending patent that hasn't expired doesn't apply to X, and have the judge rule in your favor, then go through all appeals, if any.

Assuming of course that there are no jurisdictions where you can't proactively do this.

Only once all you have completed this process can you actually assert X is patent-free.

At best, all you can say is that nobody has asserted a patent against OGG yet that has been widely publicized.

Hell, it wouldn't surprise me at all if there hasn't been some company that has been forced into some payout for supporting OGG over a patent, just with a confidentiality clause attached to it as well, just in the hopes that somebody loaded, that sells a popular product with OGG support in it, can get sued to oblivion for a large chunk of cash.

Re:So let's see: (3, Informative)

commodore64_love (1445365) | more than 3 years ago | (#34879336)

MPEG4/h264 vs. VP8 comparison (h264 slightly better): http://compression.ru/video/codec_comparison/h264_2010/vp8_vs_h264.html [compression.ru]

HE-AACplus vs. Vorbis (HEAAC wins): http://listening-tests.hydrogenaudio.org/sebastian/mf-48-1/results.htm [hydrogenaudio.org]

WebP vs. JPEG (WebP wins): http://englishhard.com/2010/10/01/real-world-analysis-of-googles-webp-versus-jpg/ [englishhard.com]

Re:So let's see: (0)

russryan (981552) | more than 3 years ago | (#34879832)

Also, http://x264dev.multimedia.cx/archives/377 [multimedia.cx] for a VP8 tear down.

Re:So let's see: (1, Flamebait)

commodore64_love (1445365) | more than 3 years ago | (#34880168)

by russryan
              Also, http://x264dev.multimedia.cx/archives/377 [multimedia.cx] for a VP8 tear down.

"Overall, VP8 appears to be significantly weaker than H.264 compression-wise. The primary weaknesses mentioned above are the lack of proper adaptive quantization, lack of B-frames, lack of an 8×8 transform, and non-adaptive loop filter. With this in mind, I expect VP8 to be more comparable to VC-1 or H.264 Baseline Profile than with H.264."

Ouch. You're a brave man to publish that on /.

Re:So let's see: (1)

RocketRabbit (830691) | more than 3 years ago | (#34885040)

Notice that your comment and the post you're referring to are both at 0 now.

Slashdot: The Unofficial PR Branch of Google(TM).

Re:So let's see: (0)

Anonymous Coward | more than 3 years ago | (#34883570)

Dude, are you seriously posting something from a website with hostname "x264" to show how bad VP8 is? Really?

Re:So let's see: (1)

arose (644256) | more than 3 years ago | (#34883632)

It's not a tear down, it's a "this is how it's similar, but worse than H.264". This little gem makes it quite clear:

Update: Alt-ref frames can apparently be used to partially replicate the lack of B-frames. It’s not nearly as good, but it can get at least some of the benefit without actual B-frames.

AKA, I didn't look at them or pondered what they might be fore and now that I've been pointed out that they exist I won't consider them on their own merits, but just as an inferior B-frame.

Re:So let's see: (4, Insightful)

Anonymous Coward | more than 3 years ago | (#34880020)

I take issue with the HEAACplus vs Vorbis comparison you chose.

At the sort of bitrates that are actually used in streaming HD video all lossy encoders are essentially transparent, even old war horses like MP3. Performance at lower bitrates is academic at best. Vorbis beats all comers in the 80-96kbps range, and HEAACplus beats all comers under 64kbps, but neither is relevant to HD streaming video.

Re:So let's see: (1)

cpu6502 (1960974) | more than 3 years ago | (#34883282)

Performance at lower bitrates is academic at best.

Not if you're on dialup or a cellphone. You want the lowest bitrate possible while still keeping good quality. For example the radio station I listen to at work streams at a mere 12kbit/s HEAAC and sounds... well not great but close to FM quality. Vorbis sounds like it was squeezed through a shortwave radio.

"Vorbis beats all comers in the 80-96kbps range"

It doesn't beat HE-AAC (AACplus) which still has better sound on the high frequencies.

Re:So let's see: (0)

Anonymous Coward | more than 3 years ago | (#34884948)

Performance at lower bitrates is academic at best.

Not if you're on dialup or a cellphone. You want the lowest bitrate possible while still keeping good quality.

If you're watching HD video on dialup or a cellphone, you're an incredible optimist. I was talking about HD video although your quoted bit doesn't show that. Of course lower bitrate matters if all you're streaming is audio. I never implied otherwise.

"Vorbis beats all comers in the 80-96kbps range"

It doesn't beat HE-AAC (AACplus) which still has better sound on the high frequencies.

All the public ABX tests I've seen (HydrogenAudio, same source as the OP) say otherwise. Are you talking about your own subjective AB tests or something meaningful?

Re:So let's see: (0)

Anonymous Coward | more than 3 years ago | (#34880562)

If you want to compare a new image codec against WebP, at least use JPEG 2000.

Anything proposed in the last 10 years is better than JPEG.

Re:So let's see: (1)

arose (644256) | more than 3 years ago | (#34883742)

And yet JPEG is good enough (that and JPEG2000 blurs like no tomorrow) to the extent that none of the propositions have been given a second look for widespread web usage. And this is the biggest evidence for why quality is not that critical when picking what to use for web video.

Re:So let's see: (0)

Anonymous Coward | more than 3 years ago | (#34883426)

The image comparison is interesting, and well done. I don't see any objective measurement on the audio page, just "26 listeners talking about how good they sound". And I'm sorry, but the video page seems to be /.ed.

What about information on MSE or MAE for the audio samples? Perhaps Radially Averaged Power Spectrum averaged for different frames for the video? The problem is that codecs are optimized for particular tasks, using the metric optimized for one to evaluate the other seems unfair. And it's of course unfair to come with a page where the evaluation is a limited number of so called "experts" expressing their biased opinions.

Re:So let's see: (0)

Anonymous Coward | more than 3 years ago | (#34879408)

Gogole wanted WebM to be narrowly defined. The goal is to get WebM on more devices which is easier if all it takes to support it is implementing one audio codec, one video codec and a dedicated container. The inverse of this approach can be seen in MKV which was designed to support everything and the kitchen sink, the downside being getting a device maker to support it fully is near on impossible.

Re:So let's see: (1)

AvitarX (172628) | more than 3 years ago | (#34879684)

I don't know why .ogg was not used, as according to Matroska.com this is where .ogg excels.

MKV is definitely superior to OGM though (Matroska is modest on this point int their faq).

look at the table here: http://www.alexander-noe.com/video/documentation/containers.pdf [alexander-noe.com] to see MKV vs OGM

4.3 in the linked PDF is probably why WebM was created (a pure subset of Matroska I believe).

I can't find any support, but I believe I read somewhere that OGM was week in seeking vs MKV (don't know how this compares to WebM).

Re:So let's see: (3, Informative)

BZ (40346) | more than 3 years ago | (#34879950)

http://lachy.id.au/log/2010/05/webm [lachy.id.au] under "Benefits of Matroska" describes the seeking issues in some detail. The summary is that ogg requires you to read more separate bits to seek correctly, and each separate bit ends up having to be a separate HTTP request in the context of web streaming. So your latency starts to bite you when seeking. It's not an issue if you don't have to seek or if you have the whole file already. But for the youtube use case, neither is true, typically.

FWIW, Ogg can have an index (0)

Anonymous Coward | more than 3 years ago | (#34886548)

We do have optional index support in Ogg now precisely for this case of seeking over high latency networks.

Firefox 4 uses it. In practice it seldom makes a visible difference, even though firefox doesn't cache any of the intermediate seeking steps, doesn't pipeline the range requests, and is really sloppy about stopping them— the seeking over normal round trip times is so fast that it doesn't matter.

It does, however, make a difference if you're one of the Mozilla media infrastructure engineers, -- who are all in NZ.

Re:So let's see: (1)

Goaway (82658) | more than 3 years ago | (#34879936)

"WebM" is not really the container, it's an overall name for VP8 and Vorbis in a container that is a subset of the MKV format.

Also, they probably did not choose Ogg because it is a bit of a horrible mess and programmers in general don't like it at all.

Re:So let's see: (1)

Bobakitoo (1814374) | more than 3 years ago | (#34881034)

http://www.matroska.org/news/webm-matroska.html

webm stands for Web Media (not Web Matroska). It is a subset of Matroska with only the necessary features required for video (and audio) to play over the web. As of today, it is supported by web browsers like Chrome, Firefox and Opera. Some video websites like YouTube are already streaming 360p and 720p in the webm format using the HTML5 feature of these browsers. Our tools, like mkvalidator and mkclean, already support webm files; the new version of Haali's Media Splitter can handle webm files; and support in mkvtoolnix has already been added to the next release.

So it is simpler to implement on lighter devices like phone perhaps..

Re:So let's see: (0)

Anonymous Coward | more than 3 years ago | (#34881902)

There's some pointed critique of the OGG format at http://hardwarebug.org/2010/03/03/ogg-objections/ [hardwarebug.org] .
The main points seem to be that the format has unnecessary overhead and complexity, and doesn't support efficient seeking. I guess the seeking especially was a killer, what with the network latency, but Matroska looks like a better designed format overall.

Re:So let's see: (1)

badkarmadayaccount (1346167) | more than 3 years ago | (#35013080)

To put it shortly - Ogg sucks, and Matroska rules. Compare the two formats and you will see why. Matroska allows encoding almost any data and synchronizing it in the stream completely forward and backwards compatibly, with no need to develop bit-field mappings, unlike Ogg.

time better spent (0)

Anonymous Coward | more than 3 years ago | (#34879226)

I think adobe would be better served by closing its doors forever and stop bothering everyone

Flash players everywhere thanks to Google (0, Flamebait)

SuperKendall (25149) | more than 3 years ago | (#34879330)

Now that Google has dropped h.264 support from Chrome, the new reality is that the <video> tag in HTML5 is dead, and pretty much all desktop video will be served in Flash players.

So it's good they are getting a head start on getting the VP8 codec tuned in Flash, although the practical reality is that for full support in all browsers all you'll have to do is encode in h.264 and call it a day; thus that's all most companies will ever do. You have to encode in h.264 to support video playback on iOS devices which is still a huge segment of the mobile market that uses the internet.

After all Adobe owns Flash, and they have no reason to remove h.264 support now that web designers are being forced to use of Flash players for desktop. So the new steady state for the system is h.264 in Flash players everywhere except for systems that can play h.264 directly.

If video tag meant H.264, internet dies. (0)

Anonymous Coward | more than 3 years ago | (#34879372)

If video tag meant H.264, internet dies since you can't participate without the consent of a third party (the patent holders).

With WebM and not H264, the video tag MAY be dead, but only for religious zealots who DEMAND that commercial patented algorithms are the ONLY allowed solution and therefore ban the use of openly implementable standards.

Re:If video tag meant H.264, internet dies. (2, Interesting)

Rockoon (1252108) | more than 3 years ago | (#34879774)

VP8 isnt a standard.

Google has had a year to submit VP8 to a standards organization, but hasn't done so, so its Googles fault that it isnt even on the road to being a standard.

Instead, VP8 is a "here is the source" codec.

It isnt the FORMAT that is patented, but instead the METHODOLOGY.

Essentially, ONLY that reference implementation is owned by Google. Make a change that accelerates decoding (while remaining compatible) and you might just land smack dab in the middle of not "free." Have a look at the H.264 patents and you will find that most of them deal specifically with efficient methods of doing something well understood (efficient arithmetic encoding, efficient huffman encoding, efficient golumb coding...)

Re:If video tag meant H.264, internet dies. (1)

tuppe666 (904118) | more than 3 years ago | (#34880120)

As far as I am aware W3C the organisation that looks after web standards has given no codec the green light. I cannot think of a better way of showing a standard than a working implementation...Something OOXML that standard that got through by corruption and still has no working implementation. To be fair though the vast majority of browsers using the Video tag will be WebM which is next month. Which is what I would call a internet standard.

VP8 is a standard. Go implement it. (-1)

Anonymous Coward | more than 3 years ago | (#34880176)

VP8 is a standard. Go implement it. It hasn't been to a standards body, but that isn't what makes a standard. Implement WebM from the standard. Other people writing players to that standard can view your video. This is the standard. I.e. everyone can work to the same *standard*.

"It isnt the FORMAT that is patented, but instead the METHODOLOGY."

Except that the method is the format. Without the format conversion, all you have are semi-random bits.

"Essentially, ONLY that reference implementation is owned by Google."

And the only reference implementation of HTML3 is owned by W3C.

That DOES NOT MAKE IT NONSTANDARD.

Plus, I suspect that you're wrong. There are several implementations of the standard.

"Make a change that accelerates decoding (while remaining compatible) and you might just land smack dab in the middle of not "free.""

Nope, the video standard is the FORMAT, not the METHOD (as it should be: ASCII states what bitstream "i" should be, not how you decode that bitstream to a letter "i"). So when you see a bit stream, you know how to turn those bits into sound and video. If you know how to do so quicker, you are not in abrogation of the WebM STANDARD.

If you find a way to reduce the bitrate by changing the FORMAT of the standard, you're not implementing the standard. Quite possibly because someone else has patented that way of reducing the bitrate.

You use a lot of words and have only managed to display your ignorance.

Re:VP8 is a standard. Go implement it. (1, Interesting)

Rockoon (1252108) | more than 3 years ago | (#34880698)

Except that the method is the format. Without the format conversion, all you have are semi-random bits.

Not a programmer, are you? You do realize that there is more than one way to implement something identical, right? No? Yeah... thats how I know that you arent a programmer.

That DOES NOT MAKE IT NONSTANDARD.

Nobody said that it did. You, however, seem to think that source code makes a standard.

Plus, I suspect that you're wrong. There are several implementations of the standard.

If they are not identical, then only one of which is owned by Google and as such only one of which is covered by Googles "we wont sue you, unless.." terms.

The other could contain patented algorithms not owned by Google and STILL DECODE THE SAME STREAMS.

Do you not understand that?

You use a lot of words and have only managed to display your ignorance.

Comming from someone that doesnt know what patents cover (WebM is not patented, although might be in the future, but the VP8 algorithms ARE patented .. the ALGORITHMS, not the format.)
Dont be such an ignorant rude fuck, asshole, especially when you dont have a fucking clue what you are talking about.

Re:VP8 is a standard. Go implement it. (0)

Anonymous Coward | more than 3 years ago | (#34882744)

You know, regardless of whether you know your shit, or not, the only person coming across as a rude fuck is you, asshole.

How about clearly stating what it is you are trying to discuss rather than get pissy with others.

After several re-reads of the thread, it is still unclear as to what point you are trying to make.

Re:VP8 is a standard. Go implement it. (1)

tuppe666 (904118) | more than 3 years ago | (#34883284)

Thats wonderful news. So your saying that the code can be optimised, by hardware and software companies using different methods including patented ones.

Are you saying that if the FUD about WebM a format that predates H.264 really were to come into being it could be coded around ;)

They have licensed it BSD, because thats how you get adoption of the format. Thats what they want. Thats the only way they can succeeded...are you really trying to imply that Google is going to sue anyone. I suspect that with H.264 highly restrictive license and multiple company involvement you are gonna see a lot of people sued.

Re:If video tag meant H.264, internet dies. (1)

Rysc (136391) | more than 3 years ago | (#34880948)

Essentially, ONLY that reference implementation is owned by Google

ffmpeg has an independent implementation of the decoder, but for the encoder you are correct.

The main problem with vp8 isn't that it hasn't been submitted to a standards body. That's trivial detail. The problem is that it's not meticulously documented, which means that conforming implementations are difficult. If I implement an encoder in a way which contradicts the reference implementation but does not contradict the documentation, does that make my implementation wrong, the documentation wrong, or the reference implementation wrong? Logically the answer should be "the reference implementation" because it contradicts the documentation, but I don't have much confidence that this will be borne out in reality.

I say "main problem" but in reality the above is just one problem, the biggest problem is actually weaknesses in the format (as have been pretty well enumerated by x264 developers, among others). The reason no one cares about mkv being non-standard but people do care about vp8 is that mkv is known to be an extremely good format with good documentation and essentially no flaws (albeit some tradeoffs were traded in ways some people do not prefer) whereas vp8 has clear flaws and insufficient documentation.

Re:If video tag meant H.264, internet dies. (2)

Rockoon (1252108) | more than 3 years ago | (#34881344)

ffmpeg has an independent implementation of the decoder, but for the encoder you are correct.

..which may, or may not, violate patents not covered by the ones Google acquired.

Some people seem to be having trouble with this concept, so I'll use a little analogy.

I can patent a sorting method.. lets call it RockoonSort(). I can develop a compression algorithm that requires sorting and use my sorting method in it.

I cannot patent sorting itself, so you could go ahead and avoid my patent by using qsort(), heapsort(), mergesort(), bogosort(), ...

All of these video codecs use arithmetic coding, and many of the various algorithms that implement it are covered by patents. They all do the same thing, and quite a few are even functionally interchangeable (for a given input, the exact same output) but are none-the-less owned by different folks (hello IBM.)

This all boils down to methods of doing it efficiently. Using a particular kind of lookup table to avoid an expensive division? Well thats owned by someone (hello MPEG-LA) but using the expensive division is out of patent now and everyone can go ahead and do it that way (ie, slowly.) Patents on doing it without multiplications? Yep. Doing it with binary trees? Yep. Doing multiple symbols in in parallel? Yep.

Even if you accept that the reference does not violate anyones IP, you cannot accept that changes to the reference for efficiency or even porting reasons (for hardware without specific capabilities) will also keep you free and clear.

Re:If video tag meant H.264, internet dies. (0)

Anonymous Coward | more than 3 years ago | (#34882152)

..which may, or may not, violate patents not covered by the ones Google acquired.

That's pretty much the state of any software ever these days, especially if it does image, audio or video processing.
I'm not quite getting your point here. Is your argument that at least with H.264 we know we're fucked? That we should just give up on open and royalty-free standards and open source until the U.S. gets a patent reform?

Re:If video tag meant H.264, internet dies. (1)

Rockoon (1252108) | more than 3 years ago | (#34884602)

I'm not quite getting your point here. Is your argument that at least with H.264 we know we're fucked? That we should just give up on open and royalty-free standards and open source until the U.S. gets a patent reform?

Sigh.. I'm saying that any re-implementation that isnt the reference is very likely to infringe on patents.

Are you just too stubborn to admit it to yourself that you have to pretend to struggle with this idea?

Take a look at H.264's patent pool sometime. Many methods of implementing the same equivalent thing are in there for a reason, so that implementors have options. VP8 gives no options.

Why is this so hard?

Re:If video tag meant H.264, internet dies. (0)

Anonymous Coward | more than 3 years ago | (#34890012)

So anyone who wants to reimplement VP8 will have to be very mindful about patents, if they want to distribute in the U.S.
That's not much different for even a JPEG encoder.
It makes me sad, but it's nothing unique to VP8 at all.

You make it sound like this is a disadvantage with VP8 in particular, when it would apply to any video format.
VP8 gives an advantage since there is at least one implementation built specifically with patent avoidance in mind.

It's not like the breadth of H.264's patent pool gives you any advantage if you want to make a non-infringing implementation - it just means your ass is a bit more covered if you pay them the innovation toll.

On2, as I understand it, kept a fairly close watch on patents, implementing features as soon as the patent expired, or they could establish prior art.
In that sense VP8 benefits from earlier research around MPEG, in that they'll have a large pool of prior art to refer to in a patent dispute. Having someone else's expired patent is just as good as having your own current patent when you're on the defending side of a patent dispute.

Re:If video tag meant H.264, internet dies. (4, Interesting)

makomk (752139) | more than 3 years ago | (#34881358)

Google has had a year to submit VP8 to a standards organization, but hasn't done so, so its Googles fault that it isnt even on the road to being a standard.

The relevant standards bodies have no interest in something like VP8. VP8 is designed not to be patent-encumbered, whereas standards bodies like the MPEG group aim to create video codecs that are as technically advanced as possible and that are encumbered by as many of their members' patents as possible. (The patent encumbrance isn't just a side-effect of wanting the best codec possible - member organisations deliberately try and make sure that their patents are an unavoidable requirement of implementing the standard, because they directly benefit from this.)

Standards bodies are not a panacea, and they have known issues. This is one of those issue.

Essentially, ONLY that reference implementation is owned by Google. Make a change that accelerates decoding (while remaining compatible) and you might just land smack dab in the middle of not "free."

That's true of basically everything in the software industry, including h.264 itself. Remember that the h.264 patent consortium does not even guarantee it owns every patent that affects h.264, let alone patents covering particular implementations. It's still better than h.264 though - that's designed so that you can't write a compliant decoder or encoder at all without infringing patents, because the specification was written by the patent owners.

Re:If video tag meant H.264, internet dies. (1)

Rockoon (1252108) | more than 3 years ago | (#34884674)

If only one of these patent pools would patent multiple methods of doing the same thing so that implementors would have a choice of algorithms likely to be efficient on their hardware.

Oh.. wait.. MPEG-LA did exactly that.

Re:If video tag meant H.264, internet dies. (2)

TheSync (5291) | more than 3 years ago | (#34885238)

The relevant standards bodies have no interest in something like VP8.

SMPTE [wikipedia.org] is an individual membership organization. I'm sure if an individual brought VP8 before SMPTE for standardization it would happen. SMPTE has a mixture of broadcast vendors and broadcast users of all kinds. There are some folks in SMPTE who are from companies with compression IP, but there are also plenty of other vendors represented in SMPTE that don't.

Of course, it would take time (like when SMPTE Standardized Windows Media Video as VC-1), but the result will be a well-defined specification that achieves interoperability.

Feel free to join SMPTE [smpte.org] , show up at committee meetings, and do some standardization!

Re:If video tag meant H.264, internet dies. (1)

tuppe666 (904118) | more than 3 years ago | (#34879988)

Google, Opera, Firefox religious zealots OMG when did this happen. I thought they made these choices for business reasons. Please tell me more about this religion is there handshakes involved. Tell me there is lots of SEX. To be honest those other companies that only allow H.264 format that they make money off the small hardware/software companies as a barrier of entry...are they zealots too!? Tell me more.

They aren't forbidding WebM. (0)

Anonymous Coward | more than 3 years ago | (#34880210)

They aren't forbidding WebM. So, no, I don't have to tell you more, since you've already walked your own way to idiocy.

Re:They aren't forbidding WebM. (1)

tuppe666 (904118) | more than 3 years ago | (#34880834)

They aren't forbidding WebM. So, no, I don't have to tell you more, since you've already walked your own way to idiocy.

Then I look forward to Microsoft and Apple announcing there full backing of WebM using the Video tag rather than funny[sic] bolg posts or silence.

Video tag meant most used codec (0)

SuperKendall (25149) | more than 3 years ago | (#34881272)

If video tag meant H.264, internet dies since you can't participate without the consent of a third party (the patent holders).

The video tag always meant, that we should be able to assume the most widely used codec was in place.

Currently that is h.264, primarily because of hardware support. But in the future it COULD have been VP8, once there was hardware in place and wider support for it.

Instead killing off the video tag means we are LOCKED INTO h.264 in a way that would not have been true if the video tag really took off. It means we are LOCKED INTO flash players in a way that would not have been true if the video tag took off.

Don't like h.264? Then you of all people should be more angry at Google than I am, because they ensured the marginalization of WebM and VP8.

Re:Video tag meant most used codec (2)

Draek (916851) | more than 3 years ago | (#34882136)

The video tag always meant, that we should be able to assume the most widely used codec was in place.

Erm, no. The video tag always meant that we could assume that at least the codec specified in the standard itself (ie, Theora before Apple's bitchfest) was in place. It never was a popularity competition, and now that Apple managed to remove Theora from the standard and no particular codec is specified, it's all as it was before the days of Flash: a random coin toss as to whether it'll work or not, regardless of which codec(s) you use.

Instead killing off the video tag means we are LOCKED INTO h.264 in a way that would not have been true if the video tag really took off. It means we are LOCKED INTO flash players in a way that would not have been true if the video tag took off.

Don't like h.264? Then you of all people should be more angry at Google than I am, because they ensured the marginalization of WebM and VP8.

No, he should be angry at Apple, as without them there would have been a specific codec we could've relied upon even if all others were missing, one codec whose support would be universal among all HTML5-compliant browsers and devices, Ogg Theora. Instead, we get a return of "guess the codec" which, unlike what all the h.264 apologists try to claim, was pretty damn far from being universally supported even before Google's decision.

Re:Video tag meant most used codec (1)

SuperKendall (25149) | more than 3 years ago | (#34883150)

Apple only brought up the point that in order for web designers to accept the tag it had to support a widely used codec.

You can blame Apple all you like but the video tag was doomed when it was Theora only; Apple tried to save it. Google has curb-stomped it real good now, so we can forget about that part of HTML5.

On an amusing sidenote, in Chrome now using Youtube, the WebM player uses twice as much CPU than the native h.264 HTML5 player did, and the Flash player also uses less CPU than the WebM player!

Regression all the way.

Re:Video tag meant most used codec (2)

arose (644256) | more than 3 years ago | (#34883970)

Ah, revisionism. The video tag was at no point "Theora only", as you claim, Theora was suggested as a baseline. That is you could use H.264 or whatever else as you please, just as long as you had the ability to play Theora at all. Apple basically said, "we are not doing that no matter what", and it was dropped because an unimplemented standard is pointless.

Talk to Draek (2)

SuperKendall (25149) | more than 3 years ago | (#34884220)

Ah, revisionism. The video tag was at no point "Theora only", as you claim, Theora was suggested as a baseline.

Whoa there, you are responding to the wrong person. I never claimed that, I merely accepted what Draek said at face value. Correct him if you must correct someone.

The fact that Apple said "we are not doing that" simply goes back to my point that they noted people would not use a codec that didn't already have wide support. They also pointed out the madness of having to require a codec that had zero hardware support.

Re:Talk to Draek (0)

Anonymous Coward | more than 3 years ago | (#34885306)

Whoa there, you are responding to the wrong person. I never claimed that, I merely accepted what Draek said at face value.

...

Draek:

The video tag always meant that we could assume that at least the codec specified in the standard itself (ie, Theora before Apple's bitchfest) was in place.

As well as:

No, he should be angry at Apple, as without them there would have been a specific codec we could've relied upon even if all others were missing, one codec whose support would be universal among all HTML5-compliant browsers and devices, Ogg Theora.

You:

You can blame Apple all you like but the video tag was doomed when it was Theora only; Apple tried to save it.

How could I have missed the obvious agreement?

The fact that Apple said "we are not doing that" simply goes back to my point that they noted people would not use a codec that didn't already have wide support.

Letting Safari play Theora videos would have in no way affected their precious ability to play back H.264, you don't need widespread support to merely implement something. Neither would they have had to use it for their own streaming needs. It's a red hering. I mean really, did canvas have widespread support when they implemented it in Safari? What they actually did was put on an allied FUD front with MPEG LA. Oh no, MPEG LA will sue as all, just like they did with Vorbis!

They also pointed out the madness of having to require a codec that had zero hardware support.

A new standard lacking hardware implementations? Inconceivable!

So? Will all the old iPhones ever be updated to support newer HTML5 specs? But of course the two objections are related in a strange way, Apple was probably afraid that Theora would indeed gain widespread support before their older iPhones were obselete (if that is the case "widespread support" was not only a red herring, but something to be discouraged at all costs). It's worth nothing that they make no effort to push any other HTML5 related updates to older iPhones or care for other widespread things like flash.

Realistically the most likely reason to refuse is quite banal. They had alreasy decided that H.264 would be the Apple way and didn't want to bother working together with the rest of the web on the issue. Doesn't mean the requirements for a web standard? So, we don't care, we'll just use it and refuse to let anyone else standardize on something agreeable!

Google at least bothered to do something about it, instead of sticking their head in the sand. And their H.264 infrastructure dwarfs Apple's.

You don't understand... (1)

SuperKendall (25149) | more than 3 years ago | (#34886452)

Letting Safari play Theora videos would have in no way affected their precious ability to play back H.264, you don't need widespread support to merely implement something.

What happens is you kill battery life in mobile devices if you mandate support for a format no-one supports. It's just a bad idea.

I realize you care not a whit for actual USERS; the ones we all write software for? Someone had to. That's where Apple came in.

A new standard lacking hardware implementations? Inconceivable!

Actually it *is* inconceivable when if you simply specify a widely used codec that includes hardware support as baseline for the standard, you in fact have a new standard (video tag) that includes hardware support out of the gate, which means it will actually be adopted.

So? Will all the old iPhones ever be updated to support newer HTML5 specs?

They already support the HTML5 specs, including the video tag.

There's only one model of iPhone that's not tracking iOS, that is sadly EOL. But if you jailbreak it that too can run iOS4.

Apple was probably afraid that Theora would indeed gain widespread support before their older iPhones were obselete

Come on, do you REALLY believe that? APple sure didn't. It's absurd on the face of it. Apple was (rightfully) afraid of anything that would slow down HTML5 adoption; pulling a stupid stunk like forcing a base codec no-one wanted to support would not help.

They had alreasy decided that H.264 would be the Apple way and didn't want to bother working together with the rest of the web on the issue

I see, just ignore the simplest and most pragmatic reason, because it doesn't fit with your notion of Apple as the cartoon mustache twirling villain.

Google at least bothered to do something about it

Right, they decided to screw over the HTML5 video tag so they alone could control the video format used by web and mobile. How nobel and altruistic! Too bad it's done on the backs of the users who have to suffer, they suffer for the greater good*

* Google being the greatest good of all

I'll let you have the last word as obviously I cannot dent the faith of a true Google Acolyte. Shine on Google, shine on! Oh how righteous art though!

Nothing happens. (0)

Anonymous Coward | more than 3 years ago | (#34904884)

"What happens when you kill battery life"? Nothing happens.

Vorbis was "not supported" by Apple for apparently this reason. Yet Rockbox includes Vorbis support. Didn't kill the battery.

And the accelleration isn't there fore many smartphones for H.264. Funny how h264 killing battery life for these aren't a problem.

How about the future? When WebM is the default standard, hardware support will be built in. Just like hardware support for h264 was built in after they'd invented it.

The "video tag" was Theora only for _years_ (0)

Anonymous Coward | more than 3 years ago | (#34886610)

Opera released an alpha test with Video tag support years before the HTML5 working group adopted the video tag. Opera's alpha was "Theora only", so technically the video tag started out and was theora only for many years. Perhaps not what you intended, but it's pedantically correct and this is slashdot.

One of the starting premises justifying the existence of the video tag was the use at least one mandatory royalty free codec in order to ensure compatibility without compromising the openness of the web.

Really, Apple's refusal should have resulted in the video tag being abandoned by the HTML5 process: The tag is almost pointless without a baseline codec that you can count on being available everywhere. Fortunately, the coalition for freedom (Mozilla, Opera, and Google) appears like they are going to establish a baseline codec through sheer will.

Re:Video tag meant most used codec (1)

Draek (916851) | more than 3 years ago | (#34885060)

Sooo... according to you, the reason Apple didn't accept the HTML5 standard was that web developers would be unsure that a codec whose support was required by all HTML5 implementation would be supported by all HTML5 implementations? I'd love it if you could give us a source for that, I could use a laugh.

Sorry, but outside your broken logic, Apple is the reason we're in this mess and it's Google, along with Opera and Mozilla, who are trying to fix the damn problem they created.

And BTW, I've never said that the HTML5 standard was going to be Theora only, you may want to read my post again before blaming me for your own misconceptions.

Re:Video tag meant most used codec (1)

SuperKendall (25149) | more than 3 years ago | (#34886762)

Sooo... according to you, the reason Apple didn't accept the HTML5 standard was that web developers would be unsure that a codec whose support was required by all HTML5 implementation would be supported by all HTML5 implementations?

Yes, because if you think about it that's exactly why you would do that.

Source: reality. The reality is that at that point h.264 was in wide use, and had good hardware support. If you want a standard to be adopted, which path is better - to select a baseline option that no-one will use, but is the only common option - or to selct as a baseline a format that the CONTENT PROVIDERS are already all using, ensuring easy transition to the poor bastards that are the ones on the front lines actually using the standards you set forth?

You don't even have to attribute any altruism to Apple if you like. You just have to realize that Apple wins if HTML5 is pervasive because they have one of the better browser implementations for mobile devices with the most complete support for HTML5. If all aspects of HTML5 are adopted life is better for Apple - it just happens to be better for the rest of us as well, users and content providers alike.

If any of that logic appears broken to you, it's because you are not considering how standards really get adopted. Web developers don't have to move to support HTML5 you know. And they certainly are going to be ignoring the video tag in droves now.

And BTW, I've never said that the HTML5 standard was going to be Theora only

Since your misunderstanding me I thought I'd return the favor. I never claimed you thought that, just that it was to be the baseline.

I'll let you have the last response since logic seems elusive to you - I've laid out my reasons, and leave it to the reader to decide which of us is being realistic.

Re:Flash players everywhere thanks to Google (1)

bhcompy (1877290) | more than 3 years ago | (#34879434)

Now that Google has dropped h.264 support from Chrome, the new reality is that the <video> tag in HTML5 is dead, and pretty much all desktop video will be served in Flash players.

Except that Chrome has rather small share of the browser market.

Re:Flash players everywhere thanks to Google (0)

Anonymous Coward | more than 3 years ago | (#34879528)

Chrome+Firefox+Opera, however, is not small.

Re:Flash players everywhere thanks to Google (0)

Anonymous Coward | more than 3 years ago | (#34879534)

It's not that small anymore, and Firefox doesn't support h.264 either. Between the two of them, they make up a very large segment. The basic problem you have is:
FF/Chrome - no h.264
IE/Safari - no WebM

This means you have a strict division of support, and in order to satisfy more than 50% of the market, you'd have to offer both formats. If this doesn't change, unfortunately the video tag will likely die.

Re:Flash players everywhere thanks to Google (1)

arose (644256) | more than 3 years ago | (#34880138)

Why not serve WebM over Flash or Theora via Java to people who don't care about such things?

Re:Flash players everywhere thanks to Google (1)

petermgreen (876956) | more than 3 years ago | (#34884266)

Why not serve WebM over Flash
did adobe ever implement that? They said they would implement VP8 but i've found no evidence of them actually doing so and afaict they only talked about implmenting VP8 not the rest of webm.

Re:Flash players everywhere thanks to Google (1)

xouumalperxe (815707) | more than 3 years ago | (#34884878)

Did you even read the title for the article you're posting on?

Re:Flash players everywhere thanks to Google (1)

petermgreen (876956) | more than 3 years ago | (#34885196)

heh I think I glossed over the article and then came back sometime later to read the comments without remembering what the article was.

However reading the article 1.5FPS does not seem to make for a usable video player, sure you could crank down the resoloution and maybe optimise the code a bit but I'd still be surprised if this ever performs acceptablly.

Re:Flash players everywhere thanks to Google (1)

arose (644256) | more than 3 years ago | (#34885376)

They haven't yet, but then again, we have an article here about someone who did. I wasn't suggesting everyone should start doing it right now, just that it should be an option, probably by the time the first hardware is rolled out as well. They didn't specify implementing WebM, but the announcement is pretty clear that VP8 will be implemented to support it, it's probably the bulk of the WebM package.

Re:Flash players everywhere thanks to Google (1)

tuppe666 (904118) | more than 3 years ago | (#34881682)

It's not that small anymore, and Firefox doesn't support h.264 either. Between the two of them, they make up a very large segment. The basic problem you have is: FF/Chrome - no h.264 IE/Safari - no WebM

This means you have a strict division of support, and in order to satisfy more than 50% of the market, you'd have to offer both formats. If this doesn't change, unfortunately the video tag will likely die.

Not true. Your trying to imply that their is a 50% split in the market rather than the the uptake over time of the video tag. Its more complicated for a start it doesn't cover Video Content on the net YouTube is going to support WebM lets face it and is the largest Video streaming company on the net.

Now for browsers *currently* the only browsers ignoring beta's that support the video tag are chrome and safari...giving only support for webm to chrome users leaving chrome+safari for h.264, and YouTube serving its videos in H.264 format.

Trouble is come Feburary *everything* changes Firefox+Chrome both coming out next month to the tune of half the market. IE9(the only version with the video tag, still has no official release date but may come as soon as next month, but has the worst adoption rates and has limited iself to 40% of the OS it will support, We can confidently say a Maximum 20%, although its more likely to be half that, unless Microsoft Push out a mandatory update which they are unlikely to do. Leaving WebM with a 3:1 support over H.264 although in reality its more you can gesstimate through adoption ratios.

Going forward XP machines will be replaced at about 20% a year. Chome at least in the short term will continue to rise depending on how this news affects it. Firefox will I grow on its new release...How much with chrome as a competitor is anyones guess. IE I suspect will lose more market simply because its trying to push XP users onto Windows 7 with its browser.

...But thats ignoring a major factor. On Vista+ Microsoft have provided a fallback for Firefox to H.264 through a plugin. IE9 will have a fallback in Windows 7 to WebM in IE9. Safari on OSX will have a fallback to WebM. Thats about 40% that have some support for both not native for the Video tag. XP users to get the Video Tag with have to use Firefox or Chrome...about half of the do. So 60% Have some Support for WebM. 20% can ONLY use the Video tag this way.

So If your talking about a split WebM will have a third larger support than H.264, and 3 times the size of native support.

So if Market share was the only indication WebM is a long way in the lead...and with YouTubes backing!?

Its interesting to see Internet Explorer on XP is holding back the Video tag :)

Re:Flash players everywhere thanks to Google (1)

icebraining (1313345) | more than 3 years ago | (#34882368)

Now for browsers *currently* the only browsers ignoring beta's that support the video tag are chrome and safari...

No true, Firefox 3.6 and Opera 11.0 (and Chrome) all support the video tag with Ogg Theora.

Re:Flash players everywhere thanks to Google (1)

tuppe666 (904118) | more than 3 years ago | (#34882696)

Sorry that means *currenty* WebM to H.264 split of about 2:1 ratio, and the gap widening further for native support to 3:1 next month and the gap widening further.

I don't think I have made any other glaring errors. I left Opera out as it was complex enough as it was it needs a labelled graph.

Re:Flash players everywhere thanks to Google (1)

arose (644256) | more than 3 years ago | (#34884078)

No, you very secificaly said this:

Now for browsers *currently* the only browsers ignoring beta's that support the video tag are chrome and safari...

And proceeded with:

and YouTube serving its videos in H.264 format.

If you are going to ignore betas, then ignore the fucking betas, YouTube only serves HTML5 video in beta. Furthermore, it serves both H.264 and WebM there, so....

Re:Flash players everywhere thanks to Google (1)

tuppe666 (904118) | more than 3 years ago | (#34885244)

I've reread my first statement it is perfect. as it states browsers not web sites. I use the connective "and" to describe the content available for them, which primarily is YouTube

Oddly I did not mention it did both video formats were available in YouTube, but going forward it will be in WebM in a video tag with a fallback to WebM in Flash which could be as soon as Feburary.

Re:Flash players everywhere thanks to Google (1)

Desler (1608317) | more than 3 years ago | (#34883064)

So if Market share was the only indication WebM is a long way in the lead...and with YouTubes backing!?

But YouTube is going to be forced to continue supporting H.264 because of the iPhone and Android devices. That is unless Google is planning on either replacing all Android devices with ones that have a VP8 decoder ASIC or making Android phones battery life abysmal by forcing the use of a software VP8 decoder.

Re:Flash players everywhere thanks to Google (1)

tuppe666 (904118) | more than 3 years ago | (#34879586)

Now that Google has dropped h.264 support from Chrome, the new reality is that the <video> tag in HTML5 is dead, and pretty much all desktop video will be served in Flash players.

Except that Chrome has rather small share of the browser market.

Chrome has about 10% of the Market though lets be honest its a 50% Split between companies(firefox opera are WebM) who support WebM vs H.264, and a massive majority if you only include those that are cutting edge browsers with supported platforms. With IE9 still with no release date and not working on XP. That and the fact the LARGEST video streaming site on the net Youtube will support it. Ignoring the fact that OS's can provide safe fallbacks. So no not really.

Re:Flash players everywhere thanks to Google (4, Funny)

goombah99 (560566) | more than 3 years ago | (#34879540)

I just implemented Google Chrome in Flash using Alchemy. Next I'm going to implement Flash in Flash using Alchemy. Then Alchemy in Flash using Alchemy. All on my Amiga console!

Sera Island, here I come! (0)

Anonymous Coward | more than 3 years ago | (#34883526)

That's nothing, I want to implement orichalcum using Alchemy!

please Mod +1 Malkovitch (0)

Anonymous Coward | more than 3 years ago | (#34885584)

Malkovitch Malkovitch Malkovitch? Malkovitch!

Re:Flash players everywhere thanks to Google (1)

tuppe666 (904118) | more than 3 years ago | (#34879676)

Now that Google has dropped h.264 support from Chrome, the new reality is that the <video> tag in HTML5 is dead, and pretty much all desktop video will be served in Flash players.

So it's good they are getting a head start on getting the VP8 codec tuned in Flash, although the practical reality is that for full support in all browsers all you'll have to do is encode in h.264 and call it a day; thus that's all most companies will ever do. You have to encode in h.264 to support video playback on iOS devices which is still a huge segment of the mobile market that uses the internet.

After all Adobe owns Flash, and they have no reason to remove h.264 support now that web designers are being forced to use of Flash players for desktop. So the new steady state for the system is h.264 in Flash players everywhere except for systems that can play h.264 directly.

Your very fortunate. Google still offer support for WebM through Chrome as do Firefox and Opera. Hopefully Microsoft and Apple can get behind this. They have already said its better to speak the same language...and both love openstandards. As you have already stated Safari ;) and IE9(not XP Microsoft have not given them a choice for IE) have native OS fallbacks, Although as you can see those devices that give users the choice of Flash can get WebM in Flash as well.

Re:Flash players everywhere thanks to Google (0)

Anonymous Coward | more than 3 years ago | (#34888296)

Although as you can see those devices that give users the choice of Flash can get WebM in Flash as well.

No, they can't. Adobe talked about VP8 only on Google's presentation of WebM. Not a once since than Adobe mentioned WebM or VP8. Even now at the such a fortunate for Adobe event of dropping h264 by Chrome they don't say "no worries, next flash will have vp8 built in so you should be ok with you tube serving videos only in webm". What they actually say is "so long google, everybody have their videos in h264 and we have that too".

Re:Flash players everywhere thanks to Google (2)

moderatorrater (1095745) | more than 3 years ago | (#34881264)

What the fuck are you talking about? Take a good hard look at the codecs [wikipedia.org] supported by the big three browsers. Even before Chrome's announcement, there wasn't a single column that was green all the way down. This fragmentation started long before Chrome removed h.264 support.

Re:Flash players everywhere thanks to Google (0)

Anonymous Coward | more than 3 years ago | (#34882208)

Sir It is called Trolling.

Interesting (1)

VincenzoRomano (881055) | more than 3 years ago | (#34879392)

as much as useless timewasting project.
I would have preferred spending those resources into making a better/faster/leaner VP8 decoder!

Re:Interesting (0)

Anonymous Coward | more than 3 years ago | (#34879606)

almost as usefull as implementing it with a turing machine.

Turing! (1)

Dan East (318230) | more than 3 years ago | (#34879416)

Wow! Flash is Turing Complete! Who woulda thunk it? Now if only it could be implemented in Javascript so as to also be unusable within another interpreted / bytecode environment....

Stop using Android and Chrome! (0, Flamebait)

Anonymous Coward | more than 3 years ago | (#34879582)

Who cares Google did away with H.264. They can go to hell........Stop using Chrome and Android OS people!!

They won't support H.264 because its proprietary but they went out of there way to support Flash. Only reason they did that was so they had a selling point against iOS.

Re:Stop using Android and Chrome! (1)

Desler (1608317) | more than 3 years ago | (#34883032)

They won't support H.264 because its proprietary but they went out of there way to support Flash.

And yet they are forced to support it via streaming from Youtube lest they wreak all sorts of havoc on Android devices. That is unless they want to kill the battery usages of Android devices by forcing them to use a software VP8 decoder instead of the H.264 ASIC built into the phone.

Erm... (1)

interval1066 (668936) | more than 3 years ago | (#34879686)

Actually, its not that interesting. "Engineer implements random protocol with miscellaneous sdk." The fact that a programmer gets a toolset to do something shouldn't be news. Even if the toolset is used for something it wasn't intended, a well designed toolset should handle unforeseen scenarios with some dexterity anyway. A mildly interesting hack, sure. Headline worthy? No.

What about Silverlight? (2)

aitan (948581) | more than 3 years ago | (#34880814)

I think that one of the features of Silverlight was that it was possible to write a codec in c# and it was fast enough to process video, so that could be an interesting task for someone with enough time: Testing what performs better, decoding vp8 in flash or silverlight, without native support in neither platform

Just a thought (1)

rawler (1005089) | more than 3 years ago | (#34882012)

I'm sure someone has already reflected on this, but the thought hit my slow brain at first today:

  [li] A project like Firefox could never have succeeded in a web-landscape where license-payments were needed to implement a web browser.

  [li] Without Firefox, we would most likely still be stuck with IE.

time to dump flash (0)

Anonymous Coward | more than 3 years ago | (#34883838)

Is it not time to completely DUMP flash once and for all time lets do the right thing for once and get rid of something that is a bane to the web as a whole

The Meat comes from LLVM, not Alchemy (1)

tyrione (134248) | more than 3 years ago | (#34884248)

http://labs.adobe.com/wiki/index.php/Alchemy:FAQ [adobe.com]

What does Alchemy include?

The Alchemy tool chain includes a set of tools for building, testing and debugging C/C++ projects, example projects and documentation. It is based largely on the LLVM compiler project.

What is LLVM?

LLVM is a set of tools for creating and manipulating "low level virtual machine" bytecode. LLVM includes gcc/g++ based front-ends for converting arbitrary C and C++ code to LLVM bytecode. (http://llvm.org)

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...