Dab*_*ons 4 video streaming rtp h.264
这更像是一个概念问题,而不是技术问题.我对H.264的理解是,它依赖于过去和未来的帧来压缩视频数据.通过RTP或您选择的任何其他协议来获取完全压缩的H.264视频文件并将其流式传输是微不足道的,但是,这如何与实时视频一起使用？在实时视频中,您只能访问过去和当前帧,并且不知道视频的全长,那么H.264编解码器如何实际压缩视频并将其准备为RTP有效载荷？它只是简单地将视频缓冲并分块为任意大小的较小视频并压缩它吗？我能想到这个工作的唯一方法是将视频分成1秒钟的块,将它们压缩为单独的视频,并使它们成为RTP有效载荷.这是它的完成方式还是更多"
首先,有三种类型的帧.
I(帧内)帧或关键帧.这些框架不引用任何其他框架.它们是独立的,可以在没有任何其他帧数据的情况下进行解码.像JPEG一样.
P(Predecitve)框架.可以参考过去的帧.
B(双向)可以参考过去或未来的帧.
选项1.仅使用I帧和P帧.这会导致文件大约10 - 15%(或在相同文件大小下质量降低10-15%).这用于视频会议和屏幕共享等交互式系统,其中延迟非常明显.
选项2,等待未来发生.以每秒30帧的速度,未来将在33毫秒内完成.
h.264具体只能引用最多16个相邻帧.然而,大多数人将此限制在4左右.所以等待4帧只有大约133毫秒的延迟.