H.264/SVC 規格は初めてです。調べてみると、Android、iPad、iOSx などのモバイル デバイスが H.264/AVC をサポートしていることがわかりました。H.264/SVCはH.264/AVCをベースプロファイルとエンハンストプロファイルの多層構造で拡張したものなので、H.264/AVC対応の機器はH.264/SVCも対応するのかな? ?
1 に答える
この問題に関する私の (単なる理論上の) 調査によると、H.264 AVC プレーヤーは、そのままでは H.264 SVC ストリームをデコードできません。
ただし、サーバーでエンコード形式として SVC を使用しても、必ずしも SVC でエンコードされたデータをクライアントにストリーミングする必要はありません。SVC から AVC への変換は、サーバー側でわずかな計算量で実行できます。再エンコードではありません!サーバー上で H.264 SVC ファイル形式を使用しながら、使用可能なネットワーク帯域幅を決定した後、調整されたデータ レートで AVC ストリームをクライアントに送信するソリューションが市場で増えています。このようにして、ストリーミング システムは既存のクライアント ベースとの互換性を保ちながら、サーバー上で SVC の利点を既に利用できます (たとえば、ビデオごとに 1 つのファイルしかなく、ストレージのオーバーヘッドが非常に低いなど)。
一方、クライアントがストリームを処理できる場合は、ストリームを SVC 形式で送信することは実際に可能です。必要に応じて、これらの SVC ストリームは、利用可能な帯域幅に応じて、データ レートを下げることができます。これは、元の SVC ファイルから簡単に抽出でき、SVC レイヤーをドロップすることで低い計算能力で行うことができます。オンザフライでストリームを再構築し、削減されたレイヤー セット (単純な基本レイヤーまで) を送信することは、利用可能な帯域幅が完全な SVC ファイルをストリーミングできない場合はいつでも、多くのシナリオで意味があります。結局のところ、これが SVC のすべてです。つまり、単一のマスター ファイルまたは高帯域幅の SVC ストリームから帯域幅を縮小したバージョンをすばやく生成できる可能性です。
実際には、SVC ストリームからレイヤーをドロップすることは、サーバーからクライアントへの途中にある特殊な中間ネットワーク ノードおよびプロキシでオンザフライで行われることさえあります。これにより、ネットワーク接続の次のセクションの帯域幅が完全な着信ストリームに対して低すぎる場合はいつでも、信号のデータ レートを下げることができます。
オンザフライで SVC ファイルから適合した SVC または AVC ストリームを生成するシステム用に私が見つけたいくつかのプロバイダーは次のとおりです。
H.264 SVC の詳細については、次のリンクを参照してください。