H.264 CODEC

摘自: H.264_MPEG-4 Part 10 White Paper.pdf

In common with earlier standards (such as MPEG1, MPEG2 and MPEG4), the H.264 draft standard does not explicitly define a CODEC (enCOder / DECoder pair). Rather, the standard defines the syntax of an encoded video bitstream together with the method of decoding this bitstream. In practice, however, a compliant encoder and decoder are likely to include the functional elements shown in Figure 2-1and Figure 2-2. Whilst the functions shown in these Figures are likely to be necessary for compliance, there is scope for considerable variation in the structure of the CODEC. The basic functional elements (prediction, transform, quantization, entropy encoding) are little different from previous standards (MPEG1, MPEG2, MPEG4, H.261, H.263); the important changes in H.264 occur in the details of each functional element.

The Encoder (Figure 2-1) includes two dataflow paths, a “forward” path (left to right, shown in blue) and a “reconstruction” path (right to left, shown in magenta). The dataflow path in the Decoder (Figure 2-2) is shown from right to left to illustrate the similarities between Encoder and Decoder.

Figure 2-1 AVC Encoder

Figure 2-2 AVC Decoder

2.1  Encoder (forward path)
    An input frame Fnis presented for encoding. The frame is processed in units of a macroblock (corresponding to 16x16 pixels in the original image). Each macroblock is encoded in intraor intermode. In either case, a prediction macroblock P is formed based on a reconstructed frame. In Intra mode, P is formed from samples in the current frame n that have previously encoded, decoded and reconstructed (uF’n in the Figures; note that the unfiltered samples are used to form P). In Inter mode, P is formed by motion-compensated prediction from one or more reference frame(s). In the Figures, the reference frame is shown as the previous encoded frame F’n-1; however, the predicton for each macroblock may be formed from one or two past or future frames (in time order) that have already been encoded and reconstructed.

The prediction P is subtracted from the current macroblock to produce a residual or difference macroblock Dn. This is transformed (using a block transform) and quantized to give X, a set of quantized transform coefficients. These coefficients are re-ordered and entropy encoded. The entropy encoded coefficients, together with side information required to decode the macroblock (such as the macroblock prediction mode, quantizer step size, motion vector information describing how the macroblock was motion-compensated, etc) form the compressed bitstream. This is passed to a Network Abstraction Layer (NAL) for transmission or storage.

2.2  Encoder (reconstruction path)

The quantized macroblock coefficients X are decoded in order to reconstruct a frame for encoding of further macroblocks. The coefficients X are re-scaled (Q-1) and inverse transformed (T-1) to produce a difference macroblock Dn’. This is not identical to the original difference macroblock Dn; the quantization process introduces losses and so Dn’ is a distorted versionof Dn.

The prediction macroblock P is added to Dn’ to create a reconstructed macroblock uF’n(a distorted version of the original macroblock). A filter is applied to reduce the effects of blocking distortion and reconstructed reference frame is created from a series of macroblocks F’n.

2.3  Decoder
    The decoder receives a compressed bitstream from the NAL. The data elements are entropy decoded and reordered to produce a set of quantized coefficients X. These are rescaled and inverse transformed to give Dn’ (this identical to the Dn’ shown in the Encoder). Using the header information decoded from the bitstream, the decoder creates a prediction macroblock P, identical to the original prediction P formed in the encoder. P is added to Dn’ to produce uF’n which this is filtered to create the decoded macroblock F’n.

It should be clear from the Figures and from the discussion above that the purpose of the reconstruction path in the encoder is to ensure that both encoder and decoder use identical reference frames to create the prediction P. If this is not the case, then the predictions P in encoder and decoder will not be identical, leading to an increasing error or “drift” between the encoder and decoder.

时间: 2024-10-13 22:00:36

H.264 CODEC的相关文章

H.264 / MPEG-4 Part 10 White Paper-翻译

1. Introduction Broadcast(广播) television and home entertainment(娱乐) have been revolutionised(彻底改变) by the advent(出现) of digital TV andDVD-video.(--广播电视和家庭娱乐方式被彻底改变了在数字电视和DVD-Video出现之后--) These applications and many more were made possible by the stan

H.264视频的RTP荷载格式

Status of This Memo This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Stand

(转)H.264中的NAL技术

NAL技术 1.NAL概述NAL全称Network Abstract Layer, 即网络抽象层.在H.264/AVC视频编码标准中,整个系统框架被分为了两个层面:视频编码层面(VCL)和网络抽象层面(NAL).其中,前者负责有效表示视频数据的内容,而后者则负责格式化数据并提供头信息,以保证数据适合各种信道和存储介质上的传输.现实中的传输系统是多样化的,其可靠性,服务质量,封装方式等特征各不相同,NAL这一概念的提出提供了一个视频编码器和传输系统的友好接口,使得编码后的视频数据能够有效地在各种不

H.264解码过程剖析-4

x264开源工程实现H.264的视频编码,但没有提供对应的解码器.ffmpeg开源多媒体编解码集合汇集了市面上几乎所有媒体格式的编解码的源代码.其中的H264.c就是一个能正常解码x264编码码流的独立的源文件,其使用步骤也与上述的编码或解码CODEC应用案例基本相同.这一节通过自顶向下的方式,讲述H264.c如何实现H.264视频解码过程. H264.c源文件有几千行,代码量庞大,很不便于浏览.分析和移植.同时该文件还依赖其他源文件,组织结构较复杂,实现平台由于不是基于Windows的VC++

FFmpeg的H.264解码器源代码简单分析:解析器(Parser)部分

本文继续分析FFmpeg中libavcodec的H.264解码器(H.264 Decoder).上篇文章概述了FFmpeg中H.264解码器的结构:从这篇文章开始,具体研究H.264解码器的源代码.本文分析H.264解码器中解析器(Parser)部分的源代码.这部分的代码用于分割H.264的NALU,并且解析SPS.PPS.SEI等信息.解析H.264码流(对应AVCodecParser结构体中的函数)和解码H.264码流(对应AVCodec结构体中的函数)的时候都会调用该部分的代码完成相应的功

H.264开源解码器评测

转自:http://wmnmtm.blog.163.com/blog/static/38245714201142883032575/ 要播放HDTV,就首先要正确地解开封装,然后进行视频音频解码.所以我们需要分离器,视频解码器和音频解码器,俗称hdtv的“三件套”,又统称滤镜. H264的分离器: 常见的有Gabest MP4分离器,就是MP4splitter,也是Gabest编写的,Halli的分离器和NDigital分离器等. H264的视频解码器: CoreAVC的H264视频解码器Cor

视频编解码技术详解(H.264、MPEG-4)

一.视频编解码概述 1. 应用场景 视频编码的目的就是压缩视频的占用空间,提高存储和传输的效率,在获得有效的压缩效果的同时,使得压缩过程引起的失真最小.视频压缩算法是通过去除时间.空间的冗余来实现的.通过去除不同类型的冗余,可以明显的压缩数据,代价就是一部分信息失真,可以通过熵编码器(如哈夫曼编码等)进行编码可以获得更高的压缩比.目前主流的图像/视频压缩标准为:JPEG,MPEG,H26X等标准. 2. 主流视频编码标准简介 MPEG-4和H.264(也叫AVC)是目前较为主流的编码标准.每个标

FFmpeg的H.264解码器源代码简单分析:解码器主干部分

本文分析FFmpeg的H.264解码器的主干部分."主干部分"是相对于"熵解码"."宏块解码"."环路滤波"这些细节部分而言的.它包含了H.264解码器直到decode_slice()前面的函数调用关系(decode_slice()后面就是H.264解码器的细节部分,主要包含了"熵解码"."宏块解码"."环路滤波"3个部分). 函数调用关系图 解码器主干部分的源代码在

H.264码流打包分析

H.264码流打包分析 SODB 数据比特串-->最原始的编码数据 RBSP 原始字节序列载荷-->在SODB的后面填加了结尾比特(RBSP trailing bits 一个bit"1")若干比特"0",以便字节对齐. EBSP 扩展字节序列载荷-- >在RBSP基础上填加了仿校验字节(0X03)它的原因是: 在NALU加到Annexb上时,需要填加每组NALU之前的开始码 StartCodePrefix,如果该NALU对应的slice为一帧的开始