FFmpegをもっと簡単に！ Typed-FFmpeg 3.0 型付きインターフェースとビジュアルフィルターエディタが登場！

コマンドラインオプションのパーサーって、それぞれ独自の言語みたいなもんなんだよね．Unixシェルの単語分割のせいで見た目が似てるけど、実際はすごく多様で、みんなが思ってるよりずっとバラバラなんだ．/usr/binの全プログラムで–helpや-hを試したけど、役に立つヘルプが出ないのがすごく多かったよ．ffmpegみたいに複雑なやつに型を追加するのは、この多様さに気づくきっかけになるし、実用的なメリットもあると思うんだ．良い仕事したね！

君が言いたいこととは違うのは分かってるけど、「man foo」の方が「foo –help」とか「foo -h」より信頼できて役に立つと思うんだ．

なるほどね．ドキュメント探しは大事だよね．CLパーサーツールキットは独自の言語だけど、コマンドが手作りしてるargvパーサーは完全に独自の言語で、一般的な慣習の一部しかやってないんだ．getoptが普及しなかったのは、十分じゃなかったか、早くなかったか… Bell Labsでさえ、ddやfindみたいな古いコマンドは独自の構文のまま残っちゃったんだろうね．歴史はやり直せないし、いろんなことが「根強く残る」んだよ．

DOSではもっとひどかったよ．ワイルドカード展開がシェルじゃなくてプログラムの中で行われたから、個々のコマンドがワイルドカード展開をサポートしてるかどうかわからなかったんだ！

Unixコマンドでも、シェルがワイルドカード展開してくれても、そのコマンドが複数ファイルの処理をサポートしてるかどうかわからないままなんだよ．ツールは単一ファイルだけ処理して終わっちゃうかもしれないしね．

getoptと同じ頃に、Bourne familyシェルがkey=val cmd構文を追加したんだ．これはgetenvとかで簡単にアクセスできて実装は軽くて済むんだけど、シェル固有なんだ．Unixではファイル名パターンマッチングも「ある種のロングオプション」もシェルレベルで組み込まれてたってこと．環境変数の継承は良い点と悪い点があったね．GNUが–key=valueを導入した頃のタイミングや可搬性が影響して、ロングオプションが勝ったんだろう．良くも悪くも、今はこのkey=val cmd構文を知らない人が多いみたいだ．bash/POSIXがC shellとかを打ち負かした頃の話なんだけどね．fish shellもこの構文はやめたと思うな．

そのkey=val cmd構文は知らなかったけど、名前なしパラメータとか足りない点があるね．「help= cmd」みたいにスペースで混乱しやすいし、引数と環境変数がぶつかると大変なことになる．普及しなくてよかったよ．
CP/M 3.0にはDIR [WIDE] [ATTR=ANY]みたいに角括弧で囲む構文があって、あれが一番直感的だったかな．でもDOSはもう、CP/Mから受け継いだフォワードスラッシュを使ってたけどね．

たぶん誤解だよ．あれは普通の構文に「加えて」使うアイデアで、たまたまロングネームを付ける方法なんだ．POSIX/Bash/Zshほどじゃないけど、使えるって意味では普及したよ．スペースの件は、Unixシェルの引用符と同じくらい混乱したりしなかったりかな．help= cmdは変に見えるけど、help=1 cmdとかもアリかもね．cmd [key1] arg1 [key2=val2] arg2って構文は面白いね．

ああ、完全に誤解してたよ．分かりやすく説明してくれてありがとう！でも、やっぱり普及しなくてよかったと思うな :-)

よく分からないんだけど、その「衝突」ってどこであったの？

コマンドのヘルプ集めるの？危険だからVMかコンテナでバックアップ用意して慎重にね。ルート権限はダメだよ。プロセスが固まることもあるから気をつけて。もしやるなら、/usr/bin/*のコマンドを-hとか--helpで試してみて。出力ファイルを加工して統計とるのもありだよ。最初のヘルプの出し方は超重要だよね。

これ面白いね！アクティブに開発されてるのは良いな。でも、ffmpeg-pythonと同じような問題もあるかも。
例えば、colorみたいな入力なしのフィルターを指定する方法が見当たらないし、subprocess.CREATE_NO_WINDOWみたいなPopenのフラグ渡せないのも不便。ffmpeg.compile()で回避できるけど、ffprobeのffmpeg.probe()じゃできないね。
あっ、ソースフィルターのcolorは見つけた！vfilterやafilterみたいに、どんなソースフィルターでも使えるの？

Pythonで動画処理スクリプト組むなら、個人的には最初からVapoursynth[1]を使うのをめっちゃオススメするよ。これはその目的のためにゼロから作られてて、活発にメンテされててコミュニティやツールも良い感じ。ffmpegのCLIに縛られないのが強みだね。
[1] https://www.vapoursynth.com/

”完全な型安全性、オートコンプリート、検証”がtyped-ffmpegのウリなのに、なんで幅や高さ（またはx、y座標）を文字列で渡すのが理にかなってるのか説明してくれる？
””<br>.drawbox(x=”50”, y=”50”, width=”120”, height=”120”, color=”red”, thickness=”5”)<br>””
（https://github.com/livingbio/typed-ffmpeg?tab=readme-ov-file...より）

問題は、それらが単なる整数じゃなくて、整数に評価されるffmpegの式ってことだと思うな。例えば、ffmpegのドキュメントにあるこの例を見てみて。
2ピクセルの赤い2.40:1マスクを描画する例：
drawbox=x=-t:y=0.5*(ih-iw/2.4)-t:w=iw+t*2:h=iw/2.4+t*2:t=2:c=red
これをちゃんと型チェックするには、DSLみたいなものが必要になるだろうね。

Jules previewにプロンプト入れてどうなるか試してみたよ。実装はかなり素朴だね。もっと読みやすいアプローチも思いつくけど、超短いプロンプトを使った割には悪くないかな。
変更はこのブランチにあるから興味あったら見てみて。
https://github.com/matt-hensley/typed-ffmpeg/tree/feature/mu...

この実装がTypeScriptを使ってないって事実は、投稿者がTypeScriptでの実装を望んでるって事実とは関係ないでしょ。元の返信は投稿者がすでに知ってる事実を述べただけなんだから、それを知ってるって確認するために「うん」って言ったんだよ。

FFmpegのコマンドラインを機械が読み込めるように記述して、多言語で生成できるようにするべきっぽいね。

このビジュアルツール、特に素晴らしいね。FFmpegはモジュラーとかビジュアルプログラミングがすごく役に立つ例みたいだ。FFmpegの全部を知ってるわけじゃないからね。ちょっとしたUXノートとしては、ノードとかエッジを消すのにDELキーが使えると思ってたんだ（Win11/Chrome）。でも全体的に：すごい！

MicrosoftのDirectShow GraphEditみたいなものがやっと出てきたかって感じだね。

これはかっこいいね。でも、フレーム全体をコマンド間でパイプ処理するのって対応してる？個人的には、それがFFmpegフローの一番面白い形を引き出す時だと思うんだけど。

これ、いいね！もしビジュアルで動画編集したいなら、僕のツールも紹介させてよ。https://newbeelearn.com/tools/videoeditor/
これがFFmpegコマンドを生成するんだ。

関係ないんだけど、僕のC++の解決策これだよ: https://github.com/richardpl/lavfi-preview

これこそ僕が探してたものだよ: リアルタイムのビジュアル。すごくいいね。