AnnexB格式

AnnexB格式NALU数据开始前缀00000001或000001此处注意为甚么是4bit或3bit后面有描述针对H320电话会议RTP格式NALU数据20个字节的类似的并不符合RTP协议的RTP头针对IP网络的RTP打包方式H264协议只规定了字节流格式没有规定RTP格式可能也是因为这个原因JM的RTP格式没有被用到任何场合场合中成为了摆设下图中的RTP格式是h264乐园的firstime从JM86中分析出来的实际包交换网络中必须按照RFC3984将NALU数据封装为RTP包而不能使用JM的RTP格式下面引自QUESTIONMARK的博客下面说明3字节起始码和4字节起始码以下和leadingzero8bitstrailingzero8bits已无关系忘掉ifnextbits240x000001zerobytef8startcodeprefixone3bytesf24根据B1节可以看到所谓的4字节起始码是zerobyte3字节起始码那么看zerobyte的说明就可以明白zerobyte什么时候出现也就能明白什么时候出现4字节起始码1SPSPPSnalu是4字节起始码2AccessUnit的首个nalu是4字节起始码参见74123这里举个例子说明用JM可以生成这样一段码流不要使用JM86它在这部分与标准不符这个码流可以见本楼附件SPS4字节头PPS4字节头SEI4字节头I0slice04字节头I0slice13字节头P1slice04字节头P1slice13字节头P2slice04字节头P2slice13字节头I0slice0是序列第一帧I帧的第一个slice是当前AccessUnit的首个nalu所以是4字节头而I0slice1表示第一帧的第二个slice所以是3字节头P1slice0P1slice1同理总结1附录B字节流在一个bytestreamnalunit的前后可能出现若干个0x00仅用作填充之用这个不常见24字节头只出现在SPSPPS和74123规定的AccessUnit的首个nalu其余情况都是3字节头一共有两种起始码3字节的0x000001和4字节的0x000000013字节的0x000001只有一种场合下使用就是一个完整的帧被编为多个slice的时候包含这些slice的nalu使用3字节起始码其余场合都是4字节的NAL层处理简析20100609160034javascript转载标签httpblogsinacomcnsarticlelist114366063711html分类H264javascripthttpunisinacomcncphptblogampknalB2E3amptsbpostampstypetagnal层httpunisinacomcncphptblogampknalamptsbpostampstypetagnalhttpunisinacomcncphptblogampkD4D3CCB8amptsbpostampstypetag杂谈NALNetworkAbstractionLayer基本上可分两种1以有序字节流方式传送的针对H320的2针对IP网络的RTP打包方式的NAL作用specifiedtoformatthatdataandprovideheaderinformationinamannerappropriateforconveyanceonavarietyofcommunicationchannelsorstoragemediaNAL的处理过程基本上分为两步1将VCL层输出的SODB封装成nalunitNalunit是一个通用封装格式可以适用于有序字节流方式和IP包交换方式2针对不同的传送网络电路交换包交换将nalunit封装成针对不同网络的封装格式第一步的具体过程VCL层输出的比特流SODBStringOfDataBits到nalunit之间经过了以下三步处理1SODB字节对齐处理后封装成RBSPRawByteSequencePayload2为防止RBSP的字节流与有序字节流传送方式下的SCPstartcodeprefixone3bytes0x000001出现字节竞争情形循环检测RBSP前三个字节在出现字节竞争时在第三字节前加入emulationpreventionthreebyte0x03具体方法nalunitNumBytesInNALunitforbiddenzerobitnalrefidcnalunittypeNumBytesInRBSP0fori1iifi2rbspbyteNumBytesInRBSPrbspbyteNumBytesInRBSPi2emulationpreventionthreebyteelserbspbyteNumBytesInRBSP3防字节竞争处理后的RBSP再加一个字节的headerforbiddenzerobitnalrefidcnalunittype封装成nalunit第二步的具体过程case1有序字节流的封装bytestreamnalunitNumBytesInNALunitwhilenextbits240x000001zerobyteifmoredatainbytestreamstartcodeprefixone3bytesnalunitNumBytesInNALunitCase2IP网络的RTP打包封装IDR刷新帧与I帧的一些知识点20100608203840javascript转载标签httpblogsinacomcnsarticlelist114366063711html分类H264javascripthttpunisinacomcncphptblogampkD4D3CCB8amptsbpostampstypetag杂谈IDR帧属于I帧但是I帧不一定是IDR帧解码器收到IDR帧时将驱动器参数块DPB清空而I帧不会我自己理解为即把参考帧列表刷新从新更新就是不再参考idr前面的帧由此可见在编码器端每发一个IDR就相应地发一个nal当然在现在的编码中为了取得更高的图像质量在一个视频文件中有好多个IDR帧这些IDR帧把视频文件分成了片但是每片中第一个帧是IDR而且仅此一个例如存在这样一段视频码流IDRBBPBBP帧号1234567对IDR帧的处理与I帧的处理相同1进行帧内预测决定所采用的帧内预测模式2像素值减去预测值得到残差3对残差进行变换和量化4变长编码和算术编码5重构图像并滤波得到的图像作为其它帧的参考帧这里要提一下当编码器处理完IDR帧遇到B帧时编码期先把其放入缓存器中存放起来直接对P进行编码即编码器中编码的实际顺序是IDRPBBPBB即1423756有用的来了IDRinstantaneousdecodingrefreshIDRpictureAcodedpictureinwhichallslicesareIorSIslicesthatcausesthedecodingprocesstomarkallreferencepicturesasunusedforreferenceimmediatelyafterdecodingtheIDRpictureAfterthedecodingofanIDRpictureallfollowingcodedpicturesindecodingordercanbedecodedwithoutinterpredictionfromanypicturedecodedpriortotheIDRpictureThefirstpictureofeachcodedvideosequenceisanIDRpicture也就是说IDR的出现其实是相当于向解码器发出了一个清理referencebuffer的信号吧上面说前于这一帧的所有已编码帧不能为inter做参考帧了还有因为264采用了多帧预测就有可能在displayorder下I帧后的P会参考I帧前的帧这样在randomaccess时如果只找I帧随后的帧的参考帧可能unavailableIDR就是这样一种特殊的I帧把它定义为确保后面的P一定不参考其前面的帧可以放心地randomaccess多参考帧情况下转SODBRBSPEBSP的来龙去脉20100607212239javascript转载标签httpunisinacomcncphptblogampkh264amptsbpostampstypetagh264httpunisinacomcncphptblogampkC6F0CABCC2EBamptsbpostampstypetag起始码httpunisinacomcncphptblogampkC6F0CABCC2EBBEBAD5F9amptsbpostampstypetag起始码竞争httpunisinacomcncphptblogampkCAFDBEDDC1F7BDE1B9B9amptsbpostampstypetag数据流结构httpunisinacomcncphptblogampkD4D3CCB8amptsbpostampstypetag杂谈httpblogsinacomcnsarticlelist114366063711html分类H264H264起始码在网络传输h264数据时一个UDP包就是一个NALU解码器可以很方便的检测出NAL分界和解码但是如果编码数据存储为一个文件原来的解码器将无法从数据流中分别出每个NAL的起始位置和终止位置为此h264用起始码来解决这一问题H264编码时在每个NAL前添加起始码0x000001解码器在码流中检测到起始码当前javascriptNAL结束为了防止NAL内部出现0x000001的数据h264又提出防止竞争emulationprevention机制在编码完一个NAL时如果检测出有连续两个0x00字节就在后面插入一个0x03当解码器在NAL内部检测到0x000003的数据就把0x03抛弃恢复原始数据0x0000000x000003000x0000010x000003010x0000020x000003020x0000030x00000303附上h264解码nalu中检测起始码的算法流程forifnext24bitsare0x000001startCodeFoundtruebreakelseflush8bitsforiftruestartCodeFoundstartcodefoundFlushthestartcodefoundflush24bitsNownavigateuptonextstartcodeandputtheinbetweenstuffinthenalstructureforgetnext24bitsampcheckifitequalsto0x000001iffalsenext24bits000001searchforpattern0x000000checkifnext24bitsare0x000000iffalseresultcopythebyteintothebuffercopyonebytetotheNalunitelsebreakelsebreakfor2MPEG4起始码MPEG4的特色是VOP没有NALU的概念仍使用startcode对每帧进行分界MPEG4的起始码是0x000001另外MPEG4中很多起始码也很有用比如videoobjectsequencestartcode0x000001B0表示一个视频对象序列的开始VOstartcode0x000001B6表示一个VOP的开始0x000001B6之后的两位是00表示Iframe01表示Pframe10表示BframeSODB数据比特串最原始的编码数据RBSP原始字节序列载荷在SODB的后面填加了结尾比特RBSPtrailingbits一个bit1若干