0

HLS Live コンテンツを再生するプレーヤーに取り組んでいます。そのため、テスト リンクの .m3u8 インデックス ファイルを定期的にリロードします。

たとえば、プレーヤーは 01.m3u8 インデックス ファイルをリロードしました。

(01.m3u8 - #1)

       0.ts---the player tried to download this 100.ts file first.
       1.ts---
       2.ts
       3.ts

次に、0.ts ファイルをダウンロードしようとしました。

ただし、この 0.ts ファイルを高速にダウンロードするには、ネットワーク帯域幅が十分ではありませんでした。

1 つの TS をダウンロードするのに約 24 秒かかりました。そのため、02.m3u8 インデックス ファイルを再度リロードしました。

(01.m3u8 - #2)
       2.ts---the player tried to download 102.ts file first.
       3.ts
       4.ts
       5.ts

ただし、プレーヤーはインデックス ファイルで 1.ts ファイルを見つけることができませんでした。プレーヤーが 1.ts ファイルをダウンロードする前に、インデックス ファイルがサーバーによって更新されたためです。そのため、プレーヤーは 1.ts ファイルではなく 2.ts ファイルをダウンロードしようとしました。

これは、プレイヤーが 20 秒間のストリーム データを失ったことを意味します。混乱しているように見えるので、この動作は仕様と一致していますか??

2.ts ではなく 1.ts から始まる m3u8 を更新する必要があると思います。またはどのように決定されたか。

誰でも提案できますか？

4

2 に答える 2

0

それは正しいことをしました。直面している問題を解決するには

1つのビットレートのみが必要な場合は、ネットワーク帯域幅を把握し、それに応じてエンコードする必要があります[閉鎖された制御された環境に役立ちます]

また

複数の帯域幅でエンコードし、複数のビットレートで m3u8s を設定し、最初のエントリとして最低のものを指定すると、HLS がそれに応じて適応します。いくつかのセグメント内で、ターゲット帯域幅に到達します。それが実際の HLS の要点です。

于 2012-09-14T13:40:23.803 に答える
0

この仕様では、プレイリストがまだターゲット期間の少なくとも 3 倍である限り、サーバーはプレイリストの先頭から URI を削除できます。(draft-pantos-http-livestreaming-08 のセクション 6.2.2)

プレイリスト ファイルのデュレーションからセグメントのデュレーションを差し引いた時間がターゲットデュレーションの 3 倍未満である場合、サーバーはプレイリスト ファイルからセグメントを指定するメディア URL を削除してはなりません。

したがって、プレイリストに 4 つのセグメントが含まれ、長さがわずかに異なるだけである限り、これは有効な動作のようです。ライブ ストリームの場合、サーバーがセグメントを追加するのと同じ速度でストリームからセグメントを削除することを期待します。したがって、10 秒のセグメントでは、1 つのセグメントをダウンロードするのに 24 秒を費やしている間に 2 つのセグメントを削除するのが妥当だと思います。

于 2012-09-14T13:23:34.440 に答える