我们之前讨论过一种解决方案是利用云服务的力量对视频进行转码。虽然可以使用本地计算进行转码，但过去三年生成的大量内容——以及大部分内容是以 4K 格式获取的事实——使得云转码成为一个更具吸引力的主张（即使点播流媒体内容以接近 720p 或 1080p 的数据速率和分辨率通过网络交付）。
源码演示：y.jcedus.top
部分源码：main.go
package main
import (
"io/ioutil"
"log"
"NYTimes/gizmo/server"
"google/gops/agent"
"video-dev/video-transcoding-api/v2/config"
_ "video-dev/video-transcoding-api/v2/internal/provider/bitmovin"
_ "video-dev/video-transcoding-api/v2/internal/provider/elementalconductor"
_ "video-dev/video-transcoding-api/v2/internal/provider/encodingcom"
_ "video-dev/video-transcoding-api/v2/internal/provider/hybrik"
_ "video-dev/video-transcoding-api/v2/internal/provider/mediaconvert"
_ "video-dev/video-transcoding-api/v2/internal/provider/zencoder"
"video-dev/video-transcoding-api/v2/service"
)
func main() {
agent.Listen(agent.Options{})
defer agent.Close()
cfg := config.LoadConfig()
server.Init("video-transcoding-api", cfg.Server)
server.Log.Out = ioutil.Discard
logger, err := cfg.Log.Logger()
if err != nil {
log.Fatal(err)
}
service, err := service.NewTranscodingService(cfg, logger)
if err != nil {
logger.Fatal("unable to initialize service: ", err)
}
err = server.Register(service)
if err != nil {
logger.Fatal("unable to register service: ", err)
}
err = server.Run()
if err != nil {
logger.Fatal("server encountered a fatal error: ", err)
}
}
由于质量捕获的提高和整体内容创建的增长，本地转码在陷入建难以跟上 原来你最简单的工作流程。这就是云转码发挥作用的地方。
与让多台计算机坐在本地机架上，经常在大型转码工作之间闲置，基于云的转码的概念是在给定时间将计算能力实例分配给给定转码工作。在这些时间之间，计算实例——可以是单个强大服务器上的多个虚拟机 (VM) 之一，也可以是实际服务器本身——将被重新分配给其他任务甚至其他客户。
云转码源码技术核心
本地转码的一个论点是，可以通过利用用于视频编辑的计算机的功能快速执行转码过程。这样做的前提是，最熟练的本地计算旨在以每秒 50-110 兆字节的速度处理 4K、6K 甚至 8K 编辑，因此任何给定的转码工作 - 将内容降低到较低的分辨率和较低的数据率——对于同样强大的计算机来说要容易得多。
不幸的是，我们必须解决两个问题：首先，在编辑计算机上执行多个转码会影响在同一台计算机上实际编辑的能力。其次，更重要的是，现代点播流媒体系统依赖于以不同的分辨率和数据速率对单个文件进行多次再现。这些统称为演绎版，给定的文件可能需要转换为多种数据速率（称为转码）甚至多种编解码器（真正的转码）以及与多个音频流集成（称为转码）。最终结果将是占用本地计算数小时对单个 30 分钟主文件进行转码。相反，基于云的转码可以通过同时启动多个计算实例来处理各种比特率和分辨率的所有任务。
与其这样做，不如考虑使用基于云的转码来加速整个交付工作流程。许多点播转码解决方案还提供了一种向流媒体观众提供点播内容的方法。将主文件上传到基于云的转码解决方案需要多长时间？我们多年来的测试表明，与在本地通用转码计算机上转码五个再现相比，上传主文件所需的时间不到四分之一。
一些潜在的云转码客户的最后一个好处是无需购买额外的本地转码计算机。这种降低的资本支出 (CapEx) 被在基于云的转码系统上租用时间的运营费用 (OpEx) 所取代。
因此，您的里程可能会有所不同，您需要找到提供简单定价机制的云转码提供商，例如转码的分钟数。此外，请查看跨多种编解码器类型存储多个再现的定价。随着转码数量的增加，这种平衡通常会自行逆转。尽管如此，此时的假设是有足够的收入流入，然后重新考虑购买本地设备或继续使用基于云的转码服务是否更有意义。
虽然视频兼容性至关重要，但云转码最常见的用例是自适应比特率流 (ABS)。 许多流媒体通过向观众提供多种不同的比特率来提供多比特率流媒体，但 ABS 通过根据观众的互联网带宽和设备的处理能力实时调整比特率，更进一步。这意味着 ABS 可以使用转码、分段、自适应比特率选择算法和其他技术大大减少缓冲并优化观众的播放体验。
ABS 已经通过诸如MPEG-DASH（HTTP 的 MPEG 动态自适应流）之类的尖端流协议成为可能 。该协议是第一个成为国际标准的自适应比特率解决方案，因为它独立于供应商且与编解码器无关。虽然它在许多方面类似于 HTTP 实时流 (HLS) 协议，但 MPEG-DASH 几乎兼容任何视频内容格式，而不仅仅是 H.264。
对于直播，转码也很关键。在直播期间，通常使用 RTMP 协议对流进行编码。 问题是 RTMP 仅与开箱即用的 Flash Player 兼容，较新的 Web 浏览器不支持。这意味着大多数广播公司需要在本地或云端将其流转码为更现代的传输协议，如 HLS 或 MPEG-DASH。
云中的视频转码与本地转码不同，因为处理发生在流媒体平台的服务器上，而不是本地计算机上。这意味着云转码不需要广播站点的额外带宽，这对于直播流媒体至关重要。基于云的方法也更具可扩展性，因为转码器可以在必要时快速增加其可用资源以处理更多视频。
同时，云转码也可以节省成本。无需通过安装额外的本地硬件来规划峰值负载，基于云的解决方案可以在必要时扩大规模，并在需求减少时再次缩减。云转码的这种固有弹性意味着流媒体只需为他们使用的资源付费。
除了包含的基于云的视频转码器 外，用户还可以将视频文件推送到自行处理转码的社交媒体平台。此外，云转码源码中设计了弹性流协议 (RSP) 以减轻视频数据在传输到云服务器时的丢失。这对于确保云视频转码器拥有完整的源文件以用作视频内容的每个转码再现的基础至关重要。这意味着支持 RSP 的云转码器是一种可扩展的选项，可以为所有设备的观众提供最高质量的视频。