>規格/仕様にはないが出回ってしまっているデータ 例えばFFmpegに実装されたRealVideo 4.0のデコーダではバギーな公式デコーダの実装に合わせてます。Kostya氏の"should RV40 designers burn in hell?"という質問とMichael氏の"yes"という回答が印象的。 もう一つ例を。最近FFmpegに実装されたTwinVQデコーダでは、ヤマハのTwinVQエンコーダがバギーなNTTのTwinVQデコーダの実装に最適化されていたということでNTTのデコーダ互換の実装になっています。実装したのはVitor氏で、ソースコードにはvery_broken_opという関数があったり、"For some unknown reason, NTT decided to code this case differently"とか書かれてたりしています。MPEG-4のTwinVQは今後別に実装されるはず。
REによって作られたもの (スコア:5, 興味深い)
例えばFFmpegの場合、仕組みを解析して数式やアルゴリズムに戻してから効率が良くなるように実装しているので、RE元のライブラリよりも高速なことが多いです。
日本のREはクラックというかファイル抽出・キー抽出に偏ってるのが残念でしかたありません。もっと、仕組みを分析し仕様化し再実装することを目指してほしいなと思います。
Re:REによって作られたもの (スコア:2, 興味深い)
> 例えばFFmpegの場合、仕組みを解析して数式やアルゴリズムに戻してから効率が良くなるように実装しているので、
> RE元のライブラリよりも高速なことが多いです。
動画系のFFmpegに限ってはそんなことする必要ないし、するべきでも無いだろ。
他に挙げた例と違って、似せたい(互換性を得たい)実装が先にあるわけじゃなくって、
規格/仕様やアルゴリズムなどが公開されていて、それに対しての様々な先行実装があるんだから。
> もっと、仕組みを分析し仕様化し再実装することを目指してほしいなと思います。
REに限っての話としていいたいことはわかりますが、
FFmpegみたいな規格ものの実装については、そもそもREみたいなアプローチではなく、
本来の動画理論などに基づいた最適実装を目指してほしいなと思います。
もちろん、vendor拡張tagや微妙なエンコード時の癖など、規格/仕様にはないが
出回ってしまっているデータを救済するために、本線のアルゴリズムとは別の目的でREするのは、
他に挙げている例と同様の事情だと思いますので、必要悪だとは思いますよ。
まあ、あとは知財リスクてんこ盛りって課題もありますな。
リファレンスの規格アルゴリズムに対して各社設計/実装レベルで
いろいろチューニングを施して、知財化している世界なので。
そもそも大元の規格特許への対応も含めて、
そういうものとして利用側や配布側が充分注意して対応していくしかないんだろうな...
Re:REによって作られたもの (スコア:4, 参考になる)
http://wiki.multimedia.cx/index.php?title=Indeo_5
同じく仕様の公開されていないVP6はこんな感じです。
http://wiki.multimedia.cx/index.php?title=On2_VP6
音声コーデックのWMAはこんな感じ。
http://wiki.multimedia.cx/index.php?title=Windows_Media_Audio
同じくALAC。
http://wiki.multimedia.cx/index.php?title=Apple_Lossless_Audio_Coding
WavPackもこの通り。
http://wiki.multimedia.cx/index.php?title=WavPack
>規格/仕様にはないが出回ってしまっているデータ
例えばFFmpegに実装されたRealVideo 4.0のデコーダではバギーな公式デコーダの実装に合わせてます。Kostya氏の"should RV40 designers burn in hell?"という質問とMichael氏の"yes"という回答が印象的。
もう一つ例を。最近FFmpegに実装されたTwinVQデコーダでは、ヤマハのTwinVQエンコーダがバギーなNTTのTwinVQデコーダの実装に最適化されていたということでNTTのデコーダ互換の実装になっています。実装したのはVitor氏で、ソースコードにはvery_broken_opという関数があったり、"For some unknown reason, NTT decided to code this case differently"とか書かれてたりしています。MPEG-4のTwinVQは今後別に実装されるはず。
>知財リスクてんこ盛り
http://www.ffmpeg.org/legal.html
FFmpeg側のスタンスとしては特許の問題は知らぬ存ぜぬ国によるで。ソースコードでの配布だと特許の問題ないですしね。
特許問題(オフトピ) (スコア:2, 興味深い)
> ソースコードでの配布だと特許の問題ない
「午後のこ~だ」がソースコードで配布してるのもこれなんだろうけど、
なんか不思議な話だよね。
インタプリタ言語とかの場合はどーなるんだろ。
Re:REによって作られたもの (スコア:1)
それにも関わらず,リバースエンジニアリングが正当な行為であるように書かれていることに疑問を感じます.
リバースエンジニアリングを禁じること自体が,もっと上位の法律なり憲法なりで禁じられていて,実質的に守る必要がないということなんでしょうか.
Re:REによって作られたもの (スコア:1, 参考になる)
> 素朴な疑問なんですが,
このあたり参照ですかね。
http://www.soumunomori.com/column/article/atc-49665/ [soumunomori.com]
http://www.license-keiyaku.com/softwear/reverseengineering.html [license-keiyaku.com]
つまり、個人でやるぶん問題ないということです。
無論、クリーンルーム方式での解析や解析手法などのノウハウの公開は良いですがその製品に関する公開されていない
解析結果について公開するとトラブルになりかねません。
#あまり自信が無いのでAC
Re:REによって作られたもの (スコア:1)
の二つの論点がありますね.
日本ではどちらも判例にはなっていない(欧米ではなっている)ので, 最終的にどう判断されるかは不確定ですが, 今のところ以下のような解釈が成されているようです.
前者は,純粋な研究目的であれば認められることに異論はなさそうです.
ただ,結果の公開や,クローンの作成はまた別の問題のようです.
後者については,公正取引委員会の報告書(PDF) [meti.go.jp]が, 日本では最も権威のある?考え方のようです.
これによると,あるソフトウェアとインターオペラビリティを持つソフトウェアを開発するために,
そのソフトウェアからインターフェース情報を取り出すことを禁止することは独占禁止法に反する,ということです.
Re: (スコア:0)
最初から上手に作れ