如何为多个设备编码视频

许多百家乐软件app最新版下载正在增加他们支持的移动和OTT平台的数量，同时实施自适应流媒体，以增强每个平台的观看体验. 有两种方法可以实现这一点:为每个目标生成一组唯一的流, 或者派生一个更小的文件组，它将有效地服务于所有平台. 在本文中，我将探讨后一种方法.

确定目标

第一步是确定你的目标平台. 对于绝大多数生产者来说, 这通常意味着桌面和移动设备, 随着OTT平台越来越普遍. 虽然添加平台一开始可能会让人望而生畏，但请记住这两个令人欣慰的事实. 首先，所有相关目标平台都玩H.264 video, 和第二, they all use one of three adaptive streaming technologies; Flash Dynamic Streaming (either RTMP or HTTP), 光滑的流, 或HTTP直播(HLS). 你可以在 表1.

单个文件max列显示每个平台支持的最大规格. 我没有包括电脑，因为它因平台而异, 没有硬性限制, 大多数已安装的电脑至少可以播放720p的视频. 所有移动平台上的播放功能都依赖于设备, 你应该在引用的URL上看到单个文件流的建议. 稍后会详细介绍. 在自适应流媒体方面, 苹果的HLS无疑是OTT领域的赢家, 只有微软的Xbox 360没有加入这个派对(这并不奇怪)。.

这对百家乐软件app最新版下载来说意味着什么? 魔鬼总是在某种程度上存在于细节中, 但如果你在每个设备上分发单个文件, 您只需要找到并使用每个平台的最佳编码参数. 如果你是自适应分布, 你需要在桌面上支持Flash或平滑流媒体, HLS获得了大部分相关的移动和OTT目标. 加入一个媒体服务器或CDN服务，可以从一种自适应格式转换到另一种自适应格式, 任务开始变得, 简单得多.

在检查每个单独的目标平台之前，让我们讨论一些高层次的现实情况.

手机奠定了基调

首先，移动设备的编码是最复杂的，因为这些设备的播放能力最小，连接速度也最不可靠. 相比之下，大多数电脑和OTT设备可以播放任何H.264配置，并连接到高比特率网络或宽带连接, 无论是直接有线还是通过Wi-Fi.

虽然在连接速度上有一些变化, 在为计算机和OTT设备配置视频时, 你的主要缺点——

Cerns在低端提供可接受的质量，在高端提供带宽成本. 当配置你的流移动, 它是关于配置流，在您的目标中最不强大的单元上播放，并在低连接速度下交付. 这意味着你将为移动传输生成一些流，而这些流可能无法传输到计算机或OTT目标. 这也意味着你应该首先考虑自己的手机平台.

为了给我们的分析增加一些视角，截至12月11日. 20, 2012, NetMarketShare报道 苹果得了61分.手机/平板电脑操作系统市场份额为1%，Android排名第二，为28%.02%， Java ME排名第三，为6.65%，黑莓排名第四，为1.42%，塞班排名第五，为1.24%， Windows Phone排名第六，为0.9%. 我将讨论苹果、Android设备和微软，而忽略其他设备.

苹果移动设备

视频制作人显然优先考虑iOS，因为它拥有最大的市场份额, 还因为苹果在让iOS平台易于推广方面做得非常出色. 例如，苹果特别定义了H.264播放功能的每一个设备发布, 包括决议, 数据速率, 和概要文件, 这一看似显而易见的举动却逃过了大多数Android硬件开发者的注意. 其次，它对HLS进行了定制和定义，使其易于访问其设备. 一个很好的例子是 表2，其中显示了为HLS传送而生成的16:9流的推荐配置参数. 数据取自 Apple技术说明TN2224, 题为“为iPhone和iPad创建和部署HTTP直播流媒体的最佳实践”."

如你所见, 您将获得特定的配置建议，以及哪些流与哪些平台兼容的通知. 对于寻求向iOS平台发布视频的制作人来说，TN2224显然是一个起点.

安卓移动设备

由于以下几个原因，Android设备上的发行要复杂得多. 第一个, 有多个硬件制造商生产的多个设备模糊地或没有提及H.264播放功能. 例如, my daughter has an HTC Rhyme; the spec sheet on the HTC website has no mention of H.264年什么.

设备的数量和多样性，以及H.264回放信息，使得创建表2这样的图表成为不可能的任务. 相反，在 Android支持的媒体格式 page, Google详细介绍了Android操作系统本身的软件回放功能，并提供了如下的建议 表3.

有人会猜测，目前大多数Android平板电脑和智能手机的硬件播放能力远远超过了这些建议. 例如, 安装在我的东芝Thrive平板电脑上, 我使用High profile播放了720p编码的视频，没有任何问题(尽管东芝网站同样未能提供H.264回放信息). 然而，在为Android设备编码时，你不得不猜测. 你知道，苹果公司.

另一个使Android支持复杂化的因素是HLS的支持姗姗来迟, 从Android版本3开始.1. 你可以查看 Android版本渗透率; when I checked in late December 2012, version 3.1及更新版本仅占整个Android市场的35%左右, 使HLS成为一个不完整的解决方案. 这也是一个不完美的解决方案, 与崩溃, 寻求, 以及某些平台上的长宽比问题, 你可以在 Jeroen Wijering谈HLS、DASH和JW Player." 正如Wijering所指出的，最全面的解决方案可能是创建自己的应用.

微软Windows手机

尽管微软目前在移动/平板电脑领域的份额微不足道, 微软对Windows 8、RT和Windows Phone平台寄予厚望. 和苹果一样，微软提供的手机数量有限 很好地记录了它们的功能. 请注意，虽然Windows RT将支持Flash(以及2013年中期的AIR), Windows手机目前不支持Flash. 对Windows Phone的支持尚未开启 Adobe的Flash技术路线图.

如表1所示, Windows Phone平台唯一支持的自适应技术是光滑的流. 正如前面提到的Windows Phone支持的媒体编解码器文档所指出的那样, 并非所有Windows手机都支持动态分辨率更改. 对于这些手机，自适应组中的所有分辨率必须共享相同的分辨率.

平滑流的推荐编码参数的最佳来源是包含在Microsoft Expression Encoder 4中的编码预设. 不过考虑到空间问题，我们无法在此复制该电子表格, 任何感兴趣的人, 我记录了1080p源视频的推荐配置参数 谷歌文档电子表格 你可以访问. 你会看到, 预设使用多种分辨率，在某些版本的Windows手机上无法使用.

过多的设备

再一次。, OTT设备比移动设备更容易，因为它们都至少依赖于相对高速的连接，并且几乎都可以解码任何H.264流你扔他们的方式. 你有链接到播放和自适应流媒体规格, 在这里我将指出其中的亮点.

虽然Roku支持多种自适应规格， 它的指南说得很清楚 HLS是首选技术. 该指南还指出，Wowza媒体服务器“非常受欢迎”, 在人力百家乐软件管理领域的预算考虑的选择,，并提供了使用Roku流媒体播放器的有用指南.

Apple TV在之前的iOS部分已经讨论过了. 注意，根据 Boxee支撑板因此，HLS只能在应用程序中工作，而不能在浏览器中工作. 有趣的是，你可以看到 表4，谷歌电视改编了它的 流的建议 来自苹果TN2224, 尽管它忽略了最低质量的分组，并推荐所有流的High profile.

最后，关于Xbox的流畅流，请参阅之前关于微软Windows Phone的讨论. 注意，我检查了Expression Encoder，没有Xbox预设.

合成

有了这个背景，让我们开始做一些决定，从流的数量开始.

有多少流??

如表2所示, 苹果推荐10个1080p源内容流, 包括音频流. 然而, 在采纳这一建议之前, 让我们来看看发行苹果最高质量的流媒体要花多少钱. 具体来说，1080p视频的8,564Kbps，一个小时的视频将消耗大约4GB. 根据 丹·雷伯恩的最新博客 关于这个问题, 客户购买的CDN定价从100美元起,每年的带宽费用从每GB 1美分到12美分不等，从000美元到100多万美元不等.

在这些价格下, 按照苹果推荐的最高费率，播放一小时视频的成本在4美分到48美分之间. 然而，我看到一些规模较小的承诺的传统带宽定价高达1美元.10/GB，这将使这个1080p配置的每小时传输成本提高到4美元.40.

在配置最高质量的流时, 选择您能负担得起的最高数据速率, 考虑到你的盈利策略和成本结构. 因为你的高质量流必须看起来非常好, 你必须相应地调整视频分辨率. 例如，如果你只能负担得起3Mbps，那就用720p编码，而不是1080p.

在频谱的另一端，确定您想要支持的最低视频数据速率. 对于苹果来说，这是200Kbps，尽管我的客户制作的视频低至110Kbps. 然后确定在该视频数据速率下提供最佳质量的分辨率/帧率组合. 苹果的416x234帧，每秒10-12帧是一个合理的起点.

现在你有了你的高端和低端流. 接下来，您需要选择完成两个目标的流的数量. 首先是为浏览器中播放视频的每个窗口大小提供至少一个流. 例如，YouTube在两种窗口尺寸下播放16:9视频，分别是640x360和854x480，外加全屏. 如果你上传720p或更大的视频, YouTube将以这两种分辨率制作视频, 因为当视频以其原生分辨率显示时，编码和视频播放都是最有效的. 因此，如果你在网站上以640x360的窗口显示视频, 您至少需要一个该分辨率的流.

您还需要足够数量的流作为最高和最低质量流之间的合理垫脚石. 对于YouTube, 这意味着在配置为176x141的移动流和1080p流(或1080p流)之间有四个16:9流, 流在426x240, 640x360, 854x480和720p). 虽然我不知道 ESPN的移动或OTT流的规格, 电脑浏览, 在低点480x272和高点720p: 576x324之间有三条流, 640x360, 和768年x432.

更多的 streams are not necessarily better; more streams means that the streams are closer together, 在增加流切换频率的同时最小化质量差异, 这会干扰观看. 理想的情况是，观看者能够快速识别出最佳流，并在视频结束时继续观看.

其他配置选项

一旦知道将产生多少个流，就需要对它们进行配置. 在光谱的低端, I prefer to drop the frame rate rather than resolution; you can read all about why in "Configuring Low Data Rate Adaptive Streams“(http://go2sm.com/configadaptive). 在选择每个流的数据速率方面, 这种差异一开始应该相当小——比如苹果前三种视频流之间的200Kbps——并在更高的比特率下继续增加, 比如分隔前四个流的2Mbps.

可能最大的配置问题与H有关.264配置文件应用到每个文件. 例如, 如果你遵循苹果的建议, 您将使用基线配置文件与视频的前四个流和主配置文件为接下来的四个, 在任何情况下都要保持设备兼容性. 如果你是为Android平台制作游戏, 最安全的方法是对所有流使用基线配置文件. 然而, 所有的OTT平台和电脑都可以播放使用High profile编码的流, 增加编码和存储成本?

我在我的文章《H.264在移动世界:告别主要和高调?“(http://go2sm.com/h264profiles), 基本上记录了我代表一个咨询客户所做的研究. 具体地说, 我制作了三个测试用例来比较基线编码视频的质量, Main, 和高调使用其他相同的参数. 只在其中一个测试用例中, 视频是在640x360@240Kbps上编码的, 差别明显吗?. 在更合理的设置下, 例如720p@800Kbps和640x480@468Kbps, 这些文件几乎无法区分.

客户查看了所有文件之间的质量差异，并合理地得出结论:通过宽带连接的计算机用户很少会长时间查看640x360@240Kbps文件. 他决定只制作一组文件, 在必要时使用基线配置文件，以保持与目标移动设备的兼容性. 我建议你对有代表性的录像进行同样的分析，然后得出你自己的结论.

要特别注意主要流和高端流之间的质量差异. 如果你选择高端的OTT和电脑, 而不是Main, 你需要使用Main配置文件创建与iOS/ Android兼容的等效文件.

我认为大多数Android设备与苹果设备有着相似的硬件播放功能，它们具有相同的外形和发布日期, 所以我不会为Android创建一组仅限基线的流. 相反，表2所示的模式对于Android来说可能是安全的. 这可能是提高效率的最佳模式, 一种适用于所有计算机的自适应分组编码, 移动, 和OTT目标.

把事情包起来

既然你已经做了所有艰难的决定, 现在是时候讨论自适应流编码的机械方面了. 第一个, 所有文件的关键帧间隔需要相同，以便无缝地进行流切换. 大多数制作人使用2或3秒的间隔，并禁止在场景变化时插入关键帧.

第二个, 使用恒定比特率编码(CBR)或约束可变比特率编码(VBR)进行编码, 最大数据速率在1.25和1.5倍于目标. 这些技术将最小化由于视频数据速率变化而不是带宽或CPU条件变化而发生的流切换.

最后, 关于音频, 认识到对自适应组中的所有文件使用相同的音频参数是最安全的, 在流切换期间，哪一种方法可以最小化弹出或类似工件的风险. 这就是为什么苹果推荐44.表2中所有流以64Kbps的速度播放1 kHz音频.

另一方面, 如果你正在制作优质内容，其中音频质量是整体体验的重要组成部分, 您可能会发现这种方法限制太大. 尽量减少潜在的问题, 对所有流使用相同的频率并切换频道数, 数据速率, 或两个. 例如，考虑使用44.1千赫单声道音频在32Kbps为您的最低流，44.1千赫单声道在64Kbps中等质量的流，和44.1千赫立体声128Kbps为您的最高质量的流. 然后在上线之前进行测试，以确保在切换流时不会出现音频伪影.

多设备映像 通过在上面.

Jan Ozer的文章首先出现在在线视频上.网