So-net無料ブログ作成
プログラミング ブログトップ
前の10件 | 次の10件

CSRFを今更ながらお勉強 [プログラミング]

いまいち分からなかったんだけど分かるまで読んでわかった。CSIRTの話でCSRFの話が出てきて、XSSとかはなんとなくしっとるけどCSRFは良く分かっていなかったなと思い出し、ググって理解した。まぁ今はCSRFもサイトが対応して出来ないようにはなっているのだろう。

そういや、猫に証拠をつけて結局見つかってしまった犯罪者がいたが、あれはCSRFを使って第三者に掲示板に書かせたんじゃなかったっけかな。そいつがつかまって終わったのだけれど、悪いのは誤認逮捕した警察と、CSRFの脆弱性を作っていたサイトの運営者じゃないかと思う。その後、警察とサイトの運営者を相手取って訴訟したって話は聞かないけれど、アメリカだったら確実に金を取りにいく事象だと思ったりする。

https://ja.wikipedia.org/wiki/%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3%E9%81%A0%E9%9A%94%E6%93%8D%E4%BD%9C%E4%BA%8B%E4%BB%B6

ん~CSRFというよりワームの感染だな。C#で書いてあって書けないとかいっていて、書けましたと自白したんだけど、出来合いのものなど使って実際コーディングしたのは少しだろうから、書けませんというのもあながち嘘ではないのかもしれない。まぁ一からスクラッチは出来ません、という意味の書けませんですが。

CSRFが可能だったサイト以外はワームの仕業ということになろうが、IPアドレスだけを頼りにしていた安易な捜査はあからさまにIT音痴を露呈させたといえるだろう。そういう意味では、警察を相手取って訴訟ということも出来なくはないだろうが、他の冤罪も無罪になっても実質的に泣き寝入りになっていることからも、官憲にたてついても無駄だと言われているのも同じだ。完全に冤罪をなくすことは出来なくても断罪できないというのは、冤罪を許す温床になっている。

ITをイット呼ばわりした森元総理だが、オリンピックでサイバー犯罪を危惧しているようなことを言っていた。元総理は中身を分かっての発言ではないことは容易にわかるが、実際サイバー攻撃でかく乱されることは創造に難くない。にしてもCSRFで意図しないで加害者になるのは勘弁して欲しいものである。わけわからんURLが張ってあるスパムメールとかたくさんあるもんなぁ。


話はCSIRTに戻りますが、CSIRTを構築しないといけない友達がいて、色々ググってみたものの明確なノウハウとかは出てこない感じでした。まぁセキュリティインシデントをどう管理して報告するかという話なんだけれども、まぁ攻撃に対する対策ってのも面倒くさいよねというところで。

https://www.jpcert.or.jp/

・フィッシングサイト
・Webサイト改ざん
・マルウエアサイト
・スキャン
・DoS/DDoS
・制御システム関連
・標的型攻撃

の報告が主になるようだけど、スキャンの話だとアクセスログを見るしかないよなとか、フィッシングサイトとかマルウェアサイトとかは通報するしかないよなとか、色々考えましたが実際に何使うんだか良く分からないので適当にうっちゃって終わりにしました。

プログラマ的に面白いなと思ったのは、
https://www.jpcert.or.jp/research/materials.html
こういう情報ってわりと少ないんだよね。あるのかもしれないけど、バッドノウハウとして累積されたものがあるかといえば、そんなになかったりしたり。

世の中、動きゃいいって節があるから、テクニカルの更に先にあるセキュアなところってのはおざなりにされる。実際MSやAdobeの例があるしね。Oracleでもいいけど、長くソフトウェア業界に君臨していれば何かしらあるわけで。

結局、一番多いのが文字列のバッファオーバーフローかよというオチだったりするわけですが、C言語なんて長々と使っているからプリミティブなプログラマ任せの方法しか取れないんだよね。まぁWebシステムをガチでC言語だけで組むということはないにしても、C言語で作られたツールを使うことはあるわけで、セキュアな脅威は言語レベルで存在してしまうという状態ではあります。

まぁC言語は組み込みから使える言語だから、自分で全部制御してどうにかする文化があるといえばあるんだけど、そろそろパソコンサーバのツールはスクラッチするものはC言語以外で書いたほうがいいんじゃないかと思うんだけどね。そこまでメモリの消費量を気にしたり、メモリを細かくいじったりすることってのも正直なくなってきているとは思うんだけども。

正直、文字列の長さなんていちいち文字数を気にしていられっか、と。大抵の言語はstring型があるので、標準ライブラリに問題がない限りはそこが脆弱性につながることはないと思われ。あったとしても一気にふさがれるので他の言語で気にしないといけないことってのは少ないかもですね。

ここでNTBSという言葉が出てきたんだけど、Null-Terminated Byte Stringの略でした。別にこんな言い方しなくてもC言語の文字列と言えばいいだけの話だと思う。まぁ\0で終わるよという話です。そのヌル文字で翻弄されるわけですが面倒ですね。

結局、強制的に文字列の配列の最後にヌル文字を入れるとか、そもそも
用意したバッファより大きいものはコピーしないとか、ヌル文字のために
文字列を一文字引いた長さにするとか、そういう対策になるらしい。
まぁいちいちチェックするのは面倒くさいよね。


C#やったんだけどWPFってすごいメモリ食うんだね。まぁGUIはそこそこメモリ食いなのは仕方がないけど、スケルトンのプロジェクト実行するだけでも100MB弱メモリを消費していた。昔はそれほどメモリを消費していなかった気がするんだけどなぁ。.NETはみんなこんなんだろうか。

コメント(0) 

最近停滞中。C#今頃やって見た [プログラミング]

というか、半年ぐらい停滞中なんですけどね。まぁやることがないというか、ないことはないがおおっぴらに出来ないというか。とりあえず、昼間の眠気はどうにかならないかなと思うのだけれど、慢性の病気の薬の副作用なので止めるわけにもいかず、カフェインで眠気止めをしているのはしているのだけれど、根本的な解決になっていないのであった。やっぱ何もすることがないと眠くなるよねぇ。

お盆休みに甥が来て土日がドラゴンボールの対戦で結構削られた。接待ゲームなので程よく負けないといけなくてちょっと面倒。あまりに気を抜きすぎってのもどうかと思うし、なるべく接戦に持っていこうとしているのだが、甥はあんまり気にしていない模様で勝てればいいという感じ。まぁまだ小学生低学年だもんなぁ。

友達がC#をやろうとか何とか言う話になって、色々調べたんだけど結局VB6のツールが動かなくなったり新規開発するときにはどうするんだということになったらしい。というか、まだVB6の実行ファイル動くねんなw。まぁWin32APIも現役だと思うので、動くのも当然なのかもしれないけど、作り直すのも労力がかかるので動かなくなるまで放っておきたい気持ちも分かる。

とりあえず、Visual Studio 2017を入れているがそこそこ時間がかかる。まぁ昔から開発環境のインストールは時間がかかるものと相場が決まっている。Eclipseみたいにディレクトリをぽいと置けば済むというものでもないし、最近のEclipseは普通にインストーラで入れるのは常道か。

やっぱりプログラミングは開発環境を入れて実際に動かして何ぼなので、友達の仕事とはいえやってみないことにはあまり無責任なことは言えない。ただでさえ環境が違ってこっちでは動くのに、他では動かないということは頻繁に起こることだし、実際に動作を確かめるってのは大切な作業ではある。テストしなくたって動けばそれで足りるんだし、最低限の確認事項ではあるわな。

最近のWindowsアプリといえば.NETがデフォルトでしょうけど、UWPっていう更に広い範囲で使えるものを作れるものが出てきた。スマホでも使えますよというものなので、正直あまり期待してはいないのだが、色々なところで使うのに作り直さなくていいのは助かる。助かるが、そういう用途があるかというとまた別で、汎用性があった方がいいな程度のものであったりする。

UWPはタッチインターフェイス優先だろうから、あまり凝ったものは作りにくいだろうなとは思う。マウスと指のオペレーションは根本的に違うからねぇ。一本化できるというだけでありがたいと思うべきなんだろうけど、それが嫌だったら今までのスタイルを貫き通せばいいというだけなんでしょうけど、貫き通す.NETの資産はないしねぇ。多くの業務アプリはWebインターフェイスになっていたりするのだろうし。

更に進んだところに、.NET Coreみたいなのがあるらしい。互換性を高められそうだけれど、やっぱり基礎的な部分にとどまりそうな予感。やっぱりGUIとかが絡んでくるととたんに互換性や移植性は落ちるのが常ですし。というか、MonoだとかCoreだとかちょっと一般的にある単純すぎる名前で分かりにくい気はする。

Windows10同士はいいにしても、もうクローズに向かっているWindows7とかは気にされていないんだろうな。まぁそれも使いたい場合は前の方法によるしかないというか、そもそもUWPの範囲に入っていないんだろうな、詳しくは知らないけど。Windows7が終わる前にWindows10は安定するだろうか。ダメかもしれないけどUWPをWindows7でやってみようと思う。まぁ本番でアプリをぶち込むわけじゃないからいいや。


これを書いたり色々なことをしているうちにもう少しでVisual Studioが入りそうです。昔はCDとかのメディアで入れていたものですが、最近はみんなネット経由で帯域を贅沢に使っていますね。というか、光学メディアでリリースするよりか手間もメリットもあるんで、無料でもリリースできるようになっているんでしょうね。今でもOSインストールメディアで、そこそこでかいファイルをダウンロードしないといけなかったりするけど、それでも最低限のファイルで後は後でこまごまダウンロードというケースがほとんどだと思います。

昔はインストール中は保障しかねるので作業しないでねといわれていましたが、最近はそういう話は聞かない。作業をしてもいいよって言うダイアログが出た時代もあったけど、メニーコアが普通になった今としてはインストール中に作業を止めること自体が少ないかもね。昔は休む口実になっていたんだけど、今は少し遅くなるくらいで作業は並行してできるので厳しい世の中になりましたw。

まぁインストール作業自体、コンパイルでもしない限りはシングルスレッドで動くものだろうから、他で影響を受けるのはストレージがバンバン使われて遅く感じるくらいでしょう。メモリが潤沢であれば、少々書き込み読み込みが発生したところで、SSDであれば気にならないでしょうね。どんどん休む口実がなくなって、手を動かす時間が増えて考える時間が減っている気がするんだけどどうだろう。立ち止まって考えるってのはプログラマには結構大事だと思うんだけどな。休む言い訳としか聞こえないだろうけど。


公式サイトのチュートリアルを見てダラダラやってみている。VB6と大きく変わってはいないところもあるだろうなとは思っていたが、基本的なところはすべて変わっていたといっていいのかもしれない。C#でやったのだけれどXAMLとCSファイルが紐づいているとか、CSファイルの名前を変えるだけでXAMLのなかみをコーディングしないといけないとか、初期の部分でかなりだるい感じで、VB6の方が楽だったと感じる部分も多かったりしました。

大まかなインターフェイスは似ていて、設計図のダイアログのボタンをダブルクリックすると、コーディング部分に飛ぶとかは基本的に同じで、良くも悪くも変わっていません。そういうところまでは変えていないけれど、内部的なところは全然変わっている感じ。

まぁVB6自体が前世紀の遺物なわけで、時間がかなり経っている時点で変わっていて当然なのですが、.NETだからといってわけの分からないほどには変わっていないのではないかと思いました。VB6にあたるWin32APIぐらいの深さを探ると面倒も出てきそうですが、基本的に既存のAPIは.NETのツリー上に存在するんでしょうし、前できたことはできるというのが普通だと思ってはいます。無くても何らかの代替案はあるんでしょうし、Deprecatedになっていたとしても何とかはなるんでしょう。

やってはみたものの特に与えられた御題があるわけでもないので、暇をつぶすだけで本人的には実害がないです。友達の会社で問題になるかもという爆弾なだけで、VB6アプリがWindowsプラットフォーム上で動き続ける限り問題ありません。というか問題があっても自分には関係ないのでお気軽に検証してみただけです。

その前にVB6だからVB.NETにすべきかとか、マイグレーションツールは上手く動くものなのかとか、色々考えることがあったのだけれど、一般的な傾向でC#でやるのがいいのだろうという方向にはなっています。人的リソースが少ないのであまりマンパワーをかけたり冒険ができないところなので、なるべく移行における被害が出ないようにしないといけないわけです。まぁ作った人がずっといるとは限らないからねぇ。いなくなっても他に保守する人がいればいいけど、そういうわけでもないしなぁ。マイグレーションってのはどこに行っても頭の痛い問題だったりします。

ただVB6のサポートが終わると言われてから、10年近くは経っていると思うので、案外ずっと使い続けられそうかもなと思ったりもします。ほとんどが64bitOSになった今でもWin32がなくなるわけでもないですし、代替となるプラットフォームがいつまでも磐石とはいえないですしね。まぁあっさりきられるテクノロジーもあるわけですが、メジャーなところだと文句が出まくるので、何とか延命される運命にはあるようです。現在のWindows10でもランタイムがあって動くようですが、どこまで延命されることか…。

ただ、あまりに延命されるとほぼ作り直しという面倒が待っているので、いい加減のところで舵を切ってもらわないと結局みんなが困るという状態になるんだろうなと思ったりします。IE6あたりでの切り替えの問題のように、それだけでもインパクトがあったので相当ソフトランディングさせないと厳しいとは思いますがね。

コメント(0) 

あんまり進捗がないHandbrakeでのNVENC組み込み [プログラミング]

NVENCのNvEncoderをHandbrakeに組み込めばお気楽に使えるんじゃないかと思って色々やっているんですが、なかなかうまくいかず。まぁそんなもんだよなぁ。でも、先行でQSVが実装されているので、それを利用すれば良い感じ。結構色々流用できそうな様子。というわけで、色々パクって色々コピペで済ませたいw。

EVNECは生のYUVを変換しているのだけれど、Handbrakeは生のYUVファイルは変換できなかった。できたとしたら、もうそのまま突っ込んでMP4コンテナに乗せるだけなんだけどな。とりあえずHandbrake側のYUVの変換部分と、NVENCの擦り合わせはある程度行わないといけないみたい。まぁ大体はYUV420ベースの扱いが多いので、色々何とかなるだろう。

そもそもNvEncoderでh.265に変換できるんだけど、MP4コンテナに載せない生の状態のH.265なので、MP4BOXで変換できるかどうかを調べておきたい。MP4Box -add test hoge.mp4でエラーが出た。

[MPEG-2 TS] TS Packet 968 does not start with sync marker
[Importer] Unknown input file type for "test"

とか出てくるんだけど、返還前のファイルの拡張子を.hevcにリネームしたら問題なくmp4ファイルを出力できた。
MP4Box -h format
でなんとなくつかめた。

基本bitstreamは一般的なものらしい。最悪、MP4Boxからソースを持ってくればストリームからmp4を生成することはできそうだ。まぁQSVと全く同じストリームの形式だとしたらそのままパクれて楽できるんだけど。

とりあえず、NvEncoderをデバッグで発動して、パラメータの中身を確かめておきたい。まぁ大体はソースでわかるんだけど、実際のものを見たほうが確実だし、新しい発見もあるかもしれないからね。

でも、デバッグができない。前はEclipseでステップ実行とか出来たんだけどな。Handbrakeのソースあたりでもできたはずだった。perspectiveにもファイルが出てきているのに、ファイルの行をダブルクリックしてもBraek Pointを張れず(張れているみたいだけど有効じゃない)、コンソールに

No source file named ファイル名


と出てきてしまう。これには大前提を忘れていてg++に-gオプションを入れないといけないらしい。
http://futurismo.biz/archives/1211

NvEncoderのサンプルファイルのMakefileでは
# Debug build flags
ifeq ($(dbg),1)
      CCFLAGS   += -g
      TARGET    := debug
else
      TARGET    := release
endif

とあるので、Eclipseのプロジェクトのプロパティのところの「C/C++ Build」の「Build command」に
make dbg=1

でブレークが張れるようになる。とにかく-gオプションを入れれば、Ecilpseではデバッグできるようになる。というか、そもそもgdbを使うんだから、デバッグ情報を入れなきゃならないのは当然だったのでした。というか、サンプルなんだからデバッグオプションぐらい張っておいても良さそうなもんなのにね。handbrakeの時は自分で-gオプションつけたのかな。まぁ解決したから先に進むだけだ。

タグ:NVENC
コメント(0) 

コンピュータ言語食い散らかし3 Ruby [プログラミング]

最近はそんなにやってないけど思い入れが大きい言語Ruby。

Rubyはかなり思い入れのある言語です。その割には空で書けるほどやっていないですね。大体のライブラリは使えるのですが、ほとんどRailsに使われていた時間が多いです。そのため、一般的なプログラミング能力が高まっているとは言えません。

ともあれ、本だけはたくさん持っているのでそこそこは読みました。関連でまつもとゆきひろさんの著作もちらほら読みました。やっぱり日本人が作った言語という切り口から入ったので、原作者の存在は大きいです。以前、何かの宗教活動をなされていたらしいですが、図らずとも自分で書いた経典の方が有名になっちゃったパターンになりますね。

日本人が作ったということで、英語偏重になっているプログラミングの世界としては学びやすいというところがあって、英語を曲りなりに読めてしまう自分としては時間が短縮し、オライリーとかの翻訳本を読まなくていいところは、ダイレクトに入ってくる部分は多かったです。他の人が曲解している部分が入りづらいとか、自分で英語を読む時に誤解してしまう面が少ないのは素直にありがたかったです。


しばらくするとRailsブームが来て世界的な言語になりましたが、正直Rubyを使っているというよりRuby on Railsのスケルトンの使い方を学んでいる感じがしました。今でも中身がどうなっているか細かいところまで理解はしていません。

そもそもSQLなどを使わず、ある程度名前の付け方などを固定して楽するというライブラリだと思っているので、逆に中身を全部知っていこうとする行為は、Rails本体を開発するのでもない限りはあまり重要で必要ではないのかなと思ったりしています。知っているには越したことはないけれど、それをするんだったらもっと簡単なフレームワークでSQLを自分で発行するようなものを作ってみたほうがいいと思ったり。


正直、Pythonに差をつけられた感はあります。Googleで採用された時には、どうせPaaSで使えるだけだと思っていましたが、近年の人工知能ブームでLLどころかプログラミング言語全体の中でも重要というか良く使われる言語となっているようです。実際、デフォルトでディストリビューションにインストールされていたし、ユーザーランドで使うツールがあれば実行環境も入れないと話にならないわけです。

自分が始めたころにはLLとしてPythonとはどっこいどっこいではありましたが、科学技術系の計算などでCUDAが使えるようなところから、機械学習で非常にもてはやされているところです。そういう用途としてはRubyがいいという話は聞きませんし、今後もそういうこともないでしょう。とはいえ、名目上の上限がない大きな数を扱えるとか、数を扱うのに適していないわけではないのでしょうが、動作速度が云々言うような処理には一向に向いていない傾向は、LL言語らしい傾向なのでしょう。基本DBのフロントエンドというか。

買った本はRailsものが多いのですが、面白かったのは人工無脳、Web検索エンジン、などがあります。一番多いのが逆引きのHow To的なものですね。実際使うにあたってググらなくてもまとまっている本があると楽という安直な理由ですw。Rubyの逆引き物は結構いっぱいあるのでググって見てください。頻繁に使う人は楽できると思います。

恋するプログラム―Rubyでつくる人工無脳 (プレミアムブックス版)

恋するプログラム―Rubyでつくる人工無脳 (プレミアムブックス版)

  • 作者: 秋山 智俊
  • 出版社/メーカー: マイナビ出版
  • 発売日: 2016/11/28
  • メディア: 単行本



恋するプログラム―Rubyでつくる人工無脳 (Mynavi Advanced Library)

恋するプログラム―Rubyでつくる人工無脳 (Mynavi Advanced Library)

  • 出版社/メーカー: マイナビ出版
  • 発売日: 2014/12/04
  • メディア: Kindle版



Rubyでつくる検索エンジン

Rubyでつくる検索エンジン

  • 作者: 星澤 隆
  • 出版社/メーカー: 毎日コミュニケーションズ
  • 発売日: 2009/05/26
  • メディア: 単行本(ソフトカバー)



ただServerSpecとかChefがRubyで書かれていて、そういう設定系のツールがRubyで操れるというところはいいなと思っています。内部DSL関係はRubyが浸透させたと思いますし、他のものはどうか知りませんが書きやすい気はします。まぁこれは書き慣れているというだけかもしれませんが、そこまで活躍してくれてないのも実情だったりしました。DRYとかもRubyでの啓蒙が大きいでしょうが、自分はI Repeat Myselfな人間なので改めないといけないなとは思っていますが、コピペの癖は抜けず…。capistranoとかもRubyだったな確か、あんま使ってないけど。


Pythonと違ってバージョン間非互換が少なくていいなと思っていましたが、Pythonも大方Ver.3に移行してきているので、それ自体はそんなに問題とならなくなってきているのでしょう。書き換えはコミュニティ全体が盛り上がっていれば誰かがやってくれることが多いですしね。使われないコードはなくなるだけですが、自分が依存していると悲しい運命になったりします。

後ろ向きな互換性の解消のコーディングは、新しい機能追加と共にやってモチベーションを上げたりするのですが、最近なかなかしんどくてコーディング自体あんまりしていません。大体のことはみんな誰かがやっていたりするので、そこをチョコチョコつまんで事を済ませてしまうことも多いです。まぁ外向きのシステムでない限りは、 rbenvとかで塩漬けすればいいんですけどね。

何かRubyで書きたくなるモチベーションが上がるトピックないかなぁ。

コメント(0) 

コンピューター言語食い散らかし2 Swift [プログラミング]

ネタがないので最近やってるコンピュータ言語で考えていることとか状況。


・Swift

OSSになったAppleが作った言語。はじめはOSSにする気はさらさらなかったらしいけど、周りからの多くの要望によってOSSにせざるを得なくなった。当時は結構揉めた気はしたが、OSSになったからと言って大して盛り上がっていない気がします。Swift3になってMacでの開発も落ち着きつつありますが、どうにも以前との互換性がなくなった分、前のソースがそのまま使えないというのは学ぶのにしんどかったりします。

SwiftがOSSになったのはいいものの、Swift自体がGUIを前提に作られたもので、コマンドライン用のライブラリがきちんと整備されていない。あるにはあるのだけれど、Core Foundationとしてかなりベアな形でしか存在していない。その上、GUI部分がOSS版には用意されていないところが発展途上なところだった。少なくともCore FoundationからのFoundationがスタブ(?)的にありはするけど実装はされていない状態では使いようがない。

今も大して変わっていないとは思うけど、恐らくは言語仕様を実現させるぐらいが関の山なのではなかろうか。OSSとして成立させるためには、他の言語と同じようにコンソールで動く標準ライブラリを充実させる必要があるだろう。そうじゃないと他の言語同様に使えない。とりあえず動きますよ的なポーズで終わってしまう可能性がある。

言語使用的には強制的にエラーチェックをしないといけないとか、バグの出にくい体制にはなっているものの、面倒くさがって避けてしまったらたいした違いはなかったりする。ただどうせ回りくどいんだったらチェックしてしまおうという気にもならなくもない。

よく考えたらこの言語で特徴的なのはこのOptionalの部分ぐらいのものかなと感じる。他にはLLにはあってもコンパイル言語にはあまりなかったところとかが新しいくらいで、既存の言語にはあるものを全部乗せした感じではある。型推論、クロージャ、ジェネリクスなどは他の言語にもある。全部そろっているかどうかは別だけど、コンパイル言語としてはないものはない感じではある。

ただ他の先進の言語を詳しく知っているわけではないから、現行の言語としては大体あるものはある的な確度しかないんだけどねw。ともあれ、こういう風にきちんと建て増しっぽくない状態で提供されるというのはいいことだろう。


建て増しで思い出したが、前のObjective-CはC言語にクラス部分を建て増していた。そのため切り分けはできていたものの異物感というのは避けられなかった。少なくとも関数とクラスのメソッドの書き方が違うというだけで、言語としての一体感を欠いていたと言わざるを得ない。C++もそうだがC言語からの建て増し感があって、ライブラリを使うための言語になってしまう側面があった気がする。実際、新しい分野や基本的分野で提供されるライブラリはベタな関数だったりするわけで、クラスによって組み上げられているものはそこそこその分野が練れてきている証拠だったりする。

建て増しという言葉がネガティブなら、C言語にクラス機能を付加するラッパーともいえるだろう。C言語自体は各環境が各々持っているアセンブラの違いを吸収するためのラッパー(それ自体ほとんどC言語のみで構成されているかもしれないが)であり、SwiftはObjective-CをLL的に使うラッパーであるとも言えるだろう。Apple的に言えば、Foundationなどを中途半端で古めなObjective-Cから置換するためのもので、これもC言語と同じように完全に置き換えをするものになっているのだろう。

そして後から出てきた言語なので、取ってつけたような異物感はあまりない。そういう意味では先進的というより現代的なコンパイル言語になっている。LLではRubyやPythonのようにいくつか現代的に整った言語は存在するけれども、コンパイル言語ではそんなに多いとは思えなかった。そういう意味でSwiftは格好の的になっていて、OSSとしてリリースさせろとあんだけ要望があったのも、現行でそういうコンパイル言語がほとんどなかったからだろうと思われる。

Linuxにしてもカーネル部分からユーザーランドまでC言語でいいやん的な雰囲気が流れているのは間違いないし、たまにPerlやPythonで書かれているものがあって、バージョン依存があって面倒だなとかいう次元だったと思う。そういう意味ではまともに最近の常識で書けるコンパイル言語というのは、割と貴重なのではないかと思う。それとメモリ処理的に問題となりやすいガベージコレクションを使わないというのも、実行サイズがコンパクトになるという点においては、コンパイルされているという点と同様に重要な点になっているだろう。


正直、OSSは先に言ったようにまだまだです。言語仕様は固まってきているとは思うけれども、使っている人も使われている例もAppleに偏っているのが実情でしょう。Linuxのカーネルに対するディストリビューションと一緒で、言語仕様だけでは使えないので、周辺のライブラリの実装がカギになってくるのでしょうね。

次はあんまりやっていないけどRuby。LLはあんまり好きになれなかったんだけど、これが契機でやるようになりました。

コメント(0) 

コンピューター言語食い散らかし1 Golang [プログラミング]

最近使ったコンピューター言語をなんとなくダラダラ思う。

・Go

スクリプト言語全盛の中で出てきたコンパイル言語。正直LL言語を使っていてコンパイルして速く動かしたいなと思う事がよくあった。それとLLは動作環境を整えないと動かないことも面倒くささが募ったりするし、バージョンの差も気になるところであった。Golangを使ってみて改めてコンパイル言語がいいなぁと思うところがあった。

思ったよりか改善著しい感じで良い。その上、言語仕様が途中で変わったりはほとんどしていないから、あのバージョンのソースが新しいバージョンで動かないとかはあんまりない気がする。バージョンの非互換性というのはどうしても言語が盛り上がれば盛り上がるほど起こってくるものだけれど、最初から標準ライブラリには必要十分なものが揃っていたし、安心して使えるという感じ。

内部的なパフォーマンスもかなり改善しているみたいで、GCとかはかなり著しく改善しているのをどこかで見た。そういう改善ってのは地味に難しいとは思うんだけど、やはりGoogleが作った言語というだけあって半端ない感じはする。正直Googleの言語かよと思っていたのだけれど、一部C言語の代替としてコンパイラ言語としては素養が良すぎる。標準ライブラリはそこそこ癖があるというか、C言語っぽくはないものの、C言語っぽく書ける上に安全で罠にはまらず書けるのはいいのかもしれない。

標準ライブラリ以外のものを使う時もGOPATHのところに突っ込む仕様になっているので、一回やってしまえば日常的に使えるのだろうし、そこのところは面倒なパッケージ管理とかはそんなにない。自分で作ったりするときはどうなのかはわからないけど、そこまでのスキルがあれば問題ないレベルだろう。まぁやれるか面倒かどうかは別の話なんだけど。

OSの中身を書くとか、既存のソースをいじるのであればC言語を始めに学んでもいいと思うんだけど、つまらない細かいしきたりとか仕様とかを考えなくても良い分、GolangをC言語よりか先に学んでもいいんじゃないかと思ったりするんだけど。というかC言語は縛りが少なすぎて、自分で律していかないとダメな面があるので、初心者向けな感じはしないんだよね。言語仕様自体が覚えることが少ない点では、初めての言語として入りやすいのだけれど、訳がわからず動いちゃってる状態が多すぎるし、それ自体がバグになっているケースが多い。それと何をするにも標準ライブラリ以外のもののしきたりを知らないといけないから、環境によって知らなくてはならないことも多くてしんどいとか。

ただでさえ初心者だったらコンパイルが通って動くまで行くのがしんどいのに、実際の動かすロジックに集中させてくれと思う。そういう意味ではGoはそこそこストレスが少ないし、適当にWebからソースを持ってきても動くことが多いので、さくっとオレオレツールを作るのには適している。最近は全部盛りな言語が多い中、覚えることが少ないのは利点なんじゃなかろうか。オブジェクト指向でできることを少しは取り込んでいるし、覚えることが多すぎて使わないものが多すぎるよりかずっとマシだ。というか、C++とか巨大すぎて普通の書き方をしていても、これなんだったっけみたいな事が起こりやすい上に、そんなの知らないという個人の認識の差が大きすぎるのが問題になったりしていた。更に明らかに使い方を間違えている既存のソースを直すのかどうかとか面倒な話になってくることもある。

Golangは最近の動向を掴んで作られているから、初期に言われていたように昔の言語のまんまじゃないですよ。確かにカッコのインデントの位置を強制させるのとかは気持ち悪いけど、まぁ慣れですよね。何にしてもC言語後継のコンパイル言語が出てきてくれてありがたいことは確かだ。まぁC言語はC言語で特定用途で残り続けるとは思うけど。プアな組み込みとか使わざるを得ないしね。


続けてSwiftとRubyを書きたいと思います。

コメント(0) 

Nvidia Video Codec SDK7.1のNvTranscoderをいじる [プログラミング]

NVENCのお勉強の一環として、NvTranscoderをいじっている。元はH.264をH.264とかHEVCに変換するものなんだけど、実はmpeg2も大した改変もなくHEVCとかに変換できた。たぶんNVDECがサポートしているコーデックならみな対応しているんじゃないかなと思う。対応しているんだけど、入力時にH.264しか入れないようになっているので、そこを取り去ってさえすればそのまますんなりトランスエンコードされる。

具体的にはVideoDecoder.cppの114行目

if (oFormat.codec != cudaVideoCodec_H264 && oFormat.codec != cudaVideoCodec_HEVC) {
fprintf(stderr, "The sample only supports H264/HEVC input video!\n");
exit(-1);
}
というところをコメントアウトするだけでいい。ここでいらないチェックをしているから、途中で止まる。少なくとも付属しているplush1_720p_10s.m2vをHEVCにエンコードできたようだ。ただ、今までと同じようにmp4のコンテナに乗っている状態ではないので、そこは別途インプリしないといけない。とりあえずHandbrakeからソースを取ってきて組み入れてみようと思う。

ん〜mpegは結構画像が荒れるな。ブロックノイズどころの話じゃない感じ。VLCとかは細かいブレをチューニングして作られていることが分かる。VOBファイルは途中でエラーが出る。まぁそうだろうね。どちらにしてもMP4化は必須なのでやらないと。

MUX部分だけHandbrakeから持ってこようとしたけど、他のヘッダや何かがかなり入り組んでいて、それだけ抽出するわけには行かなかった。関数だけ引き出すことはできるのだろうけど、それでもHandbrake由来の型が沢山あると思うので、簡単に移植できそうにない。これはHandbrakeにTranscodeのソースを持ち込む方が楽できるかなと思ったり。それにはTranscode側の訳のわかってないところを読み込まないと。もうちっと粘度が低いと思っていたけど、Handbrake自体がかなり色々なものを取り込んでいる上に全体的にはモノリシックな構造になっている。

ってかモノシリックだと今まで思っていた。モノリシックね。lithic自体が岩石関係の言葉でmonoがついているから一枚岩的な意味らしい。日本語の読みやすさで日本語英語ができることって多いよな。シミュレーションがシュミレーションとか、あまりによくありがち。雰囲気をふいんきと読んだりするのも同じだろうなぁ。あまりに頻発するので訂正する気にもならない。まぁ意味が相手に正確に伝わればいいとは思うけど気になる人は気になるだろうな。

そんなわけでmp4boxとか組み入れるなり、外から使うなりしてちょっとやってみたい。その前にHandbrakeに突入しちゃうかもなぁ。cppファイルをそのまま使ってextern"C"して使うか、スクラッチしてC言語のNvEncで始まるAPIを素で使うか、どっちが早くて確実かなぁ。内容をはっきりと理解しなくていいのは.cppファイルのまま渡す方法なんだろうけど、それだと何だかわからないが動く状態になりかねないし、それはそれでいいかなと思う自分がいたりする。目的はHandbrakeを理解することじゃなく、NVENCを使うことなので。しかし、Handbrake久しぶりだな。ちょっとソースが懐かしいとともにQSV関係のソースが加わっていたりする。」

タグ:NVENC
コメント(0) 

Nvidia Video Codec SDK 7.1のサンプルをいじってみる [プログラミング]

Video Codec SDK 8.0は動いてくれなくて、SDK7.1を使ったら動いたという話を以前にしましたが、やっぱり全部は動いてくれそうにないという話。とそれを弄って何とかHandbrakeにつなげていきたい、という地道な作業。

とりあえずNvTranscodeやNvEncodeのサンプルはビルドできたバイナリがきちんと動くことを確かめました。出力されたバイナリもきちんと確認できたし、問題はあってもそこはインプリしていないだけという状態なのがわかって少しホッとしているところ。

エンコードはきちんとNVENCが動いてくれているのはわかったけれど、引っかかったのはNVDECの方。未だLinuxでは動いてくれていない。WindowsではDirectXでのサンプルのビルドが通りきちんと動いたのだが、Linuxと同じくOpenGLの方は動いてくれていない。というか、OpenGL用ではLinuxでは通ったビルドさえ、VisualStudioではエラーを吐いてリンクの時に転んで実行ファイルができない。Windows用のfreeglutとか入れないといけないんだろうか。そもそもWindowsには昔からOpenGLは使えたはずなんだけどな。

http://egolog.hateblo.jp/entry/2016/04/09/212608

で入れ込んだけど、static linkは対応していないとか言われたっぽい。ん〜他のfreeglutとか入れてもconflictなんとかのfreeglut_staticd.lib関係のリンクエラーが取れない。というか、Visual Studioなんだからいろいろ設定して動くようにしておいてほしいんだが…。

とにかくDirectXの方のソースは動いているので、NVDECに渡すところは使えるだろう。でも、ちょっと考えてみたんだが、NVDECってインターレースの処理とかするからGPUでデコードしてCPU側にまた戻して、という処理をしなくちゃいけなくなってしまい面倒な気がしてきた。とりあえずNVENCが使えるところを頑張ってからで後で考えればいいかと思ったのでした。それにTranscodeでh.264に関してはNVDECを使っていると思われるので、そこから掠め取ってくればMPEG2とかにも応用できそうな気はする。ただ渡すパラメーターだけの問題な気はするね、きちんとソース読んでないけど。

そんなわけで、とりあえず今できていないH.265のデータをMP4のコンテナに載せる処理をしてあげないといけない。そこいらの処理はHandbrakeの処理から取ってくる方が後々整合性が取りやすくなりそうだからパクってくる。


NVDECとCUVIDがなんか違うものかなぁと思っていたら、SDKのページにおんなじ物だよと書いてあった。SDKのページはダウンロードに行くだけで全然読んでないなぁ。

https://developer.nvidia.com/nvidia-video-codec-sdk

cuvidという名前はAPIに残ってはいるものの、今はNVDECで良いらしい。ちなみにNVENCの方はcuvid何とかで始まる関数ではなくて、NvEnc何とかという関数になって別箇になってはいる。互換性の問題だとは思うけど、統一性はないわな。別機能と考えられなくはない。

基本NVIDIAのハードウェアCODECはYUVを入出力して加工すると思うので、エンコード前のデコードもGPUでやってしまった方が効率がいいと思われる。GPUでの処理のボトルネックはグラフィックメモリへの転送にあるとは思うので、一気にデータを送ってモニョモニョした方がいいんでしょう。今見ている限りでは、データを意図的にGPUに送るとか単体の関数でやっていないみたいなんだけど、内部的にはGPUのメモリに送ったり戻したりはしているとは思うので、そこを細かくしたい場合はCUDAを使うことになるのかもしれない。

Handbrakeに入れようとすると、MPEG2とかのデータを扱うことになると思うけれども、そこいらのデコードもNVDECでもちろん出来て、そのままNVENCにYUVデータを渡せそう。HandbrakeはQSVのデコードの機能はデフォルトでオンになっていないみたいなので、その分CPUへの負荷は更に軽くなると思われる。なかなかいい感じ。というか、大体の処理がGPU内で終わらせられそうだ。ただし、MP4のコンテナに載せる処理とかはやらないと、動画がDEMUXされたようなネイキッドな状態になってしまうので、Linux以外では普通画像が再生できない。

Handbrakeはc言語で、NVENC、NVDECのサンプルはC++で書かれている。組み入れる時に面倒そうだ。NVDECもNVENCもAPIはC言語の関数になっていると思うんだけど、サンプルがC++で書かれているのは移植に面倒なんだよなぁ。extern"C"すればいいんだろうけど、API自体はC言語で書かれているので、C言語で書き直したほうが早いかもしれない。どっちが楽だろうなぁ。

C言語をC++に入れるのは問題ないとは思うんだけど、逆は気をつけないといけなさそうなのでヤダ。コンパイラも統一できそうもないし結局NVCCでやってた時とそんなに変わらないMakefileの扱いになりそうで今からウンザリ。動けば良いとは思うんだけど、元々あるソースを親子関係にあるとはいえ別の言語で書き直すとかしんどすぎるんですが。ソースそのままで無理やりがっちゃんこした方が、手を加えるのが少なくていいのかもしれない。

HandbrakeはGPUに渡す前までの前処理をすることになるわけだけども、その後のMUXの処理が上手くつながるかどうかが気になるところ。とりあえずTranscodeのソースにMPEG2とかのソースを読み込めるようにして、H.265でエンコーディングしたデータをMP4の形式にしたい。今のTranscodeだとH264しか読み込めないから、そこいらの部分をクリアにして、出力が普通のアプリでは読み込めない状態をHandbrakeのMUX部分をパクって直していく。そこからHandbrakeに組み入れられればと思う。

タグ:NVENC
コメント(0) 

nvidia video codec sdk 8.0のサンプルコードが動かない(7.1で動いた)。 [プログラミング]

NVENCを使おうとして、Video Codec SDKを入れたのは良いけれど、サンプルコードさえ動かなかった話。

https://developer.nvidia.com/nvidia-video-codec-sdk

経緯を述べておきますと現在SDKは8.0で、UbuntuだとCUDAとドライバの齟齬があってうまく動かないみたいです。仕方ないのでWindowsで動かしてみても、Ubuntuと同様にコンパイルはできるけれども、実際に動いちゃくれなかったりします。

CUDAはOptionalで入れなくてもいいのかなと思いきや、サンプルががっつりCUDAを要求しているので入れざるを得ません。WindowsではサンプルによってはDirectXで良かったりしますが、なんだかんだで使いそうなのでどちらにも入れておくことにします。

んでWindowsでもUbuntuでも出たエラー。NvTranscoderで出てくる。

Failed to find required function "cuvidGetDecoderCaps" in libnvcuvid.so
cuvidInit(0) has returned CUDA error 999

そもそもDLLとかの共有ライブラリを見に行くときにこけているのでどうしようもない。それにCUDAを入れるのは必須なのでダメだったりする。読んでいるところをコメントアウトしたものの、パラメーターからファイルを読むところでコケていて、対処のしようがなかった。

NvEncoderはエラーは出ないんだけど、出力はされていない。こういうのが一番困る。何が悪いのかわからないから、デバッガでステップ実行していかないと突き止められない。デバッグしようとしたけど何やったかは忘れた。

さんざんGT 1030 NVENC未実装問題や、デバドラがきちんと入っているかわからない問題や、CUDAやっぱ入れないとサンプル動かないやん問題を通り過ぎてきたものの、何が問題なのかわからないのでデグレードというか、SDK7.1を使ってみた。すんなり動いたw。たぶん整えた環境の問題なのだろうけど、WindowsもUbuntuも、新しいグラフィックドライバに新しいCUDAを入れたのだ。SDK8.0が悪いとしか言えない。

それに音は入っていないとは言え、Transcodeは1750fpsの爆速を叩き出していた。これは移植するモチベーション上がるなぁw。それにとりあえず動くというところが良い(喜ぶところのレベルが低いw)。まだ面倒があるのには、Windowsで生成されるファイルがmp4形式で吐き出されてないっぽいところ。でも基本的にUbuntuで開発しようとしていたから別にいいかという感じ。今回はnvccとかでコンパイルしてむりやりgccなバイナリと連結しなくても良さそうだし、きちんと動画的なお作法さえ身につけていればなんとかなりそう。

問題が一つ。Transcoderで生成したファイルが、UbuntuのVideoアプリでは見られるけど、MacやUbuntuのVLCでは見られないということ。h.265が悪いのかなと思って、H.264で出力したけど見られなかった。そもそも一般的なmp4の形式で出力できていない模様。Windowsで出力したファイルもWindowsでは見られなかった。

確かにエンコードされるファイルはbitstreamと書いてあるけれども、TranscoderくらいはきちんとMP4の形式に整形してくれないと、どういうデータが来ているのかがさっぱりわからない。ビットストリームをMP4のコンテナに乗せればいいのだろうか…(わかってないw)。MP4をdemuxした状態なのかな。しかし一般的なアプリで見られないとなると、今後は動作確認などが問題になってくるだろう。データとしてはできてはいるんだろうけど、お作法に則って出力してもらわないとねぇ。

それにしても、開発環境が動かないというのは辛いですよ、NVIDIAさん。新しい環境に問題があるというのはよくあることだとしても、過去の動いていたSDKをもっと見つけやすいところに置いておいてもらわないと、正直このレベルの完成度でリリースされるとみんな困る。

https://developer.nvidia.com/video-codec-sdk-archive

タグ:NVENC
コメント(0) 

Golangまたやっか。 [プログラミング]

SwiftをUbuntuに入れて動かしてみたんだけど、正直まだまだだという事が分かった。Deprecatedな関数が多いのにもかかわらず、まだ実装されていないものもあったりで、どこまでSwiftでできないのかが分からなかった。そもそものライブラリの性質がコマンドライン用にできていないので、Foundationを扱うのも面倒な面が多かったりする。それとXcodeみたいにSwift3になって名前が変わったものをサジェストしてくれないので、自分で調べないといけないのもお手軽に書けない理由になっているのだろう。

OSSのSwiftは待ちかなぁと思うにつけ、やっぱりGolangとかはお手軽に書けていいなぁと思ったりしている。Swiftみたいに動的スクリプト言語みたいにかっこよく書けないけれども、C/C++言語から始めた自分としては何となく安心できる言語ではある。C言語的な万能さはないけれども、C/C++の罠が極力抑えられているのがいい。というか、オブジェクト指向は使うのはいいが、ライブラリ側に近いところを作り出すと一気に面倒になる。知らなくてはいけないことが多くなるし、気を付けるところもべらぼうに増える。


車輪の再発明となるが、Golangでhttpdを作ってみたい。busyboxぐらいのシンプルさのhttpdがいい。そこからHTTP/2の実装まで手を伸ばしたい。でもまずは普通のWebサーバ。Golangは標準ライブラリにすらいろいろ材料は揃っているから、割とシンプルに書けそう。あとgoroutineを有効に使ってみたい気持ちもある。なんかそういう基本のところをやってみたくなったんだよね。今まではいかにフレームワークを使うかとかだったけど、一般的なプロトコルを実装したくなった。

通信制御系のプログラミングはしていたこともあるけれども、正直全体像が分かるほど触らせてもらえなかった。仕様書ありきの世界でもあったわけなので、正直細かいことを考えたことはなかったりした。きちんと自分がすべきタスクを果たして次に渡せばよいだけだったので、全体の動きとかはまた別の話になっていた。それにしても携帯に限っては、すでに初めのころからハードウェアで実装されて、チップを配置するなりSoCに組み込むなりするだけの世界になっているのだろうから、ソフトウェアで処理して電話の通常通信処理で電池が持たないなんてことはないんだろうね。自分が3G携帯を作っていた頃でもGSMはワンチップ化されていたっぽいしなぁ。少なくとも基地局役の機器がトランシーバー並みの大きさになっていた時は、GSMの基地局側の処理もハードウェア処理されていたんだろう。

正直ハードウェア処理というのがよく分からない。ソフトウェアほど融通が利かないという事ぐらいしかわかっていない。FPGAとかそういう世界は同僚がやっているという話は聞いたことがある程度しか知らない。プログラマブルなハードウェアというのがどういう仕組みで動くのかが想像できない。やはりCPUにメモリを積んでメモリ上にロードするという処理しかしないソフトウェア技術者としては、VHDLとかでプログラミングする世界とは違う別物として考えていた。今VHDLのソースを興味本位で見たら、ネストの深い分岐処理が多いんだなくらいで、思ったほど回路回路していない感じだった。

ソフトウェア処理している部分を、ハードウェアに落とし込むときってどうやっているんだろうなとちょっと気になったり。通信制御系だとC言語とかの奔放な書き方ができる分の冗長さがなくなってやりやすいかもしれないなと思ったりはする。何でもできるからバグができるという側面がC言語には多分にあるから、今のコンパイル言語はバグが出ないようにわりと縛りがきつくなっている。それで書きやすいかどうかはまた別の話だと思うけど。


そんなわけで、おじさんの老後の楽しみとして(笑)、Webサーバぐらいはちょうどいいボリューム感なのかもなぁと思っていたり。仕事だといちからスクラッチする事ってまずないし、かといってシステムや言語に近いところをえぐるようなことも割とあったりするから、妙な知識ばっかり蓄積する。要するにつぶしの利かない仕事が多かったというわけだ。だから仕事をセミリタイアするまでは、DBとかあんまり扱ったことがなかったりして世界の違いに戸惑ったりもした。いや、パッケージでDBを利用していたりしていたんだが、SQLそのものを発行したりするところじゃなくて、Windowsのインターフェイス部分を扱ったり、別システムとのやり取りをしたりとか、そういう雑多な周りのこまごまとしたところをよくやっていた気がする。

これがDBそのものを作るとかになると、非常に敷居が高くなってしまうのだが、通信だとそこまで専門的な知識が必要ではない。英語だけれどRFCというアクセスしやすい資料も存在することだし。他のマイナーなプロトコルのサーバ実装とかもいいかなとは思ったけれども、正直へこたれそうで比較もできないと進んでいる感がないというか、実装後の検証もしんどくなるなぁとか思ってしまう。Webサーバだったら手元のブラウザですぐに確認できる。HTTPという訳が分かっているつもりのプロトコルでも訳の分からないところとか、実際どうやっているのかわかっていないところとか、実装しないとわからないところを知ってみたいという思いがある。単に手軽なおもちゃが欲しいという気持ちがあるわけで、別にそれがプロダクトになってほしいとかそういう気持ちはほとんどない。そもそも、世の中にhttpdなんてメジャーなものがたくさんあるわけで、それを自分で作れたら面白いなと感じるだけです。

とにかく語ってないで作れや、というのが世の常だと思うので、誰でも実装できそうなところから始めます。というかviとかあんま慣れてないんだが。しかし、環境からしてviかemacsでインプリするしかないんだよな。どっちにしても特殊なキーバインドなのは否めない。やっぱりWindows上で開発していたのが長かったから、そういうのにはあまり固執していないからなぁ。お手軽な方法に逃げてしまうのが人間の性というものだ。

コメント(0) 
前の10件 | 次の10件 プログラミング ブログトップ