ニコラボ

集計期間は週間のニコ生統計の1ヶ月分である。2015年の1月の2週目から取得漏れの R-18 放送を含めて Vita API で取得し始めたのでそれ以前と比べて取得放送数が増えている。

• ニコ生統計 2016年47週目
• 2016年9月のニコ生統計

Continue reading “2016年10月のニコ生統計”

2ch でも報告があったが、私も体験したことがあり、現時点でも混雑になる時間帯（土日では夕方でも起こる）で公式ニコ生のTSのコメントを保存するときにアリーナ最前列以外が kakoroku 経由で保存されることがある。今まではコメントの途中が抜けることがあったが今度は最前列以外の席のコメントを保存となるとなかなか気づきにくい。

Continue reading “公式ニコ生TSでアリーナ最前列のコメントが保存できていない”

2019年5月30日より以下のリンクにある公式の生放送以外 WebSocket 経由の rtmp は受信できなくなった。

2017年1月16日に公開された公式の新配信 HLS 形式はこちら
公式ニコ生のHTML5配信（β）の録画方法について

同時視聴の制限が緩和され、通常配信は2放送までだったのが、新配信は3放送まで同時に見られるようになり、HD配信が出来るようになった2018年1月時点では10配信同時に見ても回線が許す限り止まることは無かった。

配信映像の画質について

Twitter で調べてみるとコメントビューワの文字が読めない、同じビットレートのハードウェアエンコードの映像より汚いとか色々言われているが、確かにそのようで激しく動く映像を新配信で配信するとものすごく映像が破綻する結果になる。一方でレトロゲームやカード式のソーシャルゲームといったそれほどビットレートを必要としない映像なら 768kbps(現在は無い) まではそれほど破綻が気にならなかった。

推奨設定での配信結果

現在の仕様。映像ビットレートは公開値でほぼ推移するが映像が動かなくなるとものすごく下がる。雑談放送など映像を見てなかったり、音声だけしか聞かない放送なら 192kbps の設定が一番負荷も少なく、ギガが減らない。

qualityTypes	super_high	high	normal	low	super_low
quality	3Mbps	2Mbps	1Mbps	384kbps	192kbps
resolution	1280×720	800×450	800×450	512×288	512×288
profile	High	Main	Main	Main	Baseline
level	3.1	3.1	3.1	2.1	2.1
refs	4	4	4	4	3
bframes	3	3	3	3	0
cabac	on	on	on	on	off

master.m3u8 には、BANDWIDTH, AVERAGE-BANDWIDTH と playlist.m3u8 が記載してある。

設定内容	BANDWIDTH	AVERAGE-BANDWIDTH
3Mbps, super_high	5400000	3900000
2Mbps, high	3600000	2600000
1Mbps, normal	1800000	1300000
384kbps, low	691200	499200
192kbps, super_low	345600	249600

旧仕様

	3時から17時	17時から3時(プレ)	17時から3時(一般)
総ビットレート(公式)	1Mbps	768kbps	384kbps
解像度	800×450	800×450	512×288
映像ビットレート(概算)	907kbps	667kbps	288kbps
Profile	Main@L3.1	Main@L3.1	Main@L2.1
ref 参照フレーム	4	4	4
B-frame 最大連続枚数	3	3	3
CABAC	on	on	on
音声ビットレート(概算)	62kbps	62kbps	62kbps
旧配信からの遅延増加	1秒未満	1秒未満	1秒未満

補足としてビットレート調整について、暗部は急激に低下し、同一フレーム(いわゆる静止画放送)でも大きく低下、それ以外は基本的には平均ビットレートから外れない設定になっている。

録画方法について

画質変更は予めブラウザで設定しておいたのがそのまま録画される。

ニコ生を外部ツールで見ながら録画する

WebSocket 通信で調べる方法

以下の方法を手動で行う場合に時間制限があるので手早く行う。また新配信の放送ページのソースコードさえ分かれば、WebSocket 通信に niconico のログインは不要である。

Simple WebSocket Client – Chrome ウェブストア
Simple WebSocket Client :: Add-ons for Firefox

新配信の放送を開いたら右クリックからソースコードを開き、broadcastId、audienceTokenを探す。ちなみにログインユーザーでないと、audienceTokenの一部が anonymous-user になる。

プロトコルを ws: から wss: に変更し接続できなかったのを直した。2019年5月28日

次にbroadcastId、audienceTokenをつけて WebSocket Server を立ち上げる。
wss://a.live2.nicovideo.jp:2805/unama/wsapi/v1/watch/broadcastId?audience_token=audienceToken
例
wss://a.live2.nicovideo.jp:2805/unama/wsapi/v1/watch/138093265512?audience_token=138093265512_151356_1478995643_de1c48bc086767a044ee114e01d2ad62f30bf1a8

そして、Request の部分にbroadcastIdをつけて通信する。
{"type":"watch","body":{"params":["broadcastId","","true","rtmp",""],"command":"getpermit"}}

例：rtmp
{"type":"watch","body":{"params":["138093265512","","true","rtmp",""],"command":"getpermit"}}
http://potato.2ch.net/test/read.cgi/software/1473703893/248 より

そして、body -> currentStream -> uri と body -> currentStream -> name
を / でつなげれば録画できる URL になる。また時間切れになって録画できなくなったら rt2_nicoliveht2_nicolive以下を書き換えれば良い。

2017年3月29日より hls にも対応した。
【3/29更新】ニコニコ生放送「新配信（β）」HTML5版対応しました|ニコニコインフォ

例：hls
{"type":"watch","body":{"params":["138093265512","","true","hls",""],"command":"getpermit"}}

録画のコマンド例。これで録画できるが、ブラウザで放送を見続けるか、コメントビューワで放送のコメントを開いてないと録画が切断される。詳しくは60秒毎に Heartbeat を送る必要がある。
ffmpeg -i "http://pb04.dmc.nico:2818/hlslive/ht2_nicolive/nicolive-production-pg4033730314870_3aa577d5f54fa67be38545923fba4301b51e6a69dfed2dbd8856fcd034f5715c/1/ts/playlist.m3u8?ht2_nicolive=151356.kzwkc4_p3360t_1o1h2yre24dvv" -c copy output.ts

namarokuRecorder から保存する方法

新配信の生放送を namarokuRecorder から録画すると2018年1月時点では最高画質である3MbpsのHD配信は録画できない。

ニコ生の録画方法 まとめ

以下一般会員用の低画質、384kbpsしか録画できなかったときの内容。

新配信の放送を開き、Wiresharkなどで配信ポート番号を調べる。Wireshark を使わなくてもポート番号は現時点では 2832 から 2836 の 5通りしか確認していないので順番に試せば Wireshark で調べる必要は無い。調べ方はブラウザ以外の通信アプリケーションを終了して流れるパケットで Lenght サイズの大きいのを探し、Info の左の数値がポート番号になる。次に調べたポート番号をRTMPDumpHelperに割り当て、KSV の rtmpsrvの起動に変更する。すると RTMPDumpHelper を起動すると同時に rtmpsrv も起動し、新配信のニコ生をリロードすれば解析結果が Command.txt に出力される。

RTMPDumpHelper の使い方

ここで Command.txt で出力されたコマンドをそのまま実行しても「WARNING: HandShake: Server not genuine Adobe!」のエラーが出るので少し加工する。

加工前(録画ファイル名は加工済み)
rtmpdump -r "rtmp://pc01.dmc.nico:2835/live" -a "live" -f "WIN 23,0,0,207" -W "http://nl.nimg.jp/public/relive/2.0.5/assets/uweb/r1/swfs/v1/AriesPlayer.swf" -p "http://live2.nicovideo.jp/watch/lv1234567890" --live -y "rt2_nicolive/nicolive-production-pg333587677800_bb6f1df63b231953bca37fa80467bff3293511a3e1b402488cff5a655f3a8980?rt2_nicolive=151356.wcreq9_ogdjom_1hz5mdclcaai1" -o "output.flv"

加工後(-r を -vr に変更し、-a から -y 手前までを削除し / でつなげる)
rtmpdump -vr "rtmp://pc01.dmc.nico:2835/live/rt2_nicolive/nicolive-production-pg333587677800_bb6f1df63b231953bca37fa80467bff3293511a3e1b402488cff5a655f3a8980?rt2_nicolive=151356.wcreq9_ogdjom_1hz5mdclcaai1" -o "output.flv"
ちなみに rtmpdump の -N オプションが不要なので普通の ffmpeg でも録画できる
ffmpeg -f live_flv -i "rtmp://pc01.dmc.nico:2835/live/rt2_nicolive/nicolive-production-pg333587677800_bb6f1df63b231953bca37fa80467bff3293511a3e1b402488cff5a655f3a8980?rt2_nicolive=151356.wcreq9_ogdjom_1hz5mdclcaai1" -c copy "output.flv"

注意点として、この新配信は動画の強制再エンコードの新配信と同じように視聴ページを開いてないと録画が止まるので放送ページを開いたままにしておくか、コメントビューワで放送に接続し続けていれば録画が止まらない。

昔の内容

2017年11月1日に公開された新配信（β）以下新配信について。「ユーザー番組の配信ビットレートが1Mbps」になって高画質配信ができると思ったのもつかの間、記事をよく読むと、「時間帯と視聴ユーザーの会員状態によってビットレートが異なります」とあるように送信映像が視聴者にそのまま送られずに再エンコードされることが分かり、試す前からいやな予感がする告知であった。

Continue reading “ニコ生の新配信と録画方法について”

2019年5月23日より、従来の getplayerstatus からの rtmp は受信できなくなり、WebSocket 経由の rtmpならまだ受信できたが、2019年5月30日より公式の生放送以外 WebSocket 経由の rtmp は受信できなくなった。

ニコ生の録画と配信方法の歴史にあるように2013年11月14日から2019年5月23日までの仕様である、ユーザー生放送の生放送とタイムシフト、チャンネル生放送の生放送には-Nオプションが必要で、ユーザー生放送のタイムシフトの保存には放送時間分だけ時間がかかっている。この仕様に対応した-Nオプションではなく新しいオプションも備えて機能も拡大した rtmpdump のテストバージョンを公開している。テストバージョンは少し前から公開しているが、使い方を整理したり、新しいオプションのバグ取りになどに時間を取られ今日の記事公開となった。

Continue reading “N を使わない新しいニコ生用の rtmpdump と ffmpeg(librtmp)”

集計期間は週間のニコ生統計の1ヶ月分である。2015年の1月の2週目から取得漏れの R-18 放送を含めて Vita API で取得し始めたのでそれ以前と比べて取得放送数が増えている。

• ニコ生統計 2016年40週目
• 2016年8月のニコ生統計

Continue reading “2016年9月のニコ生統計”