[スレッド全体]

[12667] Re3:我家の取り込み画像です。返信 削除
2019/5/18 (土) 11:43:37 Go
__ / __

▼ こいしさん

 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

[▼次のスレッド]
INCM/CMT
Cyclamen v3.49
[ut:0.010][st:0.000]