详解 H.264 NALU语法结构

文章来源:https://blog.csdn.net/qq_29350001/article/details/78226286

讲到H.264除了前两篇文章提到的,I、P、B帧。参看: 图像和流媒体 -- I 帧,B帧,P帧,IDR帧的区别

还有其他相关术语:

NALU:H264编码数据存储或传输的基本单元,一般H264码流最开始的两个NALU是SPS和PPS,第三个NALU是IDR。SPS、PPS、SEI这三种NALU不属于帧的范畴。
SPS(Sequence Parameter Sets):序列参数集,作用于一系列连续的编码图像。
PPS(Picture Parameter Set):图像参数集,作用于编码视频序列中一个或多个独立的图像。
SEI(Supplemental enhancement information):附加增强信息,包含了视频画面定时等信息,一般放在主编码图像数据之前,在某些应用中,它可以被省略掉。
IDR(Instantaneous Decoding Refresh):即时解码刷新。
HRD(Hypothetical Reference Decoder):假想码流调度器。

上面这些知识我还是了解的。但还是思考了半晌,不知道从哪讲起?它们之间的关系又该怎么讲?

想了解更多内容,参看:新一代视频压缩编码标准-H.264_AVC(第二版).pdf

一、H.264 NALU语法结构

在H.264/AVC视频编码标准中,整个系统框架被分为了两个层面:视频编码层面(VCL)和网络抽象层面(NAL)。其中,前者负责有效表示视频数据的内容,而后者则负责格式化数据并提供头信息,以保证数据适合各种信道和存储介质上的传输。因此我们平时的每帧数据就是一个NAL单元(SPS与PPS除外)。在实际的H264数据帧中,往往帧前面带有00 00 00 01 或 00 00 01分隔符,一般来说编码器编出的首帧数据为PPS与SPS,接着为I帧……

详解 H.264 NALU语法结构_第1张图片

然后我们参看:FFmpeg再学习 -- 视音频基础知识

使用 UltraEdit 查看一个 h.264 文件信息

详解 H.264 NALU语法结构_第2张图片

其中 SPS、PPS 文章开始也讲了。

SPS(Sequence Parameter Sets):序列参数集,作用于一系列连续的编码图像。
PPS(Picture Parameter Set):图像参数集,作用于编码视频序列中一个或多个独立的图像。

如上图,在H264码流中,都是以"0x00 0x00 0x01"或者"0x00 0x00 0x00 0x01"为开始码的,找到开始码之后,使用开始码之后的第一个字节的低 5 位判断是否为 7(sps)或者 8(pps), 及 data[4] & 0x1f == 7 || data[4] & 0x1f == 8。然后对获取的 nal 去掉开始码之后进行 base64 编码,得到的信息就可以用于 sdp。 sps和pps需要用逗号分隔开来。

上图中,00 00 00 01是一个nalu的起始标志。后面的第一个字节,0x67,是nalu的类型,type &0x1f==0x7表示这个nalu是sps,type &0x1f==0x8表示是pps。

 

接下来我们来讲解一下NALU语法结构:

H264基本码流由一些列的NALU组成。原始的NALU单元组成:

[start code] + [NALU header] + [NALU payload];

H264基本码流结构分两层:视频编码层VCL和网络适配层NAL,这样使信号处理和网路传输分离

 

H.264码流在网络中传输时实际是以NALU的形式进行传输的.

每个NALU一个字节HeaderRBSP组成.

NAL Header 的组成为:

forbidden_zero_bit(1bit) + nal_ref_idc(2bit) + nal_unit_type(5bit)

 

1、forbidden_zero_bit: 

禁止位,初始为0,当网络发现NAL单元有比特错误时可设置该比特为1,以便接收方纠错或丢掉该单元。
2、nal_ref_idc:                  

nal重要性指示,标志该NAL单元的重要性,值越大,越重要,解码器在解码处理不过来的时候,可以丢掉重要性为0的NALU。

3、nal_unit_type:NALU类型取值如下表所示:

句法表中的 C 字段表示该句法元素的分类,这是为片区服务。

详解 H.264 NALU语法结构_第3张图片

不过上面这张图,我实在没有找到出处啊。但是我在 x264 里看到了这个。

详解 H.264 NALU语法结构_第4张图片

其中需要关注的是 SEI、SPS、PPS。我在 LIVE555 里又看到这个。

详解 H.264 NALU语法结构_第5张图片

这不就是上面我们讲到的,nalu的类型 type &0x1f==0x7表示这个nalu是sps,type &0x1f==0x8表示是pps。

 

接下来我们来举个例子,来讲解下:

该视频下载:H.264 示例视频和工具

详解 H.264 NALU语法结构_第6张图片

00 00 00 01 为起始符,67 即 nal_unit_type。

0x67的二进制是 0110 0111

则 forbidden_zero_bit(1bit) = 0;

nal_ref_idc(2bit) = 3;

nal_unit_type(5bit) = 7;即 SPS 类型。

 

然后看另一部分 RBSP 

这里提一下 SODB 和 RBSP 关系

SODB(String Of Data Bits):最原始的编码数据RBSP, 长度不一定是8的倍数,此时需要对齐. 
RBSP: 在SODB的后面填加了结尾比特(RBSP trailing bits 一个bit“1”)若干比特“0”,以便字节对齐。

详解 H.264 NALU语法结构_第7张图片

 

我们知道码流是由一个个的NAL Unit组成的,NALU是由NALU头和RBSP数据组成,而RBSP可能是SPS,PPS,Slice或SEI,目前我们这里SEI不会出现,而且SPS位于第一个NALU,PPS位于第二个NALU,其他就是Slice(严谨点区分的话可以把IDR等等再分出来)了。

而上面这个h.264文件,相当于包含两个 NALU吧,第一个是SPS,第二个是PPS。

我们先看第一个NALU(SPS)的 RBSP (10个字节)

67 4D 40 33 92 54 0C 04 B4 20

转换成二进制:

0110 0111  
0100 1101  
0100 0000  
0011 0011  
1001 0010  
0101 0100  
0000 1100
0000 0100  
1011 0100   
0010 0000

 

先看NALU头,解析结果如下:

forbidden_zero_bit = 0 // 0  u(1)
nal_ref_idc = 3 // 11  u(2)
nal_unit_type = 7 // 00111  u(5)
这就对了,看看 NAL_SPS = 7;

 

接下来进入 RBSP,先讲SPS的

还记得视频编码数据工具 Elecard Stream Eye

参看:FFmpeg再学习 -- 视音频基础知识

详解 H.264 NALU语法结构_第8张图片

点击 show\hide info 可查看 File 和 Headers (重点)

详解 H.264 NALU语法结构_第9张图片

详解 H.264 NALU语法结构_第10张图片

这里在推荐一款软件 下载:视频分析工具H264Visa

详解 H.264 NALU语法结构_第11张图片

 

我们就是根据上图里的内容来进行分析。

profile_idc = 77 // 0100 1101 u(8)  Main    参看:H264 各profiles用途和特点

constraint_set0_flag = 0 //0  u(1)

constraint_set1_flag = 1 //1  u(1)

constraint_set1_flag = 0 //0  u(1)

reserved_zero_5bits = 1 //1  u(5)

level_idc = 51 //0011 0011 u(8)

 

==================================================

对于 seq_parameter_set_id,我们看到它是ue(v),这是一种指数哥伦布编码

扩展:

参看:指数哥伦布码

指数哥伦布编码是一种在编码技术中经常用到的编码,其是无损编码,在HEVC中以及之前的编码技术H.264/AVC中,由于其可以由编码直接解得码字的变长码,所以广受欢迎。HM源码中的SPS/PPS和每个片的头部分都是用哥伦布编码进行编码。
对于一个需要编码的数 x,按照以下的几步进行编码: 
1. 按照二进制形式写下 x+1, 
2. 根据写下的数字,计算出当前数值的位数,然后在该数的前面加上当前数值位数减一后得到的数值个数的零。


例如:编码“3” 
1. 该数加一后(即4)的二进制为100, 
2. 当前数值的位数是三位,3减去1后得到2,所以在“100”的前方加上两个零,得“00100”即为3的哥伦布码。

下面列出1-8的哥伦布码: 
0=> 1=> 1 
1=> 10=> 010 
2=> 11=> 011 
3=> 100=> 00100 
4=> 101=> 00101 
5=> 110=> 00110 
6=> 111=> 00111 
7=> 1000=> 0001000 
8=> 1001=> 0001001

 

哥伦布码扩展到负数范围
每一个负数进行编码的时候,将其映射到其绝对值的两倍。即-4映射为8进行编码;正数的映射为其两倍减一进行编码,即4映射为7进行编码。 
例如: 
0 => 0 => 1 => 1 
1 => 1 => 10 => 010 
=>1 => 2 => 11 => 011 
2 => 3 => 100 => 00100 
=>2 => 4 => 101 => 00101 
3 => 5 => 110 => 00110 
=>3 => 6 => 111 => 00111 
4 => 7 => 1000 => 0001000 
=>4 => 8 => 1001 => 0001001

K阶指数哥伦布码
为了用更少的比特表示更大的数值,可以使用多阶指数哥伦布编码(代价是相比起之前的0阶哥伦布码来书,小的数值可能需要更多的比特去表示) 
进行K阶哥伦布编码的步骤是 
1. 确定进行编码的阶数K 
2. 将原数映射到” X + (2^k) -1” (即如果在3阶条件下编码4,则其将被映射到4+2^3-1=11) 
3. 将上一步骤得到的数值进行0阶编码得到0阶哥伦布码(11->0001100) 
4. 去掉码的前部分k个前导零(0001100->1100) 
在进行解码的时候,从bit stream中寻找第一个非零比特值,然后把之前遇到的零的个数存在leadingzerobit参数中,即可根据该参数去被编码值了。

 

上面讲到的只是 ue(v),但是还有其他的像是 se(v),又是什么?

参看:H264的句法和语义(二)

 

H264定义了如下几种描述子:

ae(v) 基于上下文自适应的二进制算术熵编码;
b(8) 读进连续的8个比特;
ce(v) 基于上下文自适应的可变长熵编码;
f(n) 读进连续的n个比特;
i(n)/i(v) 读进连续的若干比特,并把他们解释为有符号整数;
me(v) 映射指数Golomb熵编码;
se(v) 有符号指数Golomb熵编码;
te(v) 截断指数Golomb熵编码;
u(n)/u(v) 读进连续的若干比特,并将它们解释为无符号整数;
ue(v) 无符号指数Golomb熵编码。

我们看到,描述子都在括号中带有一个参数,这个参数表示需要提取的比特数。

当参数是n时,表明调用这个描述子的时候回指明n的值,也即该句法元素是定长编码。

当参数是v时,对应的句法元素是变成编码,这时有两种情况:

i(v)和u(v)两个描述子的v由以前的句法元素指定,也就是说在前面会有句法元素指定当前句法元素的比特长度;陈列这两个描述子外,其他描述子都是熵编码,他们的解码算术本身能够确定当前句法元素的比特长度。

 

====================================================

 

seq_parameter_set_id = 0 // 1  ue(v)

log2_max_frame_num_minus4 = 3 //00100 ue(v)

pic_order_cnt_type = 0 //1 ue(v)

log2_max_pic_order_cnt_lsb_minus4 = 4 //00101 ue(v)

num_ref_frames = 1//010 ue(v) 

gaps_in_frame_num_value_allowed_flag = 0 //0

pic_width_in_mbs_minus1 = 23 // 000011000 ue(v)    (23+1)*16 = 384

pic_height_in_map_units_minus1 = 17 //000010010 ue(v)  (17+1)*16 = 288   

frame_mbs_only_flag = 1 //1

direct_8x8_inference_flag = 1 //1

frame_cropping_flag = 0 //0

vui_parameters_present_flag = 1 //1

以上分析部分和视频分析工具 header info SPS 比较发现结果是一致的。 

 

SPS部分讲完了,然后再看 PPS

00 00 00 01 68 EE 3C 80 

首先起始符 00 00 00 01

然后 68 即 nal_unit_type。

0x68的二进制是 0110 1000

则 forbidden_zero_bit(1bit) = 0;

nal_ref_idc(2bit) = 3;

nal_unit_type(5bit) = 8;即 PPS 类型。

 

然后再看 RBSP 部分

用视频分析工具得出的结果如下图:

详解 H.264 NALU语法结构_第12张图片

将 EE 3C 80 

转换成二进制:

1110 1110
0011 1100
1000 0000

 

 

 

pic_parameter_set_id = 0 //1 ue(v)
seq_parameter_set_id = 0 //1 ue(v)
entropy_coding_mode_flag = 1 //1
pic_order_present_flag = 0 //0
num_slice_groups_minus1 = 0 //1  ue(v)
num_ref_idx_l0_default_active_minus1 = 0 //1  ue(v)
num_ref_idx_l1_default_active_minus1 = 0 //1  ue(v)
weighted_pred_flag = 0 //0
weighted_bipred_idc = 0 //00
pic_init_qp_minus26 = 0 //1 ue(v)
pic_init_qs_minus26 = 0 //1 ue(v)
chroma_qp_index_offset = 0 //1 ue(v)
deblocking_filter_control_present_flag = 1 //1
constrained_intra_pred_flag = 0 // 0
redundant_pic_cnt_present_flag = 0 // 0

 

以上分析部分和视频分析工具 header info PPS 比较发现结果是一致的。 

上面部分 参看:一步一步解析H.264码流的NALU(SPS,PSS,IDR)  同理可能还有 slice 部分的分析,这里不做介绍了

 

想深入了解的

参看:H.264学习笔记之一(层次结构,NAL,SPS)

参看:H.264学习笔记之二(片及片头语法)

参看:H.264句法和语法总结 系列

记得一定要看哦,讲的是真好。还是贴出两张 NAL 句法,不然上面的讲的内容没一点解释,以后再看会有点懵。

详解 H.264 NALU语法结构_第13张图片详解 H.264 NALU语法结构_第14张图片

到此,NALU语法结构大致讲完了。

二、NAL 进阶

我们上面有提到对获取的 nal 去掉开始码之后进行 base64 编码,这里有个 base64 编码,它是怎么回事?

1、live 555 源码分析

查看 live555 源码 live/liveMedia/H264VideoRTPSink.cpp +109

 


   
   
   
   
  1. char const* H264VideoRTPSink::auxSDPLine() {
  2. // Generate a new "a=fmtp:" line each time, using our SPS and PPS (if we have them),
  3. // otherwise parameters from our framer source (in case they've changed since the last time that
  4. // we were called):
  5. H264or5VideoStreamFramer* framerSource = NULL;
  6. u_int8_t* vpsDummy = NULL; unsigned vpsDummySize = 0;
  7. u_int8_t* sps = fSPS; unsigned spsSize = fSPSSize;
  8. u_int8_t* pps = fPPS; unsigned ppsSize = fPPSSize;
  9. if (sps == NULL || pps == NULL) {
  10. // We need to get SPS and PPS from our framer source:
  11. if (fOurFragmenter == NULL) return NULL; // we don't yet have a fragmenter (and therefore not a source)
  12. framerSource = (H264or5VideoStreamFramer*)(fOurFragmenter->inputSource());
  13. if (framerSource == NULL) return NULL; // we don't yet have a source
  14. framerSource->getVPSandSPSandPPS(vpsDummy, vpsDummySize, sps, spsSize, pps, ppsSize);
  15. if (sps == NULL || pps == NULL) return NULL; // our source isn't ready
  16. }
  17. // Set up the "a=fmtp:" SDP line for this stream:
  18. u_int8_t* spsWEB = new u_int8_t[spsSize]; // "WEB" means "Without Emulation Bytes"
  19. unsigned spsWEBSize = removeH264or5EmulationBytes(spsWEB, spsSize, sps, spsSize);
  20. if (spsWEBSize < 4) { // Bad SPS size => assume our source isn't ready
  21. delete[] spsWEB;
  22. return NULL;
  23. }
  24. u_int32_t profileLevelId = (spsWEB[ 1]<< 16) | (spsWEB[ 2]<< 8) | spsWEB[ 3];
  25. delete[] spsWEB;
  26. char* sps_base64 = base64Encode(( char*)sps, spsSize);
  27. char* pps_base64 = base64Encode(( char*)pps, ppsSize);
  28. char const* fmtpFmt =
  29. "a=fmtp:%d packetization-mode=1"
  30. ";profile-level-id=%06X"
  31. ";sprop-parameter-sets=%s,%s\r\n";
  32. unsigned fmtpFmtSize = strlen(fmtpFmt)
  33. + 3 /* max char len */
  34. + 6 /* 3 bytes in hex */
  35. + strlen(sps_base64) + strlen(pps_base64);
  36. char* fmtp = new char[fmtpFmtSize];
  37. sprintf(fmtp, fmtpFmt,
  38. rtpPayloadType(),
  39. profileLevelId,
  40. sps_base64, pps_base64);
  41. delete[] sps_base64;
  42. delete[] pps_base64;
  43. delete[] fFmtpSDPLine; fFmtpSDPLine = fmtp;
  44. return fFmtpSDPLine;
  45. }

跳转查看 base64Encode

 

 


   
   
   
   
  1. char* base64Encode(char const* origSigned, unsigned origLength) {
  2. unsigned char const* orig = ( unsigned char const*)origSigned; // in case any input bytes have the MSB set
  3. if (orig == NULL) return NULL;
  4. unsigned const numOrig24BitValues = origLength/ 3;
  5. Boolean havePadding = origLength > numOrig24BitValues* 3;
  6. Boolean havePadding2 = origLength == numOrig24BitValues* 3 + 2;
  7. unsigned const numResultBytes = 4*(numOrig24BitValues + havePadding);
  8. char* result = new char[numResultBytes+ 1]; // allow for trailing '\0'
  9. // Map each full group of 3 input bytes into 4 output base-64 characters:
  10. unsigned i;
  11. for (i = 0; i < numOrig24BitValues; ++i) {
  12. result[ 4*i+ 0] = base64Char[(orig[ 3*i]>> 2)& 0x3F];
  13. result[ 4*i+ 1] = base64Char[(((orig[ 3*i]& 0x3)<< 4) | (orig[ 3*i+ 1]>> 4))& 0x3F];
  14. result[ 4*i+ 2] = base64Char[((orig[ 3*i+ 1]<< 2) | (orig[ 3*i+ 2]>> 6))& 0x3F];
  15. result[ 4*i+ 3] = base64Char[orig[ 3*i+ 2]& 0x3F];
  16. }
  17. // Now, take padding into account. (Note: i == numOrig24BitValues)
  18. if (havePadding) {
  19. result[ 4*i+ 0] = base64Char[(orig[ 3*i]>> 2)& 0x3F];
  20. if (havePadding2) {
  21. result[ 4*i+ 1] = base64Char[(((orig[ 3*i]& 0x3)<< 4) | (orig[ 3*i+ 1]>> 4))& 0x3F];
  22. result[ 4*i+ 2] = base64Char[(orig[ 3*i+ 1]<< 2)& 0x3F];
  23. } else {
  24. result[ 4*i+ 1] = base64Char[((orig[ 3*i]& 0x3)<< 4)& 0x3F];
  25. result[ 4*i+ 2] = '=';
  26. }
  27. result[ 4*i+ 3] = '=';
  28. }
  29. result[numResultBytes] = '\0';
  30. return result;
  31. }

2、从 RTSP 协议 SDP 数据中获得二进制的 SPS、PPS

 

我不会告诉你,上面base64 编码什么的我没看懂...

但是不妨碍,有一个工具: Base64编码/解码器 在线解码 可以base64编解码。

我们试一下:

     详解 H.264 NALU语法结构_第15张图片

详解 H.264 NALU语法结构_第16张图片

你用也可以用通过程序来实现 base64编解码。

参看:从RTSP协议SDP数据中获得二进制的SPS、PPS

我们已经知道,在RTSP协议中DESCRIBE请求回复内容的SDP部分中,如果服务端的直播流的视频是H264的编码格式的话,那么在SDP中会将H264的sps、pps信息通过Base64编码成字符串发送给客户端(也就是解码器端),sps称为序列参数集,pps称为图形参数集。这两个参数中包含了初始化H.264解码器所需要的信息参数,包括编码所用的profile,level,图像的宽和高,deblock滤波器等。这样解码器就可以在DESCRIBE阶段,利用这些参数初始化解码器的设置了。那么如何将SDP中的字符串还原成sps、pps的二进制数据呢。下面的部分代码是从live555项目中取出来的,可以作为小功能独立使用,如果大家有用的着,可以直接拿去使用在项目中:

 


   
   
   
   
  1. //main.cpp的内容
  2. #include
  3. #include "Base64.h"
  4. int main()
  5. {
  6. /*
  7. RTSP 响应的SDP的内容中sprop-parameter-sets键值:
  8. sprop-parameter-sets=Z2QAKq2wpDBSAgFxQWKQPQRWFIYKQEAuKCxSB6CKwpDBSAgFxQWKQPQRTDoUKQNC4oJHMGIemHQoUgaFxQSOYMQ9MOhQpA0LigkcwYh6xEQmIVilsQRWUURJsogxOU4QITKUIEVlCCTYQVhBMJQhMIjGggWQJFaIGBJZBAaEnaMIDwsSWQQKCwsrRBQYOWQweO0YEBZASNAogszlAUAW7/wcFBwMQAABdwAAr8g4AAADAL68IAAAdzWU//+MAAADAF9eEAAAO5rKf//CgA==,aP48sA==;
  9. 其中逗号前面的内容是sps的二进制数据被base64之后的结果
  10. 而逗号后面的内容(不要分号,分号是sdp中键值对的分隔符),是pps的内容
  11. 使用live555中的base64Decode函数分别对这两部分进行反base64解码得到的二进制数据就是h264中的sps pps 的二进制内容
  12. 分别是以67 和 68 开头
  13. */
  14. char * sps_sdp = "Z2QAKq2wpDBSAgFxQWKQPQRWFIYKQEAuKCxSB6CKwpDBSAgFxQWKQPQRTDoUKQNC4oJHMGIemHQoUgaFxQSOYMQ9MOhQpA0LigkcwYh6xEQmIVilsQRWUURJsogxOU4QITKUIEVlCCTYQVhBMJQhMIjGggWQJFaIGBJZBAaEnaMIDwsSWQQKCwsrRBQYOWQweO0YEBZASNAogszlAUAW7/wcFBwMQAABdwAAr8g4AAADAL68IAAAdzWU//+MAAADAF9eEAAAO5rKf//CgA==";
  15. char * pps_sdp = "aP48sA==";
  16. unsigned int result_size= 0;
  17. unsigned char * p = base64Decode(sps_sdp,result_size);
  18. for( int i = 0;i
  19. {
  20. printf( "%02X ",p[i]);
  21. if((i+ 1)% 16== 0)
  22. {
  23. printf( "\n");
  24. }
  25. }
  26. printf( "\n\n\n");
  27. p = base64Decode(pps_sdp,result_size);
  28. for( int i = 0;i
  29. {
  30. printf( "%02X ",p[i]);
  31. if((i+ 1)% 16== 0)
  32. {
  33. printf( "\n");
  34. }
  35. }
  36. printf( "\n");
  37. return 0 ;
  38. }
  39. /*
  40. 程序的解码输出如下,得到的分别是3500的sps和pps内容:
  41. 67 64 00 2A AD B0 A4 30 52 02 01 71 41 62 90 3D
  42. 04 56 14 86 0A 40 40 2E 28 2C 52 07 A0 8A C2 90
  43. C1 48 08 05 C5 05 8A 40 F4 11 4C 3A 14 29 03 42
  44. E2 82 47 30 62 1E 98 74 28 52 06 85 C5 04 8E 60
  45. C4 3D 30 E8 50 A4 0D 0B 8A 09 1C C1 88 7A C4 44
  46. 26 21 58 A5 B1 04 56 51 44 49 B2 88 31 39 4E 10
  47. 21 32 94 20 45 65 08 24 D8 41 58 41 30 94 21 30
  48. 88 C6 82 05 90 24 56 88 18 12 59 04 06 84 9D A3
  49. 08 0F 0B 12 59 04 0A 0B 0B 2B 44 14 18 39 64 30
  50. 78 ED 18 10 16 40 48 D0 28 82 CC E5 01 40 16 EF
  51. FC 1C 14 1C 0C 40 00 01 77 00 00 AF C8 38 00 00
  52. 03 00 BE BC 20 00 00 77 35 94 FF FF 8C 00 00 03
  53. 00 5F 5E 10 00 00 3B 9A CA 7F FF C2 80
  54. 68 FE 3C B0
  55. */

其中用到的一个主要函数 base64Decode 的实现如下:

 

 


   
   
   
   
  1. #include "Base64.h"
  2. #include "strDup.h"
  3. #include
  4. static char base64DecodeTable[ 256];
  5. static void initBase64DecodeTable() {
  6. int i;
  7. for (i = 0; i < 256; ++i) base64DecodeTable[i] = ( char) 0x80;
  8. // default value: invalid
  9. for (i = 'A'; i <= 'Z'; ++i) base64DecodeTable[i] = 0 + (i - 'A');
  10. for (i = 'a'; i <= 'z'; ++i) base64DecodeTable[i] = 26 + (i - 'a');
  11. for (i = '0'; i <= '9'; ++i) base64DecodeTable[i] = 52 + (i - '0');
  12. base64DecodeTable[( unsigned char) '+'] = 62;
  13. base64DecodeTable[( unsigned char) '/'] = 63;
  14. base64DecodeTable[( unsigned char) '='] = 0;
  15. }
  16. unsigned char* base64Decode(char const* in, unsigned& resultSize,
  17. Boolean trimTrailingZeros) {
  18. static Boolean haveInitedBase64DecodeTable = False;
  19. if (!haveInitedBase64DecodeTable) {
  20. initBase64DecodeTable();
  21. haveInitedBase64DecodeTable = True;
  22. }
  23. unsigned char* out = ( unsigned char*)strDupSize(in); // ensures we have enough space
  24. int k = 0;
  25. int const jMax = strlen(in) - 3;
  26. // in case "in" is not a multiple of 4 bytes (although it should be)
  27. for ( int j = 0; j < jMax; j += 4) {
  28. char inTmp[ 4], outTmp[ 4];
  29. for ( int i = 0; i < 4; ++i) {
  30. inTmp[i] = in[i+j];
  31. outTmp[i] = base64DecodeTable[( unsigned char)inTmp[i]];
  32. if ((outTmp[i]& 0x80) != 0) outTmp[i] = 0; // pretend the input was 'A'
  33. }
  34. out[k++] = (outTmp[ 0]<< 2) | (outTmp[ 1]>> 4);
  35. out[k++] = (outTmp[ 1]<< 4) | (outTmp[ 2]>> 2);
  36. out[k++] = (outTmp[ 2]<< 6) | outTmp[ 3];
  37. }
  38. if (trimTrailingZeros) {
  39. while (k > 0 && out[k -1] == '\0') --k;
  40. }
  41. resultSize = k;
  42. unsigned char* result = new unsigned char[resultSize];
  43. memmove(result, out, resultSize);
  44. delete[] out;
  45. return result;
  46. }
  47. static const char base64Char[] =
  48. "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
  49. char* base64Encode(char const* origSigned, unsigned origLength) {
  50. unsigned char const* orig = ( unsigned char const*)origSigned; // in case any input bytes have the MSB set
  51. if (orig == NULL) return NULL;
  52. unsigned const numOrig24BitValues = origLength/ 3;
  53. Boolean havePadding = origLength > numOrig24BitValues* 3;
  54. Boolean havePadding2 = origLength == numOrig24BitValues* 3 + 2;
  55. unsigned const numResultBytes = 4*(numOrig24BitValues + havePadding);
  56. char* result = new char[numResultBytes+ 1]; // allow for trailing '\0'
  57. // Map each full group of 3 input bytes into 4 output base-64 characters:
  58. unsigned i;
  59. for (i = 0; i < numOrig24BitValues; ++i) {
  60. result[ 4*i+ 0] = base64Char[(orig[ 3*i]>> 2)& 0x3F];
  61. result[ 4*i+ 1] = base64Char[(((orig[ 3*i]& 0x3)<< 4) | (orig[ 3*i+ 1]>> 4))& 0x3F];
  62. result[ 4*i+ 2] = base64Char[((orig[ 3*i+ 1]<< 2) | (orig[ 3*i+ 2]>> 6))& 0x3F];
  63. result[ 4*i+ 3] = base64Char[orig[ 3*i+ 2]& 0x3F];
  64. }
  65. // Now, take padding into account. (Note: i == numOrig24BitValues)
  66. if (havePadding) {
  67. result[ 4*i+ 0] = base64Char[(orig[ 3*i]>> 2)& 0x3F];
  68. if (havePadding2) {
  69. result[ 4*i+ 1] = base64Char[(((orig[ 3*i]& 0x3)<< 4) | (orig[ 3*i+ 1]>> 4))& 0x3F];
  70. result[ 4*i+ 2] = base64Char[(orig[ 3*i+ 1]<< 2)& 0x3F];
  71. } else {
  72. result[ 4*i+ 1] = base64Char[((orig[ 3*i]& 0x3)<< 4)& 0x3F];
  73. result[ 4*i+ 2] = '=';
  74. }
  75. result[ 4*i+ 3] = '=';
  76. }
  77. result[numResultBytes] = '\0';
  78. return result;
  79. }

工程下载:demo_decoder_sdp

三、相关的工程

我之前讲过一个相关的工程,参看:DM368开发 -- 编码并实时播放

首先从 fwrite(Buffer_getUserPtr(hOutBuf),Buffer_getNumBytesUsed(hOutBuf), 1, outFile) != 1) 讲起。

(1)找到原来将获取帧保存为h.264文件部分,然后注释掉。

详解 H.264 NALU语法结构_第17张图片

(2)查找起始符 00 00 00 01

详解 H.264 NALU语法结构_第18张图片

(3)然后是 OnH264FrameDataOK 检测H264帧数据

详解 H.264 NALU语法结构_第19张图片  

详解 H.264 NALU语法结构_第20张图片

详解 H.264 NALU语法结构_第21张图片

到此结束!!下班啦...  这个程序其实是有问题的,明天再研究一下吧。

 

再者可参看:LIVE555再学习 -- testRTSPClient 实例    这个在此不讲了。

四、H.264 学习资源

参看:视频编解码(h.264)的一些资源

参看:H.264 学习建议

你可能感兴趣的:(H.264)