一帧就是视频中的一个画面。视频编码是按“组”进行的,每一组也叫一个GOP,GOP与GOP之间是没有联系的,编码关系只在GOP中间产生。每一个GOP组都从一个关键帧开始。
关键帧是一辐完整的画面,GOP中间的那些帧都是不完整的,需要由关键帧、前面的帧或者也包括后面的帧一起,运算后得到。
对于普通视频文件,加大GOP长度有利于减小体积;从原理上可知,GOP长度也不能过大,太大则会导致GOP后部帧的画面失真。一般建议GOP长度在250帧以下为宜。
由于PAL制式每秒有25帧(N制为30帧),如果是用于实时视频,如电视、网上视频等,GOP长度应在15至25之间。这样可以在一秒内完成视频快进或回退。
为什么非要用 Adobe 的私有协议 ?直接用 Matroska 容器封装 h264 流就能在主流浏览器里面直接 <video src=""> 播放了,要是土豪还可以转码成 webm ( vp9 )。如果不需要考虑延迟,还有 HLS 和 Media Source Extension
感谢已发送 会话详情 Reply 21
typcn 3 小时 37 分钟前
@lisonfan 由于 h265 版权费高昂,目前世界上还没有一款支持 html5 h265 播放的浏览器,例如 Google 要在全套产品支持 h265 ,每年需要支付很数亿美元的版权费用。
@livepps
@vicence 国内直播占 CPU 的原因有两个:
1. Flash 本身就费 CPU ,用了别想低。。除了某些魔改过的 flash ,全部都是软解的。软解就软解,还没有任何优化,比起 ffmpeg 那一堆库出来的效率不知道低到哪里去了
2. 那些直播站还带弹幕,用 Flash 来实现弹幕本身就是一件非常蠢的事情, Flash 的文字渲染性能处在一种不可接受的程度。
HTML 5 直播有几种方案:
(当然为了照顾国内大环境, Flash fallback 还是得有的)
1. HLS
ajax 读分片, JS 转一下容器,加上 mp4 的 header/box ,用 media source extension 来播放,在移动端上可以直接播放。
优点: HTTP 协议, CDN 友好,还可以跟 iOS 必备的 HLS 用一套源,免得服务器切片一堆东西,支持所有主流浏览器。
缺点:比 dash 占用稍微高一点点,延迟至少一个 GOP + 网络传输时间。
2. DASH
ajax 读分片,利用 media source extension 来播放
优点: HTTP 协议, CDN 友好,比 HLS 稍快点,支持所有主流浏览器。
缺点:服务器需要切片 hls + dash 两套,降低 cdn 缓存利用率,延迟至少一个 GOP + 网络传输时间。
3. Matroska
真正意义上的流,<video> 标签直接播放,具体看这里: https://matroska.org/technical/streaming/index.html
注意别转码,别转码,别转码,直接封装 rtmp 推上来的 h264 进去,每个请求来的时候生成一份 metadata ,做重传,不用等到一个关键帧就可以播放。
优点:速度最快占用最低,延迟可以做到跟 rtmp 一个级别
缺点:只支持 Chromium-based 浏览器,没法用 CDN
直播不需要什么配置,大部分情况下都是重新封装一下视频容器,树莓派也能扛几千人。
除非你要转码,或者你用的 Java 写的媒体服务器。
qtfaststart
qtfaststart -l test.mp4
平台 | HLS | HTTP mp3 |
---|---|---|
PC Web(Flash) | 支持 | 支持 |
iOS HTML5 | 支持 | 支持 |
Android HTML5 | 大部分机型不支持 | 大部分机型支持 |