可能なときには常に共有ライブラリを使うべきです。プログラムをサポート し公開 API だけを使うようにするために配布者が費す労力を減らすため です。
libav を商用プログラムに使うことができますが、使っている機能に応じて LGPL もしくは GPL をライセンスを受け入れなければなりません。 簡単なチェックリストとしては 私たちの法律上の 注意点が書かれたページ を参照してください。 またライセンスの正確な文章については GPL version 2、 GPL version 3、 LGPL version 2.1、 LGPL version 3 を参照してください。 ソースコードのいかなる変更も該当します。 着手するための最も良い方法は libav-devel メーリングリストにパッチを送ることです。
コードは K&R C スタイルで書かれます。これは以下のことを意味します:
for (i = 0; i < filter->input_count; i++) {
switch (link->init_state) {
case AVLINK_INIT:
continue;
case AVLINK_STARTINIT:
av_log(filter, AV_LOG_INFO, "circular filter chain detected");
return 0;
const char *avfilter_configuration(void)
{
return LIBAV_CONFIGURATION;
}
if (!pic || !picref)
goto fail;
ファイル内でのインデンテーションについて以下のようなガイドラインがあります:
表示のあり方は ’indent -i4 -kr -nut’ によるものです。
Libav での主な優先事項はバグの個数を最小化するための単純さと小さなコードサイズ です。
JavaDoc/Doxygen 書式を使って、(以下の例を見て)コードのドキュメントが自動的に 生成できるようにしてください。 自明でない関数はすべてその直前に、その関数が行うことを説明するコメントを持つべき です。たとえそれが単なる1行の文であっても。 すべての構造体とそのメンバー変数にもドキュメントがあるべきです。
! を含んだ Qt スタイルや類似の Doxygen 構文は避けてください。つまり
//! は /// などで置き換えてください。まマークアップのコマンドには
@ を用いるべきで、\param ではなく @param を使ってください。
/**
* @file
* MPEG codec.
* @author ...
*/
/**
* Summary sentence.
* more text ...
* ...
*/
typedef struct Foobar{
int var1; /**< var1 description */
int var2; ///< var2 description
/** var3 description */
int var3;
} Foobar;
/**
* Summary sentence.
* more text ...
* ...
* @param my_parameter description of my_parameter
* @return return value description
*/
int myfunc(int my_parameter)
...
Libav は ISO C90 言語に少しだけ ISO C99 からの追加的な機能を加えた形 でプログラムされています。それらは以下のものです:
これらの機能は我々が関知する全てのコンパイラーでサポートされており、 そのため、明確さと性能を絶対に損なわない場合を除いてそれらの使用を 取り除くためのパッチは受理されません。
全てのコードは最近の GCC やその他の現在対応している多くのコンパイラで コンパイルできなければなりません。互換性を保証するために、別の C99 の 機能や GCC 拡張は使用しないでください。特に次に警戒してください:
全ての名前にはアンダースコア(_)を使い、キャメルケースは使いません。例えば、 ‘avfilter_get_video_buffer’ は妥当な関数名ですが、 ‘AVFilterGetVideo’ はだめです。唯一の例外は構造体の名前です; これらは 常にキャメルケースであるべきです
変数および関数に名前をつけるときには以下の決まりがあります:
static と宣言されている変数および関数についてはプレフィックスはいりません。
ff_ というプレフィックスを
用いるべきです。
例、‘ff_w64_demuxer’。
avpriv_ を
用いてください。例、‘avpriv_aac_parse_header’。
Libav の整形規則に従うように Vim を設定するため、以下のコード片を ‘.vimrc’ にペーストしてください:
" indentation rules for libav: 4 spaces, no tabs set expandtab set shiftwidth=4 set softtabstop=4 set cindent set cinoptions=(0 " allow tabs in Makefiles autocmd FileType make set noexpandtab shiftwidth=8 softtabstop=8 " Trailing whitespace and tabs are forbidden, so highlight them. highlight ForbiddenWhitespace ctermbg=red guibg=red match ForbiddenWhitespace /\s\+$\|\t/ " Do not highlight spaces at the end of line while typing on that line. autocmd InsertEnter * match ForbiddenWhitespace /\t\|\s\+\%#\@<!$/
Emacs のために、以下のほぼ同等な行を ‘.emacs.d/init.el’ に追加してください:
(c-add-style "libav"
'("k&r"
(c-basic-offset . 4)
(indent-tabs-mode . nil)
(show-trailing-whitespace . t)
(c-offsets-alist
(statement-cont . (c-lineup-assignments +)))
)
)
(setq c-default-style "libav")
git format-patch を使って生成されるか、直接 git send-email
で送信されるべきです。
コミットに正しい author を設定して適切なクレジットを与えていることを確認して
ください。
我々は自分たちの規則がそれほど厳しくないと考えています。意見がありましたら、我々に連絡してください。
注意、いくつかの規則は MPlayer プロジェクトから借りています。
まず最初に、まだ未読なら上の Coding Rules を読んでください。特に パッチ投稿に関するルールを読んでください。
既に述べたように、複数の無関係な変更を含んだパッチを投稿しないで ください。 パッチを提出する際には、unified diff(diff の’-up’ オプション)を送ることを 試みてください。他の diff は読めません :-)
また、各種の無関係な変更が含まれているパッチを提出しないでください。 それを個々の自己完結したパッチに分割してください。これはファイル1つ1つに 分割するということではありません。代わりに、出来る限りパッチを小さくし、 たとえ複数のファイルに渡るとしても1つの個別の変更を含む論理的な1単位として 保つようにしてください。これによってパッチは我々にとってさらにレビュー しやすくなり、パッチが適用される機会が大幅に増えます。
パッチを調査するための Libav の patcheck ツールを使ってください。 このツールは tools ディレクトリにあります。
予期しない問題を生じないことを調べられるように、パッチを提出する前に Regression Tests を 実行してください。
パッチは base64 (またはパッチが伝送中にだめにならないことが保証されて いるその他のエンコーディングで)エンコードされた添付ファイルとして、 libav-devel に投稿されるべきです。
また、そのパッチが行うこと(例えば ’lrint を lrintf で置き換える’)、および その理由(例えば ’*BSD は C99 準拠でなく lrint() がない’)を教えていただけたら 大いに助かります。こういった説明はコミットメッセージの内容になるべき です。
また、複数のパッチを送る際には、それぞれのパッチを別々のメールとして送って ください。同じメールに無関係な複数のパッチを添付しないでください。
可能ならば git send-email を使ってください。なぜなら余分な苦労なしに
パッチが適切に送れるからです。
あなたのパッチはメーリングリストでレビューされます。あなたはいくつかの変更を 求められたり、レビューからのリクエストを組み入れた修正版を送ることを期待されます。 このプロセスは複数回繰り返されて進むことがあります。パッチが十分よいと判断され次第、 公式の Libav ツリーにコミットされます。
反応するのに数日ください。しかし反応なしにいくらか時間が経過したら、 思い出すようメールを送ってください。いずれパッチは取り扱われるでしょう。
git add しましたか?
configure --disable-everything --enable-decoder=foo
で(または --enable-demuxer、あるいは当のコンポーネントが何でも)
コンパイルが通ることを確認しましたか?
make check が通りますか?
malloc() のようなメモリを確保するための関数はよくチェックされない
ままになっており、これは深刻な問題です。
libav-devel に投稿された全てのパッチはレビューされるでしょう、そのパッチが git master branch 向けでないという明確な注意が含まれていない限り。 レビューとコメントはパッチへの回答としてメーリングリスト上に投稿されます。 そしてパッチの提出者は全てのコメントに対処しなければならず、 それは変更したパッチの再提出や議論によってなされます。 パッチの再提出はそれ自体他のパッチと同様にレビューされます。 どこかの時点でコメントなしでレビューを通過したら、それは承認されます。 これは単純で小さなパッチについてはすぐに起こるでしょうが、 大きなパッチは一般的に承認される前に何回も変更されそしてレビューされるに違いありません。 パッチは承認された後でレポジトリにコミットされるでしょう。
我々は全ての提出されたパッチをレビューするでしょうが、ときおりとても忙しく、 特に大きなパッチに対しては数週間に及ぶことがあります。
パッチを再提出する際、そのサイズが多大きくなったりレビューの過程で異なる問題が 持ち上がったりしたときには、それぞれの issue に個別のパッチになるように そのパッチを分割してください。
パッチを提出する(またはレポジトリにコミットする)前に、少なくとも それが何も壊さないということを確実にするべきです。
変更されるコードについて既に FATE にテストがあるなら、それを実行するべきです。 そうでなければテストを追加するべきです。
コーデックまたはデミュクサーに対する改善は FATE の結果を変えてしまうことがあります。 その変更を参照する更新をコミットすることと、なぜ予期される結果が変わるかをコメント で説明することを必ずしてください。
fate.html を参照してください。