Mail.Ru是俄罗斯最受欢迎的网站，最近我们在Mail.Ru云端新增了视频流媒体服务，最初开发者想要的是“瑞士军刀”那样的通用型功能——可以播放任何格式的文件，并且可以在任何云设备上播放。

上传到云端的视频内容大多分为两类：电影/剧集&用户视频。后者指的是用户用手机或摄像机拍摄的视频，这些视频包括各种各样的格式和编码方式。由于多种原因，想要在其他终端用户的设备上观看这些视频，如果不提前进行标准化，就会出现“需要的解码器不存在”，或者“文件大小超出限制无法下载”等错误信息。

本文将详细介绍在Mail.Ru云端视频播放器的工作原理，以及我们是如何使得云播放器“兼容并收”以确保最大限度支持终端用户设备播放的。

存储与缓存：两种方式

类似YouTube、社交网络等很多服务会将用户所上传的视频自动转成恰当的格式。只有转化后的视频才能播放。在Mail.Ru云，我们采用了另一种办法：在原始文件播放时进行转化。与一些专门的视频托管网站不同，我们不能修改原始文件。为什么要选择这种办法呢？Mail.Ru云主要提供云存储功能，如果用户在下载文件时发现他们的文件质量下降或者大小改变，就算只有轻微变化，也会招致用户的不满情绪。此外我们也无法支持存储所有文件的预转化副本——会占据太多空间。而且某些存储文件可能根本不会有人去看，这样做会导致很多的无用功。

动态实时转换还有一个优势：如果要修改转换设置或增加功能，就无需对之前的视频做重新转换了。在这种情况下，一切都是动态实时执行的。

工作原理

针对在线视频流，我们使用了苹果创建的HLS（HTTP实时流媒体）格式。HLS的原理是将每个视频文件切分成较小的片段（即“媒体分段文件”），然后加入播放列表，每个片段都有指定的名称和时间长度。举个例子：时长2小时的电影会被切分为720个媒体片段文件，每个时长10秒。播放器根据用户想要观看的进度，向列表请求相应片段。HLS的好处之一在于：在播放器读取文件标头时，用户无需等待便可开始播放。

这种格式还提供了重要的可能，那就是允许根据用户的网速，实时调整所播放媒体的质量，这就是所谓的自适应流媒体（adaptive streaming）。例如，用户一开始使用3G网络，观看媒体的分辨率为360p；但进入LTE（4G格式的一种）地区时，就会自动切换到720p或1080p。使用HLS时部署起来非常简单：播放器获取“主播放列表”，其中包括适用于不同带宽的交替播放列表。加载一个片段之后，播放器会评估当前的网速，并据此确定下一个片段的质量：是要保持相同、更低还是更高。我们目前支持的分辨率包括：240p、360p、480p、720p和1080p。

后端

The Mail.Ru云服务包括三组服务器。第一组是应用服务器，负责接收视频流媒体请求：创建和返回HLS播放列表，分发转化后的片段，设置转换任务。第二组是数据库服务器，使用嵌入式逻辑（Tarantool），负责存储视频信息和管理转换队列。第三组是转换服务器，负责接收从Tarantool传回的任务队列，并在数据库中记录任务完结。当接收到视频文件片段的请求时，我们首先会检查数据库服务器，查看其中是否包含已经转化好可用的相应分辨率片段。这里有两个可能的场景：

第一个：已经有转换好的片段，此时，我们立刻将其返回。如果有人发送过请求，相应片段就会存在。这属于第一个缓存级别，对所有转换文件都有效。值得一提的是：我们还有一个缓存级别，经常被请求的文件会分发到多台服务器上，避免网络接口过载。

第二个场景：没有转换好的片段。此时，数据库会创建转换任务。之前提过，我们的数据库服务器使用了Tarantool，这是一个速度非常快的开源NoSQL数据库，可以用Lua写入存储过程。这里数据库服务器负责存储视频信息及管理转换队列。应用服务器与数据库之间的通讯方式如下：应用服务器发送请求：“我需要movie.mp4的第二个片段，分辨率为720p；请于4秒内准备好”。4秒内它会收到在何处寻找相关片段的信息，或者错误信息。因此，数据库客户端其实对如何执行任务并不关心（无论是立即执行还是通过一系列的复杂操作）：它使用简单的接口，允许发送请求和接收被请求的数据。

我们提供数据库容错的办法是主-副本故障转移。数据库客户端只向主服务器发送请求，如果当前的主服务器出现问题，我们会将某个副本服务器标记为主服务器，然后将客户端重定向到新的主服务器上。在客户端持续与主服务器交互时，对于客户端来说，这样的主-副本切换是透明化的。

除了应用服务器之外，转换服务器也可以作为数据库客户端。转换服务器负责对视频片段执行转换，现在需要一个与来源视频文件相关联的参数化的HTTP链接。数据库与这种转换服务器之间的通讯，类似于它与应用服务器之间的通讯。转换服务器发送请求：“给我一个任务，我会等待10秒”，如果在10秒内收到任务，就会发送给正在等待的那个转换服务器。在Tarantool中，我们使用Lua的IPC通道，实现客户端到转换服务器的任务转发。通道允许不同请求之间的通讯，下面是转换片段的简单代码：

function get_part(file_hash, part_number, quality, timeout) -- Trying to select the requested fragment local t = v.fragments_space.index.main:select(file_hash, part_number, quality) -- If it exists — returning immediately if t ~= nil then return t end -- Creating a key to identify the requested fragment, and an ipc channel, then writing it -- in a table in order to receive a “task completed” notification later local table_key = msgpack.encode{file_hash, part_number, quality} local ch = fiber.channel(1)v.ctable[table_key] = ch -- Creating a record about the fragment with the status “want to be converted” v.fragments_space:insert(file_hash, part_number, quality, STATUS_QUEUED) -- If we have idle workers, let’s notify them about the new task if s.waitch:has_readers() then s.waitch:put(true, 0) end -- Waiting for task completion for no more than “timeout” seconds local body = ch:get(timeout) if body ~= nil then if body == false then -- Couldn’t complete the task — return error return box.tuple.new{RET_ERROR} else -- Task completed, selecting and returning the result return v.fragments_space.index.main:select{file_hash, part_number, quality} end else -- Timeout error is returned return box.tuple.new{RET_ERROR} end end local table_key = msgpack.encode{file_hash, part_number, quality}
v.ctable[table_key]:put(true, 0)

真正的代码会更复杂：比如还得考虑请求的时候，片段出现“被转换”状态。多亏了这个方案，有新任务时转换服务器会立刻获得通知，任务完成时客户端会立刻获得通知。这一点非常重要，因为视频加载的时间越久，用户越有可能在视频开始播放前关闭页面。

如下图所示，大多数转换都是这样，因此等待不会超过数秒时间。

转换

我们使用FFmpeg来进行转换，并根据需求做了适当的调整。最初我们是计划使用FFmpeg内置工具来执行HLS转换的；但在实际使用中我们遇到了问题。如果请求FFmpeg将20秒的文件转换为片段长度10秒的HLS流媒体，结果会获得可正常播放的两个文件以及一个播放列表。但如果对同一个文件作出请求，先是请求第0到10秒的片段；然后再另启动一个FFmpeg转换器，要求第10到20秒的文件，则会在两个片段的过度期间听到明显的点击声。我们花费了数天时间，尝试不同的FFmpeg设置，但无一成功。最后我们只得给FFmpeg加了一个小补丁，用了一个命令行参数来修复这个“点击”bug。

此外，我们还加入了一些FFmpeg upstream中并未包括的可用补丁，比如解决iPhone所生成的MOV文件在转化时速度很慢的已知问题。我们使用一个名叫“Aurora”的后台程序，控制从数据库中获取任务，并启动FFmpeg。Aurora等数据库后台程序都是用Perl编写的，控制事件循环及各种有用的模块比如：EV-Tarantool和Async::Chain执行异步工作。

最有意思的是：我们并没有在Mail.Ru云上为新的视频流媒体服务安装额外的服务器：需要资源最多的转换工作会在专门独立环境的存储服务器上运行。根据日志和图片显示，我们潜在的负载能力比现在实际应用的要大好几倍。自从2015年6月底我们的视频流服务发布以来，单独视频的请求量超过500万；每分钟观看的单独文件数达到500-600个。

前端

现在，几乎所有人都拥有一两台智能手机。 给朋友或者家人录制短视频没什么大不了的。因此我们做好准备要满足用户这样的需求：从手机或平板电脑上传视频到Mail.Ru云，然后立刻从自己的设备上删除，以节省空间。如果用户想要让别人观看这个视频，他们只需打开Mail.Ru云应用，或用桌面上的web版本启动播放器。现在，不再将所有视频剪辑存储在手机中，却能在任何设备上随时访问已经成为可能。在移动网络中流媒体的码率有所降低，因此都在若干MB大小。

此外，在移动平台上播放视频时，我们使用安卓及iOS本地库。因此，视频甚至可以在刚拆封的智能手机和平板电脑上，用移动浏览器播放：我们所使用的视频播放格式无需再创建额外的播放器。与桌面端的web版本类似，流媒体可以自适应带宽，图像质量会根据当前带宽自动调整。

我们的播放器与竞争对手的播放器有一个主要的区别在于：我们的视频播放器独立于用户的环境而存在。大多数候开发者要做两个不同的播放器：一个使用Flash插件，另一个是用HTML5实现的，随后再上传适用的接口，用于类似Safari之类支持HLS的浏览器。我们只做了一个播放器。并且目标是要能够轻易更换接口。因此，我们的视频和音频播放器看起来非常类似——所有的图标、布局等都是用HTML5编写的。这个播放器不依赖于播放视频的技术，

我们使用Flash来提取视频，但整个插件都用HTML构建；因此，由于无需支持特定的Flash版本，并没有遇到版本同步的问题。播放HTTP流媒体，一个开源库就够了。我们写了一个shim将HTML5视频元素接口翻译成Flash。因此我们可以按照HTML5一直能够运行的方式来编写整个插件。如果浏览器不支持这个格式，只需用本地视频元素来代替，就能实现同样的接口。

如果用户设备不支持Flash，则视频以支持HLS的HTML5来播放（目前只在Safari中实现）。在安卓4.2+及iOS中，使用本地工具来播放HLS。如果不支持或者没有本地格式，我们给用户提供一个可下载的文件。