5

libvpx を介して VP9 でライブ ストリームをエンコードしており、それを HTML5 プレーヤーにストリーミングしたいと考えています。Matroska 仕様とW3C WebM Byte Stream Formatを読み、libvpx の vpxenc ツールによって生成された WebM ファイルをいくつか調べました。すべてが良さそうに見えますが、W3C 仕様で説明されているメディア セグメント内にエンコードされたビデオ フレームをパックする方法に関する厳密なルールやガイドラインは見つかりませんでした。

私が理解している限り、内部にブロック要素を持つクラスターを含むメディア セグメントを出力する必要があります。私が理解していることから、エンコーダーから取得した各フレームには単一のタイムスタンプがあるため、単純なブロック要素を使用できます。しかし、どのようにクラスターを編成するのでしょうか? 私にとっては、バッファリングと遅延を減らすために、単一の単純なブロック エントリを使用してフレームごとに単一のクラスターを発行することは理にかなっています。そのようなアプローチは正常と見なされますか、それとも欠点がありますか? 一定の時間間隔でバッファリングしてから、バッファリングされた期間をカバーする複数の単純なブロック要素を含むクラスターを発行する必要がありますか?

アップデート

そこで、説明したアプローチ（単一の単純なブロックエントリでクラスターを放出する）を実装しましたが、ビデオが大幅に遅れているように見えるため、おそらくこれは進むべき道ではありません.

4

2 に答える 2

4

それで、私はついに何とかar作業中のライブストリームを多重化することができました.

私が説明した最初のアプローチ (単一のSimpleBlockを持つ単一のクラスターを持つ) は実際にはそのように機能するようですが、いくつかの欠点があります。

  • WebMの公式ページの推奨事項に違反しているようなものです

キー フレームはクラスタの先頭に配置する必要があります

  • ライブ ストリームが curl またはその他の手段を使用してローカル ファイルに保存されている場合、可能なシークを分割します。私の理解では、クラスターは完全な GOP で構成されている必要があります。

私の最初の仮定の 1 つは、クラスターが「不明な」サイズを持つことはできないということですが、実際には、Chrome、VLC、および ffplay はそれに満足しているように見えたので、サイズとクラスターはオンザフライで放出できます。

もう 1 つの重要な側面は、SimpleBlock要素のタイムスタンプが符号付き 16 ビット整数であるため、基本的にクラスター タイムコードから 32767 までのオフセットをエンコードできることです。したがって、1 ティックが 1 ミリ秒であるデフォルトのタイムスケールを使用している場合、これはクラスターが 32 秒を超えてはならないことを意味します。GOP サイズが大きい場合、新しいクラスターを発行するかどうかを決定する際に、この基準も考慮する必要があります。

最後に、すべてのプレーヤーで動作し、上記の説明に従って生成されるライブ ストリーム (「Big Buck Bunny」の予告編ですが、ライブ形式) へのリンクを次に示します。

この情報が誰かに役立つことを願っています。

于 2015-11-02T17:51:14.020 に答える