guvcviewが動かなくなったのでffmpegでキャプチャする方法を調べてみた
先日、guvcviewで動画が取れることが分かったので、定期的にギターの練習動画を取ってみて、モチベーションを上げようと思っていた。
これがそのときの動画。
PCに付属しているWebcamでは角度の調節が難しかったので、LogicoolのC270というやつを購入した。 また、Ubuntuが15.04のままでセキュリティ的にまずい状態だったので、15.10に上げてみた。
その後、気がつくとguvcviewでキャプチャできなくなってしまった。
cheeseではちゃんとキャプチャできたので、guvcview側の問題っぽいけど、よく分からなかった。
cheeseはJACKに対応していないので、PulseAudioかALSAを使わなければならず、あまりカスタマイズもできなさそうだったので、他の方法を模索していたところ、ffmpegコマンドでキャプチャできるということが分かった。
ここからffmpegのオプションと格闘することになるのだが、結果から言うと以下のオプションでうまくキャプチャすることができた。
ffmpeg -f video4linux2 -s 640x480 -i /dev/video1 -f jack -i ffmpeg -acodec pcm_f32le -vcodec yuv4 -y test.avi
JACK側から見るとffmpegというデバイスが見えるので、そこに向かって録音したい音をつなげてやればよい。 acodecとvcodecで圧縮させるとCPUパワーを使うため、このPCでは処理落ちなどが発生し、あまり使いものにならなかった。
acodecはJACK側がf32leだったため、それに合わせてみた。コンテナは.aviにしたが、他にもよいものがあるのかもしれない。
acodecがlibvorbis、vcodecがmjpegまたはmpeg1videoならほとんど処理落ちしなかったが、どうせ後で変換するのだし、ストレージは割と余っているので、上記オプションとなった。
最後に ffmpeg -i test.avi test.webm とかで小さくして、保存するなりアップロードするなりすればよさそう。
ALSA/PulseAudio/JACKのメモ
しばらく触っていないとすっかり忘れてしまうのがオーディオ周りのALSA, PulseAudio, JACKの設定など。
まず最初に ~/.config/pulse/client.conf に autospawn = no を書き、PulseAudioの自動起動を無効にする。 (この設定はログインしなおす必要があったと思う。killでもいけたかも。)
追記: pulseaudio -k で kill できる。
次にALSAのデフォルトを無音のループバックにして、デバイスをALSAに占有されないようにする。
デバイス一覧は aplay -l で表示できる。 alsamixergui -c 1 のようにカード番号を指定してミキサーを表示する。
/usr/share/sounds あたりに .ogg ファイルがあるので、これでいろいろテストできる。 特にCD品質な desktop-login.ogg が扱いやすい。これを sox で.wav に変換する。
$ sox /usr/share/sounds/ubuntu/stereo/desktop-login.ogg /tmp/desktop-login.wav
なお、CD品質に変換するには -b 16 -c 2 と rate 44100 を指定すればよい。
$ sox bell.ogg -b 16 -c 2 /tmp/bell.wav rate 44100
まずは hw を直接指定して aplay で音を確認する。事前にでかい音が出ないように alsamixergui で調整しておく。
$ aplay -D hw:1,0 /tmp/desktop-login.wav
次にこのデバイスに ~/.asoundrc で名前を付ける。とりあえず内蔵カードなので pc という名前にしておく。
pcm.pc {
type hw
card 1
}
動作確認。ログインしなおしたりする必要はない。
$ aplay -D pc /tmp/desktop-login.wav
あとは !default をループバックデバイスにする。rateやipc_keyは状況に応じて変更する。 詳しくは覚えていないが、今は以下のようになっている。
pcm.!default {
type plug
slave {
pcm "ploop"
#rate 44100
#rate 8000
}
}
pcm.cloop {
type dsnoop
ipc_key 18485
slave.pcm "hw:Loopback,1,0"
}
pcm.ploop {
type dmix
ipc_key 18486
slave.pcm "hw:Loopback,0,0"
}
JACKとの連携用の設定もしておく。これもあまり覚えていないが、以下のようになっていた。
pcm.jdefault {
type plug
slave {
pcm "jack"
#rate 44100
#rate 8000
}
}
pcm.alsajack {
type jack
playback_ports {
#0 system:playback_1
#1 system:playback_2
0 "jack_mixer:alsa L"
1 "jack_mixer:alsa R"
}
#capture_ports {
#0 system:capture_1
#1 system:capture_2
#}
}
pcm.jack {
type plug
slave { pcm "alsajack" }
}
JACKからこのループバックデバイスが見えたら、JACKに対応していないアプリ、例えばChromeなどからの入力を扱うことが可能となる。
参考にしたサイト
Go言語でBitcoinの署名を検証してみた(その1)
最近はGo言語のトレーニングをしていますが、慣れていないので結構大変です。 早くいろいろと記憶して楽になりたいです。
ところでgocoinというソフトがあり、その中にsecp256k1というライブラリがあったので、これを使ってBitcoinの署名を検証してみました。
GitHub - piotrnar/gocoin: Full bitcoin solution written in Go (golang)
gocoin自体は非商用利用可のライセンスのようですが、secp256k1はMITライセンスとなっておりました。 gocoinのbtcというのを使えば簡単ではあるのですが、MITライセンスの方がよいので、とりあえずsecp256k1だけを使ってみました。
今のところ、このコードでは公開鍵のhex列がないと検証できませんが、一応動いております。 署名の形式もチェックしていないので、古いクライアントで署名したものだとうまくいかないかもしれません。 ちなみにこのテスト署名はElectrumを使って署名したものです。
Bitcoinアドレスは公開鍵そのものではなく、公開鍵のハッシュ値なんですね。 だからこんなに短くできるのかと納得しました。
Bitcoinアドレスで検証するためにはどうやら署名から公開鍵に戻して、そのハッシュと比較するようです。 今回は疲れたので、このへんでやめときます。
暗号通貨を使ったプロトコルを考えてみる
ここ何日か暗号通貨を使ったサービスを考えていたが、結局のところどのようなサービスでも共通している部分はプロトコルにしてしまった方がよいのではないかと考えるようになった。
なんとなく考えているイメージは以下のようなもの。
- 基軸となる暗号通貨を決める(Bitcoin, Altcoinなど)
- メッセージングのプラットフォームを決める(メール、Web、専用アプリなど)
- 複数サポートもあり
- メッセージングのデータフォーマットを決める(JSON, MessagePackなど)
- 受付用のウォレットアドレスを決める
- 公共・分散的なものの場合はスパム防止の意味でProof of Burnを選択
これらのパラメータは各々のサービス提供者が決めればよい。
あとはサービス提供者が受け取ったメッセージをどのように扱うかというところ。
サービス利用者は専用のウォレットアドレスを1つ決め、メッセージに対して署名し、サービス提供者に渡す。通信経路が暗号化されていない場合はオプションで暗号化してもよい。
場合によっては利用者に対して返信する必要があるので、そのようなメッセージングプラットフォームを選択するか、もしくはウォレットアドレスで暗号化してWebなどでブロードキャストしてもよい。
サービス提供者は受け取ったメッセージを検証し、問題なければメッセージに書かれている要求内容を確認し、入金などの条件を満たしておればそれを実行するといった感じ。
例えば以下のようなサービスが考えられる。
- ストレージの提供
- 計算資源の提供
- 翻訳
- 広告
現状ではこれらをまとめて簡単に構築できるようなフレームワークがないと思うので、いつか作ってみたいと考えている。
ブロックチェイン上でKVS(Key-Valueストア)が使えるBlockstoreを調べてみた
Qiitaの記事で言及のあったBlockstoreというやつを調べてみました。(試してはいません。)
これはどうやらストレージ自体はブロックチェインに置かずに別のDHT(分散ハッシュテーブル)に置くようです。 ブロックチェインはBitcoinを使っており、おそらくハッシュ値だけを記録しているものと思われます。
ドキュメントを読んだ感じではNamecoinをかなり参考にしてそうな感じで、名前(name)の登録手順は似ていました。 Namecoinは独自のブロックチェイン上にデータを置いていましたが、BlockstoreはDHTに置くという違いがあります。
名前空間(namespace)の登録もできるようですが、0.4BTC以上と結構お高いので、普通は最初から用意されている .id という名前空間を使うことになりそうです。 例えば ohac.id みたいな感じでしょうか。名前空間上には名前空間の保有者でなくても名前を登録することができるようです。
名前は長さや記号の有無などでコストが変わるようで、長い文字列なら250uBTCで済むようです。 これらのコストは下記のProof of Burnのアドレスに送られるようです。
https://blockchain.info/address/1111111111111111111114oLvT2
1つの名前にはJSON形式でデータが保存でき、サイズの上限は8KBとなっているようです。
問題はDHTノード群をどのように維持していくのかといったところかと思います。
FAQを見たところ、現状ではノードを走らせるためのインセンティブがないようです。
Sybil attackも可能なようなので、DHT上にはいくつか冗長保存されるとしても少し安心感に欠けるように思います。
追記: Sybil attackについてはhttps://en.wikipedia.org/wiki/Kademlia#Next_generationに言及あり。
どの程度冗長保存されるのかまだ調べておりませんが、DHTノードだけを独立で走らせることができないのであれば各ノードはBitcoinの数十GBとDHTの両方を保存するためのストレージが必要となり、なかなかお気軽にノードを立ててみようとは思えないです。
追記: https://en.wikipedia.org/wiki/Kademlia#Locating_resources に少し書いてありました。具体的な数値はパラメータによるのかも。
このあたりがもうちょっと改善されればよさそうですね。
1,000円分のビットコインをamatenに入金してAmazonギフト券を買ってみた
amatenでAmazonギフト券などがビットコインで買えるとのことなので、ちょっと試してみました。
まずは最初なので1,000円分の入金を試してみたところ、0.01952744BTCの請求がありました。 このときのcoincheckでの相場が51,405円から51,424円でしたので、1,003.8円から1,004.2円程度の価値だったと思います。 まだ1回しか試してはいませんが、0.5%ぐらいの手数料に相当すると考えておいてよいのかもしれません。
30分以内に送金を済ませる必要があるようで、すぐにElectrumから送金してみました。 リンクが表示されていたので、そのリンクをコピーし、Electrumの送金アドレスの部分にペーストすると金額も込みで自動的に入力されました。
ネットワークへの送金手数料は大体10円ぐらいなので、トータル1015円程度のコストだったと思います。 金額がもっと大きければ送金手数料の比率が下がるので、頻繁に使うならもっとまとめた方がよさそうです。
amaten側では割とすぐに入金確認が完了し、ギフト券が買える状態となりました。 試しに250円のギフトカードを240円で買ってみました。4%オフですね。期限は2016/12末でした。 これで1,000円分買ったとすると、40円余るので25円程度お得だったということになります。
Amazonだと4%オフぐらいですが、iTunesだと12%オフとかもあるので、iTunesユーザーだと結構お得ですね。
monacoindを走らせつつbootstrap.datを共有するVagrantfile
作りました。
config.vm.box = "ubuntu-14.04"
の部分はお好きなboxをご指定ください。(Ubuntu 14.04系ならだいたいいけると思います。)
A list of base boxes for Vagrant - Vagrantbox.es
bootstrap.datはDropboxに置いてまして、それをWebseedで指定しています。 ノード提供にご協力いただけたらありがたいです。 ポートは6999で設定しておりますので、これを公開していただければさらにグッドです。 あと、その場合はついでにmonacoindのポート9401もお願いしたいです。
ちなみにbootstrap.datを使うよりも普通に接続した方が高速という見解もあるみたいですが、ノードの場所や数、性能、通信環境によってはそうとは言い切れないように思いますので、私としては今もbootstrap.datを支持しております。実際、MonacoinやDogecoinを試しに普通に立ち上げてみたところ、ものすごい時間がかかったため途中であきらめました。BitTorrentクライアントはmonacoindのようなフルノードを動かすよりも少ないリソースで簡単にマルチプラットフォームで動くので、ついでに動かしておいて損はないように思います。
次回はElectrumサーバをセットアップしてみたいですね。
