Can someone explain in layman terms, in a few sentences, how is it possible that webm has better quality than gif, while having a smaller file size?
Is it simply that the inventor of webm discovered a better mathematical method for encoding data in a smaller space?
(If yes, can this method be used to make a "new" and better .jpg?)
>>55591130
WebM uses video technologies to represent the same amount of video information in a smaller space.
Basically, imagine a video of a ball rolling. A GIF would have every single frame saved as a separate image, while WebM would only update the changed area every frame.
This is a massive simplification of the process, but you get the general idea.
>>55591130
webm is a video format, not image.
>>55591200
also this
>>55591200
Can you explain this to someone who is a retard?
>>55591130
Google "inter-frame compression".
>>55591273
Imagine gifs like flip books. Everything has to be done over and over, even parts that never, like the background. Webm's only store the parts of the video that change, so if a video has a constant background, it saves it once, and keeps reusing it.
>>55591273
https://www.youtube.com/watch?v=blSzwPcL5Dw
>>55591273
Keeping track of only the pixels that change between frames results in a smaller filesize when compared to storing the entire image for each frame.
>>55591273
Motion is analyzed between consequetive frames to determine the area of the frame that it takes place in. Only that area is encoded newly with each frame while the rest is left only coded once.
This is a really dumb explanation desu.
>>55591273
When you make tendies you don't eat one, throw the rest away, make a new batch with one less and repeat. You shove 5 in your fist, spill half on the floor and repeat.
What gets interesting is when you try to cram too many tendies at once. That's where you lose performance.
(Changes in the video frames would be tendies)
>>55591273
Imagine I tell you to draw a 400x400 image of black pixels by telling you one by one, what each pixel looks like. Every instruction I give you is a bit of data.
Now, the next frame in this video is exactly the same, but one pixel is now white.
What would be the most efficient way of telling you how to draw the next frame? Starting over, pixel by pixel, with the only difference being the white pixel? Or telling you "copy the last frame, change this pixel"
>>55591336
>Everything has to be done over and over, even parts that never, like the background
Actually gifs can do "dumb compression" if the value of a specific pixel doesn't change. So the ball example can actually be done in plain gif.
>>55591130
>(If yes, can this method be used to make a "new" and better .jpg?)
JPEG already uses technologies that are used in video compression, such as splitting the chroma information from the luminance early in the chain and compressing the hell out of it, since human vision is much less sensitive to color detail than luminance detail.
>>55591472
I know that, but I'm not going to try explaining discrete cosine transform and motion estimation to someone who doesn't understand why GIF and WebM are different.
>>55591200
But in real life footages, movies, etc, doesnt every single pixel change in every frame? "Something" always happens, camera moves, etc.
>>55591859
Not in every fucking frame and there are 24 frames inside a single second.
>>55591130
>(If yes, can this method be used to make a "new" and better .jpg?)
Can and has!
https://en.wikipedia.org/wiki/WebP
>>55591859
That's why there are a buttload of other techniques to aid this base method and account for all kinds of visual situations.
>>55591859
Yes, but from one frame to another, most of it stays the same, but just moves.
There's something called "motion estimation". It's basically prediction of the motion of blocks of pixels on screen, but it's the projection of 3d space onto a 2d plane.
The algorithm basically builds a rendering of the next frame based off how the vectors say the last one moved/was altered.
>>55591273
Only the pixels that change are saved, and are redrawn over the previous image, jesus christ
Search up "interframe compression".
Everyone in this thread is a retard. GIF stores frames as differences as well, the differences are:
* WebM is lossy and GIF is not. GIF video captures look like shit due to GIF only supporting a maximum of 256 colours, and looks best for simple flat-coloured animations. WebM, being lossy, looks terrible for flat-colours, since it's designed for "photographic" material, just like PNG vs JPEG.
* GIF stores the frame differences in a way that requires less computation to render each frame. This is a trade-off that meant 1990 PCs could display GIF animations with a 20MHz CPU and no video acceleration, in return for using more space if the animation is more complex.
tl;dr people who "GIF record" photographic video are retards. The format was never designed for high-colour, high-motion videos. That's why they're huge and look like shit.
