Android NDK 上で FFmpeg をどう扱うかを探るための、
小さなテストアプリです。
事前にビルドした libav* 系 .so や FFmpeg バイナリを JNI から呼び出し、
動画のトリミング・リサイズ・フィルタ適用などを、
実際の端末上で検証することを目的としています。
スマホの中にある動画を選び、 「この区間だけ切り抜きたい」「この解像度にリサイズしたい」 といった処理を FFmpeg で行うための基礎実験アプリです。
Kotlin 側から JNI を通じて C/C++ のラッパーを呼び出し、
そこから FFmpeg のフィルタグラフや avcodec / avformat を使って、
エンコード／デコードの一連の処理を走らせます。
失敗したらログをそのまま画面に出し、「どのビルド・どの引数で動いたか」を
一つずつメモしていくための“実験ノート”のようなアプリです。
Kotlin UI → JNI ブリッジ → FFmpeg ライブラリ群（libavformat, libavcodec,
libavfilter, libswscale, libavutil …）という流れで処理を行います。
一部の検証では、既成の FFmpeg バイナリを exec で呼ぶパターンも試しています。
trimVideo(input, output, start, end)、
applyFilterGraph(...) など。まずは「巨大な FFmpeg API の中から、どの関数を最小セットとして使うか」を整理しました。 デコード → フィルタ → エンコードの流れに必要な部分だけを抜き出し、 Kotlin からは “関数1つ” のように呼べるよう薄くラップしています。
JNIEXPORT jint JNICALL
Java_com_example_s_FFmpegNative_trim(
JNIEnv* env, jobject thiz,
jstring inPath, jstring outPath,
jdouble startSec, jdouble endSec) {
// jstring → const char* 変換など
// FFmpeg の avformat_open_input, av_seek_frame ... を呼び出す
}
C レベルで libavfilter を直接触り、
scale や crop、transpose など
よく使うフィルタを filtergraph としてつなげる実験を行いました。
これにより、後の ebutuoY のような動画編集アプリで
どの程度まで FFmpeg の機能を使い込めるかを見ています。
"trim=start=5:end=10,scale=720:-1" のような文字列を
Kotlin 側で組み立てて C 側へ渡し、avfilter_graph_parse_ptr で解釈。
既成の ffmpeg-kit のようなプロジェクトを見るだけでなく、
自分でも libavfilter.so などをビルドして構成を理解しました。
どの依存ライブラリが必要か、どの codec / filter を切り落としても大丈夫かを、
実際にビルドを通して体感しています。
s アプリ自体は地味ですが、 ここで得た知見は「スペクトログラム生成」「ショート切り抜き」など 他のアプリの裏側にそのまま乗る予定です。 どの設定が端末で実用速度か、どの解像度から厳しくなるかなどを この段階で実測しておきます。
まずは 10 秒の動画から 3–7 秒だけを抜き出す、 といった単純なタスクから検証を始めました。 最初はクラッシュやノイズ混じりの動画も多かったですが、 パラメータの組み合わせを変えながら一つずつ潰していきました。
今の s アプリは「実験用ツール」に留まっており、 一般ユーザが触る前提の UI やエラー表示にはなっていません。 また、端末ごとのハードウェアエンコーダとの兼ね合い、 ファイルサイズ・ビットレート最適化なども今後の課題です。
動画を選択 → 「trim」ボタンを押す → JNI 経由で FFmpeg が動き、 出力フォルダにトリミング済み動画が生成されるまでの様子を撮影したデモです。
s アプリで確立した JNI ラッパーやビルドスクリプトは、 将来的に「動画処理ミドルウェア」として他のアプリから再利用していきます。 たとえば ebutuoY のショート切り抜き、 スペクトログラム生成前の前処理などです。
ビルド環境の安定化・ラッパーの整理・本命アプリへの組み込みの3ステップで考えています。
FFmpeg を「ライブラリとして Android で動かす」ことは、 想像以上にビルドと依存関係のパズルでした。 ただ、その過程で CMake・NDK・クロスコンパイルにかなり慣れ、 他のネイティブライブラリも怖くなくなってきました。
s は UI 的には地味ですが、 ebutuoY やスペクトログラムアプリの“裏方”として 技術の底力を支えてくれる存在になると思います。 こういう「ちょっと地味な実験アプリ」をちゃんと残しておくことが、 将来の開発速度を何倍にもしてくれるはずだと感じました。