基于libopenh264 codec的svc分层流实现方案

本文主要是介绍基于libopenh264 codec的svc分层流实现方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

OpenH264 http://www.openh264.org/ 是标准的H.264 encoder/decoder. ffmpeg已经集成libopenh264，但不支持svc特性。
openh264 encoder支持svc特性：
1. 时域4层：Temporal scalability up to 4 layers in a dyadic hierarchy
2. 空域4层：Spatial simulcast up to 4 resolutions from a single input
Temporal scalability指的是FPS，定义为：{30,24,16,10};
Spatial simulcast指的是分辨率，定义为：
int arrHorW[]={1920, 1280, 800, 640 };
int arrHorH[]={1080, 720, 450, 360 };
通过组合，最多可以组合成16种码流。由软件出16个encoding pipeline来实现。
对于传输，用RTP协议。参考RFC6190: https://datatracker.ietf.org/doc/html/rfc6190#section-1.1.3
不同流用虚连接区分，NALU type上区分layers: dependency_id（DID) + temporal_id(TID) + quality_id(QID).
+---------------+---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|I| PRID |N| DID | QID | TID |U|D|O| RR|
+---------------+---------------+---------------+
svcRtpSvr解析NALU packet。按dependency_id + temporal_id构建16个queue分别进行buffering。audio单独一个buffer。
为了缩短首帧加载时间，需要按dependency_id缓冲一个I-frame。
参考w3c标准（scalabilityMode表），对layers进行编码，共16个layer。
"S0T0", "S0T1", "S0T2", "S0T3" "S1T0", "S1T1", "S1T2", "S1T3"
"S2T0", "S2T1", "S2T2", "S2T3" "S3T0", "S3T1", "S3T2", "S3T3"
各个不同client的svcPlayer根据网络质量/buffering长度，自行决定要拉哪些layer，主动向svcMediaSvr发出请求。
比如，刚开始播放时，尝试获取3s标清base layer S0T2进行播放，播放流畅的话，就尝试获取S1T2进行叠加图像效果。3s播放仍然流畅，继续获取S2T2和S3T2进行高画质叠加。
player需要不断测试网络带宽，根据网络带宽的80%来计算应该在哪个layer上进行播放为佳。