以下是有关我们如何从NVidia加载卡并对其进行流代码转换的任务的详细故事。 让我们展示一下我们尝试了发生的事情，以及如何最好地使用视频卡进行在线流式传输。几年来，我们的团队一直在开发用于在线处理和分发媒体内容的产品。
本文最近
介绍了为什么在我们的YouTube时代内容所有者可能需要这样的解决方案。
Nimble Streamer媒体服务器是我们的产品之一，它是一种服务器软件，可将实时流和文件输入到输入中，并使大量观众可以访问它们，同时允许其通过内容获利。 这是一个用C ++编写的本机应用程序，已移植到所有流行的OS（Linux，Windows，MacOS）和平台（x64，ARM）上。 从一开始，低资源消耗和高生产率就是主要要求，我们在此方面取得了
不错的成绩 。
去年，我们发布了Nimble Streamer附加
直播流转码器 。 此应用程序允许您获取不同格式的视频和/或音频的输入流，并实时对其进行各种转换。 功能包括解码（软件和硬件），使用过滤器的视频和音频转换（调整大小，覆盖等）以及编码（编码）-软件和硬件。
转码器通过WMSPanel Web服务进行控制，转码脚本通过拖放界面创建，使您可以直观地看到该过程。 可以一起运行各种方案-通过这种方法，可以方便地运行测试组合，以各种形式加载服务器。
在这些视频中，您可以看到有关界面工作方式的示例。
每个流的解码仅在进行所有进一步的转换之前完成一次。这使您可以节省昂贵的解码操作上的资源，这将在测试中更清楚地看到。
可以在我们的转码器中使用的转换机制之一是使用NVidia的GPU进行硬件解码和视频编码。 最新一代的图形卡使您可以执行一些典型任务，从而减轻了CPU的负担。 我们的转码器能够与此硬件一起使用，该硬件已被我们的客户积极使用。
在与NVidia俄罗斯办事处代表进行沟通的过程中，我们被要求尝试对转码器和NVidia GPU进行联合压力测试，以便了解将这种串联方式与仅使用软件转码进行的经济效果相比，而无需硬件加速。 此外，我想了解如何最佳地使用GPU，并在可能的情况下提供良好的配方。
在我们的实验周期中，我们需要快速获得合适的熨斗并对其进行访问。 我们计划开会两个星期。 剩下的就是去哪里找到设备了。 最好的选择是在云中找到它们并获得远程访问。 在寻找选项之后，事实证明AWS还没有配备带有Maxwell一代GPU的VM，并且在Azure云中，仅计划尽快开始提供它们。
1.在Softlayer云中从NVidia提取铁，设置Nimble Streamer
在NVidia的帮助下，IBM为我们提供了对其云（IBM Bluemix云平台）（以前称为
Softlayer ）的访问权限。 这是一个大型的现代化数据中心网络，遍布世界各地（在发布时约为50个），由一个公共专用网络连接，并提供大量的云基础架构服务。 所有数据中心都是统一的，可以让您租用一到数百台具有所需配置的虚拟或物理服务器，租用几个小时，以及平衡器，存储系统，防火墙-通常，为部署的IT服务构建可靠的IT基础架构所需的全部资源。
IBM的俄罗斯代表处使我们能够完全访问用于管理云服务的
自助服务门户和必要的服务器配置，在其中我们可以使用不同的输入流和代码转换器设置。
铁
首先，为我们提供了一个物理服务器（裸机），该服务器具有128 GB的RAM和2xGPU NVidia Tesla M60，并预装了OS Ubuntu 14.04。 所有服务器参数，密码，固件版本，其切换，专用IP，硬件组件的状态都可以直接在您的个人帐户中看到，从而使您可以使用租用的硬件进行所需的操作，从而最大程度地减少了与IBM支持人员交互的需要。 在测试运行期间，事实证明，由于上下文生成方面的许多限制，我们无法最佳地加载此配置。
我们想减少配置。 由于我们使用了云平台，因此需要通过自助服务门户来请求配置更改。 批准后，此操作大约需要2个小时才能到达批准的服务窗口。 在这段时间里，阿姆斯特丹数据中心的技术人员从先前提供给我们的服务器中删除了额外的组件（RAM插槽和1xGPU），然后将其恢复运行。 应当注意，对于开发人员而言，此选项非常方便，因为无需处理硬件设置，对其进行修复，甚至无需花费时间安装操作系统。 让我提醒您，在这种情况下，不使用管理程序，因为我们需要最大限度地利用硬件资源。
根据我们的研究结果，我们确定了以下服务器配置：
双Intel Xeon E5-2690 v3（2.60GHz）
24核
64GB RAM
1TB SATA
我们有2个处理器，每个处理器具有12个内核，而且由于采用了超线程技术，我们获得的处理器数量是原来的两倍。 几乎48个内核。
在具有图形加速器的场景中，使用了基于GM204芯片-Tesla M60的卡：
NVIDIA Tesla M60
1个GPU：2个Maxwell GM204
记忆体：16GB GDDR5
时钟速度：2.5 GHz
NVIDIA CUDA核心：2 x 2048
内存带宽：2 x 160GB /秒
我提请您注意以下事实：在简化的硬件上没有完成亲和力，芯片调整，超频或其他魔术操作-仅非超频的CPU和GPU，对于GPU，仅使用了从NVidia网站获得的官方驱动程序。 如果有人有类似的经历，请分享评论。
因此，我们可以访问。 快速了解控制面板的Web界面（那里的所有操作都很简单明了），然后通过SSH访问服务器-这是我们在通常的Ubuntu命令行中使用的Nimble Streamer，注册新的转码器许可证并进行一些配置设置。
灵活的流光代码转换器
Nimble Streamer已配置为预先创建GPU上下文缓存。 这是由于GPU限制了所创建的解码和编码上下文的最大数量，此外，即时创建上下文可能会花费太多时间。
有关创建上下文问题的更多详细信息，请参见下面的相应部分。
第一个系列测试的示例上的Nimbl设置：
nvenc_context_cache_enable = true
nvenc_context_create_lock = true
nvenc_context_cache_init = 0：30：15.1：30：15
nvenc_context_reuse_enable = true
有关这些设置的更多详细信息，请
参见我们的文章 。
在开始每个系列的测试之前，考虑到每个任务的细节，分别配置了缓存。
创建转码脚本
在我们的WMSPanel服务中进行了进一步的工作，在该服务中配置了代码转换器脚本。
如前所述，工作通过Web界面进行，一切都非常清晰和方便。 我们创建了许多方案，这些方案结合了不同的代码转换选项（CPU / GPU），不同的分辨率选项和不同的编码参数（CPU / GPU，配置文件，比特率等）
可以同时运行多组场景，从而可以引入各种测试组合，以不同的顺序增加负载，并根据情况进行更改。 只需选择必要的方案，然后停止或继续它们即可。
这是一组方案：
这是其中一种情况的示例：
GPU解码器如下所示：
我们应用图像尺寸过滤器：
这是GPU变体的编码器：
通常，可以
在这些视频中看到代码转换器界面的操作。
2.转码流FullHD 1080p
首先，我们测试了最高负载的情况，以找出铁功能的极限。 目前，实际使用的最“高分辨率”是FullHD 1080p。
为了生成原始的实时流，在
Full H （
264 * 1080）中以
高清晰度
H.264拍摄了一个文件。 内容本身就是该城市的视频之旅，即 这是具有平均图像更改率的视频。 没有可以促进代码转换器工作的静态单色帧，但是类型和颜色的更改没有太快。 一句话-一个相当典型的负载。
将36个相同的流馈送到Nimble Streamer输入，然后将其用于转码器中的不同场景。
通常使用转码方案-传入流是
1080p高配置文件，
720p，480p，360p主配置文件 ，然后从中生成
基准配置文件流
：240p，160p 。 总的来说，在输入端有1个流，在输出端有5个流，通常，还对原始流进行直通（无变化的传输），以便观看者在观看时可以选择1080p本身。 我们没有在脚本中添加它，因为 它不使用代码转换-数据从输入直接传输到输出。 此方案在Nimble中进行了优化，在实际情况下，它将相对稍微增加内存消耗。
生成的流中的音频-不。 向脚本中添加音频不会导致大量的CPU负载，但是出于实验的纯洁性，我们排除了声音。
CPU测试，无GPU
首先，我们在不使用GPU的情况下启动了转码脚本，并在脚本中指定了软件解码器和编码器。
结果，在发出所有退出许可的80个流的情况下，仅可能处理16个输入流。
CPU负载-4600％，即 涉及46个核心。 RAM消耗-约15GB。
CPU + GPU测试
启动时的上下文缓存配置为0：30：15.1：30：15-即 每个GPU 30个用于编码的上下文，15个用于解码的上下文。
让我提醒您，在GPU上，我们有两个内核，它们使我们能够并行化任务-这对我们很有用。
通过以下流程配置可获得最大负载。
输入解码器GPU0和GPU1-15流。 因此，我们获得了30个解码流，准备进一步使用。 每个流仅解码一次，无论将来使用多少场景。
分别向编码器GPU0和GPU1馈送15个数据流以获取720p，即 退出时有30个720p的视频流。
此外，GPU0和GPU1编码器分别提供了480p的15个流-并且还输出了30个480p的流。
由于编码器上下文已用尽，因此在CPU上设置了剩余权限的编码。 结果是：
- 30个流360p
- 30个流240p
- 30个流160p
结果是2600％CPU，75％解码器，32％编码器。 接下来，为CPU加载了6个用于解码的流，为每5个类似的分辨率配置了一个，每个输出总共30个线程。
总共
在输入处接收
了36个流，在输出处发布了180个 。 最终负载固定为：
4400％CPU，75％卡解码器，32％卡编码器，30GB RAM 。
一些细节
我们决定检查在GPU上处理最困难的任务的选项-解码1080并编码720和480，然后让其余部分通过CPU处理。
首先，我们检查了解码器的限制。 在22个线程的情况下，解码受上下文问题的影响，因此根本无法创建它们。 减少到21-创建了上下文，但是负载变为100％，并且开始在流中观察到伪像。 我们停止了20个流-我们解码了20个流，以160p编码-一切正常。
此外，凭经验证明，此板载16GB RAM的卡可以自信地在47种环境中使用-两者之间没有区别，它们是编码器或解码器的环境。 我再说一遍-这是专门针对这款Tesla M60 GPU的，在其他显卡上，此数字可能有所不同。 我们认为，如果卡具有24GB的RAM，上下文的数量可能会有所不同，但这需要进行测试。
结果，我们选择了缓存创建公式“解码器的15个上下文和编码器的30个上下文”-该公式为输入提供30个流，并且每个流都允许您创建2个权限。 因此，较高的分辨率（720和480）是在GPU上启动的，其余分辨率（360、240和160）已发送到CPU。 由于此后CPU仍然是空闲的，因此我们用新线程“完成”了空闲内核，剩下4个内核用于实用任务。
3.转码流高清720p
典型的负载情况 现在，大多数内容都是以高清格式创建的。 甚至最近的SuperBowl LI（美国市场上收视率最高的节目）也
以高清广播 ，从而使FullHD成为未来。
为了生成源流，以
高清晰度 （
HD * 1280 * 720）拍摄了一个
文件 。 内容是我们工程师最喜欢的“好妻子”系列，即 这是具有平均图像更改率的视频。
在Nimble Streamer的入口处，输入了70个相同的流，然后将它们用于转码器中的不同场景。
使用以下转码方案-传入流是
720p高配置文件，
480p，360p主配置文件 ，然后
从中生成240p，160p基线配置文件流。 总计，在输入1，在输出4。未执行原始流的传递，如前一种情况一样。 生成的流中的音频也不是。
CPU测试，无GPU
如上一节所述，我们仅尝试在CPU上对流进行转码。 结果，通过发出所有退出许可的88个流，仅可以处理22个输入流。 CPU负载-4700％，即 涉及47个核心。 RAM消耗-大约20GB。
CPU + GPU测试
启动时的上下文缓存配置为0：23：23.1：23：23-即 每个GPU有23个用于编码的上下文，有23个用于解码的上下文。
使用GPU，对46 720p流进行了解码。 在那里，在GPU上对46个480p的流进行了编码。 接下来，在CPU上完成360p，240p和160p编码-每个流46个。
固定负载为2100％CPU，61％解码器，16％编码器。
此外，针对GPU的每个1个线程-4个输出启动了对CPU的24个线程的编码和解码。
总共
输入了70个流，输出了280个流 。
负载：
4600％，解码器的61％，编码器的16％，30GB RAM 。
至于先前的测试，也许更大的RAM GPU将提供更多的上下文，并且我们可以处理更多的线程。 但这只是理论上的，有必要检查。
4.在NVidia GPU中创建上下文的问题
关于这个问题的几句话使我们无法在GPU上处理更多的线程。
去年年底，我们与NVidia团队一起测试了几张卡片。 当使用多个GPU时，事实证明，创建上下文会大大降低服务器的速度-创建每个新上下文会占用地图上越来越多的时间。 如果第一个上下文的创建时间约为300毫秒，则随后的每个上下文都会增加200-300毫秒，而在第三个十个上下文中已经创建了一个新上下文，每个上下文花费了3-4秒。 当用户创建代码转换脚本时，假定他立即开始工作且没有延迟，并且这种新情况抵消了Nimbl速度的所有优势，并延迟了创建上下文的时间，从而导致开始编码的延迟。
最初，人们怀疑Nimble，但随后我们使用ffmpeg进行了测试，NVidia本身向客户提供了ffmpeg，结果完全相同-GPU花费越来越多的时间创建每个新上下文。 在服务器已经进行代码转换并且您需要启动新线程进行处理的情况下，这会影响整体性能并使服务器完全无法使用。
NVidia团队详细描述了该问题，但到目前为止，尚未提供全职解决方案。 因此，到目前为止，我们已经在服务器中实现了上下文缓存机制，并在服务器启动时初步创建了上下文。 从最终用户的工作角度来看，这解决了问题，但是Nimbl的启动可能需要一些时间。
在我们的博客中介绍了设置Nimbl以便有效处理上下文。
另外，上下文不容易创建。 当包含任何转码脚本时，由于上下文众多，NVENC API开始引发错误：“ API调用失败，因为它无法分配足够的内存来执行请求的操作。”
从经验上看，事实证明一个GPU可以在47个上下文中启动并可靠地工作-并没有区别，它们是编码器或解码器的上下文。 有人认为这是由于GPU上的内存量所致。 现在有16 GB，如果您将卡设置为24 GB，则可能可以完成更多上下文。 但这只是一个理论，有必要进行检查，如前所述。 获得的数据对于特定的GPU型号有效，其他卡必须单独测试。
在处理大量工作时，对上下文数量的限制成为主要障碍。
5.结论
因此，测试的目的是研究GPU在指定任务范围内的有效性，并开发适当使用方法。 结果如何？
经济效果
上面，我们看到了在CPU和CPU + GPU串联时可以处理的线程数是如何不同的。 让我们看看这对金钱意味着什么。 作为基础，我们采用所有相同的Softlayer及其设备租赁价格。
- 没有GPU的配置每月费用为819美元 。 在这里您可以接车。
- 在阿姆斯特丹的数据中心，配备GPU的配置每月费用为1729美元 ，可在此处找到价格。 使用GPU时，由于使用了较大的2U机箱尺寸，因此服务器租赁价格略有上涨。 购买设备时，经济效果可能会更高（但这需要对TCO进行认真分析，考虑到NVidia GPU产品线的不断更新）。
现在让我们看看测试结果：对于FullHD 1080p- 不带GPU的CPU：每个输入16个线程+每个输出80个线程
- CPU + GPU：每个输入36个线程+每个输出180个线程
GPU优势：2.25倍。使用GPU的好处：租用一台带GPU的服务器时，每月 $ 819 * 2.25-$ 1729 = $ 113。对于高清720p- 不带GPU的CPU：每个输入22个线程+每个输出88个线程
- CPU + GPU：每个输入70个线程+每个输出280个
GPU优势：3.18倍。使用GPU的好处：租用一台带有GPU的服务器时，每月 $ 819 * 3.18-$ 1729 = $ 875也就是说，有了租用选项，节省下来的钱是非常可观的。这没有考虑折扣-在IBM俄罗斯办事处，他们承诺与此处提供的价格相比，在云中租用资源有折扣。我们没有在购买中涉及这些选项，因为在这里，TCO很大程度上取决于供应商的选择，数据中心的服务成本以及裸机工作人员熟悉的其他因素。但是，初步数据也表明支持基于GPU的解决方案。另外，请不要忘记流量和通道宽度-它们以上述比率包含在一定数量中，但是您将需要根据线程数，预期用户数等为任务选择选项。缩放比例
在我们看来，每台服务器带有一个图形卡的选件比带有两个或多个卡的选件更具成本效益。如我们所见，GPU解码器总是比编码器负载更多，但由于上下文使用方面的问题，即使它仍然保持不足。如果添加第二张卡，解码器的使用量将更少，编码器我们将无法满负荷加载，并且所有编码工作仍需要转移到CPU，这对于钱来说是不合理的。借助Softlayer的支持，我们还使用两个GPU测试了该选件，但是由于经济影响较弱，因此我们在本文中未提供详细信息。因此，为了扩展负载，与将卡添加到现有计算机相比，最好使用一张显卡添加新服务器。如果项目的传入和传出流的数量相对较小-例如，十几个具有少量输出分辨率和相对少量过滤的HD流，则使用不带GPU的服务器会更方便。还值得注意的是，用于转换线程的任务的RAM数量不如处理能力那么重要。因此，在某些情况下，还可以通过减少内存量来节省。结论
提出的硬件解决方案-结合了Tesla M60 CPU和GPU-非常适合在重负载下对实时流进行转码。GPU处理最耗费资源的操作-解码流并将其编码为最高分辨率，而中分辨率和小分辨率在CPU上得到了很好的处理。如果其中一位读者有经验并优化了现场直播的图形卡性能，我们将很高兴结识您的经验-在评论中写下。