先ほど説明したソリューションの 1 つは、クラウド サービスの機能を使用してビデオをトランスコードすることです。トランスコーディングにローカル コンピューティングを使用することは可能ですが、過去 3 年間に生成された膨大な量のコンテンツと、そのコンテンツの多くが 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) の 1 つ、または実際のサーバー自体であるコンピューティング インスタンスは、他のタスクまたは他のクライアントに再割り当てされます。
クラウド トランスコーディング ソース テクノロジー コア ローカル
トランスコーディングの引数の 1 つは、ビデオ編集に使用されるコンピューターの能力を利用して、トランスコーディング処理を迅速に実行できることです。これは、最も優れたネイティブ コンピューティングが、毎秒 50 ～ 110 メガバイトで 4K、6K、または 8K の編集を処理するように設計されていることを前提としています。同等に強力なコンピューター。
残念ながら、2 つの問題に対処する必要がありました。まず、編集用コンピューターで複数のトランスコードを実行すると、同じコンピューター上で実際に編集する機能が妨げられます。2 つ目は、さらに重要なことですが、最新のオンデマンド ストリーミング システムは、1 つのファイルをさまざまな解像度とデータ レートで複数回再生することに依存しています。これらはまとめてレンディションと呼ばれ、特定のファイルを複数のデータ レート (トランスコーディングと呼ばれる) または複数のコーデック (真のトランスコーディング) に変換し、複数のオーディオ ストリームと統合する (トランスコーディングと呼ばれる) 必要がある場合があります。最終的には、ローカル コンピューティングに何時間もかかる単一の 30 分のマスター ファイルをトランスコードすることになります。対照的に、クラウドベースのトランスコーディングは、複数のコンピューティング インスタンスを同時に起動することで、さまざまなビットレートと解像度ですべてのタスクを処理できます。
これを行う代わりに、クラウドベースのトランスコーディングを使用して配信ワークフロー全体を高速化することを検討してください。多くのオンデマンド トランスコーディング ソリューションは、オンデマンド コンテンツをストリーミング視聴者に配信する方法も提供します。マスター ファイルをクラウドベースのトランスコーディング ソリューションにアップロードするのにどのくらいの時間がかかりますか? 長年にわたる当社のテストでは、マスター ファイルのアップロードにかかる時間は、ローカルの汎用トランスコーディング コンピューターで 5 つのレンディションをトランスコードする場合の 4 分の 1 未満であることが示されています。
潜在的なクラウド トランスコーディングの顧客にとっての最後の利点は、追加のオンプレミスのトランスコーディング コンピューターを購入する必要がないことです。この削減された設備投資 (CapEx) は、クラウドベースのトランスコーディング システムのレンタル時間の運用費用 (OpEx) に置き換えられます。
そのため、マイレージはさまざまである可能性があり、トランスコードされた分数などの単純な価格設定メカニズムを提供するクラウド トランスコーディング プロバイダーを見つける必要があります。また、複数のコーデック タイプにまたがる複数のレンディションを格納するための料金も参照してください。このバランスは通常、トランスコードの数が増えると逆転します。それでも、現時点では、オンプレミス機器の購入やクラウドベースのトランスコーディング サービスの使用を継続することを再検討する前に、十分な収益が得られるという前提があります。
ビデオの互換性は重要ですが、クラウド トランスコーディングの最も一般的な使用例は、アダプティブ ビットレート ストリーミング (ABS) です。多くのストリーマーは、視聴者に複数の異なるビットレートを提供することでマルチビットレート ストリーミングを提供しますが、ABS はさらに一歩進んで、視聴者のインターネット帯域幅とデバイスの処理能力に基づいてリアルタイムでビットレートを調整します. これは、ABS がトランスコーディング、セグメンテーション、適応ビットレート選択アルゴリズム、およびその他の技術を使用して、バッファリングを大幅に削減し、視聴者の再生体験を最適化できることを意味します。
ABS は、MPEG-DASH (MPEG Dynamic Adaptive Streaming over HTTP) などの最先端のストリーミング プロトコルによって可能になりました。このプロトコルは、ベンダーやコーデックに依存しないため、国際標準となった最初のアダプティブ ビットレート ソリューションです。多くの点で HTTP ライブ ストリーミング (HLS) プロトコルに似ていますが、MPEG-DASH は、H.264 だけでなく、ほぼすべてのビデオ コンテンツ フォーマットと互換性があります。
ライブ ストリーミングでは、トランスコーディングも重要です。ライブ ブロードキャスト中、ストリームは通常、RTMP プロトコルを使用してエンコードされます。問題は、RTMP はすぐに使用できる Flash Player とのみ互換性があり、新しい Web ブラウザーではサポートされていないことです。これは、ほとんどの放送局がローカルまたはクラウドでストリームを HLS や MPEG-DASH などの最新のトランスポート プロトコルにトランスコードする必要があることを意味します。
クラウドでのビデオ トランスコーディングは、ローカル コンピューターではなくストリーミング プラットフォームのサーバーで処理が行われるため、オンプレミスのトランスコーディングとは異なります。つまり、クラウド トランスコーディングでは、ライブ ストリーミングに不可欠な、ブロードキャスト サイトから追加の帯域幅を必要としません。クラウドベースのアプローチは、必要に応じてより多くのビデオを処理するためにトランスコーダが使用可能なリソースを迅速に増やすことができるため、よりスケーラブルです。
同時に、クラウド トランスコーディングはコストも節約できます。追加のオンプレミス ハードウェアをインストールしてピーク負荷を計画する代わりに、クラウドベースのソリューションは、必要に応じてスケールアップし、需要が減少すると再びスケールダウンできます。このクラウド トランスコーディング固有の弾力性は、ストリーマーが使用したリソースに対してのみ料金を支払うことを意味します。
付属のクラウドベースのビデオ トランスコーダに加えて、ユーザーはビデオ ファイルをソーシャル メディア プラットフォームにプッシュして、トランスコーディング自体を処理できます。さらに、Resilient Streaming Protocol (RSP) は、クラウド サーバーに送信される際のビデオ データの損失を軽減するために、クラウド トランスコーディング ソース コードで設計されています。これは、クラウド ビデオ トランスコーダが、ビデオ コンテンツのトランスコードされた各レンディションのベースとして使用する完全なソース ファイルを確実に持つために重要です。これは、RSP 対応のクラウド トランスコーダが、すべてのデバイスの視聴者に最高品質のビデオを配信するスケーラブルなオプションであることを意味します。