fc2ブログ
 

倍速液晶が0.5フレーム遅延するのはどうして?

今回の検証の中で倍速液晶(60Hzのビデオ信号を120Hzで表示するテレビやモニター)は60Hz駆動の液晶と比べ0.5フレーム遅延すると書いてきました。

実際REGZAの公称値でも60Hz駆動の26ZP2の処理遅延が0.2フレーム、倍速液晶の32ZP2が0.7フレームとなっており倍速液晶の方が0.5フレーム多くなっています。また、東芝のサイトでも
倍速補間のところにかかっていた1フレームの遅延を、0.5フレーム、理論限界まで抑えた。
とありますので倍速液晶における0.5フレーム遅延と言うのは仕組み上避けることのできないものであるということがわかります。
しかし、その理論についての説明はなくネット上を検索してもなかなかでてきませんので私なりの考えを書きたいと思います。


(1) 60Hzのビデオ信号について
まずはビデオ信号について知る必要があります。
60Hzのビデオ信号では1画面分の画像を約16.6ms(話を単純にするため以下16msとします)かけて画像の上から下に向かって転送します。とても速いので一瞬で送っているように感じてしまいますが、実際は16msかけて”ゆっくり”上から順番に送っていると捉えることが重要になります。
PlayStation3、XBox360はもとよりほぼすべてのゲーム機が60Hzのビデオ信号で画像を出力します。また、現在のPCも60Hzをメインで使うようになっています。


(2) 60Hzのビデオ信号を60Hzで表示する場合
60Hz駆動の液晶で表示する場合は、ビデオ信号の初めの方(画像の上端)を受信してすぐに液晶パネルの表示(スキャン)を開始することができます。液晶パネルも画面の上から下に向かって16msかけてスキャンしていきますので、画面の中央や下端でもビデオ信号を受信してすぐに表示することができます。
理論上は遅延を限りなく0にすることができます。
60Hz液晶遅延概要図


(3) 60Hzのビデオ信号を120Hzで表示する場合
一方、120Hz駆動の液晶パネルでは画面の上から下に向かって8msかけて表示します。60Hzの液晶が16msですのでその倍の速さと言う意味で倍速液晶と呼ばれています。
(2)のケースと同様に60Hzのビデオ信号の初めの方を受信してすぐに表示を開始したらどうなるでしょうか。画面の上側はビデオ信号が送られてきてから表示するので問題ありませんが、画面の下に向かうにしたがって液晶の表示位置(スキャン位置)がビデオ信号を追い抜いてしまいます。
例えば、表示を開始して8ms後に液晶パネルは画面の下端を表示しようとしますが、ビデオ信号はまだ画像の半分しか受信できていません。画像の下端のビデオ信号が受信できるのは16ms後です。
これでは表示する画像が無くて困ってしまいますね。

原則は画面の上端でも下端でも入力されるビデオ信号より後に表示処理を行わなければいけません。つまり、入力されるビデオ信号をスキャン位置が追い抜かないように制御する必要があるわけです。
簡単な制御方法としては1フレーム分をメモリーにキャプチャしてからメモリーの内容を液晶パネルに表示することです。液晶テレビでは様々な画像処理を行いたいため、一度メモリーにキャプチャしてからフレーム単位で画像処理するという設計は理にかなっています。ただし、この方法では最低でも1フレーム分の遅延が生じてしまい遅延の点では不利となってしまいます。
実は1フレーム分キャプチャしてから表示を開始しなくても、キャプチャ途中で見切り発車して大丈夫な場合があります。重要なのは「入力されるビデオ信号をスキャン位置が追い抜かない」ですので、この条件を満たすぎりぎりの表示開始タイミングを模索することができます。
考え方としてはビデオ信号の終わり(画像の下端)を受信するタイミングと、液晶パネルの下端を表示するタイミングがそろうように開始時間を逆算します。
結果だけ書くとビデオ信号が入力され始めてから8ms後に表示を開始することで途中で追い抜くことなく画面の下端まで表示することができるようになります。(待ち時間が8msより短いと途中で追い越してしまいます。)
この8ms遅らせる部分が0.5フレームの遅延の正体です。
倍速液晶遅延概要図


同様に4倍速液晶の場合も12ms遅らせて表示開始することでビデオ信号の終端と240Hz液晶パネルの下端を表示するタイミングを揃えます。


n倍速液晶の理論上の最小遅延の計算式

最小遅延 = (n-1) / n   フレーム

例:4倍速液晶の場合
  最短遅延=(4-1)/4=0.75フレーム
  4倍速液晶の場合ビデオ信号を受信してから最低でも0.75フレーム以上遅れて液晶パネルの表示を開始する必要がある。

これは表示速度(スキャン速度、画面の上端から下端まで表示するのにかかる時間)が速くなればなるほど液晶の表示開始タイミングを遅らせる必要があることを意味しています。


(4) ズームによる遅延
REGZA 32ZP2に720pのビデオ信号を入力した場合のズームによる遅延についても今回検証を行いました。
スケーラーでズーム処理を行う「ゲームフル」とスケーラーを使わない「Dot by dot(以下DbD)」ではDbDの方が遅延が少ないと思い込んでいましたが、検証の結果は逆にスケーラーを使った「ゲームフル」の方が4msほど遅延が少ない結果となっています。これも倍速液晶と同じ原理で表示速度(スキャン速度)による避けることのできない遅延が関係しています。
今回倍速液晶で検証したのでここでも倍速液晶を例に説明します。倍速液晶の液晶パネル全体にゲーム画面を表示した場合画面の上から下に向かって8msかけて表示することは先に説明した通りですが、DbDの場合は液晶パネル全体ではなく画面の中央に小さくゲーム画面が表示されます。その表示領域(画面縦方向)は1080分の720なので約66%となります。32ZP2では1080画素を8msかけて表示するようになっていますので、720画素ではその66%の約5msでゲーム画面を表示(スキャン)することになります。
もうピンときたかもしれませんが、表示速度が上がった(表示するのにかかる時間が短くなった)のでその分液晶パネルの表示開始タイミングを遅らせる必要が出てくるわけです。そうしないと液晶に表示する処理が入力されてきたビデオ信号を追い越してしまい破綻します。
ではどの程度表示開始を遅らせるかと言うと画面いっぱいの表示にかかる時間の8msとDbDの表示にかかる時間の5msの差である3ms分DbDは表示開始を遅らせることになります。
こうすることでDbDでもゲーム画面の下端(液晶パネルの下端ではなく額縁の内側)と入力されてくるビデオ信号の終端をそろえます。

考え方としては表示領域が狭くなればなるほど相対的にゲーム画面を表示するのにかかる時間が短くなりその分表示開始タイミングを遅らせる必要が出てきます。
60Hz駆動では(1080p液晶で720p DbD表示)16.6msの33%=約5ms遅延が増えます。
Dot by Dotなどにより表示領域が狭くなる(額縁が大きくなる)→遅延は増える(額縁遅延)

ただし、これらはスケーラーによる処理遅延が0の場合の話です。 例えばスケーラーによる処理遅延が3ms以上であればやはりスケーラーを使わないDot by dotの方が低遅延となります。

32ZP2 ズームによる遅延の検証結果
ズームモードキャプチャとの差
秒間480コマで撮影
遅延
1080p6コマ約12ms0ms(基準)
720pゲームフル4コマ約8ms+4ms
720p DbD2コマ約4ms+8ms
※ 「キャプチャとの差」は基準となるモニターからどれだけ早く32ZP2が表示されたかです。数値が大きいほど32ZP2の遅延が少ないことを意味します。

1080pを基準にみると720pゲームフルはスケーラーにより4ms遅延が増えていることになります。
720p DbDはスケーラーの処理が入らないので理論上は額縁による3ms遅延となるはずですが、検証では8msとやや大きい遅延となっています。推測ですが32ZP2はDbDの場合もスケーラーかなにかの余計な処理を通すようになっているのでしょうか。



まとめ
(1) 倍速液晶はほぼすべての製品において60Hz駆動液晶より0.5フレーム以上遅延が増える。
(2) 「倍速補完をOFFにすることで遅延を軽減」と説明されている場合でも、補完処理にかかる2フレーム程の大きな遅延が軽減されるだけで最低でも0.5フレームの遅延はのこるし、液晶パネル自体が60Hz駆動になるわけではないようです。
(3) 4倍速液晶はさらに遅延が増える(最低0.75フレーム)。
(4) Dot by dotなどの額縁表示では表示領域が小さくなるほど遅延が増える。
(5) BenQ XL2420Tでは60Hzのビデオ信号が入力された場合に液晶パネルも60Hzで駆動し、0.5フレームの遅延はない。


テーマ : PC周辺機器     ジャンル : コンピュータ
 
 
あまラボへようこそ
このブログでは自作ソフトの最新情報やtips、PC動画に関する話題を掲載していきます。各記事へは下にあるカテゴリからアクセスして下さい。

ファイルのダウンロードはホームページの方でお願い致します。

質問・要望・不具合報告はこちら
アマレコTV
アマミキ!
アマレココ
アマレコ・ライト
ファンタジーリモート
AMVコーデック



ホームページ
カテゴリ
最新コメント
カレンダー
01 | 2013/02 | 03
- - - - - 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 - -
最新記事
最新トラックバック
ブログ内タグ

アマレコTV ビデオキャプチャ アマレコVR AMVコーデック Oculus アマレココ Quest アマミキ! コーデック gQuest SC500 動画配信 Pico GO ファンタジーリモート 4K アマレコライト Unity プラグイン G2 AMV4 oculus SC512 ライブ機能 パススルー機能 Passthrough デスクトップキャプチャ AVX2 リモートソフト FAQ アセット機能 質問コーナー DirectShow HDキャプチャ ニコニコ動画 Asset 120Hz 背景透過 レゴ 遅延 可変再生速度 組み換え 解説動画 LEGO MetaQuest Meta VR GV-USB2 2 XL2420T Pico4 Quest3 液晶モニター 倍速液晶 AMV2MT デインターレース ベンチマーク アマステ Pro 背景透過V3 PS4 VRonVR MonsterX3A Intensity VideoKeeper2 designs インストール Alternate AVX XCAPTURE-1 31024 GV-USB SD-USB2CAP4 ffmpeg 32ZP2 31006 RDT233WX-Z 画像処理 60fps Robust Matting RGBキャプチャ Rift Video Shadow Play WindowsMR RYZEN UtVideo T2 HDMI NVEnc HDCP QSV LameACM OBS 音遅延 MP3 Haswell 電源オプション 音ズレ 録画 オーバーレイ XCapture-1 MonsterXU3.0R フィギュア ハイパースレッディングテクノロジー HT 31021 MPC 液晶テレビ DirectShowFilter プレビュー 擬似NTSCキャプチャ SD-USB2CUP4 Livetube AtomでHDキャプチャ キャプチャーツール シンクライアント イベント IntensityPro DC-HD1 額縁遅延 REGZA ZP3 倍速補完処理 32ZP32 Kabelake リプレイ機能 モノステ 倍速駆動 ゲームスムーズモード LAVFilters SkyBox Hand Tracking 2.0 ファイルマネージャプラス pytorch APIパススルー機能 API python ハンドジェスチャー パカラーススルー機能 アルファ付き動画 アルファ付きVR動画 RVM クロマキー ダウンロード AssetBundle 物理処理 download passthrough 検証 Preferred Filter Tweaker SteamVR GPU使用率 可逆圧縮 SKnet GV-USB3 キャプチャカード VR動画 フレーム間圧縮 新プレイヤー機能 AMPlayer 60Hz 新アマレコVR 90Hz VRコントローラー MR Windows SSE 

ブログ内検索
月別アーカイブ
アマレココに関するリンク
お世話になっているソフトのリンク
RSSリンクの表示
管理画面
  • 管理画面