GMの抵抗ワショーイ

GMの抵抗ワショーイ

2021.10.17
XML
テーマ: YouTube(1585)
カテゴリ: サーバ
よし!配信やるぞ!と意気込んで始めようとしたところ、なぜか配信が始まらない…






ちなみに当該エラーが発生する先週までは普通に動作してました。

【使ってるもの】
* OBS Studio 27.0.1 or 27.1.3
* Youtube Stream
* 光回線



試したこと

とりあえずPC再起動、OBSのアップデート、枠の取り直しを試したけどダメ。
他の配信設定ソフトに切り替えてもダメ。
…ということでエラーログを見てみます。

OBS Studioの場合、デフォルトではエラーログは下記位置にあります。

C:\Users\***\AppData\Roaming\obs-studio\logs


(OBS画面からも選択してフォルダ表示可能)


ログをみるとこんなメッセージがありました。

22:59:27.366: [rtmp stream: 'adv_stream'] Connecting to RTMP URL rtmps://a.rtmps.youtube.com:443/live2...
22:59:27.367: [rtmp stream: 'adv_stream'] Interface: Realtek PCIe GbE Family Controller (ethernet, 100 mbps)
22:59:29.934: [rtmp stream: 'adv_stream'] Connection to rtmps://a.rtmps.youtube.com:443/live2 successful
23:00:03.827: WriteN, RTMP send error 10054 (16 bytes)
23:00:03.827: WriteN, RTMP send error 10053 (59 bytes)
23:00:03.827: WriteN, RTMP send error 10038 (42 bytes)
23:00:03.827: [rtmp stream: 'adv_stream'] Disconnected from rtmps://a.rtmps.youtube.com:443/live2
23:00:03.827: Output 'adv_stream': stopping
23:00:03.827: Output 'adv_stream': Total frames output: 353 (1003 attempted)
23:00:03.827: Output 'adv_stream': Total drawn frames: 1094
23:00:03.827: Output 'adv_stream': Number of dropped frames due to insufficient bandwidth/connection stalls: 650 (64.8%)
23:00:03.827: Output 'adv_stream': Reconnecting in 10 seconds..
23:00:03.827: [rtmp stream: 'adv_stream'] Freeing 1896 remaining packets
23:00:03.862: warning: 2 frames left in the queue on closing
23:01:10.516: YouTube API error:
23:01:10.516: HTTP status: 403
23:01:10.516: JSON: {"error": {"code": 403, "errors": [{"domain": "youtube.liveBroadcast", "extendedHelp": "https://developers.google.com/youtube/v3/live/docs/liveBroadcasts/transition#params", "message": "Invalid transition", "reason": "invalidTransition"}], "message": "Invalid transition"}}

※一部clientID等に関わる部分のログは省略してます。以降同様。

今回注目したのは WriteN, RTMP send error 10054 (16 bytes)
見た感じ、かなりパケロス起きているような…?
ということで、エラーでググってみるとこんな解決策を見つけた。

Is this error Facebook's fault or mine? WriteN, RTMP send error 10054 (117 bytes)

MTUパケットサイズの変更が必要らしい。(通常は1500設定なのを変更していく)
※MTU:ネットワークで一回に送信できる最大のデータサイズのこと。
 イーサネットのMTUは1500バイトで、光ファイバ(FDDI)は4352バイト

1. Open cmd as admin and type netsh interface ipv4 show subinterfaces
2. Check the number on the same line as your network adpater (Ethernet/Wi-FI), usually its1500
If its not 1500, change it to it because its the most accurate baseline. You can do this by using netsh interface ipv4 set subinterface “Name of Adapter” mtu=1500 store=persistent (Name is under Interface of the first command)
3. After thats established follow the steps in this article https://hide.me/en/knowledgebase/how-to-find-correct-mtu-values/
4. After that (make sure you add 28) change the MTU using the same command netsh interface ipv4 set subinterface “Name of Adapter” mtu=(number) store=persistent
5. Once thats set you can go ahead and type netsh winsock reset and netsh int ip reset then reset the PC. Not required but kind of a full refresh of the network, so just a mention


ということで、MTUを変更してみる。

How To Find Correct MTU Values on Windows?
自分は ping www.google.com -f -l 1420 あたりでつながるようになりました。

netsh interface ipv4 show subinterfaces
1448 2 5100 686 Wi-Fi
1448 1 347722775 29158780 イーサネット

C:\WINDOWS\system32>ping /n 50 www.google.com -f -l 1500

www.google.com [216.58.220.132]に ping を送信しています 1500 バイトのデータ:
パケットの断片化が必要ですが、DF が設定されています。
パケットの断片化が必要ですが、DF が設定されています。
パケットの断片化が必要ですが、DF が設定されています。

C:\WINDOWS\system32>ping www.google.com -f -l 1420

www.google.com [216.58.220.100]に ping を送信しています 1420 バイトのデータ:
要求がタイムアウトしました。
216.58.220.100 からの応答: バイト数 =68 (1420 を送信) 時間 =6ms TTL=115
216.58.220.100 からの応答: バイト数 =68 (1420 を送信) 時間 =7ms TTL=115
要求がタイムアウトしました。

216.58.220.100 の ping 統計:
パケット数: 送信 = 4、受信 = 2、損失 = 2 (50% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 6ms、最大 = 7ms、平均 = 6ms


※DFってのはパケットの分割禁止フラグのことです。
今回は手動でWiFiとイーサネットを設定変えます。
1420で通ったので、+28した1448で設定。PC再起動。


…が、それでもうまくいかず。
原因をさらに探ってみたところ、そもそもパケロス率50%は高くない?というところに行き着く。
pingを50回回してみる。

ping /n 50 www.google.com -f -l 1420
216.58.220.132 の ping 統計:
パケット数: 送信 = 50、受信 = 31、損失 = 19 (38% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 5ms、最大 = 14ms、平均 = 6ms


…38%はヤバいですね。
LANケーブルの接触不良、ルーターの故障、インターネットプロバイダーの混雑などが原因である可能性が高いので、ルーターの再起動+LANケーブルを取り替えてみました。
(これでもダメならFTTH接続であればプロバイダに問い合わせたほうがいいのと、--tracert a.rtmps.youtube.comを実行して、パケットが通過するホストが表示、各ホストへのpingを測定して、パケット損失が発生している場所を確認する流れかな…。)


…してみたところ、上手く動きました。
原因はLANケーブル不良なのかな?と思ってLANケーブルを他に使いまわしてみたのですが、普通に動くんですねこれが。
(Youtubeは見れるしオンラインゲームは遊べるぐらいには快適)

ひとまず、 WriteN, RTMP send error 10054 (16 bytes)のエラーが出た時はネットワーク周りを見直す・つなぎ直す が良さそうなことはわかった。

ネットワーク周りつなぎ直したらパケロスも0%になったからね。
(今のインターネットってパケロス率高くても動くようになってるの、進化してる)






そうだ、LANケーブル替えよう

…が、一時的にLANケーブル替えただけなので、恒久対応としてLANケーブルいいのを買うことにしました。
一般家庭であればCAT 6A 型がおすすめ
CAT7~8を一般家庭で使っても逆に動作不安定を起こすので非推奨です。
よく分かるLANケーブルの選び方。CAT.6でも10Gbps対応可能。CAT.8まで速度差を検証

配信用途であれば、例えばこのあたりがお手頃で安定じゃないかな。




「業務用だとどんなのがあるのさ」「数万円するLANケーブルどう?」って配信でコメントもらったので調べてみました。そんなのあるのかなと思って調べたら…存在するんですね。



現実ではこんなケーブルみたことないです。
自分はお手頃な1500円のケーブル注文しました。
翌日には届くらしい。やったね。

LANケーブルの長さは部屋の広さで推測するのがおすすめ。
業務用だと2~3mのが一般的だけど、6畳1部屋タイプなら5~10mあると安心。
今回は安定して通信してほしいので10mにしました。
[参考] LANケーブルの選び方

ひとまずこれで回線弱者にはならないで済むはず…?
もっとオススメの回線あるよ!とかあればコメントで色々教えてください。
(一般家庭向けでお願いしますね)


参考までに、OBSの設定おいておきます。

Youtube配信ならビットレートは~4500がおすすめ。



[参考] 【YouTube Live】配信が始まらない、サイトに画面が反映されない場合の対処法
[参考] ライブ配信のエラー メッセージ
[参考] YouTube のエラー メッセージのトラブルシューティング


   ww
 ,,#´ω`#,,
 #´・_・`#ノシ
 #´・ρ・`#ノシ
 #´・▽・`#ノシ
 #´・w・`#ノシ
 #´・ω・`#ノシ
 #´・∀・`#ノシ
 #´・Д・`#ノシ
 #´・-・`#ノシ
 #´・ε・`#ノシ
 #´・ヮ・`#ノシ
 #´・⊇・`#ノシ
..[..===..]
 |ノシショボテン|
 |_ \3500 _|





お気に入りの記事を「いいね!」で応援しよう

Last updated  2021.10.18 09:08:21
コメント(0) | コメントを書く


【毎日開催】
15記事にいいね!で1ポイント
10秒滞在
いいね! -- / --
おめでとうございます!
ミッションを達成しました。
※「ポイントを獲得する」ボタンを押すと広告が表示されます。
x

© Rakuten Group, Inc.
X
Create a Mobile Website
スマートフォン版を閲覧 | PC版を閲覧
Share by: