I’ve watched a few tournaments for games like Starcraft or Hearthstone, and I’ve noticed that some include “anti-spoilers” at the end of the video - extending the length of the video to hide how long the games took to play.
My question is this: does 20 minutes of a static screen saying “The tournament’s over, go home.” contribute the same amount to the file size/bandwidth use as 20 minutes of regular audio and video, or does the filetype allow for the fact it’s being asked to show the same frame 600 times and not 600 different frames?
Static data uses a tiny amount of data compared to dynamic content.
Although typically you will encode your video to a certain target bit rate. The end result of a 60 minute video with 20 minutes of black is a file of the same size but with really kick-ass quality the first 40 minutes.
In very general terms, the way that most video compression works is that certain frames of video are included in their entirety (keyframes), and the other frames are represented as the change from the previous frame.
This makes sense because most frames in a video are a lot like the frames immediately preceding.
Generally, you put a keyframe in whenever there’s a cut or a sufficiently different image that the difference between frames is too large. For a static image, you technically only need one keyframe at the beginning, and everything after is just “no change”.
In practice, though, you have to add keyframes in regularly so you can seek to a particular point in the video. If you had an hour long video of a static image with one keyframe and you wanted to seek to 30 minutes in, you’d have to process all 306024 frames (assuming NTSC) between them. Which would take a while, even for “no change” frames. So you put in a keyframe every 5 or 10 seconds whether you need it or not.
These keyframes are why it takes so long to change channels on digital TV. You have to wait for the next keyfram to arrive before your TV can figure out what to show you. Un intil then, you’re just getting “a little different from last frame”, “a little different from last frame”, etc, etc, etc.
I assumed that this might be the case - I have seen video where the keyframe appears not to have displayed when seeking to a new point, and instead the first few seconds just adds those change frames on top of what was displaying earlier.
There is nothing in any currently used codec to aid with static images. But it allows me to share an idea I’ve had for a while. I’ve often thought it might be useful to have a video format that did help with this, by allowing what I call pointer frames, which would point back to the exact byte value of the frame you need (a keyframe.)
If negotiating that would take too long (since it requires two synchronous requests instead of one), another idea I had is to allow there to be hidden frames at the beginning of a video–frames that never play, and then point back to those frames. You would then always include a request for the start of the video–which is already necessary in order to determine the length of the video and exactly where the in the file you need to go.
I’ve also thought about adding the ability to encode loops and basic fades. Though, since I’m not a video codec designer, I doubt my ideas will ever come to fruition.
You could certainly do that. But there’s no free lunch in data compression.
If you make the compression of static images in video more efficient, your new compression scheme is not going to compress dynamic images as well.
So I expect that no one is going to make this change, unless they have a very particular set of video to encode. Static images are already compressed pretty well. And if a bunch of your video is actually static, video might be the wrong tool for the job
You’re talking theory without paying attention to the proposed implementation. It’s technically true, but the added data is less than a kilobyte. It basically involves avoiding a certain byte pattern that would indicate a pointer frame, and including where the actual video starts–skipping any frames that aren’t supposed to be displayed. (Something I’m not entirely sure isn’t already there, since video files already contain headers.)
The change I propose is an incremental change. It’s even backwards compatible if you don’t use the new features. It requires no new hardware decoders–just a bit of software changes.
And, as for “the wrong tool”–have you seen any HTML5 slideshows with audio? I haven’t. People clearly would prefer to use video. And bandwidth is becoming more limited in the mobile space.
You want your video seen? You use YouTube, and YouTube just does video.
No I’m not. I understand exactly what you’re proposing. But the problem is that the proposed implementation will make every video that doesn’t need it take just a little more space. And that’s a real tradeoff. In theory and in practice.
Youtube cares a great deal about video compression ratios, and they have very talented people working on reducing their storage and improving streaming for their users. It’s possible that they are working on something like this. It’s also quite possible that static content is a small enough fraction of their video that doing this would actually have negative returns overall.
