おこしやすネットサル＞その他トップ＞このページ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【このページの目次】
対象者と前置き
初心者向けQ&A
エンコードに関する知識、情報など
設定例
配信テスト
注意：
情報の多くは2008年(*1)が基準なので、OBSやSCFFが出て久しい現在、役立つ情報はもうないと思います。
「Windows Media エンコーダ」「SCFH DSF」という古いアプリケーションを前提にしています。
*1:こういう年です。
●SCFH DSFが出た年。
●Windows XPはメインストリームサポート期間。最新OSはWindows Vista。
●Intel Core 2 Duoの時代？ でもPentium4以下のCPUで配信している人もまだまだ多い。
●Windows XPなら物理メモリは512MBがやや多め？
●ADSL利用者はまだまだ多い。
●YouTubeライブもTwitchもKTEもOBSもSCFFもない。EEはあったらしい（当時知らず）。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【対象者と前置き】
「とりあえずまともに配信できる程度には知識があり、なおかつ
もっと高品質な配信を目指したい、あるいは高品質な配信に興味がある人」
を対象としています。
「ここはこういう設定にしましょう」という記述はいろいろなサイトで見かけますが、
なぜいいのか、どういう効果があるのかなどについてまで言及しているサイトはほとんどありません。
これでは応用が利かないので、自分の環境に合った設定を煮詰められません。
私より詳しい人もいることとは思いますが、WMEのヘルプを読んだり
テストを繰り返した結果に得られた、私なりの考え方を書いておきます。
私はヘルプ以外にはほとんど何も読んでいないので、専門的な知識はありません。
ですが、ヘルプと実際のテストから得られた情報を書いているので、少なくとも配信に関しては
間違ったことは書いていないと思います。
ちなみに、このページでは画質のことを鮮明さと同じ意味として書いています。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【初心者向けQ&A】
Q:「ビデオビットレート」を上げずに画質を良くしたいです。
A:●「ビデオサイズ」を小さくする。
●取り込み対象と同じ「ビデオサイズ」にする(*1)。
●「フレームレート」を下げる。
●「ビデオの滑らかさ」を上げる。
●「パフォーマンス」「プリセット」といった項目を高品質寄りに設定する。
●wmv形式での配信をやめる。
があります。
*1:画質が上がると言えるものではないかもしれませんが、「ビデオサイズ」を小さくすると、
小さな文字はつぶれて読めなくなってしまうので、文字の読みさすさに限って言えば、
語弊はありますが感覚的には「画質が上がった」と言えることかもしれません。
Q:配信ビットレートはどのくらいまでなら大丈夫でしょうか？
（配信対象に対する適当なビットレートではなく、使用可能ビットレートの上限という意味）
A:ご自身の回線速度に余裕があっても、ビットレートの合計は1000Kbps未満にしてください。
1000Kbpsぎりぎりでも高いですが、上限の目安として。
ストリーミング配信において、ビットレートが高くなりすぎてしまうと
受信しきれなくてまともに視聴できない人が出てきます。
ですがそれは古い基準であり、今日では、ビデオビットレートだけでも1000Kbpsを超えることが
当たり前の世界になりました。
これは全く関係のない話になってしまうのですが、ビデオビットレートが1000Kbpsを超えると、
「Windows Media Video 9」が「Windows Media Video 9 Professional」になる条件が
一つ満たされるので、1000Kbpsを超えるビットレートにすることをいとわず、なおかつ
変わったことが好きな人は、ビデオビットレートを1000.001Kbpsにするのもいいかもしれません。
（条件は全部で二つあって、残りの条件は画素数が300000を超えていること。640x480ならOKです）
Q:オーディオに割くビットレートはどのくらいがいいでしょうか？
A:配信内容によって使い分けるのが一番ですが、私は合計ビットレートの1割を目安にしています。
合計ビットレートが400Kbpsなら、
オーディオビットレート40Kbps＋ビデオビットレート351Kbps＋オーバーヘッド9Kbps
ということですね。
「最低でも64Kbpsはないと」といったビットレートに関する話はよく見ますが、
私にはあまり違いを感じられなかったのでわかりません。
音楽を聴かせることを主目的としていない、雑談やゲーム配信なら
32Kbpsもあれば十分だと思っています。
Q:パソコン性能は低いですが、回線速度に余裕があります。おすすめの設定はなんでしょうか？
A:まず、ビデオコーデックを「Windows Media Video V7」にしてください。
映像が粗く、激しい動きにも弱いですが、基本的には軽く、高い「ビデオビットレート」を割けるなら
画質もあまり問題にならないと思います。
ほかの設定は、画面を縮小しても高い「ビデオビットレート」によって
文字が見えなくなるのを防ぐことを優先的に意識するといいです。
配信対象によって違いはありますが、縮小しすぎるとどれだけ「ビデオビットレート」を割いても
文字がつぶれてしまうことには注意します。
Q:パソコン性能に余裕はありますが、回線速度が遅いです。おすすめの設定はなんでしょうか？
A:まず、ビデオコーデックを「Windows Media Video 9」にしてください。
画質が高く、負荷も安定しています。
そして「パフォーマンス」を「高品質」寄りにしてください。ですが一番右は
かなりのパソコン性能が求められます。テストもしながら、慎重に操作してください。
ほかの設定は、「ビデオサイズ」をできるだけ等倍に近づけて
文字が見えなくなるのを防ぐことを優先的に意識するといいです。
取り込み対象と等倍なら低ビットレートでも文字が見やすいです。
ただし、フレームの欠落には注意します。
Q:WMEに向いたパソコンはどんなパソコンでしょうか？
A:WMEは、ビデオ用に最大4つのプロセッサを使うことができます。
裏を返すと、4つしかプロセッサを使うことができません。
そのため少なくとも、WME以外の要素を考慮しないのなら
プロセッサが8個あって一つ一つのクロック数が低いパソコンよりも、
プロセッサが4個あって一つ一つのクロック数が高いパソコンのほうがWMEに適しています。
ほかの要素は関係ないと思います。
バッファサイズを100秒にする（これは極端な設定です！）と多くのメモリが必要になる程度です。
配信には大容量のメモリが必須と主張する人もいますが、そのようなことはありません。WMEに限らず。
Q:配信に自分の名前や情報などを載せている人を見ます。どのようにすればいいのでしょうか？
A:「属性」から設定できます。
Q:キャプチャーソフトのプレビューの黒枠を消したいです。
A:クロップ機能を持っているキャプチャーソフトを使うのが一番ですが、
SCFH DSFの「Drag here.」ではなく「範囲選択」で指定して取り込むことでも、
黒枠を映さず配信できます。
ただしこのやり方は黒枠を配信画面に映さなくするだけであって、黒枠自体は消えません。
Q:縦横比がおかしかったり、上下や左右に黒枠が出てしまいます。
A:WMEの「ビデオサイズ」の数値と、SCFH DSFに表示されている数値が等しいか確認します。
ここが等しくないと縦横比が崩れたり、黒枠が出ます。
等しかった場合、次にSCFH DSFの「レイアウト」を確認します。
ここに映っている割合で配信されるということに注意します。
枠いっぱいまでドラッグして伸ばしてください。
WMEの「ビデオサイズ」の数値と、SCFH DSFに表示されている数値が等しくない場合、
黒枠があってもよく、縦横比を直したいだけなら、SCFH DSFの「アスペクト比維持」に
チェックを入れることで、配信を中断させずに縦横比を直せます。
Q:字幕が映りません。
A:SCFH DSFの「レーヤードウィンドウ表示」にチェックを入れることで映るようになります。
字幕に限らず、「レーヤードウィンドウ表示」にチェックを入れることで大抵のものは
映るようになります。
ただし、「Windows Aero」のせいで映らなくなっている場合もあります。
詳細を書くと「初心者向け」から外れてしまうので、下のほうにある当該項目をご覧ください。
Q:WMEの「ビデオサイズ」が4の倍数でしか指定できません。細かく指定できるようにしたいのですが。
A:「圧縮」にある「ビデオ入力と同じ」のチェックを外すと、2の倍数まで指定できるようになります。
ただし、これはWMEや配信に限らない話ですが、
2の倍数よりも4の倍数にするほうが好ましく、4の倍数よりも8の倍数にするほうが好ましく、
そして8の倍数よりも16の倍数にするほうが最も好ましいといわれています。
例えば、250x190まで切り詰めるよりも、256x192のほうがコストパフォーマンスがよいという話ですね。
ヘルプに載っておらずウェブ検索で得ただけの知識なので、私は説明できるほどわかっていませんが。
ちなみに、16の倍数よりも32の倍数にするほうが好ましいという話は見なかったので、
考慮するなら16の倍数までで十分だと思います。
Q:おすすめの設定を教えてください。
A:環境や配信対象などを書いてくれないと答えようがない、と言いたいところですが、
実は、WMEの初期状態に選択されている設定のまま配信してもそれほど問題ありません。
ですが、「ビデオサイズ」が小さいからと、「フレームレート」29.97fps、
「ビデオビットレート」241Kbpsのまま、「ビデオサイズ」を上げることは、
フレームの欠落が避けられなくなるため、やめておくべきです。
「フレームレート」を半分にするか、「ビデオビットレート」を倍にすることで、
「ビデオサイズ」を320x240から、448x336程度まで上げられます。
Q:WMEは現行のWindows OSで動くのでしょうか？
A:基本的には動かないと思います。
マイクロソフト公式ダウンロード センター
のサポートされるオペレーティング システム
には、Windows7の名前すらありません。さらに、
Windows Media Encoder 9 の Windows 7 サポートについて
にも、Windows7はサポート対象外と明記されています。
ただし、私の経験で言うと、Windows7（32ビット・Windows Aero無効）では問題なく動いていました。
また、Windows8.1（64ビット・Windows Aero有効）では、「ファイルにエンコード」で
録画失敗する不具合が時々発生するものの、録画成功することも多かったです。
（不具合詳細：出力ファイルが6KBしかない。録画中の統計タブは普通で、不具合発生の見分けがつかない）
私はWindows10へのインストールは試していませんが、
インストールすらできないという話と、何やら頑張ればインストールできたという話を見かけます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【エンコードに関する知識、情報など】
しっかり知りたい人向け。Q&Aよりもこちらのほうが読んでいてためになると思います。
《よい配信の基本》
●接続が安定してできること。
●配信者側の回線速度不足やパソコン性能不足によるバッファを起こさないこと。
●取り込み範囲や縦横比が正常であること、文字がつぶれていないこと。
●音割れを起こさず、なおかつ適切な音量バランスで聴こえていること。
●フレームの欠落が発生していないこと。
上から順に重要です。
「ビデオサイズ」を縮小する場合は、文字がつぶれてしまわない程度に。
フレームを削減する場合は、低くしすぎて状況がわからなくなってしまわない程度に。
「ビデオビットレート」を削減する場合は、「欠落したフレーム」が出てしまわない程度に。
ビットレートと回線速度の細い視聴者を意識できるようになると、さらによいです。
《画質》
「ビデオビットレート」だけが画質に直結するわけではありません。
わかりやすくするために簡単な説明になりますが、
「ビデオの滑らかさ」50、「コーデック」Windows Media Video 9、を前提に考えると、
用意された「ビデオビットレート」は、「ビデオサイズ」と「フレームレート」と画質が
奪い合うことになります。
これは言い換えると、「ビデオビットレート」を上げなくても
「ビデオサイズ」や「フレームレート」を小さくすることでも画質はいくらか上がるのです。
また、もしビットレートに余裕があるのなら、「ビデオビットレート」は
足りるか足りないかわからないくらいよりは、少し多めに割いておいたほうがいいです。
余った「ビデオビットレート」は画質に回されるので、無駄にはなりません。
《文字つぶれ、「ビデオサイズ」の縮小》
画質と似ているようで、画質とは少し違います。
「ビデオビットレート」を大量に割いても、文字つぶれは改善されません。
逆に、「ビデオビットレート」が足りなくても文字が読める場合もあります。
文字がつぶれず読めるかは、「ビデオサイズ」が大きくかかわります。
簡単に言うと、縮小せず、もとの画面の大きさと同じ大きさで配信すれば、文字がつぶれることは
理論上ありえません。
（※一度縮小してから再拡大したらもちろんつぶれます）
少しくらいなら縮小しても文字が読める場合があります。
具体的にどの程度までなら縮小が許されるかはゲームによりますが、一例として
スーパーファミコンのゲームである「ファイアーエムブレム トラキア776」について書きます。
トラキア776では、画面サイズを160x122にすると、
操作／マップメニューや操作／進撃準備のように
読みづらくなります。
少しくらい読みづらくても脳内補間できる……というのは経験者に限った話。
未経験者のためにも、画面はもっと大きくするほうが望ましいです。
一方操作／パラメーターでは、画面サイズが240x186になっているおかげで何とか読めます。
配信だと画質の問題もあるので、これよりもう少し読みづらくなるのですが、
トラキア776では240x186くらいが下限と考えてもいいかもしれません。
画質が悪いだけなら問題と言うほどのことではありませんが、文字がつぶれて読めないのは問題なので、
画質向上よりも文字が読める状態にすることを優先して考えるようにしてください。
余談1：画質向上には「ビデオサイズ」を小さくするという手があるのですが、文字が読める状態にすることを
優先しなければならないせいで、「ビデオサイズ」を小さくするという手が使えないことは結構あります。
余談2：文字つぶれとは別問題ですが、多くの人は似た問題という印象を抱くと思うのでここに書いておくと、
等倍にしていてもPCので文字がかすれることならあります。文字が細いPCノベルゲームで顕著です。
これは、単純に画質が足りていないことが原因です。
《パフォーマンスの効果》
パフォーマンスや配信形式（例：wmvとflv）などの画質にかかわる設定は、
元のビットレートが低いほど効果を実感できます。
「ビデオビットレート」に+100Kbpsされる、と例えればわかりやすいでしょうか。
100Kbpsが200Kbpsになることは違いを感じられますが、1100Kbpsが1200Kbpsになっても
違いはほとんど感じられません。
そのため、これらは低ビットレートでやりくりしたい人に真価を発揮します。
代償として、パフォーマンスを高品質寄りにしていくごとにCPUへの負荷が増大します。
体感では、メモリを一つ動かすごとに「+0 → +1 → +2 → +4 → +8 → +16」と負荷が倍増していく
印象です。
また、+0 → +1 のときの変化よりも +8 → +16 のときの変化のほうが画質向上効果が大きいということは
ないと思います。
余談ですが、「出力」タブの下にある項目が、
「ファイルへ保存」と書かれていれば「ブロードキャスト時」を参照し、
「ファイルにエンコード」と書かれていれば「ファイルへのエンコード時」を参照します。
さらに脱線すると、パフォーマンスは、ビデオコーデックが「Windows Media Video 9」でないと
有効になりません。
またさらに脱線。ヘルプには「Windows Media Video 8.1」でも有効とありますが、
私の環境では「Windows Media Video 8.1」という選択肢がなく、さらに
「Windows Media Video 8.1」に関する情報がほとんどないのでわかりません。
少なくとも「Windows Media Video V8」では有効になりません。
《「ビデオサイズ」と「フレームレート」の共通点》
「ビデオサイズ」も「フレームレート」も、
「ビデオビットレート」とパソコンの性能を求めています。
「ビデオサイズ」も「フレームレート」も、大きくなればなるほど、より多くの
「ビデオビットレート」とパソコンの性能を求めます。
「ビデオビットレート」かパソコンの性能のどちらかが足りない場合、
動画の品質は大きく落ちてしまいます。
《「ビデオの滑らかさ」について》
「ビデオの滑らかさ」は、「ビデオビットレート」が足りない場合に
「画質を落とすか（フレーム維持）」「フレームを落とすか（画質維持）」の
優先度を決める項目です。
画質を落とす、フレームを落とす、どちらもよくない状況なので、この項目は
中間点である50から変える必要は基本的にありません。
「ビデオビットレート」を十分に用意して、変える必要のない設定を組むべきです。
ですが、「ビデオビットレート」を十分に用意した上で、万が一の一時的なフレーム欠落への対策として
テストではない実際の配信時に限り、「ビデオの滑らかさ」を50未満にしておくというのはよい考えです。
フレーム欠落よりも低画質のほうが、見やすさはまだましです。
《「バッファサイズ」について》
簡単に説明すると、これは動画を送信する前にエンコーダが動画情報を
反芻する秒数になります。この値を大きくすると、動画の品質が少し上がります。
（多分、バッファサイズ内でABR的な処理をしているのだと思います。WMEは完全なCBRにはなりません）
ですが動画情報を反芻するため、設定した秒数だけ送信に余計な時間がかかり、結果
視聴者とのずれが大きくなってしまいます。
品質が高まるとはいえ、配信は鮮度が命なので考えなしにこの値を大きくするのは考えものです。
ところで、「回線の細い人は『バッファサイズ』を大きくしたほうがいい」という情報を
見たことがあります。
ですが、私にはその意味がよくわかりませんでした。
回線速度が明らかに足りていない場合には無意味だと思いますが、
その一方で、回線速度が不安定な場合には有効な手段だと思います。
《動画のカクカク改善》
「フレームレート（設定値）」と「平均fps（実際の出力）」の値がそろうようにすべきです。
「フレームレート」30fps → 「平均fps」20fpsよりも、
「フレームレート」15fps → 「平均fps」15fpsのほうが見やすいです。
目安として、「平均fps」が「フレームレート」の9割しか出ていない（例：設定30fpsなら27fps）
ようなら、設定を見直すべきです。もちろん10割が理想ですが。
「フレームレート」の値を変えて改善を試みる際、値を大きくするのではなく
小さくすべきということに注意します。
大きくすると、「フレームレート」と「平均fps」の差が広がり、
さらにカクカクを感じてしまいます。
ちなみに、「欠落したフレーム」を見ることは効果的とは言えません。重要なのは割合です。
「フレームの合計」が200で、そのうち「欠落したフレーム」が100だと
全体の50%も欠落していることになりますが、
「フレームの合計」が20000で、そのうち「欠落したフレーム」が100だと
全体の0.5%しか欠落していないことになります。
さて、「平均fps」が下がってしまう主な原因は、
「ビットレート不足」と「スペック不足」の2種類があります。
前者なら、主に以下のことをすれば改善が期待できます。
●「ビデオサイズ」を小さい値にする
●「フレームレート」を小さい値にする
●「ビデオビットレート」を大きい値にする
●「ビデオの滑らかさ」を小さい値にする
後者なら、主に以下のことをすれば改善が期待できます。
●より高性能なパソコンに変える
●よりパソコンへの負荷が少ないエンコード設定にする
●不要なアプリケーションを終了させる
●その他、ゲームの設定を変えるなどしてパソコンへの負荷をできる限り減らす
原因がどちらにあるかは、
「欠落したフレーム」が出て「平均fps」も下がったなら前者、
「欠落したフレーム」は出ていないのに「平均fps」が下がったなら後者、
と判断できます。
（後者についてはほかにも考えられることがいくつかあるのですが、私自身が
そのすべてについて言及できるほど詳しくないので省略します）
《ほかのものが映らない問題（Windows Aero）》
配信者にとって、「Windows Aero」は天敵です。
これが有効になっている状態で、範囲指定取り込みではなく
ウィンドウ取り込み（「Drag here.」）をすると、当該ウィンドウ以外が映らなくなります。
（これに対しては、SCFH DSFの「レーヤードウィンドウ表示」は関係ありません）
突然変なウィンドウが前に出ても映らないという意味では安全でもあるのですが、
ゲーム画面とメモ帳や字幕を重ねて配信している人や、ちょっとウェブブラウザを見せたいというときには、
少し面倒臭いと感じるかもしれません。
すでに書いているのでおわかりかと思いますが、対処法としては以下の2種類があります。
●「Windows Aero」を無効にする
●ウィンドウ取り込みではなく範囲選択取り込みにする
このうち、「『Windows Aero』を無効にする」については、Windows 8以降では困難です。
また、「ウィンドウ取り込みではなく範囲選択取り込みにする」については、環境によって
fpsが落ちて、動画のカクカクにつながることがあります。
つまるところ、Windows 7のパソコンを買って、またはWindows 7のパソコンを修理して、
Windows 7のパソコンでAeroを無効にする、というのが一番いい対処法です。
それができなければ、fps低下を覚悟して範囲選択取り込みにするしかありません。
《SCFH DSFメモ》
●ウィンドウ指定取り込み（「Drag here.」）だと、余計な範囲まで取り込んでしまって
（例：ウェブページに埋め込まれたブラウザゲームだけ取り込みたいのにウィンドウ全体を取り込む）
範囲選択取り込みにしないといけないという場面があります。
ですが、Aeroに冒されているパソコンだと、範囲指定取り込みは避けたいところです。
そんなときは、まずウィンドウ指定で余計な範囲も一緒に大きく取り込み、その後「レイアウト」を見ながら
SCFH DSFの「範囲」から手入力してトリミングすることで、結果的に範囲取り込みと同じことができ、
なおかつAeroにじゃまされることのない高いfpsでエンコードできるようになります。
●SCFH DSFは、パソコンでメインにしているディスプレイの解像度以上のサイズは取り込めません。
例えば、メインディスプレイ1920x1080にサブディスプレイ1024x768があっても2944x1080は
映せませんし、メインディスプレイ1024x768にサブディスプレイ1920x1080という構成だと、
縦幅768を超えるウィンドウはサブディスプレイに映してもちゃんと取り込むことはできません。
対象ウィンドウの下部が犠牲になり、SCFH DSFはそのぶん縦に引き延ばす、または
上下に黒枠が入った状態（「アスペクト比維持」有効時）で映し出します。
ちなみに、SCFH DSFを使わず、WMEのソース → ビデオ → 「画面の取り込み」なら
メインディスプレイ1024x768にサブディスプレイ1920x1080でも全く問題ないので、原因があるのは
SCFH DSFで確定です。
《キーフレームについて》
フレームは基本的に、直前のフレームと違いのある部分だけを更新するようになっています。
こうすることで更新する部分を減らし、必要とするビットレートを減らしています。
（このときのフレームをデルタフレームと呼びます）
ですが、デルタフレームだけでは少しずつ画面が汚くなっていきます。
それに対して、前の情報を使い回さないフレームであるキーフレームがあります。
あなたが配信視聴経験の豊富な人なら、ストップウォッチやメモ帳などの字に
跡のようなものが残ることを見たことがあるかもしれません。
これらが残る原因はデルタフレームであり、それが一時的に消えるタイミングもキーフレームが入るときです。
画面や色などがひどく崩れてしまったときにも、キーフレームが入れば直ります。
車におけるワイパーのようなものでしょうか。
余談ですが、動きのない画面をエンコードしていると、「モニタパネル」の「統計」タブにある
「現在のビットレート」の数値は極めて低い値を示しますが、それでもたまに一瞬だけ
「現在のビットレート」の数値が高くなります。まさにその瞬間にキーフレームが入っているのです。
デルタフレームは直前のフレームと違いのある部分だけを更新しますが、それは言い換えると
直前のフレームを持っていない場合は何もできないということを意味します。
配信に接続した直後の数秒間、音声は流れるのに映像が映らないというのはこのせいです。
また、デスクトップの描写が一時的に止まって配信画面が一時的に
消えたとき（例：ユーザーアカウント制御）にも同様に、
キーフレームが入るタイミングを待つことになります。
このように、キーフレームの存在は偉大なものとなっています。
ならば「キーフレームの間隔」の数値を小さくして頻繁にキーフレームを入れたらいい、
あるいはすべてキーフレームにしたらいい、とあなたは考えるかもしれません。ですが、その
前の情報を使い回さないフレームは、デルタフレームよりも多くの「ビデオビットレート」を使います。
そのため、キーフレームを入れすぎると「ビデオビットレート」を使いすぎることで、
キーフレームが入っていないときの画質が落ちたり、ひどい場合には
フレームの欠落が発生してしまいかねません。
《ビデオビットレートの目安》
適切なビデオビットレートは配信対象によって異なるということは言うまでもありませんが、
最低限必要なビデオビットレートとしては、
「画素数×フレームレート÷10000」で単位をKbpsにしたものを当てはめることは、
とても簡単に計算できる一つの目安になれるかもしれません。
ですが、キーフレームとデルタフレームの存在があるので、実際はうまく計算が合わないこともあります。
キーフレームはフレーム単位ではなく時間単位で入るので、例えば
「10fps→20fps」で2倍のビデオビットレートが必要になるというわけではありません。
フレームレートが多いほどキーフレームの割合が減ってデルタフレームの活躍する場が多くなるので、
「10fps→20fps」のときよりも「20fps→30fps」のときのほうが
増やすべきビデオビットレートは少ないです。
さらに、（これは知識不足のためにうまく説明できませんが）解像度についても、小さい画素数のほうが
上記の式に対して必要なビデオビットレートはやや多くなるようです。
具体例としては、「640x480の600Kbps」よりも「320x240の150Kbps」のほうが低画質になります。
「640x480の300Kbps」が「320x240の150Kbps」と同じくらいになるでしょうか？
そのため、「画素数×フレームレート÷10000」の計算式は使わないか、使うとしても
●ほんの参考程度に留める
●計算結果が小さい値であるほど、多めのビットレートを割く
ということに気をつける必要があります。
《オーバーヘッドの一覧》
必要となるオーバーヘッドの大きさは、合計ビットレートによって変わります。
| オーバーヘッド | 合計ビットレート(オーバーヘッド込み) |
| 3Kbps | | 〜 | 16000bps(19000bps) |
| 4Kbps | 16001bps(20001bps) | 〜 | 30000bps(34000bps) |
| 5Kbps | 30001bps(35001bps) | 〜 | 45000bps(50000bps) |
| 6Kbps | 45001bps(51001bps) | 〜 | 70000bps(76000bps) |
| 7Kbps | 70001bps(77001bps) | 〜 | 224999bps(231999bps) |
| 9Kbps | 225000bps(234000bps) | 〜 | |
ビデオのないラジオ配信なら話は別ですが、多くのビットレートを必要とするビデオあり配信が前提なら、
「ビデオビットレート＋オーディオビットレートが225Kbps未満ならビットレートがわずかに節約できる」
とだけ覚えればOKです。
コーデックを変えたり、オーディオを消してビデオのみの状態にしたりしても同じなので、
どの条件でもこうなるかと思います。
通常利用で見かけることはありませんが、合計ビットレートが2147483647bpsを超えると、
オーバーフローしてマイナスになるというバグがあります。
《プロセスの優先度について》
性能の低いパソコンで配信する場合にwmenc.exeの優先度を上げることは、
一つの手段として確かにあります。
ですが優先度は相対的なものなので、一つのプログラムの優先度を上げると、ほかのプログラムの
動作が鈍くなってしまいます。
explorer.exeの動作が鈍くなると、困る場合もあるのではないでしょうか？
そのため、上げずに済むのなら上げないほうがいいです。
あるいは、wmenc.exeの優先度を上げるのではなく、
閉じることはできないけど今は重要ではないというアプリケーションの優先度を下げる方法もあります。
もしCPU使用率が常に100%になっているのなら、優先度を上げるのではなく配信設定を見直すべきです。
ヘルプにもこのように記載されています。
一般的に、CPU の負荷 (モニタ パネルの [全般] タブに表示されます) が
継続的に 80% 以上になる場合は、コンピュータのアップグレードを検討する必要があります。
ちなみに、wmenc.exeの優先度を上げる場合は、キャプチャーソフトやパソコンゲームの配信対象も
一緒に上げたほうがいいです。ゲームの動作が鈍くなってしまっては、
せっかくWMEの優先度を上げても意味がありません。
《テストの目的を持つ》
テストする際、きちんと目的を持たないと非効率的になったり、テストの途中で
自分が一体何のためにしているのかよくわからなくなってしまうことがあります。
品質と負荷は近い関係にあることが多いですが、それでも
品質に関するテストなのか、負荷に関するテストなのかをしっかり意識しておかなければ
いけません。
例えば品質の比較なら、あえてフレームの欠落を多く発生させる設定にすると
違いがわかりやすくなり、テストが楽になります。
この場合は例えばビットレートを落とすといいですね。
《もっと配信に関する知識がほしい》
WMEのヘルプを熟読しましょう。いろいろ載っています。
《メモ》
| 設定箇所 | 設定値 |
| ビデオ サイズ | 240x160 |
| フレーム レート | 60fps |
| キー フレームの間隔 | 20秒 |
| ビデオ ビット レート | 192.999Kbps |
| バッファ サイズ | 3秒 |
| ビデオの滑らかさ | 50 |
| パフォーマンス | 100（CPUは問題なし） |
この設定で、ネットサル（エミュレータ）でピッチの外から50秒間カメラを回す。
逆斜め下入力による高速回転。
| ピッチ | 欠落fps/合計fps |
| スタジアム | 433/3049 |
| 北極 | 962/3023 |
| 地下帝国 | 0/3011 |
| 宇宙 | 1601/3002 |
| 海底都市 | 0/3007 |
| 海賊の島 | 833/3006 |
| 砂漠 | 0/3008 |
| 火吹き山 | 988/3005 |
| サンダーランド | 0/3004 |
最もフレーム欠落が発生しやすいピッチは宇宙だった。
宇宙でもう少し試行すると、23fpsでも欠落あり、22fpsでは5分間回しても欠落なし。
ビデオサイズを480x320にすると、7fpsでも欠落あり、6fpsでは5分間回しても欠落なし。
キーフレームの差はあるだろうけど、240x160の22fps ≒ 480x320の6fps ということがわかる。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【設定例】
《想定環境》
ビデオキャプチャーボード＋レトロゲーム配信。動きは少なめ。
具体的にはトルネコ1や風来のシレンGBなどの配信です。
レトロゲームなので滑らかさはあまり必要なくて、文字が読み取りやすいよう画質を重視したい。
キャプチャーソフトには、黒枠込みで720x480の画面が出力されるものとします。
（GV-USBがこうだったので）
上り回線速度は3XXKbps台のADSL。リレーを前提とした@1配信。
有線接続で、上り回線速度は安定しているものとします。
CPUは十分。大体Intel Core 2 Duoの2.00GHzくらい？
《ビデオコーデック》
Windows Media Video 9
ビデオサイズやフレームレートは低負荷のそれになっているので、V7にしたくなることは少ないと思います。
《オーディオ形式》
32 Kbps, 32 kHz, 2 channel 16 bit CBR
「Windows Media Audio 9.2よりもWindows Media Audio 10 Professionalのほうが高音質」
という話を聞いたのでこれに。
合計ビットレートに対してオーディオビットレートの割合が高いですが、
Windows Media Audio 10 Professionalの中で選べる最低値がこの32Kbpsなので仕方ありません。
《ビデオビットレート》
192.999Kbps
オーディオビットレートを32Kbpsとした場合に、オーバーヘッドが7Kbpsで収まるぎりぎりの値がこれです。
すべて合わせた合計ビットレートは231.999Kbpsです。
上り回線速度を300Kbpsぴったりとすると、割合は77.333%ですね。
上り回線速度が安定している人以外にはおすすめできない割合です。
合計を231.999Kbpsから減らす場合、Windows Media Audio 10 Professionalをあきらめて
ビデオビットレート以上にオーディオビットレートを下げます。
極論かもしれませんが、文字の判読を始めとした状況確認ができないとどうしようもないので
ある程度高いビデオビットレートは必須である一方、音は聞こえさえすれば何とかなるので、
レトロゲームならオーディオビットレートは最低値の5Kbpsでもいいと思います。
（※0Kbpsも設定できますが、無音になってしまいます）
ただし……これは必要最低限の画質を確保できていることが前提にある状態での話ではあるのですが、
例えばオーディオビットレートを32Kbpsから5Kbpsへと27Kbps下げることよりも
ビデオビットレートを231.999Kbpsから204.999Kbpsへと27Kbps下げることのほうが
視聴時の印象への悪影響は小さく済むかもしれません。このような考え方もあります。
《ビデオサイズ》
320x240（※「ビデオ入力と同じ」にチェックを入れる）
キャプチャーソフトで出力された720x480の画面からクロップして640x448にして、
それをSCFH DSFで取り込みます。50%縮小ですね。320x224。
320x16が余りますが、その部分には等倍のメモ帳を映します。メモ帳は等倍ですよ。
メモ帳が必要なければ、ビデオサイズ自体を320x224にしてもいいです。240も224も、16の倍数です。
お好みでどうぞ。
《フレームレート》
10fps
トルネコ1や風来のシレンGBなどなら激しい動きがないおかげで10fpsでも見えるので、画質を優先します。
これが例えばネットサルになると、10fpsではかなり厳しくなります。画質を犠牲にしてでも
15fpsくらいまで上げるほうがいいです。
そうなると画質以上に負荷が怪しいので、パフォーマンス設定の品質を落とさざるを得なくて、
画質がさらに落ちることになりますが、ほかに削れる部分もありませんから仕方ないです。
ゲームの性質的にフレームレートがもっとほしいとしても我慢しましょう。
画質とのバランスを考えると、この上り回線速度やビットレートでは15fpsが限界です。
それに15fpsなら動きの激しいゲームでもまあまあ見ていられます。
《キーフレームの間隔》
20秒
ヘルプに載っている値と同じ秒数です。
ビットレートが限られているので、キーフレームにはあまりビットレートを割きたくないです。
それに動きの少ないゲームですし。
ですが、配信に接続した直後の視聴者は、真っ暗な画面を最長20秒間見ることになります。
初期値である8秒にするのもありです。それくらいの余裕はあります。
《バッファサイズ》
5秒（既定値は使用しない）
初期値と同じです。
ビデオビットレートが低いので、ここを小さくしすぎると画質がさらに悪くなってしまいます。
ですが、配信ということを考えるとあまり大きな数値にもしたくないのが悩ましいです。
既定値（3秒）にするのもありです。それくらいの余裕はあります。
《ビデオの滑らかさ》
0
カクカクするくらいなら画質が落ちるほうがましです。
もちろんエンコードテスト時は50でします。ここで0にするのは保険です。
《デコーダの複雑さ》
自動
私には画質の違いがわかりませんでした。
《スクリプトビットレート》
私には使いこなせないように思いました。
《パフォーマンス設定》
100
一番右です。もとが低ビットレートに合わせた低負荷な設定なので、パソコンの性能によっては
100でも配信が可能です。
ビットレートが低いので、パフォーマンス設定による影響も大きいです。
CPU性能が足りない場合、ビデオコーデックやビデオサイズではなくまず真っ先にここの設定を変えます。
一段回左……80にするだけでも負荷は大きく減ります。
《その他》
SCFH DSFの縮小方法はSoftware(bilinear)にします。縮小しても文字が比較的読みやすくなります。
SCHF DSFのオーバーサンプリングは使いません。画質が落ちてしまいます。
この例のエンコーダ セッション ファイル。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【配信テスト】
実はどちらもほとんど同じです。
《「ファイルにエンコード」での確認》
ポート開放の確認にはなりません。
映像や音声の圧縮具合を確認できます。つまり、文字がつぶれていないか確認できます。
ファイルとして保存できます。
《動画再生プレイヤー「localhost:XXXX」「127.0.0.1:XXXX」での確認》
ポート開放の確認にはなりません。
映像や音声の圧縮具合を確認できます。つまり、文字がつぶれていないか確認できます。
配信の遅延がわかります。
どちらもポート開放、回線速度（バッファ）の確認にはならないという点には注意です。
ですがそれでも、動画の品質に関する確認のほとんどは一人で済ませられますし、ポート開放の確認も
ポートスキャンしてくれるウェブサイトを探せば済みます。
ほかの人に接続してもらって確認してもらう必要があるのは、特殊な環境での配信を除くと、
接続が安定するかどうか、バッファの確認くらいではないでしょうか。
一人で確認できることをわざわざ配信テストすると、怠け者と怒られてしまいますよ。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
おこしやすネットサル＞その他トップ＞このページ