一般論として、リポジトリ内の改行コードは LF がよい、ということになっているようですが、例えば Ut Video Codec Suite とかのリポジトリでは CRLF で入っています。ついでに src zip も CRLF です。
なんでそうなっているのかというと、昔は Linux 上で svn リポジトリを checkout して samba 経由で Windows から開く、ということをたまにやっていたからです。Visual Studio 2005 だといくつかのファイルは CRLF でないと正常に開けなかった(はず)ため、じゃあってんで全部 CRLF になるようにしていました。今の git リポジトリの状態はそれを踏襲したものになります。 Git for Windows の設定も autocrlf=false にしています。
今後 Linux で使えるようにしようと考えると、改行が CRLF な状態は好ましくない(リポジトリ内が CRLF でチェックアウト状態が LF という設定はできない)かなぁ、と思い始めているのですが、リポジトリ内の改行を CRLF から LF に変更するとそのタイミングで blame での変更追跡が切れる、という問題が発生します。うーん。まあ仕方ないですが…
ちなみに、svn 時代はリポジトリは公開されていなかったのですが、その頃に CRLF になっている src zip を LF に変換して fork (?) している github リポジトリがあるのを見たことがあります。
先日、映像作品上映イベントである FRENZ 2017 が開催されましたが、今回の上映システムでは UtVideo が使われていた — つまり、上映用の動画ファイルは UtVideo でエンコードしておいて、それをリアルタイムで再生したそうです。「そうです」と書いた通り、私はこの上映システムとは直接無関係で、そうなってることを(後で)聞きました。
Read the rest of this entry
次回のコーデックベンチマークに向けてツールを修正したりテストクリップを生成したりしていたわけですが、めんどくさくなってきました。具体的に何がめんどくさいかというと、計測結果をもとにグラフの画像を生成する部分です。
今までは Excel を使っていたのですが、Excel だとグラフの画像のサイズをピクセル単位で厳密に指定できません。ピクセル単位で指定すると mm 単位に変換され、それに応じてピクセル単位でのサイズが決まります。なので微妙な誤差が発生します。めんどくさい。あと GUI ツールなので自動化しづらいという問題があります。ベンチマークした結果でグラフを大量に生成するつもりだったので手打ちではやってられません。
コマンドラインツールでグラフを描くというと昔から gnuplot というツールがあります。ただこれ、何とビックリ、単独では横棒グラフが描けません。じゃあどうするのかというと、縦棒グラフを他のツールで90度回転させるのだそうです。しかしその場合、凡例などの文字列はあらかじめ90度回転したものを描画させることになり、しかも回転したことによる位置ズレは自力で微調整しなければいけません。今時ありえん。
てな感じで、調べれば調べるほどやる気がなくなってきました。