ffmpegならこちらへ 6

公式サイト
http://ffmpeg.org/

エンコード、ストリーミング配信を高画質高音質で行えるffmpeg。
OSに拘らず対応コーデックが多い。
対応コーデックが多く、多彩なオプションを使用可能。
コマンドラインから使用することができる。
ffmpegならこちらへ 5
https://egg.5ch.net/test/read.cgi/software/1597315425/

コマンドプロンプトとして使うぶんには.NetもC#も関係ないしパイプも単純に使うだけなら問題ない
なんかめんどくさいことやろうとしてるなら知らんけど

PowerShell って俺の環境では深刻に起動が遅い。
単にマシンパワーが足りんだけかもしれんが、
少なくとも俺の環境では普段使いしづらい。

windowsのコマンドは滅多に使わないし独特で調べるのがめんどい…
ffmpeg一発ならpowershellで何も問題ないけど複雑なことをしたいときはvm上でやってる

ウチもpythonでスクリプト書いとるわ
増築しては書き直しを続けて400行超えになってもうた
とりあえず100行は減らしたい

ワイは makefile から呼ぶことが多いな。

シェルスクリプトが一番楽にできそうだけどね
シングルクォーテーションが使えると楽に使えるオプションが多いいし

>> 196
スクリプトファイル(.ps1)や関数がパイプ処理できるようになるにはこれだけの要素が必要

param (
[Parameter(ValueFromPipeline=$True)]
[string[]] $Path #パイプラインを受け取る変数
)
begin { #最初の一回だけ }
process {#パイプラインの要素ごと }
end { #最後に一回だけ }

※結果を次のパイプラインに送るには Write-Output などを使ってオブジェクトを出力する必要がある

>203
>>203
>> 203

＆gt;203
<a href="../test/read.cgi/software/1629006665/203" rel="noopener noreferrer" target="_blank">＆gt;＆gt;203</a>
＆gt;＆gt; 203

>>204
>>203 はアンカーミスったんだなw
ごめんね

メモリ増やしたら速くなるかなーと思って16→32に増やしたけれど意味なかった(´・ω・｀)ﾁｯ

CPU使用率が100%に張り付いてたらCPU交換以外に効果はない

だよねやっぱりCPUだよねぇ・・・i9 12900K試してみたいが高いよヽ(｀Д´)ノ
今はおんぽろXEON E5-2660を2個で回してるけど、i9がどれくらい早いのか気になるな

いやCPU交換以外にも手はあるだろ

…まさか…クロックアップ…

クロックアップできないお前など敵ではない

じゃあ並列処理で全コア全GPUも使う

オーバークロックは無理ぽ
誰かi912900K買って試してくれたまえ

エンコする場所をRAMディスクにして少しでも入出力の速度を稼ぐとかダメ？

ストレージにボトルネックがないのにRAMに置いてもほぼ変わらんよ

何が遅い原因かどころか何をやったかかもわからないのに試してくれとは…

あーいやすまない、たぶん>>208の言う通りCPUの限界だと思うんだよね、新型i9を使った変換速度を見てみたくてさ・・・
現在の環境がどれくらい遅いのか比較になるものあればなー

>>218
新CPUが発売されたら大体x264とx265のエンコード速度ベンチやってるからそういう記事見たらわかると思う

あとこのスレとか
【x264/x265】実用エンコベンチ Part6
https://egg.5ch.net/test/read.cgi/jisaku/1507728392/

>>219
Σ！？そんなスレが・・・ありがとう逝ってくる

リサイズが入るとCPUがやるから一気に遅くなるんだ
GPUにも機能はあるけどバイナリ配布できないのでビルドしないといけない
いつかやろうと思って放置してあるけどそろそろやろう

ffmpegて8スレッドまでなの？
最新のi9だから24スレッド使えるはずなんだけど
-threadsで24を指定しても8スレッドしか使わない

コアは使ってるなら変わらないのでは

旧石器時代のコンピュータじゃあるまいし1コアしかなくても24スレッド立てられる
ffmpegはコーデックで大幅に挙動変わるし疑問があるならオプション全部晒さないと始まらない

IOで詰まるせいで効率が落ちるならスレッドを増やすと待ち時間が減って速くなる
計算量が多い場合は、スレッドを増やすと逆にオーバーヘッドの分だけ遅くなる
CPUの負荷が100%で張り付いてるような時はスレッドは減らした方がいい

ピントハズレな奴らばっかりだな
OSのスレッドの話じゃないし
タスクマネージャーの論理プロセッサの話だとわからないかな

>ffmpegはコーデックで大幅に挙動変わるし疑問があるならオプション全部晒さないと始まらない
これがすべてよ

コーデックなんだか知らんけどx264, x265当たりは12スレッドくらいしか使わなかった気が。10980XEでも俺環では3並列エンコしないと100%行かなかった

タスクマネージャー?
あぁ、ドザか

mp4のメタデータ全部削除するにはどうしたらいいの？

>>230
-map_metadata -1

>>230
-map_metadata -1

>>231-232
できたサンクス

明日は仕事サボってビルドしよう

やっぱり面倒だー
git cloneした所まで
そのうちwin10にするんだから、続きはその後

.m3u8
.ts

をffmpegで結合する時、
30000/1001のファイルなのに、29970/1000と認識されてしまい何秒かに一回カクっと来る動画になってしまうものがあって悩んでおります
これを、できれば再エンコードなしで、30000/1001の正常な動画で出力したいのですが、
何か手はありませんでしょうか？

-r 30000/1001で再エンコードありだと、かなり画質の落ちた30000/1001の滑らかな動画が出力されました

↑.mkvで出力しております。

mkvなら手っ取り早くmkvmergeを使ったほうがいいよ
確実に調整できるから

inputオプションに指定してもだめなの？

>>238
ありがとうございました
MKVToolNixの公式サイトがどこか分からず
解説サイトもなく偽物をインストールしたらどうしようと不安でしたが
カクカクが直りました
間引かれたフレームなかったみたいで少し安心

MediaInfo
フレームレート: 29.970 (30000/1001) fps
オリジナル: 29.970 (29970/1000) fps

再エンコードなしでも十数分かかるので、
ffmpegだけで完結できたら最高なのですが…

ブラウザでストリーミング再生した時はカクカクじゃないので、
ffmpegが間違って認識してると思います…

>>239
それが出来るのが私としても理想なので
-allowed_extensions ALL -r 30000/1001 -i input.m3u8 -c copy output.mkv
など、いくつか試してみたのですが、
エラーも出ずにできたファイルは29970/1000ばかりで…
；；

分数形式じゃなく -r ntsc にするとか
出力ファイルをmp4にしてみるとか
どうかな

サンプルは無いのか

ffmpegでコンテナレベルでのフレームレート変更はうまくいかないよ
何が原因かはわからないけど、とにかく無理だった
諦めてmkvmergeを使って、別コンテナ形式に入れるときにffmpegを用いたくらい

別のツールならできるし、それらしい機能もあるなら、
やり方が間違ってるかバグってるかのどちらかだろう
追求する価値はある

バグってるって言えば、mp4コンテナでaac扱うと
vbrフラグが承継されない（variable→constantになってしまう）のはなんとかならんのかねぇ
別のツール（drax）で扱うとフラグが復活するので、データ自体は変わっていないみたいだし
再生に差し支えるわけじゃなさそうだが、気持ちのいいものではないな

試したことないけどこれで出来ない？

再エンコードせずに FPS を変更する
https://nico-lab.net/change_fps_without_re-encode_with_ffmpeg/

サンプル用意できればしたいのですが、ちょっとお時間かかるかもしれません

>>246
すみません、そのリンク先は試した後でした

mp4コンテナの再エンコード無しのFPSの変更はこんな感じで出来たけどmkvだと何故か上手くいかないな

ffmpeg -i input.mp4 -bsf:v setts=ts=N/(30000/1001)/TB -c copy output.mp4

settsの使い方がイマイチわかってないので提示例が間違ってるかも

ssimでmkvを入力するとやたらめった低くなるのって既出？

ソース(origin.m2ts、BD、H.264)とソースを比較
ffmpeg -i origin.m2ts -i origin.m2ts -an -filter_complex ssim -f null -
当然結果は1.0(inf)

ソースをmp4にmuxしてタイムスタンプを合わせて比較
ffmpeg -i ref.m2ts -an -c:v copy copy.mp4
ffmpeg -i copy.mp4 -i origin.m2ts -an -lavfi "[0:v]settb=AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=AVTB,setpts=PTS-STARTPTS[ref];[main][ref]ssim" -f null -
copyなので予想通り結果は1.0(inf)

ソースをmkvにmuxしてタイムスタンプを合わせて比較
ffmpeg -i origin.m2ts -an -c:v copy copy.mkv
ffmpeg -i copy.mkv -i origin.m2ts -an -lavfi "[0:v]settb=AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=AVTB,setpts=PTS-STARTPTS[ref];[main][ref]ssim" -f null -
結果は
SSIM Y:0.922225 (11.091597) U:0.985489 (18.383000) V:0.989469 (19.775481) All:0.943976 (12.516286)
mkvmergeでm2tsをmkvにmuxしても全く同じ数値

ソースをlibx264でエンコード・エンコード時にssim計算・mp4出力・ffmpegで再び計算
ffmpeg -i origin.m2ts -an -c:v libx264 -x264-params ssim=1 x264.mp4
↓
x264のSSIM
SSIM Mean Y:0.9828054 (17.646db)
ffmpegのSSIM
SSIM Y:0.983138 (17.731021) U:0.992124 (21.037030) V:0.993634 (21.961672) All:0.986385 (18.659951)

ソースを.mp4にmux(copy.mp4)した後にlibx264でエンコード・mp4出力
↓
x264のSSIM
SSIM Mean Y:0.9828054 (17.646db)
ffmpegのSSIM(copy.mp4)
SSIM Y:0.983138 (17.731021) U:0.992124 (21.037030) V:0.993634 (21.961672) All:0.986385 (18.659951)
origin.m2tと比較しても同じ

ソースをlibx264でエンコード・mkv出力
↓
x264のSSIM
SSIM Mean Y:0.9828054 (17.646db)
ffmpegのSSIM
SSIM Y:0.915586 (10.735878) U:0.982084 (17.467682) V:0.986489 (18.693172) All:0.938487 (12.110299)
ffmpegで出力したx264.mp4をmkvmergeでmkvにmuxしても同じ値
copy.mp4をlibx264でエンコードしてmkvで出力しても同じ値

ソースをmkvにmux(copy.mkv)した後にmp4にmux
ffmpeg -i copy.mkv -c:v copy copy-copy.mp4
↓
copy.mkvとcopy-copy.mp4のSSIMが1.0(inf)になる
copy-copy.mp4とorigin.m2ts(もしくはcopy.mp4)のSSIM
SSIM Y:0.922225 (11.091597) U:0.985489 (18.383000) V:0.989469 (19.775481) All:0.943976 (12.516286)

copy-copy.mp4をlibx264でエンコードしてmp4出力
↓
x264のSSIM
SSIM Mean Y:0.9828054 (17.646db)
ffmpegのSSIM
SSIM Y:0.983138 (17.731021) U:0.992124 (21.037030) V:0.993634 (21.961672) All:0.986385 (18.659951)

copy-copy.mp4をlibx264でエンコードしてmkv出力
↓
x264のSSIM
SSIM Mean Y:0.9828054 (17.646db)
ffmpegのSSIM
SSIM Y:0.915586 (10.735878) U:0.982084 (17.467682) V:0.986489 (18.693172) All:0.938487 (12.110299)

copy.mkvをlibx264でエンコードしてmp4出力
↓
SSIMは他のlibx264+mp4出力時と同じ

copy.mkvをlibx264でエンコードしてmkv出力
↓
SSIMは他のlibx264+mkv出力時と同じ

libx264+mkv出力とcopy.mkvを比較
↓
SSIMはlibx264+mp4出力とorigin.m2ts(copy.m2ts)と同じ

長すぎて>>250-253を誰も読んでないだろうからまとめると

・.mkvコンテナをmain、mp4やm2tsをreferenceにしてSSIMを計算すると値が悪くなる
・mkvmergeで作成したmkvでも同じく悪くなる/エンコーダーが計算してるSSIMは全く同じ/
「copyしたmkvとエンコードしたmkv」で比較した際は「ソースとエンコードしたmp4」で比較した時と同じSSIMを返す/
って点から中身に問題はなくてffmpegのフィルタがバグっている？
・mkvはガッツリ下がるがmp4でもエンコーダーが計算した値より1dbほど良くなる←？
・m2ts→mkv→mp4にcopyで変換するとmp4でもmkvのSSIMになる←？？？

何がどうなってるかよく分からんが一応メモ残しとくわ…

肝心な事忘れてた
結局MKVコンテナとそれ以外のコンテナでSSIMを比較するなら
AviSynthでDGDec系かL-SMASH使って読むのが手っ取り早かった
後者はffmpeg使ってデコードしてffmpegに渡すって絵面だけ見たらバカらしい事になるけど…

ssimは気にしたら負け

違うフレームを比較してるんじゃね
MKVコンテナに入れ替えたときタイムベースの精度が落ちたか固定フレームレートになるなりしたか

こうした場合は？
ffmpeg -r 30000/1001 -i copy.mkv -r 30000/1001 -i origin.m2ts -an -filter_complex ssim -f null -

>>258
それだとmkvでも1.0(inf)になったわ

>>257
確かにVFRになってた…というかBDのm2tsってCFRじゃないんだな？(MediaInfo見る限りは固定とも可変とも書いてない)
でmp4にcopyした方は
Frame rate mode : Variable
Frame rate : 23.976 (24000/1001) FPS
Minimum frame rate : 23.974 FPS
Maximum frame rate : 23.981 FPS
になってた

これだけならmkvに入れるとフレームレートがおかしくなるからやめましょうねチャンチャンなんだけど
じゃあ一旦mkvにして失われたフレームレートやタイムベースがAviSynth嚙ましたりx264にエンコードして.mp4出力すると復活するのは何なんだろう…わっかんね…

>>259
いつもおまじない程度につけてたけどやはり効果あるようだな

mkvはそもそもフレームレートって概念ないからssimフィルタ内かその前かでフレームごとのタイムスタンプがぐっちゃになってんじゃないか

もしかしてtracに報告している人？

>>259
確かにmkvに入れるときタイムベースとPTSが書き換えられてるなら同じタイムスタンプ(＝タイムコード)にはならないぞ
タイムベースの分解能の差から生まれる違いはこう生まれる
1001/30000秒*1tick=33.366666666666...
1/1000秒*33tick=33
フレームレートなんてものは無くて、ただあるのはタイムベースとPTSなんだともいえる

失われたフレームレートやタイムベースが復活するの意味がよくわからないが、また24fpsになるってことなら
MKVコンテナのdefault durationかコーデック（H.264のビットストリーム）のフレームレートを読んでるんじゃないか、知らんけど
フレームレート情報の格納場所はコンテナだけじゃないし

コンテナによってタイムスタンプが違うのは前提で>>250が使ってる
-lavfi "[0:v]settb=AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=AVTB,setpts=PTS-STARTPTS[ref];
ってのがそれを仮想的に揃えるコマンドなんじゃないの？ドキュメントにも別コンテナで比較する時に使えって書いてあるし

コンテナが違う場合は
settb=AVTB
じゃなくて
settb=1/AVTB
にしないとダメらしい
-lavfi [0:v]settb=1/AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=1/AVTB,setpts=PTS-STARTPTS[ref];[main][ref]ssim
でmkvと他コンテナで比べてもジッター無しで測定できるってさ

確かにタイムベースが逆数で扱われる場面があったな、理由はよく知らないけど
Time Baseって言葉に共通規格みたいな定義無いのかな

皆様、29970/1000になってしまう件の検証本当にありがとうございます。

にもかかわらず、あまり手が付けられておらずすみません。
ただ、29970/1000と誤認されるファイルの共通点が見つかりました。
エンコーダーのバージョンが
x264 core 142 r2409M+r890[x86] release1
今のところ、全部これでした。
(これ以前のバージョンの動画は持ってないです。

x264 core 148 r2665以降では発生してません。
違法なものではありませんが、自分でエンコしたものではないので、使ってるソフトとかも分かりません。

LAV LAVFiltersでデコードする時も同様の状況なので(そもそもffmpegとデコーダ共通かもしれませんが…)
もしかしたら、読み込みではなくエンコードの方がおかしいのかもしれません。
ただ、ブラウザでは期待通りの滑らかな再生ができるので、何とかなりそうな気はするのですが…
サンプルできたら持ってきます。

mkvの話が出てたけど8月あたりから
-default_mode の初期値が passthrough になってて、デフォルトトラックの概念の無いコンテナからそのままmkvに出力すると
今までは自動的に映像/音声/(字幕)の各1トラックに付与されてたデフォルトトラックフラグの無いmkvが生成されるようになってるから注意な
別に実用上問題は無いけど

VFRと小数フレームレートが合わさるともう大変だな

ffmpeg-windows-build-helpersでビルドしてたけど最近あんまりスクリプトのアプデが活発じゃないから
rav1eには対応しないし既に上流でマージされたパッチほったらかしだったりバージョン指定してるライブラリがえらい古かったり
media-autobuild_suiteに乗り換え時なのかな
自分でスクリプト編集しろ？ｱｯﾊｲ

タイムベースの話を聞いて、AAC-LCとOpusはよく使われるタイムベースが違うのにフレームサイズが20msに近いのはなぜだろうとおもった
近づけたのか？

>>266
タイムベースの逆数がタイムスケールってやつだとおもう、たぶん、自信ない
こういうことなんじゃないかと箱根駅伝を見ながら描いたイメージ図、あってるかな
https://imgur.com/a/YxWn1UT

>>272
タイムスケールか……仮にその関係性が正しいならコンテナごとに実はタイムスケールを採用してるとかだとしっくり来るね

図は合ってると思うけどタイムベースって1つずつ全部並べるイメージ無かったなぁ
数直線上に（フレームが存在するtickだけ）丸め誤差による1tickのずれを無視すれば等間隔に存在するイメージ

ねんがんのWSL2+Ubuntu入れた
ビルドはまた今度

>>273
そうそうタイムベースが1刻みずつ数直線上に並んでるイメージで描いてた
複数のトラックと同期を取るため必要十分な精度のクロック的な見かただった
等間隔に存在するイメージというのもわかる、動画のフレームに着目すると3003tickのかたまりが並んでるイメージ
タイムベースしだいで誤差が出る件はもやもやしてた
こっちは誤差のn-tickのずれが現れるのはタイムスケールがフレームレートで割り切れないときで
複数トラックそれぞれのフレームレートの公倍数にタイムスケールを設定するとずれが現れないということだとおもう
MPEG2-TSのタイムベース1/90000はNTSCの30000/1001、PALの50、音声の48000/1024、48000/1536でうまく割り切れたからたぶん

朝起きたらrelease 5.0とかいうのがffmpegのgitに出現してるけど4.5の次5.0になるの？

>>276
https://semver.org/lang/ja/

いやこの時機でメジャーアップデートなのかって意味じゃないの？

ビルド方法って何がいいの?
公式?

ビルドアップ！

音声と動画の結合にかなり時間がかかります（元動画の3倍位）
その間ずっとCPU使用率100%なのが怖いし、いい方法ないですか？
ffmpeg -i input.mp4 -i input.m4a output.mp4

GPUを追加する

そのコマンドだけだと変換が入ってる
無変換で結合するなら-vcodec copy とか-acodec copyを入れる

>>281
ffmpeg -i input.mp4 -i input.m4a -c copy output.mp4

どうも有難うございます！
あっという間に終わりました！
今まで開きっぱなしで負荷をガリガリかけてたのは何だったんだ・・・

>>285
再圧縮のために時間がかかって、再圧縮のために電気代もかかって、再圧縮のために画質と音質を削ってただけだからあまり落ち込まないで…

デフォルトってH.264とAACなんだな
H.264はいいとして、AACは音質悪いのでは

>>287
オプション指定しない場合は -c:v libx264 -crf 23 -c:a aac -b:a 128k 相当だった気がする

いまのAACネイティブエンコーダーはデフォルトでも問題ないよ
かつてのlibfaacとかlibvo_aacencはそのままでは使えなかったはず

>>286
セイロン島に（・∀・）ｶｴﾚ!!

>>289
そりゃ192kbpsや256kbpsみたいな他のエンコーダーでもほとんど差が分かんないようなビットレートならそうだけど
128kbpsぐらいまで行くとあ〜〜〜ってならない？
俺はOBSでそうなった

低いビットレートというか、ソースにノイズが多いとキュルキュルになる

videotoolboxと hevc_videotoolboxもデフォルトじゃ使えなくなった

4.5の霊圧も消えて4.4(.1)の次が5.0になるようだ
だからってなんかあるわけじゃないけど

ffmpeg -iでも判定されずmpc-hcでもvlcでも再生できず極窓でも拡張子不明なファイルって諦めるしかない？
拡張子はwmvだけど中身は違ってるっぽい。
バイナリエディタでも見たけど判読可能な英単語などは含まれてなかった。
wmvだとエンコード情報が判読できる。
zipやrarに固まってることもなかったし先頭にHTMLレスポンスのゴミがついてるということもなかった。
2000年頃の分割warez時代からの生き残りだから試せることは試したつもりなんだけどなぁ。

現物のうｐキボンヌ

バイナリエディタで先頭部分とビットマップ表示をキャプって貼ってくれないか
推測しようにも手がかりが無さすぎる