4 ms·
> We have plenty of bandwidth. Smartphone users might not have lots of bandwidth and GIFs are incredibly inefficient compared to H.264 and WebM videos. Why was
by arthurfm 12y ago
> We have plenty of bandwidth.
Smartphone users might not have lots of bandwidth and GIFs are incredibly inefficient compared to H.264 and WebM videos. Why waste bandwidth when you don't have to?
For example, the following GIF of a CD in a microwave is 8 MB, but when converted to a WebM by Gfycat is just 369 KB.
http://gfycat.com/GrimOpenDutchsmoushond http://gfycat.com/GrimOpenDutchsmoushond
- cooper12 12y agoOff-topic: Strangely enough, it reported the same size for the MP4, but downloading it [0] shows that it's 1.1 MB. Inspecting it with `mediainfo` shows that it was encoded with the Baseline Profile, so that might explain the counterintuitively large size. (This profile is used for supporting low-powered devices, like phones, and results in a higher bitrate being used; 757 vs 252 Kbps in this case.) It seems that Gfycat just reports the WebM size either out of technical constraints, and/or for the sake of boasting higher amounts of bandwidth saved. [0] http://fat.gfycat.com/GrimOpenDutchsmoushond.mp4 http://fat.gfycat.com/GrimOpenDutchsmoushond.mp4
- glitch 12y agoGyfCat reports the smallest file size between the both WebM and MP4. If the MP4 is smaller (or the WebM is smaller), it shows that in the textual information, regardless of video file presently playing. What's shown in the textual info is purely about the boasting in this case. Still, that's definitely a file-size improvement over the GIF. GrimOpenDutchsmoushond.GIF: 8,714,192 bytes. GrimOpenDutchsmoushond.MP4: 1,137,305 bytes. GrimOpenDutchsmoushond.WebM: 378,363 bytes.
- cooper12 12y agoAh, I see. Thanks for the explanation. That does make sense. And of course. I was just digressing. Your original point still stands.