今回入手してしまったのはPYNQ。Xilinx Zynq7020シリーズを搭載した評価ボードで、あらかじめ用意されたイメージをSDカードに書き込んであげればJupiterからWebブラウザ経由でもいくらか操作を試せるというお手軽さがウリ。
届いたPYNQのパッケージ
秋葉原の職場に送ってもらったので、受け取ったら早々と部品やでヒートシンクと熱伝導シーツを調達。
SDカードにイメージを焼いて起動したら、当然とはいえ、普通にヘッドレスなARM7 Linuxマシンとして起動してきた。OSはUbuntu 15。 OpenCVは 3.1 で、FFmpegサポートも入った状態でコンパイルされている。……これは色々と便利なのでは？
試しにIkaLogでビデオファイルを解析させてみたら、あっけないほど簡単に動いた。
PYNQにはビデオキャプチャ利用を想定したHDMI Inputポートがあるので、これでキャプチャできるかは大変興味があるところ。Jupiter上でOpenCVの顔認識をするコードを途中まで実行したら、WiiUの画像がキャプチャできた。
ただしPYNQのbase.bitではDDCの応答内容に問題があるのかWiiUからビデオ信号が出てこない。このためHDMIマトリックススイッチやスイッチャーなどの機械を挟んでいる。また、720pだと色々安定していないような感じ……。過去に試していたとき、ZYBOではDigilentのdvi2rgbのEDIDを書き換えたらWiiUの信号を直接、安定して食えるようになったので、そのときの成果を持ってくれば解決するだろう。だいたい解決策は見えているので後回し。ちなみに以前ZYBOで実験していたときの写真がこちら。
自作HDMI-RGB回路でWiiU画面うつるようになった。 pic.twitter.com/kMH2UQH0NL— もつなべおじさん (@hasegaw) 2015年12月5日
Jupter で操作した内容を IkaLog の映像インプットとして使えるようクラスを追加して、とりあえずだけども対応完了。
https://github.com/hasegaw/IkaLog/commit/5b6b9ce55e1ae32e57c2dd6f05ae20aa00c9b3fd
HDMIのキャプチャは実現できたが、PYNQにはHDMI Outputもあるので、こちらにパススルーすると、PYNQがIkaLogマシン＋ビデオキャプチャ＋HDMIスプリッタを兼ねるという、いままでIkaLogを利用するにあたって必要となる３つのアイテムをワンボードで実現できることになる。
Pynqのドキュメンテーションを読んでいると、じつは上記の設定でHDMIパススルーも実現できていることがわかった。上記の設定を行うとOut側がIn側のバッファからデータを受け取るようなかたちでパススルーしてくれる（プロセッサは通していないと思う……フレームバッファは通しているかも？）
というわけで、数時間でできちゃったIkaLog+PYNQ（キャプチャ機能＋映像のみスプリッタ機能）。
Pynqで動くIkaLog、Project Inqと命名。Pynqの利用用途として思いついてはいたけども、思った以上に簡単に実装できてしまった。ここまでの成果については下記 WIki ページを見ていただければ再現できるはず。PSoCが可能にした、10Wで動作する #IkaLog Hardware（ARMアーキテクチャ、HDMIキャプチャ／スプリッタ内蔵）の Proof of Concept です。ご確認ください。リアルタイムで解析したデータはこちら https://t.co/2zbp1yl5bk pic.twitter.com/osoKH4S0W8— もつなべおじさん (@hasegaw) 2016年10月15日
https://github.com/hasegaw/IkaLog/wiki/en_Installation_Pynq
これをしばらく動かしてみるといくつか課題が見えてくる。
一つ目の課題は、HDMI Outputから出力された映像がたまに縦にずれたりする。たぶんHDMI映像の伝送が、ARMのDDR3メモリに置かれたフレームバッファを介していて、IkaLogが走っているとメモリ帯域やバス幅が足りなくなるんじゃないかと疑っている。
二つ目の課題は、HDMIのスプリッタ機能といっても HDMI 信号を音無しの DVI 信号としてピクセル情報に落とし、それを DVI 信号として HDMI ポートから出しているだけなので、音が消えてしまう。もちろんレイテンシの問題もあるし、キャプチャ機能はそのまま使うとしても、 HDMI Input から入ってきた信号をできるだけ忠実に HDMI Output に出力するよう変更したい。
Xilinx FPGAなのでHDMIのシリアル信号をISERDESE2で受けて、出力するときはOSERDESE2で送信している（はず）。これらを直結すればナノ秒レベルのディレイでシリアル信号をそのまま伝達できるだろうけど、ビデオキャプチャ機能も必要なので、dvi2rgb IPと共存することは考えないといけない。
とりあえずPYNQについてきたbase.bitは忘れて、dvi2rgb -> rgb2dvi でパススルーするデザインを作ってみた。
WiiU の信号が直接映らないのは相変わらずだけども、画像がたまに縦に１ドット間延びするような現象は解決した。ARMプロセッサ側のDDR3メモリを介さずに、受け取った信号をそのまま送出しているからだろう。
でも、やはり音のデータは消えてしまっている。
手元に高速ビデオ・インターフェース HDMI＆DisplayPortのすべて という書籍があった。
これを読み返してみると、オーディオ信号はVSYNC直後のブランク期間などに入っているとのこと。ここが現状どうなっているかを調べると、色々解決しそう。 dvi2rgb がブランク期間中の信号を捨ててしまっているのではないかという想像だ。もし信号が捨てられていない事が分かればラッキーで、今度は送出側 rgb2dvi が信号を捨てていると考えればよさそう。
Integrated Logic Analyzer を追加して信号を眺めてみる。
案の定 dvi2rgb がブランク期間中の信号をゼロでマスクしているようだ。この 000000 になっているところに、本当はオーディオ信号も乗っているはず。ここにあるはずの信号も含めて rgb2dvi の OSERDESE2 に流し込んであげれば、きっとオーディオ含めてスプリッタとして動作してくれるだろう。
とりあえずの調査はここまで。
