私の持っているデジカメ(CASIO EX-ZR1300)には、解像度と明るさを犠牲にしてフレームレートを上げるユニークな動画撮影機能が搭載されています。FullHD 30fpsの撮影はもちろん可能ですが、120fps(640x480)、240fps(512x384)、480fps(224x160)、最高で1000fps(224x64)まで撮影が可能です。
フレームレート低め(120〜240fpsくらい)でも、普段目に出来ない面白い画が撮れます。例えば、阪急高槻駅のLED構内案内板を撮ってみます。
阪急高槻駅、LED構内案内板(1/8倍速撮影、240fps)
白のLEDが上から下に向かって再描画されている様子が見えると思います。他のオレンジ、緑の部分はフリッカが見えないので、白い部分だけ描画が遅いということになります。面白い設計ですよね。
白いLEDだから描画が遅いかというと、そんなことはありません。阪急の列車(1000系?)のLED行き先案内表示を240fpsで撮ってもフリッカは見えません。
若干モヤモヤして見えることからもわかりますが、常時点灯しているわけではありません。240fpsだと遅すぎて再描画の様子が映らないだけです。論より証拠で、次に1000fpsで撮ってみます。
阪急電車、LED行き先案内(1/33倍速撮影、1000fps)
すさまじい勢いで上から下に再描画が掛かっています。この動画をコマ送りで見ると5コマ程度で全体を書き終えているように見えます。カメラの性能を信じるなら、案内板のフレームレートは約200fpsです。何故だかわかりませんが、べらぼうに速いですね。
他にも高速に再描画しているものはあります。阪急富田駅のLED案内板を1000fpsで撮ってみます。
阪急富田駅、LED案内板(1/33倍速撮影、1000fps)
これは7〜8コマで書き終えているようなので、約150fpsくらいでしょうか。これも人の目にはまず感知できないでしょう。
さきほどからLEDばかりですが、同じLEDでも変わり種のLED式の歩行者用信号を1000fpsで撮ってみました。
高速にON -> OFFされていることがわかります。信号に再描画は要らないので、明るさ調整のためのPWM制御でしょう。お昼でも信号は全力で点灯しているわけではないのが意外でした。
で、ここからは推測ですが、運転していて「信号がまぶしい!」と思ったことはないので、昼と夕方と夜で、信号の明るさを変えていると思われます。
すなわち、同じLED式信号機でも、時間を変えて撮影すれば、今回撮った動画とは違う間隔でON -> OFFされている様子が撮れるのではないか?と考えています。
心配事があるとしたら、夜は恐らく光量不足で撮影不可能だし、何度も撮りに行くのが激しく面倒くさいことですね…。
この記事にコメントする
目次: ALSA
昨日(2016年5月29日の日記参照)の続き。Linuxでも測ってみました。
Windowsで測ったときと同様に、オシロの目盛が振り切れない程度に音量を調節しました。Linuxはループバック再生のやり方は特にありませんので、下記のようにarecordとaplayをパイプで繋いでみました。
arecord -D plughw:1 -f dat -B 10000 | aplay -D plughw:1 -f dat -B 10000
バッファはデフォルトだと500ms近かったので、arecord側もaplay側も10msに設定しています。パイプの分もバッファがあるので、最大で20ms + α 程度のレイテンシになると思われます。
まずCreativeのSound Blaster Play! を測ってみました。

In to Outのレイテンシ(Linux) - Sound Blaster Play!
おお、結構良いじゃないか。と思ったのですが、なぜか入力より出力が遅いようで、しばらく放っておくとレイテンシが変わってしまいます。

In to Outのレイテンシ(Linux) - Sound Blaster Play! その2
同じ機器なのに、録音と再生の速度が違うのは妙です。録音側をplugで変換しているからでしょうか。良く分からんな…。
この記事にコメントする
目次: ALSA
先日(2016年5月22日の日記参照)の続き。オシロスコープを引っ張り出してきて、測ってみました。
Windows側でサウンドデバイスの設定は特にせず、オシロの目盛が振り切れない程度に音量を調節したのと、録音デバイス側の「このデバイスを聴く」のチェックをつけ(=ループバック再生)るだけに留めました。
下記のように接続して、オシロスコープのCh1に単発トリガを掛けて、どれだけ遅れて音が鳴るかを調べました。スプリッタと格好良く書いていますが、単にステレオで出力して、赤白ケーブルの赤と白に分けているだけです…。
ちょっとした工夫として、入力信号の周波数を低め(100Hz)にして、波長の整数倍(今回は0.05s、つまり5波形分)のパルスにしています。
周波数を低くするのは、オシロの時間軸を長めに取ったときでもグラフが潰れず波形をカウントしやすいためです。
パルスを波長の整数倍にするのは、入力と出力の一致を見るためです。たまに無音状態から出音すると先頭の音が欠けてしまう(ポップノイズ防止のため、ボリュームにフェードを掛けて出す)デバイスがあります。その手のデバイスに当たると、フェードの分だけ遅れているように見えるため、不当に悪く評価してしまうからです。
最初はCreativeのSound Blaster X-Fi Go! Pro(約4,000円)です。

In to Outのレイテンシ - Creative SoundBlaster Go! Pro
約100msですね。
次は、同じくCreativeのSound Blaster Play(約1,000円)です。

In to Outのレイテンシ - Creative SoundBlaster Play!
わずかに早い、約90msです。
最後はONKYO SE-U33GXV2(約13,000円)です。このデバイスは内部で直結されているらしく「このデバイスを聴く」をチェックしなくてもループバック再生されていました。

In to Outのレイテンシ - ONKYO SE-U33GXV2
これは0msと言っても過言では無いです。あまりにも同時に鳴ってしまい、グラフが重なって見えないので、グラフを上下にずらしています。
しかしWindowsの設定なんて完全に無視してくれるので、ループバック再生できているとは言えないような。。。

In to Outのレイテンシ - ONKYO SE-U33GXV2「このデバイスを聴く」
ちなみに「このデバイスを聴く」にチェックを入れると、同じ音が二回鳴ってしまいます…。レイテンシはやはり100msくらいです。Windowsはこんなもんなのかなあ?
この記事にコメントする
| < | 2016 | > | ||||
| << | < | 06 | > | >> | ||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| - | - | - | 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 | 29 | 30 | - | - |
wiki
Linux JM
Java API
2002年
2003年
2004年
2005年
2006年
2007年
2008年
2009年
2010年
2011年
2012年
2013年
2014年
2015年
2016年
2017年
2018年
2019年
2020年
2021年
2022年
2023年
2024年
2025年
過去日記について
アクセス統計
サーバ一覧
サイトの情報合計:
本日: