Does a youtube video with a still image (ex. music) drain as much mobile data as a moving video (gameplay, etc.), and why/why not?


Does a youtube video with a still image (ex. music) drain as much mobile data as a moving video (gameplay, etc.), and why/why not?

In: 457

In theory no… although to be more specific it depends a lot on how the video is compressed either by uploader or Youtube for downstreaming. But in general, a static image w/ audio will be less.

In uncompressed raw formats almost every frame of video could be considered a complete static image. So a 1080p video frame is a 1920 x 1080 pixel image, so a 2 073 600 or ~2 megapixel image. Every frame. So the byte size of this is however many bits per pixel. 2Megapixels x 1 byte per pixel = 2 MB per frame. At 30 frames per second, well that’s 60 MB per second.

Which is a lot. So video is normally compressed and one of the easy way to get reasonably high compression is to send a “key” frame – which is a complete whole resolution frame – every once in a while, but for intervening frames just send the pixels that “change”. Obviously for a video steam which is a static image, the “changed pixels” information is essentially nothing. So much less data.

Then you have those Youtube music videos with a static background but its slowly panning around or slowly zooming in and out? depending on how the video is encoded and compressed, there might be encoding tricks like “this frame is just like last, but everything is shifted one pixel up” type of things, but because of the motion, its going to be somewhere in between our two extremes.

(edit: been a long time since my video days; as others have pointed out its a lot more bytes per pixel and more frames per second, so a lot more MB/s, but point remains w/o compression video is really fcking big data wise.)

Let’s talk about video compression.

If you were to transmit every frame of a video as a whole image, it would get very big very quickly. Instead, we use a trick. Most frames from a video are very close to the previous frame, so we just have to store the instructions on how to build one frame from the previous one.

One problem with *just* doing only those difference calculations is that, if you wanted to skip 2/3 of the way through, you would need to load the whole video up to that point. Instead, we have something called Key Frames, which are single frames that have their entire picture stored.

How often those key frames are generated is something that you can control, but for YouTube, they recommend 2 seconds, and you cannot exceed 4 seconds. You’re still going to have a lot of data for the key frames, although you don’t have as much in the calculated frames. So it will be smaller, but not necessarily by a significant amount.

Imagine you were giving a computer instructions on how to play the video. You can tell each individual pixel what color to be, and repeat that process 30 times every second. But if it is just a still image, you would only have to do that once, and just tell the pixels to stay the color they are for the rest of the video, and that would greatly reduce the list of instructions you would need to send.

A YouTube video with less movement is smaller and uses less data. That’s because the video compression (method for reducing size) stores changes from frame to frame. Something like TV static would take the most space, because every pixel changes on every frame. The opposite – a still image, would take the least amount of space.

Good answers here, but just as an aside, you can use programs like JDownloader to download youtube videos. You could probably even find some content that has both a static and a moving version and compare the two sizes if you want. You wouldn’t even need to download the videos, as the program will show you the sizes once you input the youtube link.