People say I am a troll, a hater of Open Source, an H.264 fan boy, a dozen other things, but I am just a realist. (And was on the SMPTE VC1 Ratification committee). WebM formally VP8, which is based on ON2’s family of codecs, is supposed to be patent complete, relying on no one else’s patents. The problem ON2 was never that smart iphone xr klingelton download kostenlos.
With the VP8 codec’s specification and source code available you need only look through the important bits to spot where code was pretty much lifted from the H.264 Spec. It reminds me of the DivX days when DivX just compiled the reference code for h.264 and stripped out the parts that slowed it down sound zum herunterladen.
A Video Codec is made up of several parts, so lets go through them in order:
Encoding: Predict, Transform and Quantize, Entrope, Apply Loop Filter herunterladen.
Decoding: Un-Entrope, Predict, De-Quantize and Inverse Transforms, De-Loop
VP8/WebM is a Discrete Cosine Transform Codec, meaning it uses MacroBlocks, Motion Vectors, and Search areas to predict motion, and compensate for it to achieve compression between frames. This prediction is the first place that VP8 runs afoul adobe flash downloaden mac.
The subblock prediction modes in WebM are practically line for line identical to the h.264’s “i4x4” mode. “Whole Block” prediction Modes are identical to H.264’s “i16x16 mode”. Every prediction mode in WebM/VP8 is an analogue for a similarly named mode in H.264. There are even a few modes missing from VP8 that exist in H.264 soundcloud setsen iphone.
Let me put it to you this way… What is the 133.33333333% of the Square Root of 4 Plus 1. It’s the same as 2+2.
DCT is a transform function that removes data from compression. The higher the coefficient the more data that is lost. H.264 has it’s own special version of the DCT that is called HCT. Because of efficiencies made in the HCT specific version of the H.264 DCT transform you can lose .5-2% of the accuracy but drop the computation requirement by about 50 fold. WebM’s version does the same thing that the H.264 DCT does, but is up to 2% more accurate but at 30x the computational requirement. This needlessly high accuracy doesn’t really improve the picture for normal encodes, and you can do a translation between the HCT method and the WebM method and have compatibility, so likely any hardware implementation would use the HCT method and a translation table, rather than implementing WebM’s methodology video downloader free mac.
VP8 is different from h.264 in a lot of really dumb and unimportant ways. VP8 uses non-adaptive arithmetic coding which is going to have some serious issues in hardware implementations. It is a different kind of computationally intense than the adaptive encoding that H.264 uses, and so you can’t cheat like you might with the DCT computations that a simple table can add compatibility for herunterladen.
Who the Frak wrote this thing? The Loop Order is wrong, and it is too dumb to know if it already softened a block in the previous frame so the loop strength stacks for as many frames as the current frame references. It is definitely not stolen… No other company would have done such a shite job of coding amd driversen.
I actually think the loop filter’s poor quality lends to my belief that On2 just ripped the code for VP8 off from various places. It is clearly flawed, and anyone with any codec experience would have been able to have identified why and fixed it in an hour or two herunterladen.
Things missing from VP8 that just makes it suck:
3 reference frames instead of up to 16.
Non-Standard Method for Arithmetic Encoding
VP8 didn’t go through a standards body, and it shows. There are a lot of mistakes in the code, the standard is vague in places only showing C code for what is supposed to happen. There are mistakes in the standard that are clearly the result of the authors not understanding the terminology they were speaking about. On2 Claimed 50% better quality per bit compared to h.264 but I can’t come up with a single instance where the quality would be better in a real world encode. I could create synthetic encodes that would, but over all, h.264 is the same in the places where VP8 just ripped it off, and superior in every place that they didn’t.
Where does this leave things? It is going to be a bloody war, but I suspect that about the time the web guys sort out what codec people should use, the video guys will have done the same pass through the code that I did, figure out which parts belong to who, and decide if they go after Google one at a time, or all at once. They will take their time, and they might start with a smaller fish first, but it will happen.