.环境准备

需要在执行路径下，准备一个xxx.yuv的文件。然后在qt的命令行这里，输入如下:

点击运行，编码出h264文件。看出来这个压缩比达到1:87，效果还是不错的。

下面是一些发帧的时间，编码时间等信息。

发了很多次数据，才开始编码成正真的数据packet。

当文件读取完时，必须要去冲刷编码器，把更多的缓存packet取出来。

2.FFmpeg编码视频流程

从本地读取YUV数据编码为h264格式的数据，然后再存⼊到本地，编码后的数据有带startcode。

与FFmpeg ⾳频编码的流程基本⼀致。

主要API说明：

(1)avcodec_find_encoder_by_name：根据指定的编码器名称查找注册的编码器。

(2)avcodec_alloc_context3：为AVCodecContext分配内存。

(3)avcodec_open2：打开编解码器。

(4)avcodec_send_frame：将AVFrame⾮压缩数据给编码器。

(5)avcodec_receive_packet：获取到编码后的AVPacket数据。

(6)av_frame_get_buffer: 为⾳频或视频数据分配新的buffer。在调⽤这个函数之前，必须在AVFame上设置好以下属性：format(视频为像素格式，⾳频为样本格式)、nb_samples(样本个数，针对⾳频)、channel_layout(通道类型，针对⾳频)、width/height(宽⾼，针对视频）。因为这个Buf是根据这些参数来计算。

(7)av_frame_make_writable：确保AVFrame是可写的，尽可能避免数据的复制。如果AVFrame不是可写的，将分配新的buffer和复制数据，避免数据冲突。

(8)av_image_fill_arrays:存储⼀帧像素数据存储到AVFrame对应的data buffer。

(9)av_image_get_buffer_size，通过指定像素格式、图像宽、图像⾼来计算所需的内存⼤⼩。

int av_image_get_buffer_size(enum AVPixelFormat pix_fmt, int width, int height, int align)

重点说明⼀个参数align:

此参数是设定内存对⻬的对⻬数，也就是按多⼤的字节进⾏内存对⻬。

⽐如设置为1，表示按1字节对⻬，那么得到的结果就是与实际的内存⼤⼩⼀样。

再⽐如设置为4，表示按4字节对⻬。也就是内存的起始地址必须是4的整倍数。

(9)av_image_alloc

av_image_alloc()是这样定义的。此函数的功能是按照指定的宽、⾼、像素格式来分配图像内存。

int av_image_alloc(uint8_t *pointers[4], int linesizes[4], int w, int h, enum AVPixelFormat pix_fmt,

int align);

pointers[4]：保存图像通道的地址。如果是RGB，则前三个指针分别指向R,G,B的内存地址。第四个指针保留不⽤。

linesizes[4]：保存图像每个通道的内存对⻬的步⻓，即⼀⾏的对⻬内存的宽度，此值⼤⼩等于图像宽度。

w: 要申请内存的图像宽度。

h: 要申请内存的图像⾼度。

pix_fmt: 要申请内存的图像的像素格式。

align: ⽤于内存对⻬的值。

返回值：所申请的内存空间的总⼤⼩。如果是负值，表示申请失败。

(10)av_image_fill_arrays

int av_image_fill_arrays(uint8_t *dst_data[4], int dst_linesize[4], const uint8_t *src, enum

AVPixelFormat pix_fmt, int width, int height, int align);

av_image_fill_arrays()

函数⾃身不具备内存申请的功能，此函数类似于格式化已经申请的内存，即通过av_malloc()函数申请的内存空间，或者av_frame_get_buffer()函数申请的内存空间。

dst_data[4]： [out]对申请的内存格式化为三个通道后，分别保存其地址。

dst_linesize[4]: [out]格式化的内存的步⻓（即内存对⻬后的宽度)。

*src: [in]av_alloc()函数申请的内存地址。

pix_fmt: [in] 申请 src内存时的像素格式

width: [in]申请src内存时指定的宽度

height: [in]申请scr内存时指定的⾼度

align: [in]申请src内存时指定的对⻬字节数。

H.264 码率设置

一般在实际的直播项目中，如果为了匹配不同分辨率，一般都是设置动态缓冲区适配，这样可以把不同分辨率，不同码率的延迟降到最低。这就是一个实战中得出的优化经验。

什么是视频码率？

视频码率是视频数据（包含视频⾊彩量、亮度量、像素量）每秒输出的位数。⼀般⽤的单位是kbps。

设置视频码率的必要性

在⽹络视频应⽤中，视频质量和⽹络带宽占⽤是相⽭盾的。通常情况下，视频流占⽤的带宽越⾼则视频质量也越⾼，需要的⽹络带宽也越⼤，解决这⼀⽭盾的钥匙当然是视频编解码技术。评判⼀种视频编解码技术的优劣，是⽐较在相同的带宽条件下，哪个视频质量更好；在相同的视频质量条件下，哪个占⽤的⽹络带宽更少（⽂件体积⼩）。

是不是视频码率越⾼，质量越好呢？

理论上是这样的。然⽽在我们⾁眼分辨的范围内，当码率⾼到⼀定程度时，就没有什么差别了。所以码率设置有它的最优值，H.264（也叫AVC或X264）的⽂件中，视频的建议码率如下：

⼿机设置码率建议

通过上⾯的介绍，结合我做过的⼀些⼿机项⽬，我总结了⼀套设置码率的公式，分享给⼤家如下：

如果1080P，码率低于2M，实际效果很差。不建议这么做，那样没什么意义。

FFmpeg与H264编码指南

鉴于x264的参数众多，各种参数的配合复杂，为了使⽤者⽅便，x264建议如⽆特别需要可使⽤preset和tune设置。这套开发者推荐的参数较为合理，可在此基础上在调整⼀些具体参数以符合⾃⼰需要，⼿动设定的参数会覆盖preset和tune⾥的参数。

使⽤ffmpeg -h encoder=libx264 命令查询相关⽀持的参数。

英⽂地址：https://trac.ffmpeg.org/wiki/Encode/H.264。内容有⼀定出⼊，但是可以借鉴学习。

x264是⼀个 H.264/MPEG4 AVC 编码器，本指南将指导新⼿如何创建⾼质量的H.264视频。

对于普通⽤户通常有两种码率控制模式：CRF（Constant Rate Factor)和Two pass ABR。码率控制是⼀种决定为每⼀个视频帧分配多少⽐特数的⽅法，它将决定⽂件的⼤⼩和质量的分配。

如果你在编译和安装libx264 ⽅⾯需要帮助，请查看ffmpeg和x264编译指南：

http://ffmpeg.org/trac/ffmpeg/wiki/CompilationGuide

CRF

量化⽐例的范围为0~51，其中0为⽆损模式，23为缺省值，51可能是最差的。该数字越⼩，图像质量越好。从主观上讲，18~28是⼀个合理的范围。18往往被认为从视觉上看是⽆损的，它的输出视频质量和输⼊视频⼀模⼀样或者说相差⽆⼏。但从技术的⻆度来讲，它依然是有损压缩。

若CRF值加6，输出码率⼤概减少⼀半；若CRF值减6，输出码率翻倍。通常是在保证可接受视频质量的前提下选择⼀个最⼤的CRF值，如果输出视频质量很好，那就尝试⼀个更⼤的值，如果看起来很糟，那就尝试⼀个⼩⼀点值。

注意：本⽂所提到的量化⽐例只适⽤于8-bit x264（10-bit x264的量化⽐例 为0~63），你可以使⽤x264--help命令在Output bit depth选项查看输出位深，在各种版本中，8bit是最常⻅的。

preset

预设是⼀系列参数的集合，这个集合能够在编码速度和压缩率之间做出⼀个权衡。⼀个编码速度稍慢的预设会提供更⾼的压缩效率（压缩效率是以⽂件⼤⼩来衡量的)。这就是说，假如你想得到⼀个指定⼤⼩的⽂件或者采⽤恒定⽐特率编码模式，你可以采⽤⼀个较慢的预设来获得更好的质量。同样的，对于恒定质量编码模式，你可以通过选择⼀个较慢的预设轻松地节省⽐特率。这里后面会根据代码来设置。

通常的建议是使⽤最慢的预设。⽬前所有的预设按照编码速度降序排列为：

ultrafast

superfast

veryfast

faster

fast

medium – default preset

slow

slower

veryslow

placebo - ignore this as it is not useful (see FAQ)

默认为medium级别。

你可以使⽤--preset来查看预设列表，也可以通过x264 --fullhelp来查看预设所采⽤的参数配置。

tune

tune是x264中重要性仅次于preset的选项，它是视觉优化的参数，tune可以理解为视频偏好（或者视频类型），tune不是⼀个单⼀的参数，⽽是由⼀组参数构成-tune来改变参数设置。当前的 tune包括：

film：电影类型，对视频的质量⾮常严格时使⽤该选项

animation：动画⽚，压缩的视频是动画⽚时使⽤该选项

grain：颗粒物很重，该选项适⽤于颗粒感很重的视频

stillimage：静态图像，该选项主要⽤于静⽌画⾯⽐较多的视频

psnr：提⾼psnr，该选项编码出来的视频psnr⽐较⾼

ssim：提⾼ssim，该选项编码出来的视频ssim⽐较⾼

fastdecode：快速解码，该选项有利于快速解码

zerolatency：零延迟，该选项主要⽤于视频直播

如果你不确定使⽤哪个选项或者说你的输⼊与所有的tune皆不匹配，你可以忽略--tune 选项。你可以使⽤-tune来查看tune列表，也可以通过x264 --fullhelp来查看tune所采⽤的参数配置。

profile

另外⼀个可选的参数是-profile:v，它可以将你的输出限制到⼀个特定的 H.264 profile。⼀些⾮常⽼的或者要被淘汰的设备仅⽀持有限的选项，⽐如只⽀持baseline或者main。

所有的profile 包括：

baseline profile：基本画质。⽀持I/P 帧，只⽀持⽆交错（Progressive）和CAVLC

extended profile：进阶画质。⽀持I/P/B/SP/SI 帧，只⽀持⽆交错（Progressive）和CAVLC

main profile：主流画质。提供I/P/B 帧，⽀持⽆交错（Progressive）和交错（Interlaced），也⽀持CAVLC 和CABAC 的⽀持。

high profile：⾼级画质。在main Profile 的基础上增加了8x8内部预测、⾃定义量化、 ⽆损视频编码和更多的YUV 格式。

想要说明H.264 high profile与H.264 main profile的区别就要讲到H.264的技术发展了。JVT于2003年完成H.264基本部分标准制定⼯作，包含baseline profile、extended profile和main profile，分别包括不同的编码⼯具。之后JVT⼜完成了H.264 FRExt（即：Fidelity Range Extensions）扩展部分（Amendment）的制定⼯作，包括high profile（HP）、high 10 profile（Hi10P）、high 4:2:2profile（Hi422P）、high 4:4:4 profile（Hi444P）4个profile。

H.264 baseline profile、extended profile和main profile都是针对8位样本数据、4:2:0格式的视频序列，FRExt将其扩展到8～12位样本数据，视频格式可以为4:2:0、4:2:2、4:4:4，设⽴了highprofile（HP）、high 10 profile（Hi10P）、high 4:2:2 profile（Hi422P）、high 4:4:4profile（Hi444P） 4个profile，这4个profile都以main profile为基础

在相同配置情况下，High profile（HP）可以⽐Main profile（MP）节省10%的码流量，编码时间可能更长，⽐MPEG-2MP节省60%的码流量，具有更好的编码性能。根据应⽤领域的不同：

baseline profile：多应⽤于实时通信领域

main profile：多应⽤于流媒体领域

high profile：则多应⽤于⼴电和存储领域

关于profile和level控制，可以参考这篇文章:

https://www.jianshu.com/p/48d723bb2740

低延迟

x264提供了⼀个 -tune zerolatency 选项。

兼容性

如果你想让你的视频最⼤化的和⽬标播放设备兼容(⽐如⽼版本的的ios或者所有的android 设备），那么你可以这做

-profile:v baseline

这将会关闭很多⾼级特性，但是它会提供很好的兼容性。也许你可能不需要这些设置，因为⼀旦你⽤了这些设置，在同样的视频质量下与更⾼的编码档次相⽐会使⽐特率稍有增加。

关于profile列表和关于它们的描述，你可以运⾏x264 --fullhelp

要牢记apple quick time 对于x264编码的视频只⽀持 YUV 420颜⾊空间，⽽且不⽀持任何⾼于 mian profile编码档次。这样对于quick time 只留下了两个兼容选项baseline和 main。其他的编码档次qucik time均不⽀持，虽然它们均可以在其它的播放设备上回放。

有些问题，通过解答的形式给出。

两遍编码模式能够⽐CRF模式提供更好的质量吗？

不能，但它可以更加精确地控制⽬标⽂件⼤⼩。

为什么 placebo 是⼀个浪费时间的玩意⼉？

与 veryslow相⽐，它以极⾼的编码时间为代价换取了⼤概1%的视频质量提升，这是⼀种收益递减准则，veryslow 与 slower相⽐提升了3%；slower 与 slow相⽐提升了5%；slow 与 medium相⽐提升了5%~10%。

为什么我的⽆损输出看起来是⽆损的？

这是由于rgb->yuv的转换，如果你转换到yuv444,它依然是⽆损的。

显卡能够加速x264的编码吗？

不，x264没有使⽤（⾄少现在没有），有⼀些私有编码器使⽤了GPU加快了编码速度，但这并不意味着它们经过良好的优化。也有可能还不如x264，或许速度更慢。总的来说，ffmpeg到⽬前为⽌还不⽀持GPU。

翻译注释：x264在2013版中已经开始⽀持基于opencl的显卡加速，⽤于帧类型的判定。

为Quick time 播放器压制视频

你需要使⽤-pix_fmt yuv420p来是你的输出⽀持QT 播放器。这是因为对于H.264视频剪辑苹果的Quicktime只⽀持 YUV420颜⾊空间。否则ffmpeg会根据你的视频源输出与Quick time 不兼容的视频格式或者不是基于ffmpeg的视频。

X264参数之zerolatency的分析

加⼊zerolatency之后，转码路数会明显降低。

我们都知道，加⼊zerolatency的⽬的是为了降低在线转码的编码延迟，那么，该参数是如何影响到x264的转码性能了呢？

⾸先，先来看看代码中编码延迟的影响因素：

设置zerolatency后，相应的参数配置如下：

下⾯我们来看⼀下zerolatency设置中各个参数的意义：

rc_lookahead: Set number of frames to look ahead for frametype and ratecontrol.

该参数为mb-tree码率控制和vbv-lookahead设置可⽤的帧数量，最⼤值为250。对于mbi-tree来说，rc_lookahead值越⼤，会得到更准确的结果，但编码速度也会更慢，因为编码器需要缓存慢rc_lookahead帧数据后，才会开始第⼀帧编码，增加编码延时，因此在实时视频通信中将其设置为0。

sync_lookahead: 设置⽤于线程预测的帧缓存⼤⼩，最⼤值为250。在第⼆遍及更多遍编码或基于分⽚线程时⾃动关闭。sync_lookahead = 0为关闭线程预测，可减⼩延迟，但也会降低性能。

bframes: I帧和P帧或者两个P帧之间可⽤的最⼤连续B帧数量，默认值为3。B帧可使⽤双向预测，从⽽显著提⾼压缩率，但由于需要缓存更多的帧数以及重排序的原因，会降低编码速度，增加编码延迟，因此在实时编码时也建议将该值设置为0。

sliced_threads: 基于分⽚的线程，默认值为off，开启该⽅法在压缩率和编码效率上都略低于默认⽅法，但没有编码延时。除⾮在编码实时流或者对低延迟要求较⾼的场合开启该⽅法，⼀般情况下建议设为off。

vfr_input： 与force-cfr选项相对应：

vfr_input= 1时，为可变帧率，使⽤timebase和timestamps做码率控制；vfr_input = 0时，为固定帧率，使⽤fps做码率控制。

mb_tree: 基于宏块树的码率控制。对于每个MB，向前预测⼀定数量的帧(该数量由rc_lookahead和keyint中的较⼩值决定)，计算该MB被引⽤的次数，根据被引⽤次数的多少决定为该MB分配的量化QP值。该⽅法会⽣成⼀个临时stats⽂件，记录了每个P帧中每个MB被参考的情况。使⽤mb_tree的⽅法能够节约⼤概30%的码率，但同时也会增加编码延迟，因此实时流编码时也将其关闭。

详细可以参考这个:https://slhck.info/video/2017/02/24/crf-guide.html

3.源码解读

根据传参，查找指定编码器。并分配编码器上下文。

给编码器上下文设置相关信息，如，宽高，time_base，B帧个数，gop等。

如果想一直保持I帧进行编码，就需要设置frame->pict_type设置为AV_PICTURE_TYPE_I, 则忽略gop_size的设置。

这里的time_base与帧率设置为倒数关系即可。一般做直播都是把B帧设置为0，因为b帧会缓存较多，然后会带来延时。

设置0延迟，画质效果一般，精细度不够好。

一般编码时间与画质是成一个反比关系，就是说如果使用ultrafast，那画质可能就差点，使用veryslow，那画质可能就好点。代码设置如下:

根据debug结果显示，ultrafast模式，编码时间为2270ms，medium模式，编码时间为5815ms，veryslow模式，编码时间为19836ms。直播时，一般都设置zerolatency，为0延迟。

从图中可以看出，当其他参数固定时，选择不同的preset，对应的码率和编码时间都不⼀样。

可以使⽤--preset来查看预设列表，也可以通过x264 --fullhelp来查看预设所采⽤的参数配置。一般在做直播，可以使用ultrafast、superfast、veryfast，但是就一般不会有特别复杂的算法。

码率设置，一般需要根据分辨率去配置，也会有一般值，最小值等，当然这跟动态码率，固定码率这些有关系。编码器上下文还可以设置线程数，编码速度会快，开了多线程后也会导致帧输出延迟, 需要缓存thread_count帧后再编程，所以直播为了降低延迟，一般是不去开启多线程。设置AV_CODEC_FLAG_GLOBAL_HEADER，表示只有第一个I帧，具有SPS/PPS信息，此时sps pps需要从codec_ctx->extradata读取，如果不设置，那就是每个I帧都有sps、pps 、sei。是否设置，根据自己情况去看，一般存储本地文件时，不要去设置。

如果没有设置AV_CODEC_FLAG_GLOBAL_HEADER，就可以看到每个I帧都有SPS和PPS，SEI信息。

这个就是SEI信息。

如果设置AV_CODEC_FLAG_GLOBAL_HEADER，存放到本地，PKT里没有SPS和PPS信息，但是SEI信息。

这时的SPS和PPS信息，是在codec_ctx->extradata，从这里面去获取。

注意，这个时候，是不会写到文件里的。

打开输入和输出文件。

分配PKT和frame

根据设置的参数，给frame分配buffer。

按照设置的字节对齐，计算出每一帧的数据 = 像素格式 * 宽 * 高

分配了一个yuv_buf，用来读取文件，存储使用。

当缓存B帧时，为了防止外面写数据与缓存冲突， 如果编码器内部保持了内存参考计数，则需要重新拷贝一个备份。一般如果是X264编码，一般是不会冲突，这里是为了起一个保险作用。

再把文件中读取的数据，存到 yuv_buf，然后再去填充到frame里去。这里也有字节对齐设置。

这里就开始设置pts，获取开始时间。一般pts还是要根据duration去计算比较好，如果实时流，直接从采集端拿到，然后配置下去。

编码视频。通过查阅代码，使用x264进行编码时，具体缓存帧是在x264源码进行，不会增加avframe对应buffer的reference。一般能够播放的h264是带有startcode，但是从flv里抽出的h264前，是要添加startcode才行。

注意：编码时，不管是编码还是解码，如果有B帧，都是要相互参考，可能输入多几帧进去，才会编码出来一帧。

本篇文章就分析到这里，欢迎关注，点赞，收藏，转发。如果需要测试代码，那需要私信。

/ BRIAN DIPERT

原文链接 / https://blog.addpipe.com/typical-video-bitrates-with-html-media-capture-and-mediastream-recording-api/

最近有人问我们关于视频码率与文件大小的问题：对于低、中、高质量的，比如1分钟的视频响应，有典型的文件大小吗？

我的直接回答是这取决于许多因素，但后来我意识到我应该尝试挖掘数据。在我们的大型数据集中，我们应该找一些典型码率，特别是在处理大容量数据时的码率。

我们已经研究了从用户那里采集视频的两种机制以及它们产生的码率：

1.MediaStream Recording API：由我们的(内联)桌面录制客户端使用

2.HTML Media Capture：由我们的本地移动录制客户端使用

MediaStream Recording API

由于此API允许你从你的摄像头请求分辨率，我们看了3个典型的分辨率应该支持大多数USB/集成网络摄像头:

• 320x240
• 640x480
• 1280x720

我们从数据库中提取了2021年以该分辨率录制的第一万个视频，然后通过浏览器(Chrome 和 Firefox)进一步过滤。

对于分辨率为320x240的视频：

• 使用 Chrome 录制的5691个视频的平均码率为183 kb/s。
• 使用 Firefox 录制的超过374个视频的平均码率为2 Mb/s。

我怀疑码率的不同主要是因为Firefox（仅）使用VP8压缩视频数据，而Chrome使用的是H.264。

此外，我们没有所有视频的用户代理信息，这就是为什么视频的数量加起来没有达到一万。

对于分辨率为640x480的视频：

• 使用 Chrome 录制的超过7501个视频的平均码率为589 kb/s。
• 使用 Firefox 录制的超过181个视频的平均码率为2.64 Mb/s。

对于分辨率为1280x720的视频：

• 使用 Chrome 录制的超过6956个视频的平均码率为1.97 Mb/s。
• 使用Firefox 录制的超过1265个视频的平均码率为2.69 Mb/s。

有了高清录制，可以对摄像机质量和光线设置带来的差异留有余地（低光照环境产生的噪声图像很难有效编码）

你会看到两条平行的铬线在2Mbits/s标记附近。上面的是Windows上的Chrome，而下面的是macOS上的Chrome。我可能是错的，但我怀疑他们使用的是不同的H.264编码器。如果不是这样的话，那就是每个macOS设备上都有FaceTime摄像头。

下图是按操作系统划分的Chrome数据。

HTML Media Capture

这个API允许依靠操作系统的应用和功能来采集音频和视频。它适用于Android和iOS/iPadOS（但不能只用于音频录制）。

使用HTML Media Capture不能控制或指定分辨率，但是从以往经验来看，我们知道:

• 在iOS和iPadOS上，当你在现场录制时，你可以得到480x360（和它的纵向变化）或当从库中选择一个记录，可以得到1280x720（和它的纵向变化）。
• 在Android上，你可以获取设备配置的任何记录(不像在iOS/iPad OS上那样进行强制压缩)。

iOS & iPadOS

所以你可以看出：

1.当现场抓拍视频的时，894kbits/s(和480x360分辨率)

2.当选择库中一个预先录制的视频时，2.69 Mbits/s(和1280x720)

3.平均1.8 Mbits/s

我们还查看了通过HTML Media Capture从iOS/iPadOS获得的分辨率不同于480x360、1280x720及其纵向变体的视频数量。在一万个视频中，只有548个有不同的分辨率。

Android

使用Android上的HTML Media Capture，你可以获得设备上配置的任何内容。因此，我们看到了相当多的4k视频。因为你不能要求一个特定的分辨率，我们只计算了所有10k视频的平均分辨率为12.9 Mbits/s。

这是相同的数据，但按码率排序，可以更好地看到在20 Mbits/s标记附近的分组。

这些数字与来自浏览器的数据非常相关。在处理这些文件并对其中一些数据进行转码之后，数字可能会有所不同。例如，我们将VP8视频数据从Firefox转换为H.264，将Opus音频数据转换为AAC。

节跳动视频编码器，在MSU 2020赛事中，又获得了新的好成绩。

MSU 2020是俄罗斯莫斯科国立大学举办的视频编码权威赛事，在近期公布的4K和全高清视频（1080p）主观评分两个项目的角逐中，字节跳动自主研发的视频编码器（BVC）获得了两大最新成绩：

• BVC1，斩获了4K 8bit项目8项评分标准第一名。
• BVC2，获评全高清视频（1080p）主观评分离线1 fps赛道最佳质量奖，主观评分及4项客观评分均为第一名。

加上此前2020年12月公布的全高清视频（1080p）客观评分项目1fps赛道的4项评分标准冠军，BVC系列编码器在首次参赛、仅用了40天优化的情况下，与视频领域领先公司同场竞技，已经获得了本届MSU 2020三个主要比赛项目、累计17项评分标准的第一名。

BVC系列编码器的主要研发团队是位于美国San Diego的字节跳动先进视频团队，团队成员毕业于加州大学圣芭芭拉分校、伊利诺伊大学香槟分校等知名学府，全部拥有硕士或博士学历，已经在国际顶级期刊/会议上发表了超过30篇论文，并获得全球近100项授权专利。

这支海外团队的不少成员还在多个国际标准化工作组中担任重要角色，如VVC、H.265/HEVC、H.264/AVC等多项标准文本主编及编委等。过去两年间，字节跳动先进视频团队累计递交了260项以上H.266/VVC技术提案，被采纳数量超过130项。

随着5G和高清视频场景的深入落地，BVC系列编码器证明自己可以满足高清晰度场景下的视频编码需求，能够作为推进5G媒体应用的基础架构产品。

以体现客观质量的VMAF指标为例，BVC编码器在VMAF指标上相比其他参赛编码器领先幅度约为8%-15%。这意味着，同样质量的视频内容，使用BVC编码器能为服务商节约8%-15%的带宽和存储成本，用户端在网速较慢的情况下，使用BVC编码器转码，也能享受更高画质、更流畅的视频体验。

此外，参赛的BVC系列编码器正在逐步针对企业侧用户集成输出，服务B端市场的高清视频编解码需求。

4K 8bit冠军

先来看BVC1。

在1fps和30fps的各自四项评分标准中，BVC1均取得了最佳成绩：

PSNR avg.MSE（峰值信噪比的一种计算方式），1fps

柱状图越短，意味着编码后文件体积越小、比赛成绩越好、用户使用更省流量

PSNR avg.log（峰值信噪比的另一种计算方式），1fps

SSIM（结构相似性），1fps

VMAF（视频多方法评价融合指标），1fps

PSNR avg.MSE，30fps

PSNR avg.log，30fps

SSIM，30fps

VMAF，30fps

离线1 fps最佳质量奖

另外，在1080p视频主观评判中，也就是从人类评委观看视频的主观感受评判中，字节跳动自研编码器BVC2获评离线（1 fps）赛道最佳质量奖。

而在1080p视频相关的四项客观标准评分中，BVC2同样保持了第一名的成绩。

PSNR avg.MSE

PSNR avg.log

SSIM

VMAF

首次参加比赛，多个项目冠军

除了本次公布的两个比赛项目之外，在2020年底公布的MSU 2020 全高清视频（1080p）客观评分项目中，BVC2同样获得了4项评分标准第一。

研发BVC系列编码器的字节跳动先进视频团队透露，这一系列编码器正在持续更新迭代，并推动商业化应用，满足企业级市场的高清视频编解码需求。

参考链接：

https://www.compression.ru/video/codec_comparison/hevc_2020/4k_report.html

https://www.compression.ru/video/codec_comparison/hevc_2020/subjective_report.html

https://www.compression.ru/video/codec_comparison/hevc_2020/main_report.html

关注「字节跳动技术范儿」

了解字节跳动更多技术成果

抖音40亿播放，娜扎、唐嫣都在玩的春节道具，背后是怎样的技术