7 ms·
> Our tests were conducted primarily with Standard Definition (SD) and High Definition (HD) video files, because those are currently the most popular video form
by vanderZwan 9y ago
> Our tests were conducted primarily with Standard Definition (SD) and High Definition (HD) video files, because those are currently the most popular video formats on Facebook. But because AV1's performance increased as video resolution increased, we conclude the new compression codec will likely deliver even higher efficiency gains with UHD/4K and 8K content.
This remark about higher resolution reminded me of something I've been wondering about frame rates, which are essentially also a higher resolution, except across the dimension of time.
Assuming low to negligible noise from the camera (or a CGI, which avoids the problem altogether, shouldn't doubling from 30FPS to 60FPS have less than double the size increase? The reasoning being that changes per frame are lower, leading to better predictions.
Is there any rule-of-thumb formula for expected size increase as frame rate increases?
- iameli 9y agoI don't know any math, but speaking from experience streaming it's around ~30% more.
- vanderZwan 9y agoThanks for the datapoint, even if it is anecdotal! As colde points out in the other reply, the type of content matters so: what kind of content do you stream? Games? If so, which genre(s) (as in: a 2D platformer might compress much better, given the simpler motion, not to mention minimalistic graphics that are more common there)
- jd20 9y agoThe delta encoding will be more efficient with higher frame rate, but also x264 has a tweak which decreases quality factor as frame rate increases. Why? The reasoning was that, since the frame is displayed for less time, you don't have as much time to appreciate the details and hence fewer bits can be used, while still maintaining the same perceptual quality. I found this out the hard way when encoding time lapses, even if the delta between frames is identical, the final choice of frame rate greatly affects output file size.
- vanderZwan 9y agoOooooof, now that is a good thing to know. Speaking from experience with recording 120fps, which inevitably stutters on playback unless shown at half speed, I suppose also that it is a matter of "if the CPU can't keep up decoding, there is no point"
- hnaccy 9y agoIf all frames have lower quality wouldn't it still be perceived regardless of frame rate?
- mAritz 9y agoI'm no expert but I would say no. Each frame delta might have less/same information, but since you're applying more deltas/second, it gets better again.
- vanderZwan 9y agoWouldn't this lead to bigger error accumulation? At least, my gut feeling says "less information per delta = larger error accumulation", and on top of that we have more deltas/second
- colde 9y agoYes, generally it should less than double the size. How much less depends a lot on your content. If its a talking head, it should be very efficient, if its action movie content, maybe less efficient. I haven't found a good rule of thumb to apply generally though.
- fraencko 9y agoYouTube recommends a 50% higher bitrate for 50/60FPS compared to 25/30FPS. https://support.google.com/youtube/answer/1722171?hl=en https://support.google.com/youtube/answer/1722171?hl=en
- slhck 9y agoNote that these are upload settings. YouTube will re-encode all these videos, so they give a little bit higher bitrates than what you'd typically end up with after they've re-encoded the sources.
- littlestymaar 9y agoIncreasing the frame-rate increases the bitrate by less than 100%, because you just double the amount of inter frames, and not the amount of keyframes, which weight way more (between one and 2 orders of magnitude generally speaking). If you look at this chart[1] (that I stole on this[2] article), you can see that the first frame (a keyframe) is way bigger than the others. [1]: https://people.xiph.org/~xiphmont/demo/av1/framebits.png https://people.xiph.org/~xiphmont/demo/av1/framebits.png [2]: https://people.xiph.org/~xiphmont/demo/av1/demo1.shtml https://people.xiph.org/~xiphmont/demo/av1/demo1.shtml