| ▼ こいしさん
Youtubeの素材を再生した際の、データ
ロストの原因について追いました。
■ 伝送経路と回路
サーバにある素材がモニタとスピーカで
再生されるまでの流れは
[サーバ]-(Internet網)-[端末]
端末の内部(論理上の構成)
[IP受信部]-[映像音声情報取出し]
-[映像/音声の復号処理]-[映像/音声の出力]
■ 統計情報
次に[12662]の詳細統計情報をみると、
1) [Frames]の "doropped"が激しい
2) "Network Activity"
(YouTubeが実際にどれだけ使用しているか)
で大きくきれている個所がある。
■ 考察
IP受信部では、IPパケットのロスト数を
カウントできますが、Youtubeは TCPベース
なので、受信できなかったパケットは再送
でカバーしていると考えられます(基本的
に全てのパケットが配信される前提)。
そして、フレームドロップ数をカウント
出来るのは、[映像の復号処理]部です。
(復元された音声はデータの繋がりなので
フレームという概念はない)。
フレームドロップが発生する理由は、
映像の復号処理の際に、映像フレームが
生成できなかったためですが、原因として
は情報量、または処理時間の不足です。
時間帯によっては滑らかに再生できると
なると、HWの性能には問題なく、すなわち
処理時間の問題ではなく受信した情報量の
不足が考えられます。
切り分けとしては、再生開始してすぐに
一時停止し、バッファにある程度蓄積され
た状態から再生を再開する案があります。
■ まとめ
実際に視聴すれば判るんですが、再生時
の状況による切り分けはおよそ次の通り。
a) データロストの場合
軽微な場合、映像フリーズと音声ノイズ
(あるいは映像に微小なノイズ)
激しい場合、映像/音声どちらも停止
b) データ遅延の場合
映像/音声の停止と再開
c) デコード処理能力の場合
映像の崩れ(音声は継続が殆ど)
(これは、デコード処理の時点で映像と
音声は別回路を通っており、音声処理
は負荷が少ないのでノイズになり難い)
こいしさんの環境では、おそらく [b)]と
推測します。 再生は 1920×1080になって
いるようなので、あらかじめ 1080pを指定
するのも案だと思います。
おまけで、4K解像度の素材をモニタで
精細に表示できるか見るのによさそうな
4K解像度が表示されているかどうかの確認用動画
(縦横1ドットストライプ)
https://www.youtube.com/watch?v=yt4CS0Bpx78
|
|