精华内容
下载资源
问答
  • Mac OS使用FFmpeg进行视频H264,H265编码
    千次阅读
    2020-03-29 17:08:46

    一.概述

    本文将在Mac os系统上使用FFmpeg进行音视频的H264,H265编码。
    使用FFmpeg版本为4.2。

    二、编码器初始化

    有两点需要注意的是:
    1.设置pCodecContext->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;的目的是可以通过pCodecContext->extradatapCodecContext->extradata_size提取到返回PPS,SPS,VPS数据,适用于直播场景,注释中也写的很清楚Place global headers in extradata instead of every keyframe.

    如果没有设置则会在AVPacket.data中和其他数据一起返回,适用于直接写入文件。

    2.设置pPacket.flags |= AV_PKT_FLAG_KEY的目的可以在编码后的AVPacket中识别出是否为关键帧。

        int ret;
        enum AVCodecID codecID = AV_CODEC_ID_H264;
        if (!kUseH264Encode) {
            codecID = AV_CODEC_ID_HEVC;
        }
        
        pCodec = avcodec_find_encoder(codecID);
        
        pCodecContext = avcodec_alloc_context3(pCodec);
        pCodecContext->codec_type = AVMEDIA_TYPE_VIDEO;
        pCodecContext->pix_fmt = AV_PIX_FMT_YUV420P;
        pCodecContext->width = 1280;
        pCodecContext->height = 720;
        pCodecContext->time_base.num = 1;
        pCodecContext->time_base.den = 25;
        pCodecContext->bit_rate = 1000 * 1000;
        pCodecContext->qmin = 10;
        pCodecContext->qmax = 51;
        pCodecContext->gop_size = 25;
        pCodecContext->max_b_frames = 0;
       // pCodecContext->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
        
        AVDictionary *param = NULL;
        if (kUseH264Encode) {
            av_dict_set(&param, "preset", "slow", 0);
            av_dict_set(&param, "tune", "zerolatency", 0);
        }else{
            av_dict_set(&param, "preset", "ultrafast", 0);
            av_dict_set(&param, "tune", "zero-latency", 0);
        }
    
        if (avcodec_open2(pCodecContext, pCodec, &param)<0) {
            return;
        }
        
        pFrame = av_frame_alloc();
        pFrame->width = pCodecContext->width;
        pFrame->height = pCodecContext->height;
        pFrame->format = pCodecContext->pix_fmt;
        ret = av_frame_get_buffer(pFrame, 0);
        if (ret < 0) {
            printf("ret == %s\n", av_err2str(ret));
        }
        //初始化avpacket
        av_init_packet(&pPacket);
        pPacket.flags |= AV_PKT_FLAG_KEY;
    

    三、编码

    在Mac OS系统或者iOS系统中,采集到的一般是CMSampleBufferRef对象,需要先从中拿到CVPixelBufferRef对象,再从其中提取YUV数据。而此处的YUV格式,是一种two-plane模式,即Y和UV分为两个Plane,但是UV(CbCr)为交错存储,而不是分为三个plane,需要最终转换为420P格式,即YYYYUV

    // 锁定imageBuffer内存地址开始进行编码
            if (CVPixelBufferLockBaseAddress(pixelBuffer, 0) == kCVReturnSuccess) {
                //获取Y分量的地址
                UInt8 *bufferPtr = (UInt8 *)CVPixelBufferGetBaseAddressOfPlane(pixelBuffer,0);
                //获取UV分量的地址
                UInt8 *bufferPtr1 = (UInt8 *)CVPixelBufferGetBaseAddressOfPlane(pixelBuffer,1);
                //根据像素获取图片的真实宽度&高度
                size_t width = CVPixelBufferGetWidth(pixelBuffer);
                size_t height = CVPixelBufferGetHeight(pixelBuffer);
                // 获取Y分量长度
                size_t bytesrow0 = CVPixelBufferGetBytesPerRowOfPlane(pixelBuffer,0);
                size_t bytesrow1  = CVPixelBufferGetBytesPerRowOfPlane(pixelBuffer,1);
                UInt8 *yuv420_data = (UInt8 *)malloc(width * height * 3 / 2);
                
                //将NV12数据转成YUV420P(I420)数据
                UInt8 *pY = bufferPtr;
                UInt8 *pUV = bufferPtr1;
                UInt8 *pU = yuv420_data + width * height;
                UInt8 *pV = pU + width * height / 4;
                for(int i =0;i<height;i++)
                {
                    memcpy(yuv420_data+i*width,pY+i*bytesrow0,width);
                }
                for(int j = 0;j<height/2;j++)
                {
                    for(int i =0;i<width/2;i++)
                    {
                        *(pU++) = pUV[i<<1];
                        *(pV++) = pUV[(i<<1) + 1];
                    }
                    pUV += bytesrow1;
                }
                
                // 3.5.分别读取YUV的数据
                pFrame->data[0] = yuv420_data;
                pFrame->data[1] = pFrame->data[0] + width * height;
                pFrame->data[2] = pFrame->data[1] + (width * height) / 4;
                pFrame->pts = frameCount;
                
                // 5.对编码前的原始数据(AVFormat)利用编码器进行编码,将 pFrame 编码后的数据传入pkt 中
                int ret = avcodec_send_frame(pCodecContext, pFrame);
                if (ret != 0) {
                    printf("Failed to encode! \n");
                    CVPixelBufferUnlockBaseAddress(pixelBuffer, 0);
                    return;
                }
                
                while (1) {
                    ret = avcodec_receive_packet(pCodecContext, &pPacket);
                    if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
                        break;
                    else if (ret < 0) {
                        fprintf(stderr, "Error encoding audio frame\n");
                        break;
                    }
                    frameCount++;
                    if (pPacket.flags & AV_PKT_FLAG_KEY) {
                        videoFrame.isKeyFrame =  YES;
                    }
    
                    //write file
               NSData *data = [NSData dataWithBytes:pPacket.data length:pPacket.size];
               if ([self.delegate respondsToSelector:@selector(videoEncoder:encodeData:)]) {
                  [self.delegate videoEncoder:self encodeData:data];}
                    //释放packet
                    av_packet_unref(&pPacket);
                }
                
                // 7.释放yuv数据
                free(yuv420_data);
            }
            CVPixelBufferUnlockBaseAddress(pixelBuffer, 0);
    }
    

    四、提取SPS,PPS,VPS数据

    上文说了要单独提取SPS,PPS,VPS数据,需开始设置pCodecContext->flags |= AV_CODEC_FLAG_GLOBAL_HEADER

    uint8_t *extra_data = pCodecContext->extradata;
    int extra_size = pCodecContext->extradata_size;
    

    1.H264编码时,拿到的extra_data如下所示:

    00000001 6764001f acb300a0 0b742000 00030020 00000651 e3064d00 00000168 e9732c8b
    

    很明显SPS,PPS被4个字节的start code= 00 00 00 01分割开,NALU header只有一个字节:

    00 00 00 01 67  ---> (0x67 & 0x1f) = 7 ---> PPS
    00 00 00 01 68  ---> (0x68 & 0x1f) = 8 ---> SPS
    

    代码如下:

    int pos = 0;
    int pps_pos = 0,pps_length = 0;
    int sps_pos = 0,sps_length = 0;
    while (pos < (extra_size - 4)) {
          if (extra_data[pos] == 0 &&
             extra_data[pos+1] == 0 &&
             extra_data[pos+2] == 0 &&
             extra_data[pos+3] == 1) {
            if ((extra_data[pos+4] & 0x1f) == 7) {//sps
                sps_pos = pos+4;
            }else if ((extra_data[pos+4] & 0x1f) == 8){//pps
                 pps_pos = pos+4;
            }
         }
    	pos ++;
    }
    sps_length = pps_pos - sps_pos - 4;
    pps_length = extra_size - pps_pos;
    

    2.H265编码时,同样方法拿到的extra_data提取SPS,PPS,VPS``NALU header有两个字节,提取方法如下:

    00 00 00 01 40 01  ---> (0x40 & 0x7E)>>1 = 32 ---> VPS
    00 00 00 01 42 01  ---> (0x42 & 0x7E)>>1 = 33 ---> SPS
    00 00 00 01 44 01  ---> (0x44 & 0x7E)>>1 = 34 ---> PPS
    

    需要注意的是,此处还可能包含被3个字节的start code= 00 00 01分割开的NAL_UNIT_SEI数据:

    00 00 01 4e 01  ---> (0x4e & 0x7E)>>1 = 39 ---> SEI
    

    五、编码结束

    编码结束时,需要冲洗编码器,将编码器中缓存的数据冲洗出来,防止丢帧。方法是发送avcodec_send_frame(pCodecContext, NULL),当avcodec_receive_packet的返回值为AVERROR_EOF则表示冲洗完成。最后再释放内存。

    更多相关内容
  • H265编码解码安装包,里面有简单的安装说明,简单的操作说明 以及VLC播放器,以及可以看到电脑上所有解码的工具 注意根据自己的系统安装32,还是64位 由于H265 HEVC编码不支持win10自带播放器 所以要安装VLC...
  • 浅析HEVC/H.265编码器中的熵编码

    千次阅读 2020-03-29 21:57:18
    在保证视频图像质量的前提下,HEVC通过增加一定的计算复杂度,可以实现码流在H.264/AVC的基础上降低50%。为了实现目标,HEVC采用了一些全新的编码技术,比如:基于LCU(Largest... 今天主要介绍一下HEVC/H.265码...

            在保证视频图像质量的前提下,HEVC通过增加一定的计算复杂度,可以实现码流在H.264/AVC的基础上降低50%。为了实现目标,HEVC采用了一些全新的编码技术,比如:基于LCU(Largest Coding Unit)和四叉树(Quad Tree)的灵活编码结构[1]、大尺寸变换单元结构的选择[3]、改进的去方块滤波技术以及HEVC的并行化改进设计等。 今天主要介绍一下HEVC/H.265编器码中的熵编码。

    1、HEVC编码过程中的熵编码:

    1)HEVC的视频码流结构

    2)transquantbypass_flag和skip_flag编码

    3)prediction mode编码

           prediction mode包括MODE_INTRA和MODE_INTER两种模式,当slice type=I_Slice时,prediction mode=MODE_INTRA,当slice type=P_Slice/B_Slice时,prediction mode可以是MODE_INTER,也可以是MODE_INTRA,后者将采用intra的预测方式,编码预测方向信息。为了节省码字,slice type=I_Slice时预测信息不写入码流,只对P_Slice和B_Slice的prediction mode进行编码。

    4)partition size编码

           这也是和H.264仅有symmetric类型不同之处,这样考虑主要是为了照顾一些大尺寸图像的纹理分布特性。其中INTRA_MODE只有2Nx2N和NxN两种形态。

    2、predition infomation编码

            当采用INTRA_MODE预测模式时需要编码luma/chroma intra direction,HEVC/H.265编码中采用了多达35种帧内预测模式,除了planar模式和DC模式外采用了33种基于方向的预测模式[6],精确地从更多的方向消除视频的空间冗余性,进一步提高帧内模式的编码效率。HEVC提出的planar模式能够更好得预测画面的平坦区域,对于高分辨率的大块区域可以取得较好的预测效果。split_flag, skip_flag, luma direction在HEVC熵编码中的上下文建模属于典型的运用空间相邻的同类语法元素作为依据的设计,上下文选择的依据是左侧CU和上侧CU的信息[2],但是在选择top direction时,HEVC并没有采用上面LCU的CU direction作参考,仅仅在LCU内部CU编码时会用到上面CU的direction作为参考[4],这和H.264中选择上面宏块的预测模式有所不同。当采用INTER_MODE模式进行编码时,需要编入ref_frame_idx,mvp_idx,mvd信息,因为prediction info是基于PU为单位进行编码的,所有针对不同的PU分割类型要对每一个PU块的mv信息进行编码。 当一个LCU中所有的CU数据信息编码完成之后要进行terminate标识位编码。

           本文结合前段时间所做的软件建模工作对HEVC的熵编码过程进行了分析,接下来的工作主要致力于编码器的硬件实现和优化设计。为了提高硬件设计的吞吐率,硬件算术编码引擎采用可处理multi-bins的多级流水线结构,diff-banks SRAM来存储上下文表格,针对不同大小TU块的残差数据编码过程,提出合理的ping-pong结构来避免扫描过程和编码过程的等待,缩短编码周期;为了更好的控制datapath处理过程,采用高效的转换状态机来处理各个语法元素的编码过程。

    HEVC编码器在语法方面上的新特性解析

    HEVC标准的优越性:

    一、任意点解码和码流拼接

            H.264/AVC中,码流必须从一个包含关键帧的IDR单元开始,它必须不依赖NAL中的前置的包就可以独立解码。IDR是封闭GOP的标志性组成部分。

           新的纯随机读取(CRA)语法定义了如何使用处于随机读取点(RAP)位置的关键帧。

    比如说,告诉解码器从一个临时有效的位置直接开始解码,忽略之前的视频数据,此方法称为开放式的GOP操作。

    随机位置读取的支持对频道切换、拖动操作和动态流服务是十分关键的。

           某些解码顺序在CRA帧之后,显示顺序在CRA帧之前的帧可能会参考解码器buffer中还不存在的帧,于是这些解码器无法解码的帧就只能被丢弃。基于这种情况,这些帧被定义为拖动可跳过的前置帧(RASL)。

          不同的码流之间切换可以通过断点连接帧(BLA)来拼接。简单的把需要切换的码流的RAP帧标记为BLA放到当前帧的下一个CRA帧的地方,然后传输新码流就可以完成码流拼接的工作。

           RAP帧可以是IDR、CRA、BLA帧,CRA和BLA的后面都可能跟随着RASL帧(BLA的NAL单元的标记可定)。BLA帧之后的RASL帧解码器必须抛弃,因为它们可能参考了拼接前源码流的帧导致无法解码。

            还有一种解码顺序在RAP帧之后,显示顺序在RAP帧之前的帧,叫做拖动可解码的前置帧(RADL),这种帧不会参考解码顺序在RAP之前的帧。

    RASL和RADL可以统称为前置帧(LP)。

            解码和显示顺序都在RAP帧之后的帧叫做后置帧,它们不可以将LP作为它们的参考。

    二、临时分层编码

            类似H.264/AVC的可伸缩编码扩展(SVC)的功能,HEVC可以在NAL的头上临时定一个分级预测的层。这样就可以只解析到NAL层面就实现可伸缩性。

            某些情况下,针对同一个码流,解码器可以自主决定临时解码层的数量。从低级子层到更高级子层切换的操作可以在临时子层帧(TSA)和步进临时子层帧(STSA)完成。

           TSA点允许切换到比当前子层高的任意子层,STSA只允许切换到只比当前子层高一级的下一层(除非更高的层也包含TSA或者STSA帧)。

    三、扩展参数集

            新加入VPS元数据描述包括临时层级依赖在内的编码视频的全部特征。主要目的是增强在系统层的兼容扩展性。

    比如说,对未来可伸缩编码或者多视角的视频需要被旧的解码器解码时,那么它就可以方便地忽略那些高级解码器才需要的码流扩展信息。

    四、参考帧集和参考帧列表

            为了管理解码多参考帧,已解码好的帧被放在解码帧缓冲区(DPB)中并被详细标记以供码流中后续的帧参考。每个片的头部都会包含一个帧序计数器(POC)以定位那些帧。

            保留下来用以参考的帧集合叫做参考帧集合(RPS)。

            H.264/AVC的DPB中有两个帧的列表,分别叫做参考帧列表0和参考帧列表1。定位具体帧的索引叫做参考帧索引,如果列表中只有一个帧,则参考帧索引为0,不在码流中传输。单向预测时,可以从0和1两个列表中选出一个帧。双向预测时,则会从两个列表中各选一帧。

            定位RPS和将参考帧列表用于帧间参考的语法比前代H.264/AVC的设计对丢包的兼容性更好,在拖动和其它播放模式下(快进、快退、动态码流切换等)也能工作地更好。

            HEVC编码器/H.265编码器的这项优化的关键是让语法更加明确可展现,避免了之前对解码器解码过程中的中间状态和临时值的依赖。而且还比H.264/AVC中的语法更加简化了。

            H.265/HEVC编码器对安防行业发展的影响

           现在4K超高清应用已经应用到安防行业,类似于当年H.264/AVC,H.265/HEVC编码器也会逐渐应用到安防行业,但这需要各个配套环节成熟起来。

           参考当年H.264/AVC的普及过程,H.264/AVC于2003年正式颁布为国际标准时,在接下来的2到5年时间里,很多人用各种DSP去实现编解码器,比如ADI的blackfin561、TI的DM642。当时这些DSP内部都没有硬件加速器,只是一核或两核通用DSP,只能软件优化实现。再后来,TI推出达芬奇系列SOC,此时芯片带有几个硬件加速器和多个处理核,在上面开发H.264/AVC编解码器时,软件优化同时调用加速器提升效率,同时芯片的处理能力提升很多。同时国内的海思也推出编解码器ASIC化的SOC方案,安霸也推出类似SOC方案。再后来TI推出Netra系列芯片,在SOC上嵌入更多加速器,编解码能力大幅提升,此时的编解码器设计变得异常简单,只需调用厂商提供的接口调用硬件编解码器即可。

           现阶段,IPC、DVR、NVR中的H.264/AVC编解码器都是用加速器和ASIC实现的,已经没有软件优化的实现模式了。

            反观H.265/HEVC现在情况,鉴于其复杂度和主要编码对象大分辨率的情况,再在通用多核DSP平台上实现软件优化已经不可能,只能由芯片厂家用ASIC或加速器方案实现。但是芯片设计周期通常很长,尤其是经过几代芯片才会稳定下来,现在H.265/HEVC标准颁布才有一年多时间,所以芯片厂家成熟方案推出还为时过早。

           同时在超高清采集成像、显示部分上下游环节也还没有完全大量应用。相信在未来几年里,H.265/HEVC编解码芯片推出后,将和4K超高清应用变成相互促进的过程,共同走向普及。但在标清和部分全高清应用,仍会使用H.264/AVC编解码方案。

           H.265/HEVC编码器产品化后,对安防各个行业架构都会产生影响。不仅仅是简单的视频编码器由H.264/AVC替换H.265/HEVC,对前端成像采集、平台架构、存储、后端显示、都有明显的影响。浙江宇视科技有限公司从很早之前就已经在各个环节做好充分准备,已经推出了4KUHDV的IPC,型号为HIC5681-L。已经在镜头设计、ISP成像处理、网络传输、平台架构、矩阵存储等各个方面做好充足准备。

    HEVC/H.265编码器复杂度和可实现性并存

    1、软件及硬件提升带动视频编码发展

           由软件和硬件提供的不断加强的处理能力带动了视频压缩编码的发展。新兴的HEVC视频编码标准意在相对于H.264/AVC将其编码效率提高一倍,并且用一半的比特率就能传送相同质量的视频。HEVC解码器的复杂性与H.264/AVC解码器相比好像没有显著的不同,这使得HEVC解码软件在当前的硬件上非常实用。HEVC编码器/H.265编码器预计将会比H.264/AVC编码器复杂上数倍,并在未来的数年内成为一项研究主题。

    2、HEVC实现的复杂性成本不明显

           HEVC编码器,以实现卓越的压缩性能的复杂性成本并不明显。虽然某些方面的设计其他比H.264/AVC需要更多的处理,等各个方面都进行了简化。

    3、软解码的可行性加速HEVC推广

           实时软件解码的HEVC比特流是非常可行的,目前的发电设备:1080p60的解码的笔记本电脑或台式机,移动设备上(包括合理的比特率范围内)和480p30解码。这样的性能是可以实现的,而无需依靠在解码过程中的多个内核。这是很重要的,因为它可提供快速,广泛采用HEVC软件路径。

           在编码器方面,需要大量的额外工作作出实时编码器,提供媲美的HM编码器的压缩效率。预计这将在今后几年里是一个活跃的研究领域。

    H.265/ HEVC编码标准的专利授权问题尚未明确

    1、H.265/ HEVC编码标准建立在众多专利技术之上

          效率更高的HEVC编码标准(H.265编码)即将通过,对于更高分辨率和更精巧的数字视频产品设计具有很强适用性。HEVC之所有尚未大范围推广其中一个重要因素是专利使用权费问题。与H.264一样,HEVC的出现建立在一系列的专利技术上,而HEVC编码器解码器的上市该如何给予专利持有者知识产权补充也是尚未解决的问题。2012年6月,一站式专利授权组织和H.264专利池组织者MPEGLA宣布要申请HEVC必不可少的专利,2013年2月举行的第三次会议有25位响应者。

    2、专利授权涉及费用问题尚未明确

           不过,根据MPEGLA官员的话,没有为专利使用费指引发布乃至将合并一个专利集团的保证设定时间表,因为其他专利打包者或各个持权者可能决定单独主张他们的权利。一些细分市场,最突出的是芯片、编码及其它设备供应商,面对此不确定性将可能加紧其与HEVC有关的工作,并且为可能的专利权做储备。不过,其它细分市场,特别是试图获得HEVC编码提供的带宽节省的免费流媒体内容分配商,几乎肯定将等待许可权使用费情况明了。

           目前,供应商申请的H.265HEVC技术专利可能高达500项之多。但截至目前,谁拥有哪些专利?数量有多少?以及厂商们预计的授权费用等,都尚未明朗。

    HEVC编码技术狙击Google VP8/WebM

    HEVC编码技术狙击Google VP8/WebM,Google在视频编解码市场上棋逢对手。市场份额竞争将起。

    1、国际电信联盟(ITU)通过H.265编码标准速度惊人

           早在1999年,H.264编码技术已比较完善,然而,国际电信联盟(ITU)一直到2003年3月才正式审核通过H.264编码标准。2012年8月爱立信推出就首款了H.265编码器,半年后,国际电信联盟(ITU)规范以惊人的速度通过H.265标准审核。

    2、快速推出H.265/HEVC编码标准狙击巨头

          为何H.264和HEVC编码技术的待遇差距如此之大?原因是HEVC编码技术有一个强大的竞争对手,HEVC视频编码技术必须尽快建立标准来抗衡。这个对手就是Google VP9/WebM视频编码技术,目前Google VP8/WebM编码技术主要针对HTML5和云播放领域,Google旗下的YouTube视频网站已采用VP8/WebM编码技术进行编码(未来会采用VP9/WebM编码技术),考虑到YouTube的强势,Google VP9/WebM编码技术是HEVC编码技术不得不重视的对手。

           所幸的是,在家电领域,目前Google的影响力相对有限,三星、索尼、LG、夏普、松下、苹果等国际巨头的支持HEVC编码技术有着相对光明的前景。2015年春季,一旦蓝光4K标准确定采用HEVC编码格式(几乎板上钉钉),那么HEVC编码格式的未来将无需担忧。

    3、HEVC编码器性能优越

           相比H.264,H.265提供了更多不同的工具来降低码率。H.265的编码单位可以选择从最小的8x8到最大的64x64。信息量不多的区域(颜色变化不明显,比如天空的灰色部分)划分的宏块较大,编码后的码字较少,而细节多的地方(细节变化较多,比如大楼部分)划分的宏块就相应的小和多一些,编码后的码字较多,这样就相当于对图像进行了有重点的编码,从而降低了整体的码率,编码效率就相应提高了。这个过程有点像“感兴趣区域编码”,针对重要的更多关键细节的部分进行增强划块,无更多关键细节的部分进行简单划块,但是这个过程在H.265上可以自适应识别实现。

    H.265/HEVC编码器面临难题

           H.265/HEVC编码器标准主要作用是在有限带宽下传输更高质量的网络视频。 从两年前出现到2013年被确认,至今各企业逐渐推出产品,发展速度还是很快。随4K技术的发展,H.265/HEVC编解码的进步也变得重要,H.265编码器的一大问题随着应用的广泛而不断显现。

    1、存储成为发展中的重点难题

           H.265编码在视频存储方面是一大难题,能否用大容量的蓝光光盘存储呢?理论上这是H.264格式编码的发展,但空间仍然是个难题。采用H.264视频编码的4K电影需具备至少100G空间蓝光碟片,那么在网络视频以及监控行业领域内又是否能找到100G支持可擦写的光盘呢?

          换句话说,尽管H.265编码和芯片已经准备就绪,其仍然缺乏4K内容支持,与现有蓝光光盘标准兼容性、存储空间和回放成为最大绊脚石。这也成为H.265最大的挑战。

    2、关键技术还未普及开来,是否收费成焦点

           另外,目前H.265的视频压缩技术、区域分类技术,还停留在少数几个厂家里;如果涉及收费,必然提高设备成本,而这些成本,就会进一步转嫁到用户身上。

    3、专家意见

    (1)H.265必须满足特定条件:原有行业的更新换代是大发展的前提。随着视频监控技术的发展,宽动态性能的提升,摄像机本身性能的增强,会有更多复杂的信息在网络上传送,但是带宽却没有提升的前提下,H.265技术才会广泛应用。

    (2)硬件的问题:H.265虽然可以少占用带宽,却提高了硬件性能消耗,这就要求不管是前端还是后端,都必须有一个高性能的硬件处理H.265编码、解码等问题。

    (3)H.265专利问题:随着市场经济的发展,将会有很多相应的解决方法或更好的技术,但是这些需要时间做前提。

           对于用户而言,H.265存在的问题也不免会遇到,为此,要根据专家提出的几点建议,根据自身实际,找到切实的解决方法,当然,随着视频监控的快速发展,关于H.265技术存在的问题会越来越多,而解决方法要在实践中不断摸索。

    HEVC/H.265目前的研究方向

          HEVC/H.265编码基于传统的混合视频编码框架在每个模块上进行了创新,包括更加灵活的划分模式、基于竞争的运动视频预测、基于DCT的分像素插值滤波器、高效的自适应算术编码以及波形并行处理技术等——这些新技术使得HEVC编码效率比H.264/AVC提高了一倍。

          这些编码选项的灵活组合使得HEVC的编码复杂度大大增加,成为阻碍HEVC标准快速推广的一大原因。因此研究快速、高效的编码率失真优化算法、码率控制算法、主观质量优化算法成为研究重点。

    1)快速、高效的编码率失真优化算法

           基于对HEVC编码器参考模型HM的测试分析可知,灵活的块划分模型,包括编码单元CU、变换单元TU以及预测单元PU,对视频编码的率失真性能提高最为明显,但其带来的计算复杂度也最大,因此HEVC编码器如何根据相邻块上下文属性以及当前编码块的纹理特征进行快速的CU、PU和TU划分,这具有非常重要的研究价值。

    2)快速、高效的码率控制算法

           为了适应多核处理器的发展趋势,HEVC中引入了片层、条带以及WPP(波形并行处理)的思想,然而目前已有的并行视频编码方法粒度较粗,并行度不高,负载不均衡,无法充分挖掘多核处理器的计算能力,影响编码效率。因此研究适用于多核处理器的高并行度视频编码方法,为视频编码发展提供持续的计算能力保证,具有重要意义。目前这方面的研究刚刚起步,研究点主要包括并行运动估计算法、并行帧内预测算法和并行熵编码算法等。

    3)快速、高效的视频主观质量优化算法

           HEVC在视频编码算法方面,还在不断的进行着扩展式的发展,以便应多应用需求的不断变化,这些扩展发展的主要研究方向包括:

    (1)3D视频、立体视频和多视角视频的编码技术,不仅对视频数据进行压缩,还要对其他深度信息进行编码;

    (2)分层式HEVC编码技术:用于提高HEVC对网络的自适应能力,目前主要应用于空域和质量域可分层视频编码;

    (3)HEVC即将把人类对视频图像的认知模型融入到视频编码算法中,对视频图像中感兴趣的区域分配较多的码率以提高视频图像的主观质量,主要包括感兴趣区域的检测技术和动态码率分配技术等;

    (4)优化视频图像的主客观质量评价方法,目前主要以峰值信噪比以及结构相似性指标作为评价标准,难以精确模拟人类视觉系统的功能,目前正在进一步提高和改进。

    HEVC/H.265编码在3D图像技术上的拓展应用

           HEVC编码扩展为三维视频编码支持多个视图和相关的编码深度数据。它增加了新的编码工具HEVC设计,提高压缩功能依赖视频和深度数据视图。

           最近3D视频技术进步直接诱发市场日益增长的3D视频兴趣。从电影屏幕数量上能够看出制作3D电影和播放3D电影的数量近年来不断增加,3D电视和蓝光播放机,首部3D频道,和3D蓝光光盘的发布,等现象也表明3D视频开始进入消费者的家庭。不断地改进的自动立体显示技术被认为是一种很有前途的技术,因为它可以使人们在家即可不带眼镜体验3D视觉效果。相对于常见的立体显示,自动立体显示器为实现3D视觉体验不仅需要两个,而是多种不同视角。但是多视角视频编码的比特率的要求于MVC来说,像新扩展的增加近似线性的编码的观点,MVC是不适合传输自动立体显示的3D内容。

           一个有前途的替代方法是在多视图三维视频的传播视频加上深度的显微)格式。MVD的格式,通常只有几个观点实际上是编码,但他们每视角都是与编码深度数据相关的,,代表基本几何捕获的视频场景。基于传输视频图像和深度地图,另外适合显示3D视频内容的自动立体显示可以使用基于深度图像生成呈现在接收机端(DIBR)技术。

           图像视频编码组和3 d编码组在MVD编码格式下联合开发了对于3D视频数据的HEVC的扩展应用。与MVC相似,所有视频图片和深 度地图表示的视频场景同时即时构建一个访问单元和输入MVD信号的接入单位连续编码。目前世纪鼎点的核心编码器已在3D方面有突出优势。

           内部访问单位,所谓的独立视图的视频图像传输第一次直接紧随其后的是深度映射关联。此后,其他视图的视频图片和深度地图直接传输,视频画面总是紧随其后的是深度映射关联。原则上每个组件使用HEVC-based编码器信号编码。相应的比特流数据包多路形成了三维视频比特流。独立的视频图像是使用非改编的HEVC编码器编码。

           相应附属比特流可以从3 d比特流中提取,HEVC解码器解码,并显示在传统的二维显示。另一个组件是使用修改HEVC程序员编码,包括额外的编码扩展的工具和组件间的预测技术,使用已编码的数据在相同访问单元如图1红色箭头表示的。支持一个可选的丢弃的深度数据比特流,例如,对解码two-view视频适合传统立体显示器,可以配置组件间预测的方式可以独立解码视频照片的深度数据。

    H.265/HEVC编码进行生活化

            互联网在中国历经二十几年的发展已经影响了中国人生活的方方面面,现今商人的生意经无有不围绕互联网展开的。编码技术的进步使视频的传输一点一步的在互联网中占据越来越多的位置,H.265/HEVC编码的产生加快了网络视频的生活化进程。4K超清分辨率是电视行业的必然发展趋势,即将取代1080P,成为主流。当然,4K流媒体视频也会带来一系列的问题。比如都有哪些供应商、需要多少带宽、会被压缩吗、画质如何等等。

    1、流媒体网络平台最先发布4K视频内容:

           目前,国内优酷、腾讯、搜狐,乐视都相继推出4K频道。而国外就更加热闹,包括Netflix、亚马逊、M-GO及YouTube等国外视频网站,都将在今年支持4K超清内容。其中,Netflix将率先提供自然纪录片、知名美剧《纸牌屋》等内容;亚马逊则更有前途,将联合狮门影业、华纳兄弟、20世纪福克斯和Discovery频道,提供4K视频内容。M-GO则得到了梦工厂的支持,预计会提供大量4K动画片。最后,YouTube则与索尼影业合作,或将带来一些重量级的4K电影内容。

    2、4K内容对于电视标准的需求

            一般来说,但早期的电视机型大部分无法支持超高清流媒体解码或是应用程序,但相信如三星等厂商可能会提供一种外接形式的修复方案。至于具体机型选择,需要了解购买机型所支持何种平台的流媒体服务,这是相当重要的。当然,通过支持4K流媒体平台的机顶盒,也能够获得4K内容。

    3、4K内容播放顺畅需要的网路宽带支持

            显然,4K分辨率流媒体视频对网络环境的要求更高。Netflix、亚马逊的数据,至少需要15Mbps-20Mbps的带宽。不幸的是,即使用户拥有良好的网络环境,也不能完全保证4K流媒体的流畅,有时候还取决于平台服务器和互联网服务提供商(ISP)。比如目前即使我们家中达到了20Mbps的宽带连接,有时候播放1080P在线视频仍然不够流畅,这还需要平台服务商优化解码、提供更稳定的服务器以及ISP优化。

            面对高质量视频内容,和宽带不足的矛盾,显然H.265/HEVC编码解码标准是解决之道,这自然得益于H.265/HEVC编码解码标准的极高性能。H.265新加入的压缩系统可以把传输1080p视频所需的带宽降低50%,实际数字大概在30%左右。这样就能增加视频传输的质量,而不会对网络带宽造成负担;而蓝光和电视节目,还可以因此体验到4K视频,或许还有更高质量的3D。

    网络环境下H.265/HEVC编码器展现优势

            自小米盒子、乐视TV热卖以来,IPTV市场发展越发迅猛,今年更是与4K超高清电视联手席卷了电视市场线上线下的货架,成为客厅家电消费的明星词汇。而随着视频编解码技术已经迎来新的编解码标准H.265/HEVC,更是使超高清视频在网络视频中得以成为现实,日前更是有视频网站——迅雷和PPS推出H.265高清视频专区栏目了,而视频编解码技术视频编码技术作为网络电视发展的最初条件,我们相信伴随H.265编码标准的实现,IPTV必将迎来史无前例的进步。

    1、完美实现传输成本的直接下降;

           在全高清时代,H.264 High Profile 可在低于1.5Mbps的传输带宽下,实现1080p全高清视频传输。但是H.264的压缩效率比MPEG-2提高了1倍多,其代价是计算量提高了至少4倍,导致高清编码需要100GOPS的峰值计算能力。

           比起H.264/AVC,H.265/HEVC提供了更多不同的工具来降低码率,以编码单位来说,H.264中每个宏块(marcoblock/MB)大小都是固定的16x16像素,而H.265的编码单位可以选择从最小的8x8到最大的64x64。

           在相同的图象质量下,相比于H.264,通过H.265编码的视频大小将减少大约39-44%。目前,有线电视和数字电视广播主要采用的仍旧是MPEG-2标准。好消息是,H.265标准的出台最终可以说服广播电视公司放弃垂垂老矣的MPEG-2,因为同样的内容,H.265可以减少70-80%的带宽消耗。

           可能在消费类电子产品中,我们还会认为这些要求离我们有些远,但现实的工业级应用里,包括先进的汽车安全辅助系统、遥控飞机成像、城市监控和流水线成像,甚至是医疗影像方面,都已经有了这些超高清的应用。

    2、H.265/HEVC编解码标准硬件革新生产的加速

           在今后可能的H.265的相关应用中,最重要的领域无疑会是平板、智能手机、彩电、数码相机、摄像机以及目前在全球大量采用的高清监控系统。这些领域大多会通过DSP+ARM处理器或是CPU+GPU的架构来实现。不少芯片厂商已经在快速布局,甚至有相关的芯片发布。

           目前已经有超过40家公司参与到HEVC编解码器(也称为H.265)的标准化当中。高通公司通过标准化会议以及在CES和MWC等关键技术事件上的公开展示等行为表达了对H.265标准化的支持。高通表示视频是网络数据流量爆炸式增长的一个主要驱动力,而H.265的压缩效率要比H.264多出近40%,所以H.265将在业内有非常好的表现。

           而市场上已经有公司推出支持H.265技术的超高清家庭网关芯片,新的HEVC/H.265编解码器在视频方面拥有广泛的应用。该技术使用更高效的比特率输出分辨率更高的视频,进入了超高清电视((UltraHD TV))的新时代。该技术拥有更高的压缩率,能够提高所有消费设备的视频传输速度。HEVC/H.265标准允许服务提供商以更低的比特率提供更高质量的流媒体服务,以同样的比特率提供相同甚至更多内容,因此服务提供商也可以从中获益。预期HEVC/H.265在超高清电视的部署过程中将发挥关键性作用。新的编解码器技术将减少传输带宽,使超高清电视通过卫星、电缆或者IP通道传输成为可能。

           IPTV上下游产品线亦有硬件巨头表示将提供针对电视、机顶盒等相关领域的H.265的方案。H.265让有线电视运营商可以在他们的产品库中加入更多频道,还可以让基于VDSL的IPTV运营商提升图像质量,并提供更多有用的功能,如“同时观看/录制最多4个频道的节目”。当然,H.265将让所有运营商都能实现超高清内容播放。

           从目前市场状况和技术趋势上看H.265编码器在中国市场瞄准的应用与全球市场是一致的,甚至很多产品的市场趋势是由中国厂商在引导着的。随着4K面板的成本快速下跌,4K内容的需求将会逐渐上升。此外,由于屏幕品质提升,对于更高色彩逼真度的要求也会增加。消费者对于观看质量要求的日益提高对新产品的认可和买单将是对产品的唯一验证。

    H.265编码技术助力网络视频发展

            编码器技术对于视频来说就好比砖石至于房屋,为之根本的方式存在着。客厅电视已经进入4k时代,网络视频也进入超高清时代,观众都希望在不用增加带宽费用的前提下获得更高清更唯美的视频画质体验。H.265编码器的出现对于这样的期待真是恰逢其时了。H.264统治了过去的五年,H.265/HEVC编码解码技术的出现也已经有两年光景,差不多该接班了。

    一、 视频监控对H.265编码需求日盛

            目前网络监控的需求量越来越大,间接促进了网络视频编码器的加速发展,目前网络视频编码器已经由单功能的视频编码传输,逐渐发展成为可以支持WIFI、3G、4G等多种网络环境,甚至带录制存储功能;传输通道也从原来单路逐渐发展成为:单路D1,两路HD1,四路CIF和多路兼容的多菜单操作与管理的集成系统。目前国内顶尖的编码器生产商世纪鼎点(www.powersmarttv.com)的拳头产品Powersmart系列编码器即可支持在3G、4G、WiFi等多网络环境下的多路回传。编码器是将信号或数据进行编制、转换后进行传输出去的设备。网络视频编码器只是编码器通过发展之后其中的一个很常见的应用。

           随着应用广泛视频编码标准地位逐渐提高,在视频传输过程中在要求图像不失真,则图像传输的比特数就大,在网络带宽一定的情况下,降低视频图像的码流就成为一项重要的技术。H.264也称AVC(AdvancedVideoCoding),是一种先进数字视频压缩技术和标准,由JVT(JointVideoTeam)于2003年3月正式发布的。H.264标准的主要目标就是在同等保真条件下,提高编码效率,与之前的H.263或者MPEG-4标准相比,其在保证相同图像质量的情况下,降低约50%的码率。

          更为先进的H.265编码技术是ITU-TVCEG于2013年1月推出。在技术上,H.265将在现有的主流视频编码标准H.264上保留了一些较为成熟的技术和继承其现有的优势,同时对一些其他的技术进行改进,可能体现在提高压缩效率、提升错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延以及降低复杂度等方面。

    二、 H.265编码优势多多

          从编码框架上来说,H.265仍然沿用了H.264的混合编码框架,但是每个技术细节都有提升或改进。

    1、宏块和变换块。相对于H.264的4×4、8×8、16×16宏块类型,H.265引入了32×32、64×64甚至于128×128的宏块,目的在于减少高清数字视频的宏块个数,减少用于描述宏块内容的参数信息,同时整形变换块大小也相应扩大,用于减少H.264中变换相邻块问的相似系数。

    2、使用新的运动矢量预测方式。基于空间域的运动矢量预测方式,H.265扩充更加多的方向进行帧内预测,同时将预测块的集合由原来的空间域扩展到时间域及空时混合域,通过率失真准则计算后选择最佳的预测块。

    3、更多的考虑并行化设计。当前芯片架构已经从单核性能逐渐往多核并行方向发展,H.265引入了Entropyslice、WPP等并行运算思路,使用并行度更高的编码算法,更有利于H.265在GPU/DSP/FPGA/ASIC等并行化程度非常高的CPU中快速高效的实现产业化。

    4、新添加的Tile划分机制使得以往的slice、帧或GOP为单位的粗粒度数据并行机制更加适合于同构多核处理器上的并行实现。Dependentslice和WPP机制解决了以往H.264等编码技术中熵编码环节无法并行实现的问题,使得整个编解码过程中DCT、运动估计、运动补偿、熵编码等任务模块的划分更加均衡,显著提高并行加速比。

    5、更低的码流。反复的质量比较测试已经表明,在相同的图象质量下,相比于H.264,通过H.265编码的视频码流大小比H.264减少大约39-44%。由于质量控制的测定方法不同,这个数据也会有相应的变化。通过主观视觉测试得出的数据显示,在码率减少51-74%的情况下,H.265编码视频的质量还能与H.264编码视频近似甚至更好,其本质上说是比预期的信噪比(PSNR)要好。

    HEVCH.265编码器 —技术难点分析

    和其他复杂的数字信号处理相比,视频编码标准本身并不复杂,在制定标准时候已经考虑到可实现性问题。

           但视频编码有其自身的特点,主要特点在于单位时间需要处理的数据量十分庞大,尤其是编码画面越来越大的情况下。以1080P@30fps为例,即使每个像素点分配2个时钟的运算时间,也要超过100MHz的系统时钟才能实现实时编码,而在2个时钟内,要完成一个像素包括亮度和色度的所有编码运算,这就给硬件编码器的系统设计提出了很大的挑战。

           而区别于以往的视频编码标准如H.264等,HEVC/H.265编码器在算法的灵活度方面要大大加强了,最典型的是摒弃了以往以16×16固定编码块大小的做法,而是采用了更为灵活的编码块结构,这种灵活的结构也带来了编码器性能的差异化,一般来说硬件编码器会对编码工具集进行一定的取舍和优化,如何在保证性能不受大的影响的情况下减少硬件资源占用和系统运行时钟,成为硬件编码器的一大挑战,也是一大难点所在。

          另外,HEVC/H.265编码器摒弃了对CAVLC的支持,而只有CABAC一种码流编码方式。CABAC的硬件实现一直是视频编码的难点所在,H.265也不例外,CABAC比较难以并行化运算,需要很多的硬件设计技巧和方法,通常CABAC部分也成为制约整个硬件编码器速度性能的瓶颈所在,虽然,H.265支持多个CABAC模块并行计算,但同样也会引起系统设计的复杂性以及硬件资源增加等问题,需要综合进行考虑。

    HEVC/H.265编码器--- 软硬编码器设计方法的差异

         视频软硬件编码的概念是相对的,通常把基于处理器平台实现的编码器称为软编码,典型如基于PC/ARM/DSP的视频编码器,而硬编码则通常指基于数字逻辑电路搭建的视频编码器,典型如基于FPGA平台以及SOC芯片中的编码器硬核等。

         软硬件编码器在设计方法上迥然不同。软编码是在特定的硬件平台上实现的,它所对应的硬件资源是固定的,如它在单位时间内的运算处理能力是固定的,对于设计者而言,更多需要做的是在软件实现算法上做优化。而硬件编码器则是在最基本的逻辑电路上进行自由搭建,就好比在一张白纸上绘画一样,可根据需要添加硬件资源,如果以软件编码的方法或者在C程序上做移植优化的方法来进行硬件编码器设计,则很难设计出优秀的硬件编码器。另外硬件编码算法的差异化和灵活性会更高,相对软件编码器而言,不同设计方法导致的硬件编码器的性能差异化会更大。

    评判一个视频硬件编码器的性能,主要考虑几点:

    1. 压缩性能:一个视频压缩标准会有不同的编码工具集,并非所有的编码工具集都需要在编码器中实现,特别是对于实时硬件编码器,会根据编码器的应用场合特点对编码工具进行适当的删减,因此不同编码器在最佳编码性能方面会有些差异;

    2. 硬件资源占用: 通常用逻辑门数和RAM大小等指标表示。不同的设计算法,特别是整个系统的设计安排,导致的硬件资源占用差异化很大,通常可以达到2——3倍以上;

    3. 实时工作频率和fmax:实时工作时钟频率是衡量编码器的重要指标,这是硬件编码器设计之初即确定的参数,功能模块的算法设计选择需要根据实时工作时钟频率的要求来做相应调整,一般越低的工作时钟频率对模块以及系统的设计会带来更高的要求。由于视频编码数据量十分庞大,每个像素的处理时间甚至要求在1——2clk内完成,此时每增加1clk时间,都可能带来实时工作频率的极大增加。例如,同样的FPGA硬件平台,有的设计可以实现1080P@30fps实时编码器,而有的设计却只能完成CIF(320*240)实时编码器,差距在十倍以上。除了实时工作时钟频率外,还要考虑整个电路的最高可运行频率fmax,这个和硬件设计算法有关,fmax越高,实时工作频率越低,则编码器性能越优秀;

    4. 功耗:功耗也是编码器设计需要考虑的问题,特别是编码器应用在移动便携式领域时。

    不管是软件编码器还是硬件编码器,要设计一款优秀的产品都不是容易之事。软件编码器有官方的参考软件,可在此基础上做优化,但不同优化方案的性能差异相对有限,国内目前进行HEVC/H.265编码器设计的公司有世纪鼎点等。

    微软推出原生支持MKV解码与HEVC编码的windows10操作系统

    日前,微软操作系统部门团队负责人 Gabriel Aul 在 Twitter 上确认了微软 Windows 10 中原生内置了 HEVC(高效率视频编码,或称为 H.265)支持。HEVC,是一种视频压缩标准,并且是H.264或高级视频编码(AVC)的后续标准,也被称为H.265,MKV是一个灵活开放的视频文件封装协议,它已经迅速成为高清晰度视频首选。现在Win10可以直接播放MKV,而不需要额外的解码器,Windows10内建的媒体播放器现在可以直接播放MKV和HEVC格式的文件,而不需要依赖其他第三方软件了。对于Win10在客户体验和服服务上微软是真的用心了。

    1、视频压缩技术的发展对网络视频发展至关重要:

    随着视频技术的发展,特别是高清(HD)、超高 清(UHD)、 3D和多视点(multi-view)视频技术的兴起,各种视频信息已普及和深入到我们生产和生活的方方面面。据估计,视频流数据将在2015年占到整个互联网流量的90%左右,说夸张一点,整个互联网络差不多就是视频网了。尽管近年来网络带宽 和存储能力增加迅速, 但是也远不能满足以海量信息为特征的视频数据的传输和存储的要求。因此视 频信息量的高效压缩过去是、现在是、在可预见的未来也必然是解决这一矛盾的重要技术措施之一。

    由于微软在操作系统霸主地位几乎全球80%以上的人都在用微软的操作系统,这也意味着H.265编码标准可以在市场普及中迈开一大步,实在是实际意义上的市场推广中的一大突破。可以想见,不日HEVC编码标准必将顺风顺水的在软件领域推行了。

                       

    2、HEVC复杂度仍需客服,应扬长避短

    H.265的能力超群,最大的需求会是在高清甚至超高清的视频源的传输上,1080P以及以上分辨率的高清系统应用中会对HEVC编码器的推广形成重要影响,为扬长避短,高清系统能实现的各方因素都需考虑到。目前网络、存储类组件技术发展迅速,更新换代很快,成本降低的也快,为HEVC应用及在市场上的推进节省了一定的成本。而对高清视频源的产生离不了高清超高清摄像机,而镜头、Sensor等组件与物理材料工艺的关系更为密切,目前硬件发展相对平缓,对高清系统来说网网是高成本组件,由此可知HEVC的普及速度主要受制于视频源太少。

    3、H.265/HEVC编码器应用前景

    结合H.264在视频应用领域的主流地位可以预见H.265协议在未来必定有广阔的发展前景。国际上的一些主流广电组织及媒体运营商已经广泛选择H.264作为媒体格式标准,一些主要的编解码设备厂商也一致积极参与到H.265的研发当中。

    H.265初出茅庐,实力非前辈可比,在压缩效率、并行处理能力以及网络适应性方面的极大进步必然是顺应大势发展的,乘上windows10这场大船一定很快能进入一个全新的高度。

    H.265技术或促使视频编码器进入智能化

    人类对科技的需求走在前面还是科技的发展走在前面,这个问题困扰了我一段时间,有人会说必然是有人对品质有更高要求才衍生出各种技术的进步啊,但是想想很多技术出现了并不一定很快被普及开来,快的也许几个月,慢的甚至十几年,或许人类生活本不需要那么多点缀,所有技术回归到最基本的需求上来说就最有发展了。闲话少说我们还是来看一下人类视觉体验的技术发展,H.265技术已经出现两年,零星也出现了H.265/HEVC编码器解码器,可普及程度还不到市场的十分之一,其中道理我们详细来谈:

    1、H.264编码弊端明显,但仍是市场主流

    关于H.264和H.265的对比证据和文章已经不少,我在此简单概括,H.265编码器,在带宽相同时,画面质量比H.264编码器提升至少一倍。相同画质的视频,用H.264编码画面模糊,出现卡顿,“马赛克”满屏,而“H.265体验”观看,视频清晰流畅。目前国外占领导地位的视频编码技术还是主要采用H.264技术。而13年底我国问世首台H.265视频实时编码器,这使我国第一次成为国际视频标准产品化的先驱者,从而结束了拿着高清设备只能看标清的历史。

    众所周知,视频编码器用于实现视频源痨数字化和网络化,具体功能包括监控点模拟视音频信息和报警信息的接入、编码/压缩、传输以及外围设备的控制。

    尽管网络摄像机正在大量涌现,但因为以下两个原因,视频编码器仍将在网络视频监控系统中占据不可替代的重要位置:一是大量已建的模拟和数字监控系统等待网络化改造,为了保护现有模拟摄像机的投资,这些改造将产生庞大的视频编码器需求;二是市面上网络摄像机的种类不多,难以满足不同用户个性化需求,所以很多场合还必须基于模拟摄像机加视频编码器的模式实现前端的数字化和网络化。

    2、H.265编码器让传输与视频管理变得更高效

    据研究发现,在模拟技术稳步发展时,IP视频以每年30%增速急速追赶模拟市场。除了技术应用不同外,在大多数情况下两种架构没有太多的交集。

    网络视频提高了画面质量、改善管理,并且能够降低系统运营成本。此外它还能提供一个面向未来的平台,良好的网络技术时刻有可能进入百万像素和高清标准。监控市场中有很多种编码器,单通道或多通道连接模拟摄像机,应安装独立的编码器,接近模拟摄像机信号,否则将会影响数字转换结果。

    高效率痨视频编码器使网络更加灵活、适应性更强。编码器让模拟信号进入了IP系统,最大的好处就是节约了成本,弥补了技术差距。

    3、H.265承接混合编码框架,细节优化极大

    H.265虽然沿用了前辈的编码框架,但是优化了每个技术细节,使编码效率极大提升:

    1)运动补偿,允许更大的宏块和变换块:

    H.265引入了32×32、64×64甚至于128×128的宏块,目的在于减少高清数字视频的宏块个数,减少用于描述宏块内容的参数信息,同时整形变换块大小也相应扩大,用于减少H.264中变换相邻块问的相似系数。

    2)使用新的MV(运动矢量)预测方式。

    区别于H.264基于空间域的运动矢量预测方式,H.265扩充更加多的方向进行帧内预测,同时将预测块的集合由原来的空间域扩展到时间域及空时混合域,通过率失真准则计算后选择最佳的预测块。使用该方法,在基本模式下测试,在与H.264相同质量的情况下,得到平均为6.1%的压缩增益,复杂图像的压缩增益甚至能提高到20%。

    3)更多的考虑并行化设计。

    当前芯片架构已经从单核性能逐渐往多核并行方向发展,H.265引入了Entropyslice、WPP等并行运算思路,使用并行度更高的编码算法,更有利于H.265在GPU/DSP/FPGA/ASIC等并行化程度非常高的CPU中快速高效的实现产业化。

    4)新添加的Tile划分机制使得以往的slice、帧或GOP为单位的粗粒度数据并行机制更加适合于同构多核处理器上的并行实现。

    Dependentslice和WPP机制解决了以往H.264等编码技术中熵编码环节无法并行实现的问题,使得整个编解码过程中DCT、运动估计、运动补偿、熵编码等任务模块的划分更加均衡,显著提高并行加速比。

    5)更低的码流。

    反复的质量比较测试已经表明,在相同的图象质量下,相比于H.264,通过H.265编码的视频码流大小比H.264减少大约39-44%。通过主观视觉测试得出的数据显示,在码率减少51-74%的情况下,H.265编码视频的质量还能与H.264编码视频近似甚至更好。

    4、H.265将促使编码器走向智能化

    编码器性能随着机械自动化程度的提升而进步,信号转换已经不再是用户的唯一需求,更便利的服务更快的应变更加适应互联网更个性化的需求,这些都会促使编码器走向完善智能化的过程。

    H.265标准市场化发展缓慢主要因片源有限

    如今的视频内容平台是史无前例的数量,视频内容当然迎来了大丰富阶段,观众关注的不在是看不看得到内容,而是清晰度够不够高,因而视频质量的衡量标准清晰度就变得尤为重要。视频标准从标清480p、高清720p,到近两年大众已经习以为常的高清1080p,乃至超高清4K这迅速的演进,足以表明清晰度是大家对视频方面最迫切的需要。虽然从10年的《阿凡达》D转3D立体显示也曾风靡过一阵,但需要带眼镜,市场一直止步于电影院观看,受众也还是有限。

    去年起大热的4K视频与3D不同,不需要借助外带设备,少了一重麻烦,4K标准的分辨率大小为3840×2160(还有一种标准为4096×2160),能达到1080p四倍的清晰度。而家庭消费中对大屏幕的买单意愿,也是极强的,因而,也许4K清晰度才是适应未来家庭大屏电视机的标准需要,发展趋势十分乐观。

    1、电视盒子大行其道,软解不及硬解适用4K视频

    1103.jpg

    近两年电视盒子产品因其轻巧灵活、实用多变、成本低且易于升级的突出优势,正在迅速进入变化迅猛的智能家电市场里。

    目前4K完整的电影片源还十分有限,如果要想观看4K视频,可以直接到部分高清论坛里找到一些相关的演示片或者MV,但类似的电影还屈指可数。现有的电视盒子大多还是通过软解或者是用更高主频的CPU去解码4K视频,这最少需要4核CPU+4核GPU以上的配置。软解给处理器带来更大的资源占用率,自然机身发热,卡顿甚至死机等不稳定的现象时有发生。而为了实现真正的4K显示,需要独立的视频编码格式去压缩片源,也就是用H.265编码封装格式。独立的解码芯片支持就能释放CPU处理器的压力,自然电视盒子就会更稳定,这就是我们常说的硬解。

    2、硬解是趋势,但仍需等待市场变化

    H.265是ITU-T VCEG继H.264之后所制定的视频编码标准,在保持H.264视频编码标准(1080P分辨率)的基础上,改善了码流、编码质量、延时和算法复杂度之间的关系,达到最优化的设置。HEVC/H.265标准全称为高效视频编码,它仅需H.264标准一半的带宽就可播放等同质量的视频文件。

    出于算法上的优化,H.264能够在低于2Mbps的网络速度下实现标清数字图像的传送;而H.265更是可以凭1-2Mbps的网络带宽传送1080P的全高清视频。带宽要求降了,清晰度高了,这就是真正意义上的事半功倍。H.265编码若得以普及,就算不看4K视频,如果大家看1080p视频在2Mb的相同带宽下都不用缓冲了,就如同现在网上的720p一样流畅,

    H.264作为蓝光光盘的一种编码标准而著名,这种技术统治了过去的八年,而H.265要想真正普及,想必时日也不会太短。就跟软件、硬件的兼容搭配要合理才有市场一样,从硬件配置、视频文件大小,到存储空间、网络速度,四个方面谁都不能太差,短板效应会拖延H.265普及的时间。

    3、4K片源还属少数,摄制硬件价格较高

    在4K视频领域走在最前端的索尼,前不久推出了能够支持4K原生内容直接播放的媒体播放器FMP-X10,内有数十部4K电影提供下载。但价格高达3999元,未免太贵,未来还有待其他品牌跟进。

    而现有的片源基本还都是一些片花或者宣传片,基本可以当做是厂商的一种宣传噱头。笔者估计,随着4K摄像机拍摄的电影日渐增多,真正4K内容的原生电影要想铺天盖地,估计至少也要两年左右的时间。

    应该说,H.265标准迟早会成为超高清电视必备的视频编码标准,满足4K乃至8K分辨率的电影、电视片源的播放。但在硬件配置和4K视频内容都稀缺的今天,硬件配置上的升级革命速度应该会放缓。

    当然,视频质量的升级是必然趋势,必然会有更多厂商跟进硬件市场,在不久的未来我们定能看到更多的4K视频,到时支持H.265解码标准的硬件终端也会越来越多,当硬件、片源都不成问题的时候,H.265编码解码将会是下一个视频行业产品的爆发点。

    H.265编码标准是否收费成焦点

    新标准的诞生必然存在专利权所属者,专利的使用是否收费成为一项技术普及的基本成本问题,也一定程度上决定了普及度的大小。在视频领域中目前使用最广泛的压缩协议为H.264协议,随着视频领域不断的拓宽和人们对视频要求不断提高,H.264即将升级成H.265,H.265编码器已有出现,消费者关心质量和体验,生产商关心的成本价格,H.265标准出现时间不短,但存在专利权是否收费还没有定论。当然,这和新技术的出现与市场适用之间需要长时间磨合有一定关系,在适应新技术的同时该技术也要不断调整,以达到最优状态。

    1、H.265是否收费暂无定论

    对于视频压缩标准,在H.264之前还有很多,但是当人们视觉效果必须满足在1080p高清之后,自然H.264成了主角。H.265要不要收费当然还得看H.264的收费情况,由于H.264是由多项专利所组成的影片格式,虽然专利权所有组织MPEG LA先前允诺在一定期限内可以免费授权H.264提供给消费者使用,但未来是否要收费仍然是个疑虑。以目前来看,若使用一项新的标准自然存在着一定的风险,若H.264还处于免费时,若H.265收费估计会对市场推广有一定影响。

    2、优势明显可否成为卖点

    新的H.265视频标准在数据传输和码流效率上较之前的编解码算法,有明显的提升。H.263到H.264提高了50%,而H.264到H.265将提高67%。据工业和信息化部电信研究院通信标准研究所工程师栗蔚女士称,针对网络传输流媒体的分辨率越来越大,对带宽要求也越来越高的情况下,H.265可提供类似质量下更小的码率。或许在同样的图像质量下,带宽要求将会缩减到1/3。

    未来在视频标准上,虽然H.264并没有收费,但是单以H.265的技术水平来看,似乎收费又有合理的因素。同样,H.265在市场使用上依旧面临两难,一个是该专利的独特创新权,另一个则还是市场的普及率,H.264目前的使用情况的确会给H.265带来不少压力。

    3、H.265编码并非全是优势

    与HD-SDI非压缩视频图像不同的是,经过压缩的视频图像或多或少的都会对图像有所损伤,特别还是在网络传输过程中,更是避免不了丢包的现象。客观地说,只要视频图像存在压缩既会有损伤,当然在高效率的压缩也难逃这一弊端。从客观情况分析来看,视频编码损伤主要有三大类:编码标准、IP网络、Error-prone通信,细致地说这对图像模糊、噪声、数据丢包、延时、抖动以及无线信道传输带来的失真都不可避免。

    尽管H.265真的能够实现超出H.264的多倍高清,一些视频损失是通过数据测算出来的,肉眼则看到就是高清晰的画质。以目前大安防市场的视频会议来看,在高清晰画质的不断需求之下,高压缩标准的确能够进一步推动市场,只不过成本还是用户最为关注的话题。理想的价格才是最终产品流向市场的王道。

    4、H.265的应用前途

    高情视频的发展及普及离不开H.265的应用,尤其是限制于互联网的宽带条件下,H.265在安防行业中是备受看好的市场,高清视频会议中,1080p视频会议已经成为市场的主流。目前根据视频会议市场需求的调查数据显示,高清视频会议的需求和使用率正在以高达30%——40%的速度增长。除了企业级别领域外,高清在线视频和高清电视也可以采用H.265这个新协议。优酷土豆、奇艺、乐视网等都是网友们的最爱。

    4K很惊艳,8K耸人听闻?

    当身为屌丝的我还没有实力升级为土豪买一台4K电视机,8K时代就猝不及防的挤出了时代前端,为了吸引眼球获得盈利方向各生产商在创新上也是够拼的。并且国外已有厂商生产出了全球第一款面向8K超高清视频的H.265/HEVC格式的实时硬件编码器,所记录视频的清晰度可达1080p的十六倍。是否意味着8K的极致视频分辨率只有超高性能的H.265/HEVC编码器才可与之匹配呢?

    1、让我们来看看这炫目的8K视频标准吧:

    关于8K的百科:2012年8月23日,联合国旗下的国际电讯联盟通过以日本NHK电视台所建议的7680x4320解像度作为国际的8K超高画质电视(SHV)标准,SHV作为超越现行数字电视的“超高精细影像系统”,由NHK从1995年开始研发。可见日本对画质的追求真的是无可匹敌。

    2、8K身影在展览中的闪现

    去年10月,在第26届东京国际电影节举行特别放映活动的几部8K视频作品告诉影迷,没有最清晰、只有更清晰。7680*4320像素分辨率、22.2声道等数字一定让你大吃一惊。而“看清演员的毛细血管”、“演员的脸像是贴到眼前”这样的形容方式,再也不是夸张,而成为了写实。

    而在2014年的戛纳电影节上,日本放送协会NHK首次展示了8K分辨率的数字电影,首次亮相就获得了广泛的关注。所谓8K分辨率,就是指分辨率为7680*4320像素的画面。这个数字是普通高清标准的16倍,换句话说,这样的电影,比平时观众在影院中看到的作品清晰16倍。相比起来,刚刚开始逐渐普及的4K技术也“OUT”了,他的清晰度只有8K的1/4。

    不光是画面有了突破,就连声音也有了质的飞跃。大家耳熟能详的5.1声道、7.1声道已经远远不能满足需求。8K数字电影的声音采用了22.2声道,真正做到了每一个声音都能找到最佳的还原途径。

    3、8K产品化的实现

            最近,夏普在东京电子博览会上展示了一台达到8K分辨率级别的电视,这台85英寸的巨大电视分辨率惊人甚至达到了视网膜级别,肉眼几乎看不到像素颗粒。

           这台85英寸大屏幕电视有着高达7680X4320分辨率,同时还有一台同样分辨率的120英寸电视展出,配合了22.2声道家庭影院效果非常惊人,吸引了大量观展人员。此外系统还有Hybridcast输出功能,能够运行电视同时显示互联网内容及电视节目。

    娱乐游戏永远走在技术应用的前沿,目前在游戏行业8K技术已有应用,画质惊艳,的确迎合了很多玩家追求极致画质的心态,

           虽然也也有硬件设备得到了国际电信联盟的批准,而且得到了日本NHK电视台的支持(NHK表示将在2016年开始试播放8K分辨率节目,在2020年东京奥运会时全面播放4K和8K电视节目),但是8K标准的这些作品目前都还停留在试验和展示的阶段,没有对电影工业制作产生极大的影响。但是可以肯定,这样的画面一定会带给观众不一样的感受,现在8K硬件已经不存在技术上的问题,但是广播内容方面还需要等待。同时市场中编码器、摄像机的革命也在等待行业的变革。

     

    展开全文
  • h265编码1080i50,uyvy422的裸数据,码率为6M,编码器速度配置ultrafast,线程配置8线程编码 top后id为2.5 记录编码一帧h265的视频帧用时,不同时间段随机多次采样为: 88ms,135ms,73ms,58ms,102ms 1080i50帧率...

    h265压缩比为1:200,h264压缩比为1:100,压缩一帧h265理论上比压缩一帧h264多10ms的时间。
    以下数据均来自实测
    在Intel® Core™ i7-6700 CPU @ 3.40GHz 4核8线程中:
    用h265编码1080i50,uyvy422的裸数据,码率为6M,编码器速度配置ultrafast,线程配置8线程编码 top后id为2.5
    值得注意的是crtl+c也是衡量cpu是否过载的方法之一。
    记录编码一帧h265的视频帧用时,不同时间段随机多次采样为:

    88ms,135ms,73ms,58ms,102ms

    1080i50帧率为25帧每秒,每帧间隔是40ms,因此编码严重超时,满足不了帧率。cpu空闲了也用完了,性能已经到瓶颈了。更不可能编码帧率更高的视频了。
    同样的环境配置,编码方式改为h264,测试如下:

    11ms 28ms 29ms 32ms 30ms 40ms 34ms 19ms 35ms 26ms

    id:50
    可以看到跳动还是比较大的,偶尔也会超过40ms,比如记录到一个50ms的,但总体在30ms左右,不影响使用。

    再改变一下,输入视频帧格式改为1080p60。

    视频ctrl+c有延时
    12ms 22ms 15ms 30ms 24ms 25ms 23ms 9ms 33ms 27ms
    id:40

    因此1080p60帧率为60,所以每帧间隔16.6ms,从测试来看,编码器编码一帧耗时太久,丢帧还是比较严重的。因此并不满足工业级生产开发。

    再改变一下,输入视频格式改为1080i60,测试得:

    ctrl+c有延时
    41ms 33ms 36ms 20ms 40ms 18ms 25ms 32ms 46ms 38ms 22ms 19ms 43ms
    id:50

    1080i60帧率为30帧,每帧间隔33.33ms,因此从测试来看,依然丢帧严重。

    再改变一下,输入视频格式改为1080i50,测试得:

    ctrl+c无延时
    正常不丢帧
    id 55

    再改变一下,输入视频格式改为1080i50,四路视频输入,同时编码,编码一个小时,分不同时间段采样,测试得:

    id:25
    25帧 25帧 25帧 25帧 25帧 25帧 25帧 25帧 25帧 25帧 25帧 25帧

    可以看出这个配置编码四路1080i50不会丢帧,音频也无问题。

    在Intel® Core™ i5-6300U CPU @2.40GHz 4核4线程中:
    配置低于上面的i7。
    用h264编码1080p60,uyvy422的裸数据,码率为6M,编码器速度配置ultrafast,线程配置4线程编码。
    不同时段,三次采样分别丢

    13帧,9帧,13帧

    id:21

    视频改为1080i50,无丢帧。

    在Intel® Core™ i5-4460 CPU @ 3.20GHz 4核4线程中(台式机):
    用h264编码1080i50,uyvy422的裸数据,码率为6M,编码器速度配置ultrafast,线程配置4线程编码。测试无丢帧。

    换成Intel® Core™ i5-4200U CPU @ 1.60GHz2核2线程,其他不变,测试一路h264编码id为40,编码一路h264视频粗略约为30ms,另一个电脑ffplay播放后音视频都没问题。因为代码编码使用的是多线程编码。
    如果使用命令:

    ffmpeg -re -stream_loop -1 -i westLife.mp4 -ar 44100 -acodec libfdk_aac -s 1920x1080 -pix_fmt yuv420p -preset ultrafast -vcodec h264 -f mpegts srt://192.168.100.78:8080?streamid=uplive.sls.com/live/test1
    

    编码推流,发现id为2,播放推流的音频卡顿严重。
    (srs是在上面i5-4200U运行的。但如果再运行一路./TestPattern,则id为16,另一个电脑ffplay后音频卡顿。四个线程负载id都在80左右,有时单个id97)。
    此配置当只进行一路h264解码时,音频偶有卡顿,id为85。

    哎呦喂ヾ(✿゚▽゚)ノ~路长馆小,雪轻帘薄,酒热乎,这位爷~您ヾ(✿゚▽゚)ノ~ 里面坐~
    本公众号专注分享C++,ffmpeg,opencv等相关音视频知识
    webrtc,udp,tcp,rtsp,rtmp,srt/nginx+rtmp等流媒体协议和服务器
    同时也会有大厂音视频技术专家不定期直播分享…
    国人开发流媒体srs服务器,及yangrtc(国人版的webrtc)协议新动向
    偶尔分享下程序员梦呓碎碎念(๑•॒̀ ູ॒•́๑)啦啦啦
    目前刚刚开通,接受读者的优质投稿…
    鉴于国内音视频圈子小,起步晚,以致分享少,门槛高,特开通分享,一起扇动这阵风吧!
    微信扫描下方二维码,关注公众号,赶快进入音视频开发者社区吧!

    展开全文
  • STM32F103ZET6使用定时器3驱动步进电机,使用定时器4驱动编码器,并将编码器的值通过串口传到电脑
  • H.265视频编码原理总结

    千次阅读 2022-01-12 16:05:02
    H.265视频编码原理总结 转载地址 1 概述 H.265(HEVC High Efficiency Video Coding)是现行H.264标准于2003年实现标准化以来时隔10年推出的新标准,将成为支撑未来十年的影像服务和产品的视频压缩技术。其特点是,...

    H.265视频编码原理总结

    转载地址

    1 概述

    H.265(HEVC High Efficiency Video Coding)是现行H.264标准于2003年实现标准化以来时隔10年推出的新标准,将成为支撑未来十年的影像服务和产品的视频压缩技术。其特点是,支持1080p以上的4K×2K和8K×4K分辨率,将视频压缩率提高至H.264的约2倍。也就是说,能以原来一半的编码速度发送相同画质的视频。例如,按照20Mbit/秒发送的H.264格式视频内容,在相同画质的条件下用HEVC格式只需10Mbit/秒的速度。

    1.1 H.265发展背景

    H.264虽然是一个划时代的数字视频压缩标准,但是随着数字视频产业链的高速发展,H.264的局限性逐步显现,并且由于H.264标准核心压缩算法的完全固化,并不能够通过调整或扩充来更好地满足当前高清数字视频应用。

    视频应用向以下几个方面发展的趋势愈加明显:

    • 高清晰度:数字视频的应用格式从720P向1080P全面升级,在一些视频应用领域甚至出现了4K×2K、8K×4K的数字视频格式;

    • 高帧率:数字视频帧率从30fps向60fps、120fps甚至240fps的应用场景升级;

    • 高压缩率:传输带宽和存储空间一直是视频应用中最关键的资源,因此,在有限的空间和管道中获得最佳的视频体验一直是用户的不懈追求。

      由于数字视频应用在发展中面临上述趋势,如果继续采用H.264编码就会出现如下一些局限性:

    • 宏块个数的爆发式增长,会导致用于编码宏块的预测模式、运动矢量、参考帧索引和量化级等宏块级参数信息所占用的码字过多,用于编码残差部分的码字明显减少。即:单个宏块所表示的图像内容的信息大大减少,导致4×4或8×8块变换后的低频率相似程度也大大提高,会出现大量的冗余;

    • 分辨率的大幅增加,表示同一个运动的运动矢量的幅值将大大增加,H.264中采用一个运动矢量预测值,对运动矢量差编码使用的是哥伦布指数编码,该编码方式的特点是数值越小使用的比特数越少。因此,随着运动矢量幅值的大幅增加,H.264中用来对运动矢量进行预测以及编码的方法压缩率将逐渐降低;

    • 并行度比较低:H.264的一些关键算法,例如采用CAVLC和CABAC两种基于上下文的熵编码方法、deblock滤波等都要求串行编码,并行度比较低。针对GPU、DSP、FPGA、ASIC等这种并行化程序非常的CPU,H.264的这种串行化处理越来越成为制约运算性能的瓶颈。

    基于上述视频应用的发展趋势和H.264的局限性,面向更高清晰度、更高频率、更高压缩率的高效视频编码标准H.265应运而生。

    HEVC的核心目标:在H.264的基础上,保证相同视频质量的前提下,视频流的码率减少50%。在提高压缩效率的同时,允许编码端适当提高复杂度。

    HEVC的编码框架:沿用H.263的混合编码框架,即用帧间和帧内预测编码消除时间域和空间域的相关性,对残差进行变换编码以消除空间相关性,熵编码消除统计上的冗余度。HEVC在混合编码框架内,着力研究新的编码工具或技术,提高视频压缩效率。

    HEVC的技术创新:基于大尺度四叉树结构的分割技术,多角度帧内预测技术,运动估计融合技术,高精度运动补偿技术,自适应环路滤波技术以及基于语义的熵编码技术。

    1.2 发展历程

    早在2004年,ITU-T视频编码专家组(VCEG)开始研究新技术以便创建一个新的视频压缩标准。在2004年10月,H.264/ AVC小组对潜在的各种技术进行了调查。2005年1月VCEG的会议上,VCEG开始指定某些主题为“关键技术”作进一步研究。2005年成立软件代码库称为Key Technical Areas (KTA)用来评估这些新的“关键技术。KTA的软件是在联合模型(JM)基础上由MPEG和VCEG的视频组联合开发的,项目名称暂定为H.265和H.NGVC(Next-generation Video Coding)。

    按照NGVC的初步要求,在维持视觉HEVC(High efficiency video coding)。质量相同的情况下,比特率较H.264/MPEG-4 AVC的高中档(high profile),计算复杂度维持在比特率较H.264/MPEG-4 AVC的高中档的1/2至3倍之间。 2009年7月,实验结果表明比特率相较于H.264/AVC High Profile平均降低20%左右,这些结果促使MPEG与VCEG合作发起的新的标准化工作。

    2010年1月,VCEG和MPEG开始发起视频压缩技术正式提案。相关技术由视频编码联合组审议和评估,其合作小组第一次会议于2010年4月召开大会,一共有27个完整的提案。评价结果表明,一些提案在许多测试用例可以达到只用一半的比特率并维持H.264相同的视觉质量。在这次会议上,联合项目名改称为高效率的视频编码(HEVC),并且JCT-VC小组把相关技术集成到一个软件代码库(HM)和标准文本草案规范,并进行进一步实验,以评估各项功能。

    2012年2月10日,在美国圣何塞召开了第99届MPEG会议。MPEG组织和ITU-T组织对JCT-VC的工作表示满意,准备于2013年1月,同时在ISO/IEC和ITU-T发布HEVC标准的最终版本。

    2013年1月26日,HEVC正式成为国际标准。总结HEVC发展的标准时间点:

    • 2010年1月,ITU-T VCEG和ISO/IEC MPEG联合成立JCT-VC联合组织,统一制定下一代编码标准:HEVC;

    • 2012年2月,委员会草案通过了HEVC;

    • 2012年7月,HEVC国际标准草案获得通过;

    • 2013年1月,国际标准最终获得通过。

    1.3 应用领域

    伴随着每次视频压缩技术的进化,会产生多种影像服务和产品的诞生,如图1.1所示。1995年实现标准化的MPEG-2得到了DVD和数字电视等领域采用,大幅扩大了视频压缩技术的应用范围。MPEG-4在1998年实现标准化后,立即应用到了移动和互联网视频服务领域。伴随视频压缩技术的升级,各种影像服务和产品随之登场。2013年以后,随着HEVC的出现,4K及8K电视及网络全高清影像服务也纷纷出现。箭头指示的是各服务和产品主要采用的压缩技术。

    img

    图****1.1 视频压缩技术及对应的影像服务和产品的历史

    HEVC的应用示意图如图1.2所示。在广播电视、网络视频服务、电影院及公共大屏幕等众多领域,4K×2K和8K×4K视频发送将变得更容易实现。个人电脑及智能手机等信息终端自不用说,平板电视、摄像机及数码相机等AV产品也会支持HEVC。不仅是这些既有市场,HEVC还有可能在今后有望增长的新市场上大显身手。例如,影像监控系统就是其中之一。影像监控系统最近几年在快速从原来的模拟摄像头组合VTR的方式,向经由IP网络发送、存储和浏览数码摄像头拍摄的视频的方法过渡。为提高安全性,需要增加摄像头数量、提高影像的精细度,而与此同时,确保网络频带和存储容量增加。估计HEVC将作为解决这些课题的措施而被得到应用。

    img

    1.2 HEVC的应用示例

    1.4 优缺点

    优点:

    • 高压缩率:在视频质量相同的条件下,较264平均减少50%的码流,可以节省大量的网络带宽及存储空间;可以在相同码流的条件下提供更加高质量的视频
    • 支持8192×4320分辨率

    缺点:

    • HEVC使用到的技术和算法较前两代标准264和MPEG-2更为复杂,视频流在压缩过程中需要更多的选择和运算。
    • HEVC不支持大多数硬件,通常需要效率更高,更多的处理器来辅助,这意味着,如果有一个固件需要更新,而编解码器却跟不上升级速度的话,那么我们的电视机顶盒和蓝光播放机是无法播放HEVC编码内容的,需要等待解决方案出现后才能继续使用。

    2 基础概念及算法

    2.1 码率

    视频码率是视频数据(视频色彩量、亮度量、像素量)每秒输出的位数。一般用的单位是kbps。

    在视频会议应用中,视频质量和网络带宽占用是矛盾的,通常情况下视频流占用的带宽越高则视频质量也越高;如要求高质量的视频效果,那么需要的网络带宽也越大;解决这一矛盾的钥匙当然是视频编解码技术。评判一种视频编解码技术的优劣,是比较在相同的带宽条件下,哪个视频质量更好;在相同的视频质量条件下,哪个占用的网络带宽更少。

    码率越高理论上意味着质量越好,但是在肉眼分辨的范围内,码率高到一定程度就没什么差别了。所以码率设置有最优值,以H.264文档中视频建议的码率:

    视频大小分辨率建议码率
    480P720X4801800Kbps
    720P1280X7203500Kbps
    1080P1920X10808500Kbps

    2.2 帧率

    是用于测量显示帧数的量度。所谓的测量单位为每秒显示帧数或“赫兹”。区别与码率,帧率是记录显示帧数的量度,而码率是数据传输时单位时间传送的数据位数。

    由于人类眼睛的特殊生理结构,如果所看画面之帧率高于16的时候,就会认为是连贯的,此现象称之为视觉停留。这也就是为什么电影胶片是一格一格拍摄出来,然后快速播放的。

    而对游戏,一般来说,第一人称射击游戏比较注重FPS的高低,如果FPS<30的话,游戏会显得不连贯。所以有一句有趣的话:“FPS(指FPS游戏)重在FPS(指帧率)。

    每秒的帧数(fps)或者说帧率表示图形处理器处理场时每秒钟能够更新的次数。高的帧率可以得到更流畅、更逼真的动画。一般来说30fps就是可以接受的,但是将性能提升至60fps则可以明显提升交互感和逼真感,但是一般来说超过75fps一般就不容易察觉到有明显的流畅度提升了。

    如果帧率超过屏幕刷新率只会浪费图形处理的能力,因为监视器不能以这么快的速度更新,这样超过刷新率的帧率就浪费掉了。

    2.3 量化参数QP

    QP是量化步长(Qstep)的序号,对于亮度编码而言,量化步长共有52个值,QP取值051,对于色度编码QP的取值039。

    量化参数,反映了空间细节压缩情况。值越小,量化越精细,图像质量越高,产生的码流也越长。QP 小,大部分的细节都会被保留,码率增大。QP 增大,一些细节丢失,码率降低,但图像失真加强和质量下降。也就是说,QP 和比特率成反比的关系,而且随着视频源复杂度的提高,这种反比关系会更明显。

    img

    img

    2.4 GOP

    GOP(Group Of Pictures, 图像组)是一组连续的图像,由一个I帧和多个B/P帧组成,是编解码器存取的基本单位。GOP结构常用的两个参数M和N,M指定GOP中首个P帧和I帧之间的距离,N指定一个GOP的大小。例如M=1,N=15,GOP结构为:IPBBPBBPBBPBBPB,GOP有两种:闭合式GOP和开放式GOP:

    闭合式GOP:闭合式GOP只需要参考本GOP内的图像即可,不需参考前后GOP的数据。这种模式决定了,闭合式GOP的显示顺序总是以I帧开始以P帧结束

    开放式GOP :开放式GOP中的B帧解码时可能要用到其前一个GOP或后一个GOP的某些帧。码流里面包含B帧的时候才会出现开放式GOP。

    开放式GOP和闭合式GOP中I帧、P帧、B帧的依赖关系如下图所示:

    img

    2.5 失真

    衡量失真的三种准则:

    • 均方差MSE
    • 信噪比SNR
    • 峰值信噪比PSNR

    2.6 量化

    1、大概的公式:l = floor(c/Qstep + f),c表示系数、Qstep表示量化步长、l表示量化后的值,floor是向下取整函数,f控制舍入关系

    2、HEVC有52个量化步长,对应了52个量化参数QP,可以通过查表查询

    3、对于色度分量,量化参数限制为045。具体的说,当亮度分量的QP小于30时,色度分量的QP和亮度的相同,当亮度信号QP在3051时,两者的关系可以通过查表得出

    4、量化过程同时要完成整数DCT中的比例缩放运算,为了避免浮点计算,HEVC把分子分母进行放大处理,然后取整,以此保证运算精度,QP的运算方式也要进行调整:QP = floor(QP/6) + QP % 6

    5、总的量化公式:

    img

    2.7 率失真优化

    1、分层递归遍历所有的CU划分模式,选取最优的CU划分模式,这个过程称为CU划分模式判别

    2、对于其中的每一个CU,遍历所有的PU模式,选取最优的PU模式,并在此基础上选择最优的TU模式

    3、对于其中的每一个PU,遍历所有的预测模式,选取最优的预测模式,这个过程称为预测模式判别

    (1)帧内预测模式。

    ​ ①遍历所有的预测模式,得到每种模式下的残差信号,再对残差信号进行Hadamard变换计算SATD值

    ​ ②利用SATD值计算每种预测模式的率失真代价,选取率失真代价最小的几种模式(与PU大小相关)为预测模式集

    ​ ③将已编码相邻块的预测模式补充到预测模式集中

    ​ ④遍历模式集合中的所有模式,并对残差信号进行正常编码(熵编码),计算率失真代价

    ​ ⑤选取最优的预测模式作为该PU的最优模式

    ​ ⑥当亮度块的模式确定之后,把该模式以及DC、planar、水平方向模式、垂直方向模式作为色度块的候选模式,选取最优的模式即可

    (2)帧间预测模式。

    ​ HEVC采用了Merge和AMVP技术,更加高效地表示帧间预测参数,但是这两种方式有比较大的区别,因此帧间预测可以分成Merge帧间预测模式和非Merge帧间预测模式(采用AMVP技术),分别选取最优的Merge帧间预测模式和非Merge帧间预测模式,然后从中选取最优的模式。

    ​ 对于Merge帧间预测模式,遍历所有的候选模式,计算率失真代价,选择率失真代价最小的模式为最优模式。当采用merge帧间预测模式I按摩,且预测残差信号的编码比特数为零时,只需要编码skip标识和merge索引两个语法元素,此时该模式称为MODE_SKIP模式

    ​ 对于非Merge帧间预测模式(采用AMVP技术)

    ​ ①根据AMVP技术确定MVP列表,计算每个MVP的率失真代价,得到最优的MVP

    ​ ②以最优MVP为起始点,进行整像素运动预测,得到最优的整像素运动矢量

    ​ ③以整像素运动矢量为中心,进行半像素搜索,从周围的8个点确定最优的半像素精度运动矢量

    ​ ④以半像素精度矢量为中心,进行1/4像素精度的运动搜索,确定最优的1/4像素精度运动矢量

    (3)PU模式判别

    ​ ①计算2Nx2N模式的率失真代价,将其作为最优代价,如果预测残差的编码比特数为零,那么满足CBF_Fast,直接跳至⑪,并将2Nx2N作为最优的PU模式

    ​ ②如果CU的深度已经取得最大值,且inter_4x4_enabled_flag是1,那么执行③,否则执行④

    ​ ③计算NxN模式的率失真,更新最优代价和模式,如果预测残差的编码比特数为零,那么满足CBF_Fast,直接跳至⑪,并将NxN作为最优的PU模式

    ​ ④计算Nx2N模式的率失真代价,更新最优代价和模式,如果预测残差的编码比特数为零,那么满足CBF_Fast,直接跳至⑪,并将Nx2N作为最优的PU模式

    ​ ⑤计算2NxN模式的率失真代价,更新最优代价和模式,如果预测残差的编码比特数为零,那么满足CBF_Fast,直接跳至⑪,并将2NxN作为最优的PU模式

    ​ ⑥如果TestAMP_Hor为1,当前CU执行水平方向上的AMP模式,否则执行本步骤。计算2NxnU模式的率失真代价,更新最优代价和模式,如果预测残差的编码比特数为零,那么满足CBF_Fast,直接跳至⑪,并将2NxnU作为最优的PU模式;否则计算2NxnD模式的率失真代价,更新最优的代价和模式,如果预测残差的编码比特数为零,那么满足CBF_Fast,直接跳至⑪,并将2NnD作为最优的PU模式

    ​ ⑦如果TestAMP_Ver为1,当前CU执行垂直方向上的AMP模式,否则执行本步骤。计算nLx2N模式的率失真代价,更新最优模式和代价,如果预测残差的编码比特数为零,那么满足CBF_Fast,直接跳至⑪,并将nLx2N作为最优的PU模式;否则计算nRx2N模式的率失真代价,更新最优模式和代价,如果预测残差的编码比特数为零,那么满足CBF_Fast,直接跳至⑪,并将nRx2N作为最优的PU模式

    ​ ⑧注意上面的都是帧间的模式,现在需要计算帧内2Nx2N模式的率失真代价,更新最优模式和代价

    ​ ⑨如果当前CU深度为最大值,计算帧内NxN模式的率失真代价,更新最优模式和代价

    ​ ⑩如果当前CU大于或等于PCM模式所允许的最小单元,并且代价大于PCM模式,那么更新最优模式和代价

    ​ ⑪结束搜索,得到最优的PU模式。注意对于每一种PU模式,都要夯实不同的TU划分,选取最优的TU模式,因此最优的PU模式包含了最优的TU模式

    (4)CU划分模式判决

    ​ ①把CTU作为CU,计算率失真代价(最优PU模式时),此时应包含CU分割标志(split_flag)的编码比特数

    ​ ②对CU进行四叉树划分,计算每个子CU的最小率失真代价,并对所有子CU的率失真代价求和,得到该CU的率失真代价

    ​ ③为每个子CU作为CU重复②

    ​ ④重复③直到编码的最大深度

    ​ ⑤从最大的编码深度,比较4个子CU与CU的率失真代价,一次选出最优的划分方式。

    ​ ⑥对于每个CU,如果其帧间2Nx2N模式为MODE_SKIP,则满足Early_SKIP条件,直接结束该CU的进一步划分

    3 编解码技术

    3.1 H.265编码框架及编码单元结构

    与H.263以来的编码标准一样,HEVC的设计沿用了经典的基于块的混合视频编码框架。框架主要包括,帧内预测、帧间预测、转换、量化、去区块滤波器、熵编码等模块,但在HEVC编码架构中,整体被分为了三个基本单位,分别是:编码单位(coding unit,CU)、预测单位(predict unit,PU)和转换单位(transform unit,TU)。

    img

    img

    1.3 HEVC编码框架

    视频编码的基本流程为:将视频序列的每一帧划为固定大小的宏块,通常为16×16像素的亮度分量及2个8×8像素的色度分量,之后以宏块为单位进行编码。对视频序列的第一帧及场景切换帧或者随机读取帧采用I帧编码方式,I帧编码只利用当前帧内的像素空间预测,类似于JPEG图像编码方式。其大致过程为,利用帧内先前已经编码中的像素对当前块内的像素值作出预测(对应图中的帧内预测模块),将预测值与原始视频信号作差运算得到预测残差,再对预测残差进行变换、量化及熵编码形成编码码流。对其余帧采用帧间编码方式,包括前向预测P帧和双向预测B帧,帧间编码是对当前帧内的块在先前已编码帧中寻找最相似块(运动估计)作为当前块的预测值(运动补偿),之后如I帧的编码过程对预测残差进行编码。编码器中还含有一个解码器,模拟解码过程以获得解码重构图像,作为编码下一帧或下一块的预测参考。解码步骤包括对变换量化后的系数激进型反量化、反变换,得到预测残差,之后预测残差与预测值相加,经滤波去除块效应后得到解码重构图像。

    img

    图****1.4 帧内预测编码图

    img

    图****1.5 帧间预测编码图

    HEVC以LCU块为单位对输入视频进行处理,首先是预测,有两种模式:帧内预测与帧间预测。

    帧内预测,即利用当前图像内已编码像素生成预测值;

    帧间预测,即利用当前图像之前已编码图像的重建像素生成预测值。

    3.2 编码单元结构

    H.264通常会以16×16像素为单位,将图片划分为多个大小相同的宏块,并以这些宏块作为编码时的最小元素。H.265则是将切割画面的工作从使用者手工设定,转交给编码器来决定,让编码器视情况以16×16、32×32、64×64等尺寸,将画面切割为数个编码树单元,一般来说区块尺寸越大,压缩效率就越好。

    img

    图****2.1 左图是H.264标准,每个宏块大小都是固定的;

    右图是H.265标准,编码单元大小是根据区域信息量来决定的

    H.265没有沿用之前H.264之前宏块的概念,而是使用编码单元(CU)作为及基本的编码结构。一个CU可以包含一个或多个不同尺寸的预测单元PU,一个PU包含若干个变换单元(TU)。CU、PU、TU三种在编码中起的作用不一样,不过这种编码方式还是基于混合编码,只是采用这种划分方式能够更好地分割一幅图像,用于后续的预测和处理。采用这种结构设计的目的是在增加灵活性的同时,使压缩预测更符合图像特性。

    1. 编码基本单元(CU)

    CU的特点是方块,在LCU基础上划分的,通常LCU的大小64×64,可以使用递归分割四叉树的方法来得到,大的CU适用于图像中比较平滑的部分,而小的CU则适用于边缘和纹理较丰富的区域。采用大尺寸CU主要是为了高清压缩编码的应用,毕竟如1080p甚至更大分辨率的视频图像,其空间会有更大面积的一致性,因此采用更大的编码单元能更有效地减少空间冗余。

    编码单元是否被划分取决于分割标志位split flag。0表示不再进行四叉树划分,1表示继续划分为4个独立的编码单元。

    img

    图****2.2 图像划分结构示意图

    如果仍采用光栅扫描方式对CU寻址会很不方便,因此,H.265定义了Z扫描顺序,如图2.3所示。这种顺序保证了对于不同分割都能按照相同的遍历顺序进行寻址有利于程序中递归实现。

    img

    2.3 Z扫描方式

    2.预测单元(PU)

    PU是基本的预测单元,是在编码单元CU的基础上进行划分的,有skip、intra、inter三种模式可以分割,每个CU中可以包含一个或者多个PU。PU可以是正方形的,也可以是长方形的,这是为了能够更好地区分背景与物体,如图2.4所示。

    img

    2.4 PU划分图

    如图2.5所示,PU的划分方式可分为对称及不对称两种,要注意的是PU的尺寸不能超过其所属的CU。不对称的划分方式主要适用于CU中纹理偏差比较大的情况,增加预测的精准度,不对称的PU仅适用于帧间预测。

    img

    2.5 PU划分方式

    3.变换单元(TU)

    TU是变换及量化的基本单元,它可以大于PU但是不能大于CU的大小。TU同样采用二叉树的分割结构,所支持的尺寸从4×4至32×32的大小。TU的形状取决于PU的划分模式,当PU为正方形时,TU也是正方形的,当PU是长方形的,TU也是长方形的,一个CU可以包含一个或多个TU。

    根据预测残差的局部变化特性,TU可以自适应地选择最优的模式。大块的TU模式能够将能量更好地集中,小块的TU模式能够保存更多的图像细节。这种灵活的分割结构,可以使变换后的残差能量得到充分压缩,以进一步提高编码增益。

    img

    2.6 TU划分图

    总结:如图2.7,可以形象地展示CU、PU及TU之间的关系。

    img

    图****2.7 划分关系

    3.3 帧内预测

    利用图像的空间相关性,用周围重建像素值对当前编码块进行预测 。

    H.265更多的帧内预测方向,在H.264采用9个帧内预测方向的场合,,H.265预测方向拓展到33个,另外加上一个DC和一个planar,一共35中预测模式,使得预测更加精细,增加更多提升更高效帧内压缩的可能的参考像素块。明显的代价是在增加的方向中搜索需要更多编码时间。

    img

    图****2.8 帧内预测模式

    Planar模式

    平面预测是一种新提出的预测方法,常用于内容平滑或纹理不清晰的单元。它为预测单元中的每一个像素点也都要进行插值预测,如图所示。首先根据左侧相邻单元的右下角像素和上方相邻单元的下边界像素插值出当前预测单元下边界的每个像素点,再根据上方相邻单元的右下角像素和左侧相邻单元的右边界像素插值出当前预测单元右边界的每个像素点,然后利用上方相邻单元的下边界、左侧相邻单元的右边界以及插值出的当前单元的下边界和右边界插值出其余的像素点。

    img

    2.9 Planar插值预测

    3.4 帧间预测

    帧间预测利用连续图像之间的相关性,通过运动估计和运动补偿的编码方法去消除视频信息的时间冗余。利用先前已编码重建帧作为参考帧进行预测。

    • 帧间预测采用融合模式时,当前PU块的运动信息(包括运动矢量、参考索引、预测模式)都可以通过相邻PU的运动信息推导得到。编码时,当前PU块只需要传送融合标记(Merge Flag)以及融合索引(Merge Index),无需传送其运动信息。

    • 帧间预测还可以通过空域相邻PU以及时域相邻PU的运动矢量信息构造出一个预测运动矢量候选表,PU遍历运动矢量候选列表,在其中选择最佳的预测运动矢量。

    3.4.1 广义B帧预测技术

    在高效预测模式下,H.265仍然采用H.264中的等级B帧预测方式,同时还增加了广义B帧(GPB)预测方式取代低时延应用场景中的P帧预测方式。GPB预测结构是指传统P帧采取类似与B帧的双向预测方式进行预测。在这种预测方式下,前向和后向参考列表中的参考图像必须为当前图像之前的图像,且两者为同一图像。对P帧采取B帧的运动预测方式增加了运动估计的准确度,提高了编码效率,同时也有利于编码流程的统一。

    3.4.2 去块滤波(Debtock)

    去块滤波位于反变换之后,主要是去除诗篇压缩过程中产生的方块效应。首先对垂直边界进行水平滤波,先亮度块后色度块;再对水平边界进行垂直滤波,先亮度块后色度块。H.265对8x8块的边界进行滤波,与H.264中对4x4边的边界进行滤波相比,H.265中去块滤波算法的时间复杂度有所降低。

    3.4.3 采样点自适应偏移(SAO)

    把一帧划分为若干个LCU,然后对每个LCU中每个像素进行SAO操作,将根据其LCU像素特征选择一种像素补偿方式,以减少源图像与重构图像之间的失真。自适应样点补偿方式分为带状补偿(BO)和边缘补偿(EO)两类。

    1. 带状补偿

    带状补偿将像素值强度等级划分为若干个条带,每个条带内的像素拥有相同的补偿值。进行补偿时根据重构像素点处的条带,选择相应的带状补偿值进行补偿。

    现有的HM模型将像素值强度从0到最大值划分为32个等级。同时这32个等级条带还分为两类,第一类是位于中间的16个条带,剩余的16个条带是第二类。编码时只将其中一类具有较大补偿值的条带偏移信息写入片头;另一类条带信息则不传送,这样的方式编码将具有较小偏移值的一类条带忽略不计,从而节省了编码比特数。

    img

    \2. 边缘补偿

    边缘补偿主要用于对图像的轮廓进行补偿。它将当前像素值与相邻的2个像素值进行对比,用于比较的2个相邻像素可以在下图中所示的4中模板中选择,从而得到该像素点的类型。解码端根据码流中标识的像素点的类型信息进行相应的补偿校正。

    img

    3.4.4 自适应环路滤波(ALF)

    ALF在编解码环路内,位于Debtock和SAO之后,用于恢复重建图像以达到重建图像与原始图像之间的均方差(MSE)最小。ALF的系数是在帧级计算和传输的,可以整帧应用ALF,也可以对于基于块或基于量化树的部分区域进行ALF,如果是基于部分区域的ALF,还必须传递指示区域信息的附加信息。

    对于亮度分量,采用CU为单位的四叉树ALF结构。滤波使用5x5,7x7和9x9三种大小的二维钻石型模板。滤波器计算每个4x4块的Laplacian系数值,并根据该值将所有4x4块分成16类,分别对应16种滤波器。

    img

    2.10 ALF滤波模板

    对于色度分量,滤波时色度分量统一使用5x5矩形滤波模板,不需要通过Laplacian系数来选择滤波器类型。

    3.5 并行设计

    当前芯片架构已经从单核性能逐渐往多核并行方向发展,因此为了适应并行化程度非常高的芯片实现,H.265引入了很多并行运算的优化思路。

    3.5.1 Tile

    用垂直和水平的边界将图像划分为一些行和列,划分出的矩形区域为一个Tile,每个Tile包含整数个LCU,Tile之间可以互相独立,以此实现并行处理。

    img

    2.11 Tile划分示意图

    3.6 熵编码

    H.265的熵编码只采取基于上下文的二进制熵编码算法(CABAC),在本质上与H.264的CABAC是一致的,只是在实现细节上有些差别。H.265减少了上下文的数量,以改进熵编码的性能和编码速度。

    3.7 变换量化

    H.265的变换支持4x4到32x32,比H.264增加了16x16和32x32两种变换核。在H.264中,一个宏块只能采用一种变换核,而H.265提供了残差四叉树(RQT)的递归变换结构,对于一个CU或者PU,可以采用多种变换核。

    另外,对于4x4的TU,H.265提供了跳过变换模式,在这种模式中,预测残差只进行移位。对于帧间预测的4x4变换块,H.265还提供了离散正弦变换(DST)。在量化方面,H.265采用了与H.264相同的量化方法,H.265还提供了率失真优化量化方法(RDOQ)方法。率失真优化量化就是在量化过程中引入率失真优化选择的思想,具体可以分为三个步骤:

    1. 对当前处理的TU,以4x4的块为单位进行扫描,对于4x4量化块的每个量化值,分别加一减一,这样就得到三个量化值,根据率失真代价最小准则对4x4量化块的每一个点选择最佳的量化值;

    2. 对于扫描到的每一个4x4的量化块,将其量化值设置为零,并与之前的率失真代价比较,选择一种最佳的量化方式;

    3. 对于当前TU来说,若最后一个非零系数的位置距离当前一个非零系数的位置较远,则将最后一个非零系数改为零,同时比较这种方式下的率失真代价并与之前的率失真代价进行比较,选择一种最佳的方式。

    4 码流结构分析

    4.1 重要参数

    4.1.1 视频参数集VPS(Video Parameter Set)

    VPS主要用于传输视频分级信息,有利于兼容标准在可分级视频编码或多视点视频的扩展。

    1. 用于解释编码过的视频序列的整体结构,包括时域子层依赖关系等。HEVC中加入该结构的主要目的是兼容标准在系统的多子层方面的扩展,处理比如未来的可分级或者多视点视频使用原先的解码器进行解码但是其所需的信息可能会被解码器忽略的问题。
    2. 对于给定视频序列的某一个子层,无论其SPS相不相同,都共享一个VPS。其主要包含的信息有:多个子层或操作点共享的语法元素;档次和级别等会话关键信息;其他不属于SPS的操作点特定信息。
    3. 编码生成的码流中,第一个NAL单元携带的就是VPS信息

    4.1.2 序列参数集SPS(Sequence Parameter Set)

    包含一个CVS中所有编码图像的共享编码参数。

    1. 一段HEVC码流可能包含一个或者多个编码视频序列,每个视频序列由一个随机接入点开始,即IDR/BLA/CRA。序列参数集SPS包含该视频序列中所有slice需要的信息;
    2. SPS的内容大致可以分为几个部分:1、自引ID;2、解码相关信息,如档次级别、分辨率、子层数等;3、某档次中的功能开关标识及该功能的参数;4、对结构和变换系数编码灵活性的限制信息;5、时域可分级信息;6、VUI。

    4.1.3 图像参数集PPS(Picture Parameter Set)

    包含一幅图像所用的公共参数,即一幅图像中所有片段SS(Slice Segment)引用同一个PPS。

    1. PPS包含每一帧可能不同的设置信息,其内容同H.264中的大致类似,主要包括:1、自引信息;2、初始图像控制信息,如初始QP等;3、分块信息。
    2. 在解码开始的时候,所有的PPS全部是非活动状态,而且在解码的任意时刻,最多只能有一个PPS处于激活状态。当某部分码流引用了某个PPS的时候,这个PPS便被激活,称为活动PPS,一直到另一个PPS被激活。

    参数集包含了相应的编码图像的信息。SPS包含的是针对一连续编码视频序列的参数(标识符seq_parameter_set_id、帧数及POC的约束、参考帧数目、解码图像尺寸和帧场编码模式选择标识等等)。PPS对应的是一个序列中某一幅图像或者某几幅图像 ,其参数如标识符pic_parameter_set_id、可选的seq_parameter_set_id、熵编码模式选择标识、片组数目、初始量化参数和去方块滤波系数调整标识等等。

    通常,SPS 和PPS 在片的头信息和数据解码前传送至解码器。每个片的头信息对应一个pic_parameter_set_id,PPS被其激活后一直有效到下一个PPS被激活;类似的,每个PPS对应一个seq_parameter_set_id,SPS被其激活以后将一直有效到下一个SPS被激活。参数集机制将一些重要的、改变少的序列参数和图像参数与编码片分离,并在编码片之前传送至解码端,或者通过其他机制传输。

    4.2 NALU type

    前缀码后面跟随的前两个字节为NALU的语法元素,主要有四个部分组成:

    • forbidden_zero_bit = 0:占1个bit,与H.264相同,禁止位,用以检查传输过程中是否发生错误,0表示正常,1表示违反语法;
    • nal_unit_type = 32:占6个bit,用来用以指定NALU类型
    • nuh_reserved_zero_6bits = 0:占6位,预留位,要求为0,用于未来扩展或3D视频编码
    • nuh_temporal_id_plus1 = 1:占3个bit,表示NAL所在的时间层ID

    NALU的语法元素由H264的一个字节变为两个字节,而nal_unit_type则为NALU的类型,因此我们可以通过以下获取NALU的类型:

    int type = (code & 0x7E)>>1;

    nal_unit_typeNALU类型备注
    0NAL_UNIT_CODE_SLICE_TRAIL_N非关键帧
    1NAL_UNIT_CODED_SLICE_TRAIL_R
    2NAL_UNIT_CODED_SLICE_TSA_N
    3NAL_UINT_CODED_SLICE_TSA_R
    4NAL_UINT_CODED_SLICE_STSA_N
    5NAL_UINT_CODED_SLICE_STSA_R
    6NAL_UNIT_CODED_SLICE_RADL_N
    7NAL_UNIT_CODED_SLICE_RADL_R
    8NAL_UNIT_CODED_SLICE_RASL_N
    9NAL_UNIT_CODE_SLICE_RASL_R
    10 ~ 15NAL_UNIT_RESERVED_X保留
    16NAL_UNIT_CODED_SLICE_BLA_W_LP关键帧
    17NAL_UNIT_CODE_SLICE_BLA_W_RADL
    18NAL_UNIT_CODE_SLICE_BLA_N_LP
    19NAL_UNIT_CODE_SLICE_IDR_W_RADL
    20NAL_UNIT_CODE_SLICE_IDR_N_LP
    21NAL_UNIT_CODE_SLICE_CRA
    22 ~ 31NAL_UNIT_RESERVED_X保留
    32NAL_UNIT_VPSVPS(Video Paramater Set)
    33NAL_UNIT_SPSSPS
    34NAL_UNIT_PPSPPS
    35NAL_UNIT_ACCESS_UNIT_DELIMITER
    36NAL_UNIT_EOS
    37NAL_UNIT_EOB
    38NAL_UNIT_FILLER_DATA
    39NAL_UNIT_SEIPrefix SEI
    40NAL_UNIT_SEI_SUFFIXSuffix SEI
    41 ~ 47NAL_UNIT_RESERVED_X保留
    48 ~ 63NAL_UNIT_UNSPECIFIED_X未规定
    64NAL_UNIT_INVALID

    type值所代表的类型:VPS=32 SPS=33 PPS=34 IDR=19 P=1 B=0

    img

    2.12 H.265输出码流

    如上我们看到了四个NALU包,每个NALU的头部信息为:

    ① 00 00 00 01 40 01 —> (0x40 & 0x7E)>>1 = 32 —> VPS

    ② 00 00 00 01 42 01 —> (0x42 & 0x7E)>>1 = 33 —> SPS

    ③ 00 00 00 01 44 01 —> (0x44 & 0x7E)>>1 = 34 —> PPS

    ④ 00 00 00 01 26 01 —> (0x26 & 0x7E)>>1 = 19 —> IDR

    展开全文
  • Windows 10用的免费HEVC/H265解码(转发) 这几天发现好多HEVC的视频居然在Win10 Explorer里面没有缩略图,一查才发现居然Win10没有自带HEVC解码。 到微软商店一搜,HEVC Video Extensions,居然还要卖钱。微软...
  • 多摩川编码器读取程序,支持多摩川ADM485协议,在STM32F4上实验读取TS5668N21成功。
  • 硬件编码相关知识(H264,H265)

    千次阅读 2020-10-23 10:54:11
    阅读人群:研究硬件编码器应用于iOS开发中,从0研究关于硬件编解码,码流中解析数据结构 内容概述:关于H264,H265的背景,数据结构,在iOS开发中编解码的应用 ---------------------------------------------------...
  • 背景 在刚提出4K视频的时候,大多数人都觉得没有必要,4K的...4K视频具有高分辨率、宽色域、高动态范围等优势,随着5G技术和H.265(HEVC)编码标准的出炉,4K视频直播迎来了曙光。 一张图解释4K VS 1080P 1080p Ofte
  • 解码h264和h265需要的cpu性能

    千次阅读 2022-01-07 17:45:14
    在Intel® Core™ i5-4460 CPU @ 3.20GHz 4核4线程中,视屏1080i50,12M,一路Testpattern h264解码,id为83,播放出来后音频偶尔卡顿,不明显,但缺乏长时间压力的测试。 两路的话,id为47,但Testpattern声音卡顿较...
  • ijkplayer播放器h265解码能力调研

    千次阅读 2019-09-24 12:21:07
    H.264: H.264/AVC项目的目的是为了创建一个比以前的视频压缩标准,在更低的比特率的情况下依然能够提供良好视频质量的标准(如,一半或者更少于MPEG-2,H.263,或者MPEG-4 Part2 )。同时,还要不会太大的增加设计的...
  • 使用FFmpeg调用NVIDIA GPU实现H265转码H264背景H265H264一些基本知识H265码流nalu头H264码流nalu头补充:IDR帧和I帧的关系转码的一些基本知识软编码和硬编码如何区分软编码和硬编码比较目前的主流GPU加速平台目前...
  • 硬件加速 - H264(NVIDIA® NVENC)如果您使用高端NVIDIA显卡并...支持 Nvidia NVENC 编码器的环境:显卡GTX 600系列或更高版本。显卡GTX 950系列或更高版本(Maxwell,GM20x)-(该环境使用 “H.264” 比 “NVENC” 好...
  • VP9编码器 v1.3.0

    热门讨论 2014-01-07 18:41:37
    VP9相比VP8有着很多的提升。在比特率方面,VP9比VP8提高2倍图像画质,H265的画质也比H264高2倍。VP9一大的优势是没有版税。和H.264和H.265不同,它免费进行使用。
  • iOS H264,H265视频编码(Video encode)

    千次阅读 2018-02-23 09:50:27
    本例需求:使用H264, H265实现视频数据的编码并录制开始200帧存为文件. 原理:比如做直播功能,需要将客户端的视频数据传给服务器,...H264进行编码,iOS 11 之后,iPhone 7以上的设备可以支持新的编码器H265编码器...
  • 如果你尝试过渲染一段视频,或者做直播推流,一定会知道有H.264这么个东西,后来又出现了个H.265,这又是什么呢?其实他们都属于视频的编码格式,而我们平时所说的MP4、AVI、FLV、MOV这些,都属于封装格式,也就是一...
  • 编码器支持 MPEG-4、H.263 和 H.264视频,以及16MP JPEG 图像,适合要求超低功率的设备的芯片组,这些设备包括便携式摄像机、移动电话、远程安全摄像机、笔记本电脑和网络摄像机。Hantro 7280具有每秒30 帧、每帧...
  • 佳能EOS R5不仅支持8K,而且支持H.265/HEVC的MOV视频编码,如果有遇到佳能EOS R5拍摄电量不足等中断导致的DAT文件,一定很想知道这个DAT文件还能不能修复或者转为MOV的视频格式。首先明确一点,如果文件不0字节的,...
  • H265简介

    千次阅读 2013-11-08 11:47:16
    H.265是ITU-T VCEG 继H.264之后所制定的新的视频编码标准。H.265标准围绕着现有的视频编码标准H.264,保留原来的某些技术,同时对一些相关的技术加以改进。新技术使用先进的技术用以改善码流、编码质量、延时和算法...
  • ENC5 H264/5 4K高清编码器使用说明书

    千次阅读 2019-07-02 16:33:14
    ENC5 H264/5 4K高清编码器使用说明书第一章. 产品介绍第二章. 接口说明第三章. 技术规格与指标 第一章. 产品介绍     ENC5高清编码器是有5个HDMI输入接口,每个HDMI接口都支持4K@30输入。该产品是由广州灵派科技...
  • 2.5.Construct decoder ([g] and [h]) 如编码器中所述,标签输入被嵌入到向量中并被整形以用作解码器的输入。 embeddingDimension = 20; % 标签调整后的大小 projectionSize = [1 1]; layers = [ % 对标签进行编码...
  • 高清视频网络编码器在同一个局域网内,将视频源设备,视频编码器,以及设置控制编码器所要用到的电脑串联在一起。 视频网络编码器将视频编码后用RTMP协议将视频流推送到流媒体服务器。视频直播编码器一般都支持RTP/...
  • 使用X265编码视频

    千次阅读 2021-12-09 08:28:30
    使用X265编码视频 环境准备 使用hg 下载x264源码 https://www.videolan.org/developers/x265.html 如果电脑之前没有安装过 hg,yasm,nasm 可以使用 brew 安装一下 brew install hg brew install yasm brew ...
  • 2003年,编解码器h.264(商业名称为AVC)发布。 它现在是视频压缩的行业标准,因为它提供了良好的压缩,几乎可以在任何设备和平台上播放。 所有现代浏览器,操作系统和移动平台都支持h.264。 H.265 / HEVC 经过IT...
  • 是一款免费开源跨平台的优秀的现代化视频格式转换软件,由于图标是一个可口诱人的大菠萝水果,所以也叫大菠萝转换,能帮助大家将包括.MP4(.M4V) 和 .MKV、H.265(x265 和 QuickSync)、H.264(x264 和 QuickSync...
  • #Unity 视频编码器问题解决方案(视频卡顿,花屏,黑屏) 1、用“格式工厂”从新输出“H264”格式 or 其他 MP4解码器格式 ...4、如果原视频是H265的格式,电脑安装H265的微软解码器,avpro都不需要修改,应该就可以解决
  • Android音视频【一】H264编码基础

    千次阅读 2020-12-12 15:48:10
    音视频编码解码就是指通过特定的压缩/解压技术...当然还有比H264更好的H265编码H265是基于H264优化的。 1.H264标准的演进 国际上主流制定视频编解码技术的组织有两个,一个是国际电联(ITU-T),它制定的标准有H.261
  • h265初创公司

    千次阅读 2015-05-11 11:35:15
    h265创业公司: http://www.realpower265.com/ ...去年八月,爱立信公司推出了首款H.265编解码,而在仅仅六个月之后,国际电联(ITU)就正式批准通过了HEVC/H.265标准,标准全称为高效视频编码(High Efficiency
  • HandBrake中文版是一款免费开源跨平台的优秀的现代化视频格式转换软件,由于图标是一个可口诱人的大菠萝水果,所以也叫大菠萝转换,能帮助大家将包括.MP4(.M4V) 和 .MKV、H.265(x265 和 QuickSync)、H.264(x...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 30,445
精华内容 12,178
关键字:

电脑h265编码器

友情链接: mmm.rar