fixedpoint.jp


ケーススタディ: コードの増大とディストリビューションについて (2008-06-09)

今回のケーススタディはおなじみの ffmpeg-devel からです。

議論の発端は開発者の1人 Diego Biurrun のパッチです。彼はコンパイル時に行うある条件分岐で参照しているシンボルに食い違いがあることに気づいたのでした: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-June/048109.html

条件付きでコンパイルされる img_convert() という関数は活発な開発の中で廃れており、その代替をソフトウェアでスケーリングを行う libswscale ライブラリが提供する予定になっています。しかし現時点では両者がともに存在するという状態です。どちらを選ぶかはオプション --enable-swscale と、(おかしなことに宣言の関係で) libavcodec のバージョンが関係しているのです。

これについて、プロジェクトリーダーの Michael Niedermayer は提案されたパッチをとりあえず横におくことにしました。そもそも --enable-swscale オプションが

という意味で用意されているのに、それを反映していないことこそがこの問題の焦点だと言います:

一方、Diego や他の開発者は、Debian や Mandriva といった Linux ディストリビューションのメンテナがとっている「新旧両方の scaler を有効にする」方法がうまくいっているように見える、という意見を出します:

しかし Michael はその方法が「(ディストリビューションのメンテナが必ずしも回避しない)コードの増大と重複」を招くという見解を示します。彼は Gnome、KDE、Firefox を引き合いに出し、特に Firefox が RAM の少ないマシンで遅くなると主張します: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-June/048200.html

ここで議論がやや脇道に反れ(http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-June/048206.html)、「少ない RAM のマシンでも利用できるディストリビューションやデスクトップ環境」についての返信に費やされます。これはこれで興味深いものです:

最終的に次のような回顧と反省を含んだメッセージで落ち着きました(http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-June/048295.html):

When swscale was added i hoped that we very soon would
drop the old scaler and API but due to various reasons this didnt happen
yet. When the code was written it was not expected that there would be
a long period with both supported.
I regret a little that i did not simply ignore the whining users and
removed the old scaler, this would have helped speed up things alot.
Now we have a google SOC task about the swscaler and iam planning to
wait to see what comes out of that before i spend time on it ...

© 2006-2023 fixedpoint.jp