閉じる
閉じる
×
ニコ生のptpt問題の原因について探ってみる
2013-11-07 09:00
- 4
最近起きてるニコ生のptpt問題、これの原因について探ってみたいと思います。
＜回避方法は今のところない＞
・クルーズ待ちタグ入れても発生する場合がある。
・原宿やGINZAにバージョン変えると改善する場合もあるが、治らない場合が多い。
・混線して他の放送の音が入ってる場合は見る側の更新で治ることもある。
現状わかってるのはこんなところ。
＜何が原因なの？＞
NetStream.Buffer.EmptyNetStream.Buffer.Full
を激しく交互に繰り返してる現象が今回のptpt現象だったりします。
ちなみに
NetStream.Buffer.Empty は 配信するための必要な量を満たしてない状態、
NetStream.Buffer.Full は 配信するために必要な量を送っている状態を示しています
これを見るにはGINZAプレーヤーである必要があり、
GINZAプレーヤーでは設定を押してから下のほうにある「システムログを表示」でログを見ることができます。
これはとある放送のログ
rtmp://nlexx.live.nicovideo.jp:xxxx/liveedge/live_xxxxxxx_xx_x ←保護のため番号は非表示■NicolivePlayerV4logic: xxxxxxxxxxxxview: xxxxxxxxxxxNetConnection.Connect.Success映像(lvxxxxxxx)の再生を開始しますNetStream.Play.ResetNetStream.Play.Start ←配信スタートNetStream.Buffer.Full ←最初は映像配信のため一回はNetStream.Buffer.Full、あるいはNetStream.Buffer.Empty NetStream.Buffer.Full NetStream.Buffer.Emptyが発生するNetStream.Buffer.FullNetStream.Buffer.EmptyNetStream.Buffer.FullNetStream.Buffer.EmptyNetStream.Buffer.FullNetStream.Play.UnpublishNotifyNetStream.Play.PublishNotifyNetStream.Play.Stop ←ptptのため配信ストップNetStream.Play.ResetNetStream.Play.Start ←配信スタートNetStream.Buffer.FullNetStream.Buffer.EmptyNetStream.Buffer.FullNetStream.Buffer.Empty ←このemptyの時にptptになってることが多いNetStream.Buffer.Full ←配信させるために必要な量を送っているNetStream.Buffer.Empty ←これを繰り返すとユーザー側ではptptに聞こえるNetStream.Buffer.FullNetStream.Buffer.EmptyNetStream.Buffer.FullNetStream.Play.UnpublishNotifyNetStream.Play.PublishNotifyNetStream.Play.StopNetStream.Play.ResetNetStream.Play.StartNetStream.Buffer.FullNetStream.Buffer.Empty ←酷いとこんな具合に続くNetStream.Buffer.FullNetStream.Buffer.EmptyNetStream.Buffer.FullNetStream.Buffer.EmptyNetStream.Buffer.FullNetStream.Buffer.EmptyNetStream.Buffer.FullNetStream.Buffer.EmptyNetStream.Buffer.FullNetStream.Buffer.EmptyNetStream.Buffer.FullNetStream.Buffer.EmptyNetStream.Buffer.FullNetStream.Buffer.EmptyNetStream.Buffer.FulNetConnection.Connect.Closedl ←放送終了
といった具合のログになります。
解説も入れてみましたがだいたいなんとなくおわかり頂けましたでしょうか？
＜結論＞
結論からいうとニコ生側の問題だったりします。
運営側も努力はしているのですが、早くこの状況が治ることを期待するばかりです。
10月29日夜追記
今のところメンテ以降わたしの確認している放送でこの現象は確認していません。メンテで改善されたのかもしれません。
今のところメンテ以降わたしの確認している放送でこの現象は確認していません。メンテで改善されたのかもしれません。
寄稿者名：神崎ちはやTwitter：@chihaya_kanzaki
プロフィール：「コミュでは主に艦これ。他は天鳳、音ゲー、C9放送。だが実態は腐女子。よく理系と間違われるが実際は文系。ツイッターでは腐ネタもあるので注意。そのうちHP立ち上げ予定。
コミュ：co1217166
チャンネル会員ならもっと楽しめる！
- 会員限定の新着記事が読み放題！※1
- 動画や生放送などの追加コンテンツが見放題！※2
-
- ※1、入会月以降の記事が対象になります。
- ※2、チャンネルによって、見放題になるコンテンツは異なります。
『ライフログ』生主ブロマガ
更新頻度：
ほぼ毎日
最終更新日：
チャンネル月額：
¥110
(税込)
コメント
コメントを書く
本当に原因を突き詰めたいのならパケットをキャプチャーして解析してみたらいいのでは？
パケットモニターとかフリーソフトありますよ。
非常に興味深い記事です。
ただ、この生主ブロマガというメディアの特性（？）や背景を活かして、運営側の事情や見解を取材するところまで突っ込めたら面白いな、とも思います。
次回も期待しております。
これはいい記事、面白かった。
次回も期待
これはフラッシュプレイヤーのログだから基本的に再生側のメッセージですね。
基本的にストリーミングはストリーミングバッファーにデータを蓄積し随時再生しながら再生を終えたデータは新しいデータに上書きされる仕組みです。
再生はこのストリーミングバッファーと呼ばれるメモリ域の上限値に蓄積データが達した時点で開始されます。
正常な再生ではEmpty、つまり再生データが空ということは起こりません。
これは通信状態が正常でないときにデータが補充されずに再生されきってしまうということですね。
複数のクライアント側で同様に起こる場合はまずサーバーの問題と言っていいでしょう。
逆にFullが続くような場合はクライアント側の処理能力に問題があるといっていいでしょう。