关于 frame的一些基本知识 分类： ffmpeg-SDL-VLC-Live555 2013-07-22 16:30 315人阅读 评论(0) 收藏
关于 frame的一些基本知识只是摘抄了一部分，供初学者参考。
b.帧速率：
帧速率是每秒显示的图像数。标准影片(NTSC) 是29.97 帧第秒 (fps)，电影是每秒24 帧fps。欧洲标准是(PAL) 25 帧fps。如果你对你影片的尺寸 不是太注重的话，保留默认的Current选项。这将会使你制作的影片的帧速率和源文件一致。不管怎样，如果你想降低带宽和CPU的占用，你可以选择一个低的帧 速率。高的帧速率拥有高的品质的，但文件尺寸也更大。如果你选择的帧速率低于你的源文件的帧速率，一些帧将被删除。如果你选择的帧速率比你的源文件高 的话，已有的帧将被重复 (不推荐，因为增加了尺寸，但品质没有提高)。如果你选择的帧速率低于你的源文件的帧速率，使用一个你当前帧速率的简分数，比如 1/2， 1/3 等等。例如，你当前的帧速率是30 (29.97)，使用15 或10。但话说回来了，要最好的H.264品质，最好保留Current，当前）设置。
c.关键帧：
很多编码软件使用frame differencing（帧差异）来压缩图像。帧差异其实是判断从开始帧起哪些信息发生了变化 (称为key frame关键帧)。关键帧 包含了图像的所有信息。后来的帧仅包含改变了的信息。这取决于你用的编码软件，你可以指定你想要的关键帧如何出现。 如果你没有足够的关键帧，你的影片 品质可能比较差，因为所有的帧从别的帧处产生。另一问题是，关键帧多了将导致影片更大，码率更高。 在一些编码软件中，当从一帧到下一帧有太多的内容发 生改变时，那些增加的关键帧是自动插入的。 对于一般的用途，一个比较好的原则是每5秒设一个关键帧。如果你正在建立一个RTSP流文件，并且关心传输网络 的可靠度，你可能要1到2秒增加一个关键帧。要让编码软件来处理关键帧的间隔，选择 Automatic。针对H.264，我们推荐让编码软件来确定关键帧的间隔，为 此你要选择Automatic以获得最佳品质。
e.码率：通常情况下，高码率就有高的品质，但文件也会很大。在大多数情况下，你要根据你观看的影片设置码率，例如，对于384K 连接速度，你要限制码率为 350-360k每秒来留一些带宽给网络传输。如果文件是下载回来后播放，那码率可以很高（高码率，然而，网速比较慢的用户将要花比较长的时间来等待播放的开 始）。另外，记住在对话框中设置码率时，你要留一些空间给音频。
针对 H.264， 这里有一些常用的码率方案： § 画面尺寸 1920 x 1080 (真正高清)， 选择码率为7,000-8,000 Kbps。 § 画面尺寸 1280 x 720 (通用高清)， 选择码率为5,000-6,000 Kbps。 § 画面尺寸 640 x 480 (标清)， 选择码率为1,000-2,000 Kbps。 § 画面尺寸 320 x 240 (网络传输)， 选择码率为300-500 Kbps。 § 画面尺寸176 x 144 (3G)， 10-15 fps的内容选择码率为50-60 Kbps， 24-30 fps 的内容选择码率为150-200 Kbps。
提及3G 格式， 一定要记住影片的码率会被你设置的其它的压缩选项所影响， 如同帧速率。因此高的帧速率，要有高的码率，如果你对码率要求不是特别严格并 且你只想QuickTime带给你一个比较好的影片效果，你可以通过选择Automatic让H.264 编码器选择一个理想的码率。 编码器会按你选择的尺寸和你用品质滑 动条选择的品质来选择合适的编码。
f.优化：如果你已经输入了你自己的码率而不是自动选择码率，在Optimized for 下拉菜单中就有你选择的传送方式的相关选项。这些选项将告诉编码器可以高于 或低于你选择的的码率多少。要得到最好的品质，选择Download。如果你想要借助CD 或 DVD来传送影片，在码率中选择 CD/DVD，CD/DVD需要被进行一些限制 ，因此光驱要保持与观看者的电脑读与数据传送畅通 。如果你想借助RTSP流来传送影片，码率选择Streaming 将是最大限制。此选项仅能用于有限制的压缩软 件，如H.264。
相关问题：
为什么会有关键帧的存在？
对应解答：
这是因为mpeg或者其他压缩方法（我只了解过mpeg），为了提高压缩比，就选择某一帧作为基帧，以它为参考，后面的帧只记录改变的信息，这是一个压缩的 技巧，记录信息的改变是通过前后帧之间的图像相关性来完成的，分为（I，B，P）三种帧式，这三种帧式分别是三种不同的采用相关性的方式。这里的基帧就是 关键帧了。音视频同步-时间戳
媒体内容在播放时，最令人头痛的就是音视频不同步。从技术上来说，解决音视频同步问题的最佳方案就是时间戳：首先选择一个参考时钟（要求参考时钟上的 时间是线性递增的）；生成数据流时依据参考时钟上的时间给每个数据块都打上时间戳（一般包括开始时间和结束时间）；在播放时，读取数据块上的时间戳，同 时参考当前参考时钟上的时间来安排播放（如果数据块的开始时间大于当前参考时钟上的时间，则不急于播放该数据块，直到参考时钟达到数据块的开始时间；如 果数据块的开始时间小于当前参考时钟上的时间，则“尽快”播放这块数据或者索性将这块数据“丢弃”，以使播放进度追上参考时钟）。 可见，避免音视频不同步现象有两个关键——一是在生成数据流时要打上正确的时间戳。如果数据块上打的时间戳本身就有问题，那么播放时再怎么调整也于 事无补。假如，视频流内容是从0s开始的，假设10s时有人开始说话，要求配上音频流，那么音频流的起始时间应该是10s，如果时间戳从0s或其它时间开始打， 则这个混合的音视频流在时间同步上本身就出了问题。打时间戳时，视频流和音频流都是参考参考时钟的时间，而数据流之间不会发生参考关系；也就是说，视频 流和音频流是通过一个中立的第三方（也就是参考时钟）来实现同步的。第二个关键的地方，就是在播放时基于时间戳对数据流的控制，也就是对数据块早到或晚 到采取不同的处理方法。图2.8中，参考时钟时间在0-10s内播放视频流内容过程中，即使收到了音频流数据块也不能立即播放它，而必须等到参考时钟的时间达 到10s之后才可以，否则就会引起音视频不同步问题。 基于时间戳的播放过程中，仅仅对早到的或晚到的数据块进行等待或快速处理，有时候是不够的。如果想要更加主动并且有效地调节播放性能，需要引入一个 反馈机制，也就是要将当前数据流速度太快或太慢的状态反馈给“源”，让源去放慢或加快数据流的速度。熟悉DirectShow的读者一定知道，DirectShow中的 质量控制（Quality Control）就是这么一个反馈机制。DirectShow对于音视频同步的解决方案是相当出色的。但WMF SDK在播放时只负责将ASF数据流读出并 解码，而并不负责音视频内容的最终呈现，所以它也缺少这样的一个反馈机制。 为了更好地理解基于时间戳的音视频同步方案，下面举一个生活中的例子。假设你和你的一个朋友约好了今天18:00在沪上广场见面，然后一起吃饭，再去打 游戏。实际上，这个18:00就是你和你朋友保持同步的一个时间点。结果你17:50就到了沪上广场，那么你必须等你的朋友。10分钟过后，你的朋友还没有到，这 时他打来电话说有事耽搁了，要晚一点才能到。你没办法，因为你已经在旁边的餐厅预订了位置，如果不马上赶过去，预订就会被取消，于是你告诉你的朋友直接 到餐厅碰头吧，要他加快点。于是在餐厅将来的某个时间点就成为你和你朋友的又一个同步点。虽然具体时间不定（要看你朋友赶过来的速度），但这样努力的方 向是对的，你和你朋友肯定能在餐厅见到面。结果呢？你朋友终于在18:30赶过来了，你们最终“同步”了。吃完饭19:30了，你临时有事要处理一下，于是跟你 朋友再约好了20:00在附近的一家游戏厅碰头。你们又不同步了，但在游戏厅将来的某个时间点你们还是会再次同步的。 悟出什么道理了没有？其实，同步是一个动态的过程，是一个有人等待、有人追赶的过程。同步只是暂时的，而不同步才是常态。人们总是在同步的水平线上 振荡波动，但不会偏离这条基线太远。
版权声明：本文为博主原创文章，未经博主允许不得转载。
