H.264 建议的压缩比?
注意:我意识到这是一个非常复杂的问题,大约有一百万个级别的细微差别,我正在尝试将其减少到一个数字......
我即将进行一个大型视频编码项目使用H.264编码。我们正在尝试创建多个比特率配置文件,以便适应跨互联网连接、处理器、设备等的流式传输。
一般来说,我应该期望看到什么样的压缩比(同时保持在合理的质量水平内)?
例如,640x360 (16:9) 像素视频文件@每秒 24 帧和 16 位颜色应生成大约 33 MB/s 的未压缩文件。
有人告诉我,对于该文件,500 Kbits/秒(或 62 KB/s)并不是一个不合理的视频比特率。这看起来很疯狂——压缩比超过 530:1?这就是 99.8% 的压缩率。我的数学错了吗?
我只是在寻找质量的粗略外部指南,例如“超过 500 倍的压缩是疯狂的”或“低于 400 倍的压缩是浪费带宽”。我到处都看了,没有任何东西给我任何预期的压缩......
Note bene: I realize this is an immensely complicated question with about a million levels of nuance that I'm trying to reduce to a single number...
I'm about to undertake a large video encoding project using H.264 encoding. We are trying to create multiple bitrate profiles in order to accommodate streaming across internet connections, processors, devices, etc.
Generally speaking, what kind of compression ratio should I be expecting to see (while staying within a reasonable level of quality)?
For example, a 640x360 (16:9) pixel video file @ 24 frames per second and 16-bit color should yield an uncompressed file that is approximately 33 MB/s.
I've been told that, for that file, 500 Kbits/second (or 62 KB/s) is not an unreasonable video bitrate. That seems insane - more than 530:1 compression? That's 99.8% compression. Is my math wrong?
I'm just looking for a rough outer guide for quality, like "more than 500x compression is crazy" or "less than 400x is a waste of bandwidth". I've looked everywhere, and nothing gives me any kind of expected compression...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
在一个名为 H.264 Primer 的非常有趣的文档中,给出了一个简单的公式作为计算的提示基于视频特征的“理想”输出文件比特率:
其中图像宽度和高度以像素表示,运动等级是1到4之间的整数,1为低运动,2 为中运动,4 为高运动(运动是帧之间变化的图像数据量,请参阅链接文档了解更多信息)。
例如,如果我们以 24 FPS 拍摄一个 1280x720 的视频,中等运动(摄像机运动缓慢,场景变化不多......),预期的理想比特率将是:
这纯粹是一个提示,在我看来,准确找到理想比特率的唯一方法是通过错误尝试:)
In a quite interesting document called H.264 Primer, a simple formula is given as an hint to compute the `ideal' output file bitrate, based on the video's characteristics:
where the image width and height is expressed in pixels, and the motion rank is an integer between 1 and 4, 1 being low motion, 2 being medium motion, and 4 being high motion (motion being the amount of image data that is changing between frames, see the linked document for more information).
So for instance, if we take a 1280x720 video at 24 FPS, with medium motion (movie with slow camera movements, not many scene changes...), the expected ideal bitrate would be:
This is purely a hint, and in my opinion, the only way to accurately find the ideal bitrate is trial by error :)
根据源视频的内容,它会发生很大的变化。我稍后会谈到这一点。
640x360 并没有那么大。 512kbps 非常合理,可以说是标准。如果您真的对质量感兴趣,也许 768kbps。
这怎么可能?一个简单的答案:有一些关于视频压缩的技术和事实使这成为可能:
它比这要复杂得多,在特定编解码器内以及编解码器之间有无数不同的方法、技术和算法来实现这一点。
因此,回到“它会根据源视频的内容而发生巨大变化”评论:您将看到的压缩比以及最终的质量将在很大程度上取决于:
示例:房间内门的视频(例如每十分钟一个关键帧的安全摄像机)将具有惊人的高压缩比。我的餐巾纸背面计算将该场景的压缩率设为 15,000:1。
由于您正在开始一个大型视频编码项目,因此我建议您采取一些措施来确定您的压缩比:
更改编码器的参数以使视频更小也会产生其他影响:
这是一个大而复杂的主题。祝你好运。我经验丰富的“拇指到风”测试表明您会对项目的 512-768kbps 感到非常满意。
It will vary dramatically depending on the content of the source videos. I'll get to that in a bit.
640x360 is not that large. 512kbps is very reasonable and arguably standard. Maybe 768kbps if you are really interested in quality.
How is this possible? A simplified answer: There are a couple of techniques and facts about video compression that make this possible:
It is all wildly more complex than that, with zillions of different approaches, techniques and algorithms within specific CODECs and between CODECs to make this happen.
So, back to the "It will vary dramatically depending on the content of the source videos" comment: The compression ratio you'll see, and the resulting quality, will depend significantly upon:
Example: A video of a door in a room (like a security camera) with one key frame every ten minutes is going to have an amazingly high compression ratio. My back-of-the-napkin calculations put that scenario at 15,000:1 compression.
Since you are starting on a large video encoding project, I would recommend a couple of things to determine what your compression ratio is going to be:
Changing the parameters of the encoder to make the videos smaller can have other impacts too:
It's a big complicated subject. Good luck. My experienced "thumb-to-the-wind" test says you'll be more than happy with 512-768kbps for your project.
来自 https:/ /web.archive.org/web/20090206042542/http://www.kanecomputing.co.uk:80/pdfs/compression_ratio_rules_of_thumb.pdf
from https://web.archive.org/web/20090206042542/http://www.kanecomputing.co.uk:80/pdfs/compression_ratio_rules_of_thumb.pdf
不要忘记正常播放 MPEG 将仅使用 YUV 4:2:0。在 8 位颜色深度中,每个像素仅值 16 位(或每 4 个像素 64 位)。请注意,只有来自相机的 RAW 文件才会使用 16 位深度,而且它必须价值数百万美元!!中高胶片 DVR 只能提供 12-14 位!而且没有人会使用 H.264 来存储 RAW。 H.264 是为最终产品而设计的。
在 640x360/24p YUV4:2:0 中,比特率的值是:
对于 500Kbps,压缩率仅为 172:1。这是正常的
对于YUV4:2:0的解释,请阅读:
http://en.wikipedia.org/wiki/Chroma_subsampling
Don't forget normal playback MPEG will only use YUV 4:2:0. In 8-bit color depth each pixel only worth 16-bit(or 64bit each 4 pixels). Please, only RAW file from camera will use 16-bit depth, and it must worth millions USD!!Medium high Film DVR only can provide 12-14bit!!And nobody will use H.264 to store RAW. H.264 is deigned for end product.
In 640x360/24p YUV4:2:0 the bitrate will worth:
For 500Kbps the compression will be only 172:1. It's normal
For expatiation of YUV4:2:0, read:
http://en.wikipedia.org/wiki/Chroma_subsampling
只是分享我在 H264 环境下编码的知识
至于比率 450-512 kbits/秒,如果您使用 High 5.0 或 High 7.0 的 H264,则最好。
好吧,我可以建议您,要获得与最佳质量平衡的良好比例,真正重要的关键是调整分辨率大小。
视频分辨率的结果 = 3/4 * 本机/原始视频的分辨率
H264 如果您不将帧压缩为更小的分辨率,则往往会丢失更多细节。
Just sharing my knowledge over encoding with H264 environment
As for the ratio 450-512 kbits/second is best if you use H264 with High 5.0 or High 7.0.
Well i can suggest you that to get a good ratio in balance with the best quality , the key that really matters to it is to play with the Resolution size.
Result of Video Resoltion = 3/4 * Native's / Raw Video's Resolution
H264 tends to loose details more if you don't compress the frame into a little bit of smaller resolution.