投稿

2018の投稿を表示しています

GV-HUVC を買った

http://www.iodata.jp/product/av/capture/gv-huvc/index.htm

USB 3.1 Gen1 接続で、USB Video Class 対応の HDMI キャプチャーデバイス。
専用のドライバーを必要としないので Windows 以外でも動作し、メーカーからのドライバーや専用ソフトの継続的な更新を必要としないため OS の更新などでデバイスが使えなくなる心配が薄い。
ただ USB 3.1 Gen1 が実質的に必須でAMD製チップセットなど非対応なものもあるようなので、そのあたりでトラブルが起きる可能性は少なくない。

この手の HDMI キャプチャーデバイスでは近年では AVerMedia 製のデバイスが特にメジャーだと思うが、専用のドライバーやソフトウェアがあるタイプの製品はあまり好きではないので、今回は GV-HUVC を買うことにした。
AVerMedia の UVC 対応デバイスは7月に出るらしい

ffmpeg でフォーマットを列挙すると以下の通りで、MJPEG には非対応。
> ffmpeg -list_options true -f dshow -i video="I-O DATA GV-HUVC, Video Capture USB":audio="@device_cm_{33D9A762-90C8-11D0-BD43-00A0C911CE86}\wave_{4CFE616A-B674-474C-B539-907085A96B08}" ffmpeg version N-91317-gb41b6b3234 Copyright (c) 2000-2018 the FFmpeg developers built with gcc 7.3.0 (GCC) configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --ena…

拡張編集と Shift_JIS

PSDToolKit を作っていて「ダメ文字」問題と向き合うことになったので、思い出がてら記録しておく。

拡張編集は多くの箇所で MBCS 文字列を使っていて Lua スクリプトでも Shift_JIS が使われるので、例えば
A = "サシスセソ" みたいなスクリプトはそのまま記述されると上手く動かないことが容易に予想できる。

ところが、実際にはテキストオブジェクトに
<?mes("サシスセソ")?> と書くと上手く動き、
<?dofile("test.lua")?> として、test.lua の中に同じ内容を書くと、こちらは動かない。

内部で何が起きているのかを知るのは簡単で、ダブルクォートの代わりに
<?mes([[サシスセソ]])?> このようにすると、画面には
サシスセソ\ と表示される。

つまり、拡張編集では拡張編集が用意したダイアログ内に入力されたテキストに対しては独自にダメ文字対策を行っていて、その対策方法は恐らく単純に「ダメ文字を探して \ を足す」という形で行っているので、実際にエスケープする必要があるかどうかに関係なくエスケープしようとした結果、画面に「サシスセソ\」と出た。

この方法は変なことをしようとしなければ概ね上手く動くので大抵のケースでは問題にならないし、誤ってエスケープされたものも余分な \ を消せば復元できるので大きな問題にはならないはずだったが、PSDToolKit の特殊な事情により厄介な問題に発展した。

やりたかったことは、文字列をクリップボードにコピーしておいて、拡張編集のダイアログや *.lua ファイル内に貼り付けて使う、というだけの処理だった。

何が問題なのかというと、コピーした時点ではどちらに貼り付けようとしているのかがわからないので、貼り付けられた場所次第で得られる文字列が変わってしまう。
最初は「こっちからの場合は \ を消して……」みたいな場当たり的な措置でお茶を濁そうとしたのだが、置換処理が結構な回数必要になるし、気をつけて扱わないとすぐ事故る勢いだったのでこれはまずいと思ってアプローチを変えることにした。

対策は単純に「ダメ文字が出てこないようにする」というだけ。

処理の都合上、元々文字列では Unicode…