TOP
はじめに
Info.
フレーム ver.(高速)
WME 基本設定編
- はじめに
- ソース
- 出力
- 圧縮
- 属性
- 設定詳細
配信編
- SCFH
- 回線速度(収容枠)
- ポート開放
- 配信開始までの流れ
- 配信用 URL
- 配信テスト
鏡編
- はじめに
- kagami.exe
- 鏡置き場(かがみん)
- リザーブ(リザ専)
Tips
- CPU 負担軽減
- コマ落ち
- 様々なソースの設定
- より快適に


Tips
- CPU 負担軽減 -
ここでは、何かとネックになる CPU への負担について触れていきます。
前半では、CPU パワーが決定的に不足している場合の、 WME の設定変更での CPU 負荷軽減の方法です。
後半では、WME 以外での細かな CPU 負担軽減策を紹介します。

- PC パフォーマンスはそこそこある -
エンコード画面サイズを小さくしたくなければ、フレームレートを下げる。(またはその逆)
エンコード画面サイズもフレームレートも徐々に下げることでそれなりの妥協点に行き着く。
フレームレート 30 fps に変にこだわらない。(コマ落ちを発生させなければ低フレームレートでも十分ストレスなく視聴できます)
Jane Style の スムーズ スクロール のチェックをはずす。
Balloo! を使わない。
付箋ソフトや字幕ソフトをちゃんと選ぶ。
物理メモリを増やす。安くなってます。
(配信中のその他のアプリケーションの動作が緩慢になるのは物理メモリが不足しているからです)


- エンコードビデオサイズ - 
SCFH を使用しての取り込み範囲指定は全画面以外であればどんなに大きくても CPU への負担はそれほど大きくありませんが(ソース自体の動作に係る CPU への負担は別)、実際に配信される画面サイズであるエンコードビデオサイズ(ソースタブから設定、圧縮タブービデオ入力と同じ)は、CPU に一番負担のかかる項目です。
320*240   640*480   800*600
これは、最も使われるアスペクト比 4 : 3 の例ですが、エンコードするサイズが大きくなればなるほど CPU への負担も増えます。
エンコードする範囲を大きくする理由の最たるものは小さい文字の描画です。

PC ゲームで、ウィンドウの最小サイズが 640*480 であると仮定します。
このソースを 320*240 でエンコードすると画質が落ちるのもありますが、同時に小さい文字が潰れてしまいます。
絵は多少画質が落ちても何をしているかはわかりますが、文字は潰れてしまうと何が書いてあるのか全くわかりません。
これを避ける為、ソースと同じサイズでエンコード、結果 CPU への負担が増すといった感じです。

CPU パワーが決定的に不足している場合は、どうしようもないので 320*240 まで一気に落としてしまいましょう。
小さい文字のないソースの場合はこれでもそれなりに配信可能です。

- フレームレート -
次に負担となるのは、フレームレートです。5 - 30 fps の間で決定します。
30 fps と 24 fps では、それほど気になりません。24 fps で配信を開始すれば視聴者は 24 fps で違和感なく視聴するでしょう。
24 fps でも全然足りない場合は、一気に12 fps くらいまで落としてしまいましょう。

動画で 12 fps というのはお勧めできませんが、それ以外のソースで CPU パワーが決定的に足りない場合は仕方ありません。
なお、この場合は「12 fps なら絶対にコマ落ちしない」ことが前提です。
12 fps で、さらにコマ落ちもするようでは動画配信は諦めたほうがよさそうです。

- 音質 -
CPU に不安のある場合は、オーディオ ビットレートにも気を配りましょう。
ビデオ ビットレートの場合はそれほどでもありませんが、オーディオ ビットレートの場合は少し上げると CPU 使用率も無視できないレベルで上がってしまいます。
ソースにもよりますので、配信テストをしながらなるべく多くのビットレートを振らないようにすれば CPU への負担も軽減されます。

- Windows Media Video V7 -
基本設定編では、圧縮 タブのビデオ コーデックを選択するプルダウンで Windows Media Video 9 を選択してもらいました。
コーデックによって CPU への負担が変わってきます。
特に 9 から V7 に変えると大きく CPU への負担を軽減することができるので PC パフォーマンスに自信がない場合は試してみましょう。
なお、画質は 9 の時に比べて落ちます。
PC ゲームなどで、画質の良くなる「ソースと同じサイズでエンコード」をかけ、ビットレートも十分に確保できる場合には V7 を選択しても綺麗に見え、かつ CPU への負担を大幅に軽減できます。
光回線だが PC パフォーマンスに不安がある、場合には大変有効な選択肢です。


- Tips #13 CPU 使用優先度 - 

配信中、様々な実況支援ツール(字幕ソフト、付箋ソフト、自動レス表示ソフト、2ch ブラウザ、Web ブラウザなど)を使うと思います。
各ソフトが動く度に CPU パワーを一時的にそちらに取られてしまいます。
ギリギリの CPU パワーで配信をしている場合、当然エンコード処理をしている WME やソース(動画プレイヤーやゲームなど)の動作にも影響が出るわけですが、 WME と ソースの動作以外は多少もたついても配信自体には影響が薄いですね。
これを CPU 使用優先度を変更して実現します。

CPU 使用優先度をソフト毎に設定するツールはいくつもありますが、とりあえず試してみる方法を紹介します。
Windows にはタスク マネージャというソフトが標準で入っています。
Ctrl + Alt + Delete キーを押してみましょう。Windows タスク マネージャ が開けたかと思います。
プロセス タブから WME で主にエンコード処理をしている wmenc.exe というイメージ名を見つけ右クリック、優先度の設定を見ます。
デフォルトでは 通常 が選択されていると思います。これを一段階上の 通常以上 にします。
設定しようとすると警告が出ると思いますが、WME に関してはあまり気にしなくても大丈夫そうです。

続いてソースである動画プレイヤーやゲームのイメージ名を見つけ、同じように 通常以上 を選択します。
こちらは、少し注意が必要です。動画プレイヤーや視聴ソフト、エミュレータではあまり見られませんが、特に PC ゲームについては、時折ゲーム内の処理プロセスの関係で際限なく CPU パワーを消費する場合があります。
優先度の変更は、相対的なものです。他のプログラムより処理を優先させるかどうかという設定をすることになります。
CPU 使用優先度を上げているプログラムが、一時的なプロセス処理にまごつくということは、一時的に CPU 使用率が 100% を示して帰ってこないことを意味します。
処理がすぐ終わればいいのですが、しばらく時間がかかる = ハングアップ というわけで、他のプログラムは処理が再開できない状態が続きます。

とはいえ、一部の PC ゲームに限られます。
発売直後の PC ゲームにも注意が必要です。パッチが公開されている場合は必ず充てましょう

最も注意が必要なのは、WME あるいはソースの どちらか一方だけの CPU 使用優先度だけを上げてはならない 点です。
WME だけにすれば他のソフトと同様にソースの処理も後回しにされ、動画プレイヤーなどではカクカク表示されてしまいます。
エンコードのコマ落ちは大丈夫でも、ソースがコマ落ちしていてはせっかくの設定も無意味です。

また、ソースの CPU 使用優先度だけを上げれば WME のエンコード処理が後回しにされコマ落ちが出てしまいます。
▲CPU 使用優先度を上げるのであれば、WME と ソースの両方を同じレベルで上げる必要があります。
具体的なデメリットとしては、この2つ以外の処理がまごつく点です。
2ch ブラウザの更新は少し時間がかかり、Web ブラウザの表示にもいつもより時間がかかります。
メリットとしては、CPU パワー不足によるソースの動作不安定の回避と、WME のエンコード処理でのコマ落ち回避です。

ギリギリの CPU パワーでの配信を余儀なくされる場合は有効な手段です。
「そもそも CPU パワーが決定的に足りていない」場合は、この方法をとるべきではありません。
ソースと WME の処理にばかり時間がかかり、他の処理が一向に進まない = PC 全体の不安定化を招きます。


- Tips #14 エンコード範囲の正確な設定 - 

これまで、主にアスペクト比 4 : 3 での設定を前提に話しを進めてきました。
しかし、ソースによっては様々なアスペクト比が存在します。ワイド表示に使われている 16 : 9 などが代表的なものです。

WME の設定でアスペクト比 4 : 3 である 640*480 でエンコードサイズを指定し、その中に アスペクト比 16 :9 である 640*360 が入るように取り込み範囲を指定して配信(WME の画面の取り込みを 640*480 →SCFH のアスペクト比維持にチェックを入れ→ウィンドウ指定で 640*360 のソースを指定)をしてもよいのですが、 CPU とビットレートにわずかな無駄が生じるのでなるべく WME の設定のほうもソースのアスペクト比に合わせた設定をしましょう。

また、配信側でのソースの画面サイズがエンコード範囲と同じである場合は SCFH を使用するメリットが薄れます
(マウスポインタの非表示には SCFH が必要)。
SCFH の CPU 使用率はほんのわずかですがゼロではありません。この場合は SCFH を切っても問題はありません。

なお、取り込みに関しては Tips #2 も試してみましょう。







inserted by FC2 system