webrtc中的h264解析
来源:互联网 发布:pc刷mac 编辑:程序博客网 时间:2024/06/07 01:10
H264的码流解析,网上有很多开源文件;
一般的解析有: 获取NALU,sps,pps,NALU type,slice type,获取Qp等;
可以通过C++的位运算实现获取计算,但是一般可以定义结构体直接获取;
这里要说的是webrtc中的H264解析相关:
在webrtc中,关于H264的相关源码文件在:webrtc58\src\webrtc\common_video\h264中;
比较全,具体可自行查看,比较简单;
普及一些简单知识:
《h.264 SODB RBSP EBSP的区别》
from:http://blog.csdn.net/threewells_14/article/details/1508657
SODB 数据比特串-->最原始的编码数据
RBSP 原始字节序列载荷-->在SODB的后面填加了结尾比特(RBSP trailing bits 一个bit“1”)若干比特“0”,以便字节对齐。
EBSP 扩展字节序列载荷-->在RBSP基础上填加了仿校验字节(0X03)它的原因是: 在NALU加到Annexb上时,需要填加每组NALU之前的开始码StartCodePrefix,如果该NALU对应的slice为一帧的开始则用4位字节表示,ox00000001,否则用3位字节表示ox000001.为了使NALU主体中不包括与开始码相冲突的,在编码时,每遇到两个字节连续为0,就插入一个字节的0x03。解码时将0x03去掉。也称为脱壳操作。
网上查询的区别:
在对整帧图像的数据比特串(SODB)添加原始字节序列载荷(RBSP)结尾比特(RBSP trailing bits,添加一比特的“1”和若干比特“0”,以便字节对齐)后,再检查RBSP 中是否存在连续的三字节“00000000 00000000 000000xx”;若存在这种连续的三字节码,在第三字节前插入一字节的“0×03”,以免与起始码竞争,形成EBSP码流,这需要将近两倍的整帧图像码流大小。为了减小存储器需求,在每个宏块编码结束后即检查该宏块SODB中的起始码竞争问题,并保留SODB最后两字节的零字节个数,以便与下一宏块的SODB的开始字节形成连续的起始码竞争检测;对一帧图像的最后一个宏块,先添加结尾停止比特,再检测起始码竞争。
- webrtc中的h264解析
- webrtc中的rtp解析
- webrtc 支持h264 思路
- WEBRTC 支持H264编解码
- WEBRTC 支持H264编解码
- webrtc添加H264支持编译
- h264解析
- webrtc (5) 在Webrtc中集成H264 Codec
- wireshark解析流媒体中的AMR/H263/H264包的方法
- H264 in WebRTC的那些坑
- 让WebRTC支持H264编解码
- WebRtc VoiceEngine代码解析
- WebRtc VoiceEngine代码解析
- WebRtc VoiceEngine代码解析
- WebRTC-命令行参数解析
- H264 NAL层解析
- h264 NAL头解析
- H264 NAL层解析
- redis requires Ruby version >= 2.2.2问题
- POJ 2993.Emag eht htiw Em Pleh
- MySQL约束语法
- opencv其他常用数据结构
- lvs-tun原理配置
- webrtc中的h264解析
- 【资讯】东京券商所在地期待金融科技公司助其重振旗鼓
- 【国际】日本积极探索金融科技
- 【国际】直布罗陀金融监管者留意ICO增长并发布警告
- Ionic入门开发
- laydate范围选择,结束时间大于开始时间同时大于当前时间
- 自定义View 自定义一个带箭头的圆环详解 加速 减速 暂停 变色
- series.map() 映射值
- Linux-my_bash(cd)