腾讯明眸之FFmpeg框架与媒体处理原创

大家好，我是腾讯云音视频的技术导师赵军，今天我为大家带来的课程是fmpa介绍与开发，先介绍一下媒体处理这一个课程，我希望和大家是一个比较平等的交流，不大希望犯孟子所说的文字焕在，好为人师的这种错误。首先我们先看一看业界的一个发展。第一，多媒体流量和业务在互联网目前是一个井喷式的爆发。思科出了一个报告，在2020年左右，亚太地区84%的互联网流量会是video，同时呢，我们也知道关于多媒体的业务形态众多，典型的有短视频、社交、广电、ott、游戏、竞技、娱乐、直播、在线教育等等，但是这个行业它有它的一些特点，其特点主要是在于。

它的要求非常众多，然后也具备一定的门槛。以腾讯云音视频为例，我简单统计了一下音视频在上面所用的code、容器格式、pro DM这一些，目前简单统计下来会有16个左右的video或者audio code 11个左右的容器，八个streaming的proocol。五个DM。需要提及压的是，我还没有去提字幕subtitle相关的事情。视频云的架构非常的有意思，看上去并不特别的复杂，一般会分为发布、接入、媒体处理、max DM播放以及分析统计等等。但是如果考虑到规模的话，你会发现他会面临一些非常特殊的挑战。典型的有规模。可靠性，到达用户的可达性，整个音食品领域的碎片化，还有我们通常可能会有一些忽略了运营成本以及最终分发给客户的质量。

先用一句我自己觉得是对音视频行业是一个总括的话来说，这句话来自于wm four m player的作者，他说multi me is basically clean ending pain，他说多媒体领域是一个无止境的痛，我在想这可能是对我们这个行业最好的一个注释之一。但是在一七年。也加了后面的半句，他说but the way no he still it，但是我们知道，虽然他在吐槽他，但是我们还一直喜欢在这个行业，我在想，这就是我们在做这个行业的一些有意思的地方吧。今天我们的主题可能会涵盖四个部分，第一个的话，我们会去看一看FM的发展历程，第二块我们会去看一看FM的框架，以及它在实际的媒体处理中该怎么使用。第三块。我们看一看作为云和开源之间的关系，以及我们的一些思考。第四部分我们也把我们碰到的一些open question拿出来和大家一起做一个简单的探讨。

先看一看F的历史，FM创立于2000年，它实际上最初是fabas，作为m player的一个解码库，但随后被独立，开始逐步的支持更多的容器格式，更多的KOFAB应当说是我们这个领域类，可能也不光只是我们这个里面是我们这个行业类的传奇人物之一。它的特点是创立一个项目，差不多等到这个项目功成名就之后，就会从这个项目离开S到了零三年之后，觉得F这个项目已经足够，然后就离开了这个项目，随后接手的核心人物是Michael。Ma周围这个项目的美特na一直担任至今，始终是FM项目的灵魂人物。除去FM ma的发展历程以外，有一件事情我觉得很多人都可能有兴趣，主要是在2011年的时候，FM ma社区发生了一次，我们现在把它称之为动乱。

原因是有一部分的核心开发者认为f ma社区出现了一些问题，他们创建的另外一个fo的项目称为Li AV，随后一一年到一三年，Ma开始从f ma项目中回归。他主要做了两件事情，一个是快速的去把那AV分离部分的功能迈回来，另外一块积极的去维护了安全相关的吐槽。在这之后，E本AV社区又开始回归到f ma社区，但这中间也导致了一些比较核心的开发者至今仍然脱离在这个社区之外。从2015年开始，这个社区又开始蓬勃。后面来看一看FM，它被为一个多平台的软件software，它其实真正的组成大概是有两块，一块的称为man，典型炉f MPA f f player f f pro，还有已经被删除掉f f server。

它的底层是一些C库，用于处理多媒体的各种事物，主要由C和汇编组成。另外，它也是一个可扩充的框架，并且模块化和可配置性都做得非常的好。与此同时，它也依赖了少量的外部项目，但是它的原则是说，除非有需要，我才回去依赖外部项目。目前它的外部项目主要是聚集在引口的这一块，典型如Li叉264、Li叉265等等。另外需要强调一下的是，它是一个开源项目，使用它的时候其实是需要遵循一定的准则，在使用的时候需要考虑清楚它的版权问题。它的开发模式还是采用了一些老派开源项目的方式，主要用了get加上mail list，然后一宿的跟踪使用track。它开发了之后是需要你把pat发送到对应的mail list之后，然后有其他的matenna或者control做了对应的review，在得到AK之后，这个PA它会被引入到主线。另外你也可以通过PA work去看一看你的PA的状态。很多人在之前在问fmpa的release的流程大概怎么样，我可以简单的提及一下f ma一般会在六个月左右做一次正式的release。与此同时，它也有自己的回归测试项目，被称为fate，里面有大量的回归测试test case。

但是fate也存在一些问题，主要的问题在于他对future以及对于引扣的支持的并不是很好。另外目前这个项目大概有30个左右的核心开发者，每年可能在2000~5000个提交左右。提及了FM社区的情况，我们来看一看谁在用它。最初FM它是被作为播放器项目而被引入了作为m player，但是我们知道m player现在已经进化成了MPV。同时像VLC。

这种媒体中心也在使用它媒体编辑工具，基本上也没办法去脱离IPA。更为重要的是，我觉得他对现在的cloud media提供了大量的帮助，典型路腾讯云以及微软的Facebook YouTube以及亚马逊的AWS都是FM的重度用户之一，还有一些不得不提的有意思的场景，典型路浏览器。另外我觉得还有必要去提一句的，在2020年next的。伊利号火星车登陆火星的时候，在项目回顾的时候，他们的技术人员回顾了有两个开源项目，其中之一是Linux，另外一个就是I ma。接下来我们介绍一下FMM的框架，也去介绍一下媒体处理的一些基础知识，对于FM，我觉得有两个点需要大家记住，第一，它是一个开源项目，第二。他是我们多媒体领域的瑞士军刀，这其实也意味着这个项目的多样性，以及他在这个行业的一个基础的地位。这个图里面的话，我们把fmpa的一些基础组件放在了里面，主要是由de the a format decoing的A以及。

去应用各种特效的a filter。同时呢，也会看到像有AV扣戴做的encoding这一块，以及AV的这一块，另外这个图的下面也只是FM的话，可能会对外部的一些引库会有一些依赖，其实他也会对一些库会也会有一些对应的依赖啊，另外FM ma支持的格式非常的众多。我们来细致的看一下FM的这个组件。F ma从它的架构上来说，它分为两个部分，第一个部分我们把它称为command，主要是一些非常便利使用的工具。大部分人对f ma熟悉的人上都从这些command里面开始熟悉这个项目。其中FFMPA被使用的最多，它是我们用来做转码以及做分析的一些工具。另外的话是f f player，它是一个非常简单的播放器，底层使用的SDL。

第三个的话是f pro，它是一个用来从多媒体文件中萃取各种信息的一个OL。另外还需要提及一下F在历史上曾经存在过f f server，但实际上后来因为维护的原因从这个项目中已经被剔除出去。现在来说的话，我个人可能会更建议用SS这样的项目去替代FM作为一个流媒体服务器。它的底层是我们讲的这些library，这个library其实可以分作两类，第一类是最为核心的，典型是Li format，它解决了max和的问题，支撑了m four m k vts PR t PR TP等协议和容器格式。后面的话是你AV口这个库，它实现的是audio和video的coding和coding，刚才也有提及，现在的coding大部分依赖了第三方的库，紧接着往下的话是一本AV filter这个库呢，它是去实现各种特效，在1VIDEO来说，典型度scaleroping from control等等的话，也有一些像re这样的事。

除去了这一种核心库，它的下层其实还有一些基础库，第一个的话是AV u，它是一些common to library。然后还有Li swem post SW主要解决的是一个缩放的问题，这一些库也有单独使用，但是可能作用没有像Li a Li a AV在行业有那么高的影响力。紧接着我们看一个实际的例子，在FM里面我们怎么样去做传coding，怎么样去做player。首先我在前面有提及过，F ma的话，它支持了大量的源格式，典型有文件、网络流设备，甚至于peer，它会进入到max，做一个split，把我们的video和audio进行一个分离，进行分离了之后，原始流会分别进入de扣的，De扣的在上上部分的话，看到的是trans coding的路径，我们先把传Ding的路径看完de扣Ding之后，一般会有可能会进入到filter，对于video来说典型会有skill。

会有ing。对于audio来说的话，一般可能会有一些下采样进入了之后，它的后面进入的是encoding video和audio各自进入encoding，随后会在a form的地方作为max保留下来。最常用的格式的话是我们常见的MPA four mpgts f LV等等，这是一个传codeding的流程。这张图的下部分实际上是一个。简化版本的播放器，我们把它成为一个player的流程，它和上面比较大的区别在于没有引扣的流程，同时呢，它也会在播放侧做一个video和video的同步。前面提及了F，我们来看一个实际的例子，F命令实际上并不是特别的好懂，需要自己去理一理。上面是一个FM ma的命令行的例子，一般来说以这个例子为例，FM ma-I smtv.mov。

杠CVB，叉六四杠CAC，然后输出SMPTe.MPA four，这里面其实可以分为五个部分来看，第一个命令行表示了我要去run f ma，这个command-I，它实际上是告诉f ma你去。把它作为一个input的source。第三个就非常明确了，它明显是我们典型的输入文件杠CV，它实际上说的是output的时候，使用这个code就进行编码。在这里面我们对于video使用了叉六四，对于audio我们使用了AAC，最终max的MPAFOX使用fpa的时候，这地方有一些图，我觉得可以帮大家去理解max以及转码之间的差异。

上面的这个图你会看到它做的实际上是一个转码，你看到这个video源，它的容器格式是mpad four，它的video部分编码采用了264 video部分采了AAC，经过转码之后，我的容器格式依然可以保留成MPA four，但是video采用了265的编码，Audio在这里面的话还是做了编码，但它还是aacc。第二个你会看到它有一些差异，做了一个什么呢？它做的是我们典型所说的转复用，也被称为转封装，它的容器格式和前者是一样，它的编码和audio也和前者是一样，但是通过转复用了之后，我实际上改编的是容器格式，对于编码内容并没有做任何的更改，所以你看video部分和audio部分分别还是跟原保证一样，只是在max的时候做了一些改变。这两者可能是FM ma最典型的应用场景之一，也简单的提及f f pro f pro，它是一个分析工具，它有一些很好玩的命令，如果大家对于容器格式碰到问题的话，我觉得大家可以去熟悉一下这一个工具，它的命令行的格式是跟F基本上是一致，但是它也有一些自己特定的命令，比如说修stream，修ma，修packet，这样的话你会去拿到各自的信息去做对应的流分析，这对我们诊断问题会带来大量的帮助。下面的话我也给了两个link，如果大家有兴趣可以去看一看。

举了大量的例子，能看到这两个场景，会对这两个场景之下去做各种诊断，拿到多媒体文件的各种信息，介绍了FM命令行，我们可以深入过来看一看FM的类目。我觉得这个事情有一点像看魔术师背后的箱子，我们先介绍一些比较基础的知识。呃，我们先看一看容器格式，很多人不太理解容器格式是怎么回事，我觉得右边这张图的话，可能很形象的解释的容器格式，它看过来的话就有一点像我们用电线去包裹不同的导线，这里面的导线是我们的video，是我们的audio，是我们的subtitle，是我们的data attach的数据容器格式就把这些全部包裹在一起，做相应的传输。

在FM里面中也有一些对应的概念，我觉得需要提及一下。FM里面你会经常看到有几个词，我觉得这个事情是了解FM人需要去理解的。第一个的话是container容器在右侧我们做的解释，第二个的话是流，这就有点像我们右侧图里面的每一股电线，Video是一个流，蜗也是一路流，Subtitle也是一路流。以上面这个图为例，三条黄色的video线你可以认为是有三路video流，两条绿色的video线你可以认为有两条video流。提及的流，其实需要提及这个瘤是怎么产生的，这就涉及到扣袋的事情，扣袋的话，我们在后面的话再可以来简单的提及一下。fac的底层还涉及到两个概念，第一个的话是frame增，第二个的话是包。这两个概念初看有一些复杂，但是在后期我们解释一下之后，你会发现这两个概念并没有那么的复杂，你会发现理解起来也会非常的便利。ipadm的使用其实非常的简单，从右边的这个例子来看，基本上你要使用IPA ma只需要做四步，这四步有一点像我们把大象装进冰箱，第一步我们会打开一个文件，第二步我们会去读这个文件里面的流。

从这个流里面去拿到对应的包，然后把这个包解解为针。第三步我们会continue到第二步轮巡，第四步我们会把这个解出来的帧做一些对应的事情，典型如播放或者存储，如此往复。你看到F的使用非常的简单，我放的一个网上的例子，这实际上是一个播放的例子，大概写下来的话，可能只需要在20行左右就能通过FM完成一个播放的任务。

他所经历的流程实际上就是在左侧这个图里面，我们会通过一个文件把它解析成不同的流，这些流又会分成不同的packet。这些packet通过。Decode的解析变成了AV frame AV frame的话就是我们看到没有压缩过的YUV数据。好，我们来更细致的看一下K容器以及传输格式相关的一些知识。首先我们看一个问题。在实际的场景里面，我们是不是只用关心H点264 H点265以及AAC？加上ipad four这个容器，在前面我有提及过，腾讯云音视频设计了大量的code，举例来说，我们认为前一代的像mpad two，以及微软的VC one，以及现在使用最为广泛的H点264，还有谷歌的VP8，以及我们国产的as as加等等，后面的话会有2.5、VP9AS two，以及现在马上就要开始落地的AV one avs3VVCEEVCLEVC等等。

Video的话也有大量的格式出现，容器格式呢也是多种多样，最为常见的会有mpad two t s PS MPA four，以及在国内盛行的FLV，还有开源格式MKV，以及基于MKV改动的web m。传输协议其实也是多种多样，以上行、下行为例，首先我们的上行大部分都有，像RTMP，下行可能会有HTTP，加上f lvtsm four，还有安防领域的RTSP以及GB28181。下行的话，还有一些我们讲的abr的协议，最典型的代表是hrs以及death。另外还有一些特定的传输协议在里面，像SRT以及现在逐步开始扩张的quick。还有web r TC。刚才提及的传输DM的话，你会看到也会有不同的选择，所以你会看到这实际上是一个比较分裂的世界，怎么样在这一个分裂的世界里面去找到一个比较好的方式来解决问题，我觉得这对于多媒体领域是一个非常大的挑战。

刚我也说了，我还没有提及文字格式。只有我们所说的subtitle，还有一个非常重要的领域，在国内可能没有那么的注意，但是在国外，特别是OTD领域的广告插入，这是它的最大的营收来源之一，我也没有来做更多的提及，我们更往前走进看一看，我们如果要处理多媒体的话，首先。很多人都会对PX会有一些疑惑，原因是他在内存存储的时候实际上会有一个packing packing的过程，你会看到在右侧实际上真正存储所需要的空间比实际这个a frame需要的空间会更多。后面我们来看一看被很多人忽视的一个领域，颜色。看到我列出来的这些词，我想大部分都会倒吸一口气，因为光颜色在多媒体领域就会面临有color color primary transform functioning color metric colors。

需要提下的color range这一块，我觉得如果大家有兴趣可以去看一看，PC的话提供了一个零到255的全范畴的范围，但是对于TV来说，它提供的实际上是一个受限的范围。另外我们也知道比特深度在逐步的增加，目前使用最多的是8BITCH，但实际上10BITCH和12B尺可能在不久的将来就会开始普及，分辨率也在逐步的增加，当前我们大部分看到的流可能在于1080P或者720P，但是4K和8K的流即将来到。另外，在处理媒体格式的时候，我们需要关注TEL fair order pixel的expiration以及display expation。对于来说，我们需要关注的布局采样格式、采样率。

多媒体领域还有两个非常有意思的问题，DTSPT。一般认为没有解决过DTS和pts的人可能没有入门我们多媒体领域。前面提及了FM里面有两个非常重要的概念，第一个是a frame，第二个是a packet。实际上a frame它存储的是原始的音视频数据，也有可能会包含字幕数据。简单来说，它是一个没有被压缩的数据。具体而言，你可以认为它处于解码后或者编码前。对于音频来说，大部分情况下，它是一个所谓的PCM格式，对于视频来说，它实际上是一个没有被压缩的一帧图像，一个Yu UV，对于字幕，这是一个时间段内的一句或者几句文字。Packet它存储的是字节流数据，包含的是被压缩过的音视频、字幕、附件信息等等，基本上你可以简单理解为压缩后的数据。

他在FM中一般处于编码后或者解码前。然后封装的时候呢，基本上封装都都是AV packet，在解封装的时候呢，我们是先解除AV packet，然后再到AV frame。提及的前面的这些基础知识，我们来近距离的看一看f ma的各种底层库。首先我们要看的是A，它提供的是DMAX和max的功能，基本上以我的经验来看，如果IPA ma都不能支持的格式，这种格式基本上在业界，除非你是一个私有格式，要不然的话很难有存活之地。另外他也提供了各种协议的支持。这主要是为了做input的支持，典型如本地的文件啊，PTTPTPTPS等等。它的核心structure是AV form contact a output form以及AV form，前面也有提及A和URL的pro。几者之间的层次关系在右图我们来看一看。从FMM内部来看，A input，它实际上是max的一个列表。

比如，你需要读取一个m for的文件，你其实是需要一个MPA for容器格式解析的对象来实现功能。这个对象会被存储在AV input format里面，既然有DMAX，就有对应的max这一个格式被整体存在AV output format里面。如果你要生成一个IPA文件，就需要一个对应的MPA for的封装对象来实现。FM的实现实际上遵循了内核对象的一些基础的理念。前面提及了AV input format和AV output format，实际上真正使用的时候，我们更多的在使用AV format context，它是用来处理比如说读取MPA文件时runtime的数据存储对象。另外刚有提及一个文件，它里面会按照video video或者sub titlele会被分割成不同的a stream，每一个文件里面的类型不同，A stream的类型也不同。a stream，它表征的是一个数据流基本的成员，里面有K，有contact，有这个流的时长、总帧数、帧率、码率等等，还有一些data。

A format，它是一个封装的核心，基本由原的路径input的format作为输入，Output format作为输出，所有的数据流格式、分类、时间参数以及think等等。讲完Li a format，我们可以看一看Li a code Li a code的话，它提供的是一个audio和video的和的能力，目前F支持的video超过200个，超过150个，还有基本上你能够看到的所有的subtitle格式，它的核心结构体在AB扣格的contact和AB扣这两种。FM ma的话，实际上提供了两类code的封装方式，在前面我们有所提及，第一种的话，我们把它称为native的open source code，最典型的例子是HR64的扣的。

对于引扣的，很多是以第三方库的形式进入FM。比如lib x64有相关的Li m pack four Li m three的name Li v PX等等，添加一个新的code到里面的过程非常的简单。基本上只需要注册右侧的结构体即可，A和a contact的构成和前面的A非常的类似，也是实现了一个类和一个对象的管理。Code的核心接口我觉得有必要再提及一次，它的接口实际上经过了一次重构。在原来的时候，我们去使用codeak的接口，只需要使用类似于code扣的扣的two a code video扣的three这样的接口，它是一个同步的接口。但是在后期，F ma社区进行了一次重构，这个重构会把send frame和packet做了分离。它重构的基本的原因是在于对原始的API，它保证的是一个packet对应一定是一帧，但实际上对于如果的场景来说，1PACK有可能会对应两帧，甚至于更多，他们并不是一个一对应的关系。

再加上有一些性能上面来考虑，所以MMX社区把这个API构造成了两个。还需要提及依据的是，虽然现在FMX社区已经把它分割成了两个分离的API，但实际上底层的改造并没有完全的完成，而只是部分的code支持完成。第三个部分是a filter give a filter，它提供的是一个和video的后处理，典型如scanning类、from control去造，我觉得reem等等，这个图展示的是一个线性关系，但实际上a filter，它可以构成一个有效无换图，A的话一直处于重构状态，整体的性能并不算特别的好，使用它的时候需要更多的注意。多媒体领域还有一个非常重要的主题，这就是性能FM ma作为最流行的多媒体基础库之一，最近这两年来，整个社区都在硬件加速方面做了大量的努力，使得FMM也正在逐步的成为一个跨平台、跨OS、跨硬件厂商的通用硬件加速方案。对于硬件来说，我们其实需要关注三个问题，第一个媒体处理。

第二个通用计算，第三个显示与渲染。面临的挑战有哪一些呢？不同OS上面的硬件加速API并不一致，Windows上面有DX va two dxv media foundation Mac oos和iOS上面有video two box Linux上面的话就更为分裂，有英特尔。有A在后面的video pau社区同时也提供了两套对应的接口，一个是video four l，一个是m to m上面也有自己的video口。

不同的硬件厂商也有自己的硬件加速方案。以GPU为例，AMD提供了amfda，在编码上面提供了ma的、ma扣的，英特尔在提供了media SDK现在逐步在往one a p上面做升级，SOC厂商也有自己特定的方案。另外我还没有提FPGA厂商的私有方案，除去了OS和普通硬件厂商，设备行业标准其实也是多种多样，典型有KDA，还有想跟KDA对抗的open CL open gl，以及后面继任的VO以及Meta等等。在谈及这个问题的时候，我觉得需要去考虑一下，对于FM来说，接口和框架到底该怎么样去做考量这个事情有一点像我们自己去建房子，建完房子之后，我们需要有自己的小院子。但是这其实就面临一个问题，把什么放在院子里面？把什么放在院子外面？这是第一，第二，我们在什么地方开门？

第三也很重要，有些人他并不喜欢你这个墙，他甚至想把它推倒在接口和框架上面。我觉得就和造院子一样，怎么样去考虑这个项目的范畴。所以FM ma在现在的话，他去提了一个方案，可以去屏蔽不同的OS，不同的硬件平台，不同的扣细节，同时呢也能构建一个比较灵活的middle。与此同时，还有一个挑战。提到性能问题，我觉得管理大师德鲁克的一句话需要拿出来说一说，If you can't measure it you can't improve it，意思是说，如果你不能量化它，你就不能提升它，这是一个性能问题要解决时候的基础。所有的性能问题，你需要先有一个量化的数据，你才能看到性能问题的提升。在多媒体领域，性能问题永远是一个痛点。高大了说提前优化是万恶之源，他的意思是说了什么呢？是说除非你确认它是一个性能问题，否则不要启动优化。但是对于多媒体领域来说，经常会碰到性能问题。

他差不多是我们这个行业的永恒的话题之一。前面也有提及。优化的前提，你需要理解算法，需要去理解数据结构，第二，你需要有数据说话。你需要有合适的。我们先看一看我们能利用的硬件都有哪些。对于CPU来说，我们会能看到多核，我们能看到多线程，我们能看到指令级别的SMD，我们能看到更微观层次的case。但是GPU呢，该怎么做呢？FPGA还有SOC。对于CPU来说，有两大利器，我们要好好的使用。第一，线程。F ma里面解码，它实际上提供了frame级别的线程和代级别的线程。对于来说，只提供了sla级别的线程，大家可以考虑一下，为什么对于来说并没有提供frame级别的线程，对于编码器来说，叉64FRAMES都提供了相应的优化。另外SMD它又解决了什么呢？

SMD，简单理解来看的话，有一点像我们去切黄瓜。在很多时候，你把黄瓜想切成丁的时候，你可能是先把它切成条，然后再按照条一条一条的去切，但有一个更简单但更高效的办法，切成条之后把所有的条并在一起，一刀下去，多个数据马上解决。这实际上就是SMD的优化，GPU的优化方式，一般来说我们会有扩胆，还有与他尝试对抗的open CL，另外用来做3D渲染的GL，其实也可以在某些场景里面用来做加速。后续，沃肯其实开始想尝试的统一open gl与open gl的这个市场，甚至于统一open al，但是他真的能一统江湖吗？现在看来可能还是一个未知数，原因是微软在继续发展它的DX v two的技术，而与此同时，IOS苹果阵地依然推出了新的met。

CPU加速的原理线程加速线程加速的核心其实是释放多核的能力。f ma的AV filter里面有一个典型的flag，这个flag的话是做了一个SL的线程加速。它做了什么呢？它实际上提供了一个工作组的模式，把不相关的数据以行或者列为单位划分，同时批量处理，提升性能。我们在内部有个项目，通过线程简单的加速之后，其处理时间从七毫秒降低到两毫秒，提升速度达3.5倍。SM的加速。FML的SM加速，我们先看一看SMD的加速方式会有哪一些？一般来讲，汇编加速会有三种模式，第一种是intr，它的做法有一点像在C代码中写汇编语言，所有的汇编指令都被封装成了C函数，第二种内联汇编，它的问题在于它和。

编译器强关联导致没办法去跨平台。第三种手写汇编FM目前选择的是第三种方式，原因是当年的intr在不同的编译器之间会引入性能损耗F，所以就去使用了手写的汇编。另外它借用了大量的叉六四的汇编函数，多提一点线程问题，就是我们在实际的场景中碰到的，我们经常会碰到一个窘境，有的同事会过来问我性能不太好。我会让他去看一看，你把你所有的核用起来了吗？但实际情况去看，你会发现我们会像右侧的这个图一样，其中的一个核在干活，其他的八个核在围观，这样的话，你即使让这一个人他的性能达到100%，平摊到八个核之后，他大概也只有12.5%。

所以我们第一要务其实要把多核使用起来。看一看这些真实的故事，我们在一个特定的领域里面，在一个特定的场景里面，增加了一行代码，一条复杂的pipeline的执行时间立即减半。它是一个什么样的背景呢？它实际上是我们在使用FM的时候，它在一个服务器的场景并没有去更细致的控制线程的力度，导致解码并没有充分使用多核多线程，其解码时间非常的缓慢。在最后，我们增加了一行线程相关的设定，解码时间立即减慢，整条链路的时间也立即减慢。第二个故事跟他也有关系，过了两天，我的同事过来问我说，嘿。哥们，我有一个线，我有一个进程，现在拥有可能超过1200个线程，这个事让我当时有点大吃一惊，后来发现在使用fpa的时候，它的AV filter实际上会去根据CPU的核心数创建线程，但是很不幸。

这位同事他使用了多个AV filter的graph，造成的情况实际上是等于一个N乘以核心数的线程数，它中间用了大量的filter，然后我们是一个48核的机器，最终导致了一个1200个线程的一个进程。第三个故事，我觉得这个事情也挺有意思的，这个故事实际上是跟谷歌的也有一些关系，我们在评测谷歌的AV的引口的时候发现。KUV总是告诉我的，在他的环境里面有，但很不幸，在我的环境里面始终不能现这个问题。后来发现我和他使用的CPU有所差异，他使用了一个服务器版96核CPU，由此可见，多线程的问题即使像谷歌这样的公司，他也未必考虑那么的周全。第四个事儿。线程它只是影响性能吗？在我们这个领域它还有一个特定的影响，它实际上还会影响编码的质量。右侧这个图很清晰的展示了随着线程的增加，图像质量的降低而达到一个预知之后，它有可能会再去上，再度上升。所以怎么样选择一个合适的线程模型，对于多媒体处理绝对是一个有挑战的事儿，SMD的优化会也会面临一些挑战。第一数发现数据变形其实并非意事。

所有的事情并不像我们切皇冠那么的简单，事情跟事情之间，数据和数据之间可能会存在一些依赖，这种复杂性有的时候会很难被结合。第二，不同的硬件之间的一致性会面临不同。举个例子来说。叉八六和ARM他们在SMD的支持上面就会不一致，但是我们可能同时需要支持叉八六，也同时需要支持ARM，这样你怎么样保证你的优化在不同的平台都能够做支持，这是一个很大的挑战。第三，边界情况的处理。大部分的SMD都有内存对齐的需求边界情况，你该怎么样作为Co case去处理，这是一个事。第四，在你的算盘里面，SMD的话需要尽量避免分支，但实际上逻辑处理可能是我们编程中最常见的行为之一，怎么样去避免这个分支，对很多算法设计来说也是一个挑战。

这一部分我们来看一看云和开源社区的一些考量，以FM ma作为一个实际的例子，我最初到腾讯云音视频的时候，整个部门大概拥有38个FM ma的，你会看到各式各样的轮子、三角形、半圆形，这其实也反映了一个问题。在公司内部，不管是腾讯这样的大公司，还是我们的友商，还是另外的小公司，怎么样去统一impa都是一个挑战。第二个的话。我们做的这些事该怎么样去反馈到社区呢？我觉得是对国内的开发者来说是需要一个考量的事情。实际上不同的future，甚至于bug fix，你的性能优化、文档更新，甚至于是一个小的sample，都对社区是一个良性的贡献。我们在腾讯云音视频打造了一个和社区双向互动、正向的工作流程。我们在内部维护了FM的一个稳定版本，逐步的把公司内部的不同版本合并到这个版本统一维护。同时我们也把我们在工作中发现的一些问题或者优化快速的返回给社区，已达到和社区版本逐步趋同的地步。我们也对开源与云的关系做了一个思考。

我们知道软件正在吞噬这个世界，马克安德森曾经说过这样的话，但真实的场景我觉得可能更像是开源软件在吞噬这个世界。在此过程中，我们也做了一些思考。第一，开源技术，它降低了技术研发的门槛，但是它并不是一个真正的产品，它并没有解决产品。开发需要考虑的性能、特性、运营等问题。第二，云厂商在使用开源项目的同时，其实应该需要避免是开源项目吸血鬼的这种这类指责，我们需要保持一个开放的态度，和社区共生，机器的回馈开源，社区机器的开源。我们来看一看我们对FM的使用。先从一个例子说起，这是一个典型的监控场景。

视频流通过摄像头解码，后期可能会经过scale color space的转换，随后绿色部分会进行一个对象探测，我们可能会把我们感兴趣的物体探测出来。探测出来之后，我们可能会跟踪它的轨迹，会作一个object的track在上面的部分实际上是会把这个对象会单独拿出来，对这个物体作为一个分类。这是一个非常实际的场景，典型如你在安防场景里面，我需要把一个人从视频流中寻找出来，然后去遵循他在不同时间段的运行轨迹，最终把这个结果存储到服务迹。但这里面的话，你会看到绿色部分FM ma并不能涵盖。这其实也引入了一个问题，FM ma是瑞士军刀，瑞士军刀能用来法术吗？

可能可以，但是它并不是一个最优的选择。在一个实际的场景里面，FM并不能涵盖所有的情况，比如这里面的物体探测等等。在此基础上面，我们提出了我们自己的媒体处理框架。TMPF以极速高清为例，它解决了第一解决了线程优化调度。它在极速高清中提供的不同的线程池默认使用了一个分时的调度策略解决FM内置的线程调度问题。另外，在高分辨率情况下面，把编码限制线程设置成了实时调度策略，提升了编码线程的优先级。减少了编码带来的全路径等待最终的结果，我们可以看到这一点比较小的优化为编码带来了10%左右的收益。第二个，为了应对于直播场景，我们在整个框架中实现了自定义的SEI增透传。

这样的话会对业务方带来很大的帮助，因为它不需要去理解整个SSEI。技速高清在2021年的cloud videoing server中获得了非常好的成绩，他在MSU的2021年中获得了最佳的速度质量。第一名，获得了最佳的成本质量的第一名，但是在应用型方面，我们现在还有一些工作需要去做，F还在社区以及云和FM ma的一些关系，我觉得也有一些开放的问题需要拿出来做一些讨论。首先我们知道A现在的一个大大热话题。但是AI框架是不是f ma的一个部分。我觉得这个问题。有一点像哈姆雷特里面的一句原文，他说，Tobe tobe this ISA question，是还是不是，始终是一个问题。

如果要做，我们可能面临着这样的一个选择，第一，我们是实现一个特定的influence的future，还是集成一个重度的第三方的influence框架？这实际上是一个非常困难的选择。目前FM的状态是它已经有一个简单版本的DNN的influence的API，底层之前的支持了部分的deep depending的功能，主要是超分super resolution去去物，但性能堪忧。这是一个CPU的版本，同时它的底层也简单的支持了ten flow通过C的rap。这个事情在我个人看来有一点像我们去做软件架构，我们期望架构像左侧垒墙一般层次分明，只需要靠简单的粘合就能够把层次做开。但实际上，当我们想把AI框架放到f ma的时候，以open CV为例，它有一点像右侧的五花肉，肥瘦相间，但你没办法去把它完整的分割。举一个实际的例子。

Open CV在它的自己的内部调用了FM ma去做的和引Co的，与此同时，FM ma的部分历史上又调用open CV实现的部分的功能，所以他们两者之间的层次到底是什么？我觉得这有点像右边的五花肉，根本无法去做更好的分割。另外，在我个人看来，AI框架太重，它并不是F这个范畴，任何一个项目它有自己的领域，什么是做，什么是不做。相较而言，我认为说漏什么是不做比什么事做可能会更为艰难。对FM这个项目来说，我个人认为AI框架不应当作为他的一个部分。还有一些其他的open question。第一，FM的命令行在处理abr的时候转码性能堪忧，这个问题在tto的博客中有详细阐述，第二，在大部分的项目中，我们是真的要使用FM ma吗？这个问题我觉得也可以做一些更多的思考，第三，FMAPI其实缺乏了一些灵活度。简单说来。

以hrs来说，Hrs它是一个典型的DMAX嵌套DMAX的场景，在HSDMAX中嵌套了mpgts DMAX如果同时也嵌套了HTP的pro，如果HT pro出现相关问题，HSX如何感知？这是一个问题。第三，FM在版本升级的时候剔除了以前的动态协议注册扣注册、容器格式注册，这样导致所有的代码只能和FM融为一体。这样导致的问题实际上什么呢？所有的部署，如果你需要先增加一个协议code或者容器格式，需要做一次重新编译，这在增量的时候可能会带来一些问题，因为原来我们可以通过一个动态库注册到阿的内部，但是现在已经不大可能。

还有一个未来的问题，FMX社区对于新的扣的支持，目前也面临一些挑战，举例说来，Ane的抵扣的，VVC的抵扣的，以及引扣的，目前都不是内置在里面，都不是作为light的code，这个对于F社区我觉得是一个非常大的挑战，后期怎么解决，我觉得可能要看社区的这些人有一些什么样的智慧。这就是今天全部的内容，谢谢大家。