H264帧边界识别简介.docVIP

H264 帧边界识别简介 在 Symbian 平台上实现 H264 的 RTSP 流的播放原文： /asddg67/archive/2009/03/23/4017251. aspx 在 Symbian 平台上实现 H264 的 RTSP 流的播放 /linzhiji/archive/2010/02/24/5323622.as px H264 的数据读取最关键的地方就是如何识别一帧，因为 ffmpeg 的 H264 解码是按照一帧一帧解码的， 如果送去解码 的数据不是完整的一帧可能导致解码失败或者产生马赛克 的情况。 以下是我在一个文档中摘取关于帧边界识别的一 段，可以方便的解决相关的问题： 帧边界识别简介 H.264 将 构成一帧图像所有 nalu 的集合称为一个 AU ，帧边界识别实 际上就是识别 AU 。因为 H.264 取消帧级语法，所以无法简 单地从码流中获取 AU 。解码器只有在解码的过程中，通过 某些语法元素的组合才能判断一帧图像是否结束。一般来说， 解码器必须在完成一帧新图像的第一个 slice_header 语法 解码之后，才能知道前一帧图像已经结束。因此，最严谨的 AU  识别步骤如下：步骤  1 对码流实施“去  03  处理”。步骤 2 解析  nalu  语法。步骤  3 解析  slice_header  语法。步骤  4 综合判断前后两个  nalu  以及对应的  slice_header  中的若干 个语法元素，看是否发生变化。如果发生变化，则说明这两 个 nalu 属于不同的帧，否则说明这两个 nalu 属于同一帧。 结束显然，在解码前完成上述的AU 识别消耗许多 CPU 资源，因此不推荐使用 AU 方式解码为了提供一种简单的 AU 识别方案， H.264 规定一种类型为 09 的 nalu ，即编码器在每次完成一个 AU 编码后，在码流中插入一个类型为 09 的 nalu ，在这个前提下，解码器只需要从码流中搜索类型为 09 的 nalu 即可获得一个 AU 。H.264 并不强制要求编码器 插入类型为 09 的 nalu ，因此并非所有的码流都具备这种特 征。对于编码器和解码器协同工作的应用场景，建议让编码 器插入类型为 09 的 nalu ，这样可以降低解码器识别 AU 的 代价。为了降低解码器在解码前识别 AU 的代价，本文提出 一种高效的 AU 识别方法， 其主要思路是利用一帧图像的第 一个 slice_header 中的语法元素 first_mb_in_slice 一般等 于 0 这个特征（对于包含 ASO 或者 FMO 特性的码流，这个条件不一定成立） 。 view plaincopy to clipboardprint? typedef struct ParseContext{ unsigned int FrameStartFound; unsigned int iFrameLength; } ParseContext; signed int DecLoadAU(unsigned char* pStream, unsigned int iStreamLen, ParseContext *pc) { unsigned int i; unsigned int state = 0xffffffff; if( NULL == pStream ) { return -1; } for( i = 0; i lt; iStreamLen; i++) { /* 查找 nal 类型为 1 和 5 的 nal 头 */ if( (state amp; 0xFFFFFF1F) == 0x101 || (state amp; 0xFFFFFF1F) == 0x105 ) { if (i gt;= iStreamLen) /* 到达 Buffer 尾部， 退出查找循环 */ { break; }if( pStream[i] amp; 0x80) /* 查找 first_mb_in_slice 为 0 的 slice 头确定 一幅图像的开始 */ { if(pc-gt;FrameStartFound) /* 查找 到下一幅图像的开始就可以确 定图像 的起始和结束 */ { pc-gt;iFrameLength = i - 4; pc-gt;FrameStartFound = 0; state = 0xffffffff; return 0; /* 找到一幅图像的边 界返回 0 */ } else { pc-gt;FrameStartFound = 1; } } } if (i lt; iStreamLen) { state = (state lt;lt