x264 rev43©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Q ニコニコ用の動画を作りたい。
A 板違い。Youtube板の"FLV/MP4エンコードスレ"でどぞ。
Q 圧縮codecありませんか？AviUtlのx264guiEx.auoの使い方は？
A x264 VFW GUI専用スレでどうぞ。
x264vfw GUI専用スレ Part9
http://peace.2ch.net/test/read.cgi/avi/1351856057/
Q コマンドラインの使い方が分かりません
A 初心者スレでどうぞ。
x264 初心者質問スレ part6
http://peace.2ch.net/test/read.cgi/avi/1347527423/
[本家]
http://www.videolan.org/developers/x264.html
http://git.videolan.org/?p=x264.git;a=summary (ソース/チェンジログ)
http://web.archive.org/web/20150419065724/http://x264dev.multimedia.cx/ (開発者ブログ跡地)
http://web.archive.org/web/20141203142708/http://doom10.org/index.php (公式フォーラム跡地)
irc://irc.freenode.net#x264(ユーザー用IRCチャンネル）
irc://irc.freenode.net#x264dev(開発者用IRCチャンネル） アドバイスお願いします。
動きのあるシーンで動いた部分のディザーやグレインが保持できないのですが、どうすればよろしいでしょうか？
動きの少ない部分では保持できています。
パラメーターはcrf 18、umh、subme 10、psy-rd 1.0:0.3、aq 3:1.00、bframes 6、b_pyramid 2、b_adapt 2です。 --qcompを盛ってみる 0.8とか
--qpstepを盛ってみる 8〜16とか あんまり大きくしすぎても良くはならない気がする
--bframesを減らしてみる デフォルトの3とか deblock -2:-2, psy-rd <unset>:0.25, no-dct-decimate, ipratio 1.1, pbratio 1.1, aq-strength 0.5, deadzone-intra 6, deadzone-inter 6, qcomp 0.8
tune grainの中身らしいから、これを軸にいじってみればいいんじゃない 質問スレとかなくなっちゃったんだね
みんなって、最新のリビジョン使って本番エンコしてる？
さすがに最近はやらかしとかないよね posix versionsって何？
Linux用？ x264で盛り過ぎると再生(デコード)時にやたら負荷のかかるパラメータってなんだっけ？
前にx264でエンコした動画をスマホのVLCで見ようとしたらコマ落ちが酷くてだいぶ厳しかった。 x264 core 148 r2744 b97ae06 High10 Lv5.1
Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10
psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1
cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2
sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0
bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0
weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60
rc=crf / mbtree=1 / crf=15.5 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
ちなみにこんな設定。 refもbframesもスマホ向きじゃないぐらい大きいね 解像度によってはref16はかなりのハイレベルになるよ 8bitエンコにするなりrefを3~4にするなりbframesを減らしてみるなり手はあると思うんだ エンコ環境やノートPCでは何の不都合もなく再生できていたから
スマホでも行けると思って再生してみたら、ほんとやらかした感に満たされた。
画質を選ぶか負荷低減を選ぶか、どこで線引きするか悩むところだね。 少なくともbframesは盛ったところで縮みはするけど画質が上がるとは限らないと思う
refはどうなんだろうな以前盛ったり減らしたりしたけど特段盛りまくってもエンコ速度とSSIMを比べると効率が悪くなる気がして4ぐらいまでしか使ってないな 素人で再生互換性とかよくわからないからほぼデフォルトプリセットしか使ってない 費用対効果的に
ref 4
bframes 3
以上は微差しかないな まあBフレ増やして節約した容量分、crf下げれば
画質は良くなるけど再生負荷は高いよね veryslowベースの設定なのかもしれんが、「crf=15.5」ってのも結構やばいのでは・・・
Hi10pな上に、ここまでcrf値を下げる人ってあまりいないんじゃないか？ 他のコマンドにもよるだろうけど、crf16あたりからが人間の眼では劣化が分からなくなるんじゃなかったっけ？ どこが悪いというか、スマホで動かすには悪いところ多すぎてわらたｗ スマフォならHWデコードだから大して差は無いと思うが、そもそも10bitデコードに対応してる機種なの？ ハードウェアデコードとはいえ、無制限ではないからな。
想定はBDの規格内と思ってたほうが良いと思うぞ。 >>122-123
H.264の10bitのHWデコードに対応してるものなんて無いだろ。10bitはSWデコードのみ。 ちゃんとVBVを設定してHigh@4.1までならどのハードでも安心 >>123
その制限がプロファイルとレベルだと思うんだが範囲内ならドロップしたことは無いかなぁ
>>124
俺も見たこと無いんだが、スマフォでSWデコードはキツくねって言いたかった >>126
そうでもない
円盤はランダムシークに弱いからBフレも参照距離も3程度がベター
もっとも16とか指定しても使わなければ問題ないわけ（HWデコード全般で）だけど
万が一に備えると厳しめになる --crf *を指定しなくてもエンコ出来たんですが--crf 23とサイズが同じでした
crf指定無しだと--crf 23と同じ扱いになるんですか？ >>127
なんか、突っ込む気力が失せるくらい色々痛いな RFFフラグを使ったソフトテレシネ素材をx264でエンコしたいのですが、
ソフトテレシネのままエンコする方法はありますか？
一応プログラムも書けるのですが、libx264は使いたくないのでx264.exe使って
タイムコードみたいに、RFFフラグをファイルから入力させることができればベストだと思ってます
60i混在ソースなので、全部24p化するというのはできなくて
今の所フレーム水増しして60iにしてエンコしてるのですが、
ソフトテレシネのままの方が画質が良くなると思うんです
そんなに気にする必要ありませんかね --pulldown 32のオプションがあった気もするがこれがソフトテレシネであるかは忘れた >>135
それはソフトテレシネなのですが、フレームごとに指定することができない（する方法が分からない）ので、
60i混在ソースだと使えないんです zoneはきっと使えないから--stitchableと--sps-idを使って分割エンコして最後に結合すればなんとかなるんじゃない？
糞めんどくさいしややこしいから60iに統一してやったほうがいいしそこまで画質に差は出ないと思う なるほど・・・そこまでやるんだったらx264cliを改造したほうが簡単かもしれないですね。ソース読んでみます x264はMBAFFインタレだからインタレ保持にしてもPAFFインタレよりは符号化効率高いよな x264cli改造してRFFフラグをファイルから入力できるようにした
https://github.com/nekopanda/x264/commit/6d734de56d0bb7e1dc5c660634c9a2f4fb3bd02d
これでエンコしたやつ、H264のrawストリームはmpc-hcで再生してちゃんと再生されてるようにみえるんだけど
mp4にmuxするとおかしくなる。
L-SMASHだとfpsを引数で指定してるのになぜか出力がVFRになっちゃって
再生するとフレームレートが半分くらいになっちゃう
MP4boxだとpulldownしてるところがちゃんと認識されないのかL-SMASHとは逆に1.2倍速くらいに速くなっちゃう
エンコはできてもmuxできないというオチorz
x264だとソフトテレシネはプログレッシブでのエンコードになるから、60iとの混在ソースだと
エンコ途中でプログレッシブとインターレースを切り替えるためにx264_encoder_reconfigを呼ぶ必要があって
なんか危なそうだし、やめておいたほうがいいかな >>140
うーんどうだろうH.264やmp4(ISOBMFF)の規格に詳しくないから分からない
もう全体的に60iとしてエンコしてしまったほうがいいんじゃないかな x264はインタレェでもそれなりに圧縮率いいし
--stitchableと--sps-idを使って最後に結合する方法は規格上問題ないとは聞いた
muken氏とかH.264とISOBMFFの両方に精通してる人に聞かないと正しい実装に出来ないんじゃないかな 感激！そうかmuxでずれるのはタイムスタンプいれてやればいいのか。夜試してみるわ すごく内容に興味あるんだけど、うまくいったらこの--pdfile-inの書き方を教えてくれないかな？ muken氏語ってるね
残業なくてもイエスマンが出世するようになってるからダメでしょ
そんな人に勉強の成果や能力の良し悪しの判断なんて土台無理な話
で、また、イエスマンが出世する
これじゃ、中卒か高卒で公務員になって趣味に生きるのが最もコスパの人生だからね
シャープ、東芝、かつての日産見ても学習できないんだからどうにもならん
すれちすまん うぉぉーできたー！timelineeditorでタイムコード入れたらちゃんと再生できるようになった。
mukenさんありがとうございます！
ただちょっと問題が。
PC(mpc-hc)、Xperia Z4 Tablet、PS3でそれぞれ再生してみたら、
PS3だと何の問題もなく再生できたけど、
mpc-hcだとたまにインターレース縞が見えるのと、動きが若干カクカクする。
Xperia Z4 Tabletだと、インターレース縞は全く無いけど、mpc-hcと同じように若干カクカクする。
タブレットだと画面がそんなに大きくないから、カクカクって言っても、よーく見ないと分からない程度だけど、
mpc-hcでちゃんと再生されないのはなぜなのか・・・
PS3だと本当に何の問題もなく再生できて、ブラビアのモーションフロー効かせても問題ないんだよな
再生側の問題なのか、mp4ファイル側に問題があるのか、分からん 家電系は放送の変態ストリームに耐性があるけど、PC系は違うんだわな
pulldownして全部iで出すデコーダと、p部分はpのまま出すデコーダがあったりして
後者の場合にi/pの変わり目で挙動が乱れるレンダラがあったりする すまん、カクカクだったのは俺のタイムコード生成プログラムのバグだったわ
直したらmpc-hc、Xperia Z4 Tabletともにカクカクはなくなった
これでXperia Z4 Tablet、PS3では全く問題無く再生できるようになった
ただ、mpc-hcだと、プログレッシブとインターレースの切り替わりで問題があるっぽい
インターレース縞が残ったり、フレームが一瞬戻ったりする
>>147まさにそういう状況だわ
変態ストリームというかPC系がちゃんと実装してないだけなんだよな
mp4のファイル自体は問題なさそうだから、これでソフトテレシネと
60iインターレースの混在ソースをそのままエンコードできるようになった
>>144
今作ってるフロントエンドのプログラムそのうち公開するから待って mpc-hcというかLAVはどうもインタレ、プログレ混在は苦手っぽい
PAFFインタレだと60i部分が30p再生されたりとか ffmpegだとフラッグのみbobすればよかったような 参照しているフレームの情報を利用したいんだけど、どうすればいいかな？
x264_adaptive_quant_frameのところを利用できるのが理想です。 あれから出力されたストリーム詳しく見たりしてたけど、
reconfigじゃインタレとプログレの切り替えはできないことが判明して
プルダウンのときはdelta_poc_bottomがゼロになるように改めて修正した
mpc-hcでフレームが一瞬戻ったりってのもなくなったし、
FFmpegでデコードしてRFFフラグをちゃんと取得できるのを確認したから、
規格上も問題ないストリームになったかな
>>144
pdfile-inはこんな感じ↓
https://github.com/nekopanda/Amatsukaze/blob/master/Amatsukaze/TranscodeManager.hpp#L1126 >>152
なんか本当に形になるとは思ってなかった
ありがたくウォッチさせてもらうは Ryzen 1700環境を手に入れたんだが、どんなに設定を弄ってもCPU使用率100％いかないんだが
同じような現象起きてる人いる？
AviUtl x264GUIからx264(2762)でエンコしてるんだが、どんなに重い設定にしても
aviUtl 8% x264 78%くらいのCPU使用率にしかならない。
aviUtl側はフィルタ全部外して、x264の軽い設定だとaviutl側で20％くらいCPUを使っているので
aviUtlがネックになっているわけでもなさそう。
なんかせっかくの16スレッド環境を無駄にした気がしてならない。 >>158
AviSynth+のMT版に以降して、Prefetch(16)を試してみたら x264GUIはややスレチだけど、メニーコアなCPUだとCPUを完全に使い切れないことは多い Ryzen7ならL3キャッシュが4コアずつに分かれてるから
タスクマネージャーの関係の設定でAviUtlの使用コアを若い方8個と後ろの方8個に分ければいいと思う >>158
aviutlスレにも書いたけど1本のエンコードで100%は無理
それでもAviutlと合わせて80%越えてたら十分でしょ x264に限らずフィルターもマルチコアに最適化されないとどうにもならないんだから
80%近く出てるなら十分だと思うけどな
avisynthで複合型のフィルターなんか使うと20%以下もざらにあるぞ まじか。今のx264だとまだ性能出しきれるほど最適化されてないのか。
x264のチューニング入るまでは開いたCPUでBONIACでも回しておくか。 最適化はもう限界に近いでしょ
アルゴリズム的に並列作業が増やせないものは仕方ないよ
今でも使用率上がってても大半の計算結果は途中で捨ててるくらいだし x264だけなら100%近く出せると思うけど実際にそれだけという人はいないから
結局の所は使うフィルター次第という話になってくる
avisynth+にフィルターをMTに対応させる機能もあるけど不具合と限界があるから1本の処理に拘るんじゃなくて
2本3本と処理する本数を増やした方が悩まなくて済むとおもうぞ 5960X環境だけどUt_videoのavi食わせてるだけなのに100％なんていかないよ
80%くらいをうろつく ベンチスレ見てても多コアなやつは100%までいってなかったような CPUが100%に張り付けばいいってもんじゃないと開発者が言ってたと思うよ。
エンコ速度に注視しろって事も付け加えられていたようん。 マルチプロセスでスレッド数を減らすことを意識したほうがいい >>168
それぐらいが丁度いいんじゃないの？
80~90%ぐらいが いままで8bitエンコしかして来なかったけどhighDepthオプションつけて10bitエンコにしようかと思うんだが
TS抜きした映像ソースを10bitでエンコする意味ってあるのかな？
TS自体が8bitだった気が・・・ なんで10bitエンコがいいのかぐぐればすぐわかること >>174
tsそのままだとあまり意味無いね
なんらかの技術で10bit精度に補間したものを改めて10bitで収録し直すみたいな形ならともかく >>175-177
あっ、なんか意図が伝わってなくてスマソ。アスペなもんで。
8bit深度に大してH.265で採用されている10bit深度の画質的メリットはもちろん理解
しているんですが、ソースが8bit深度の映像を10bitで出力したところで画質向上には
ならないんじゃないかなと思いまして。
いろいろ調べてもTSソースを10bit補間してエンコしたみたいな話は見かけないから
そもそも10bitエンコ自体普及してないのかなぁ・・・
最近閉鎖で騒がれているnyaaとかには10bit精度でエンコされた動画でわざわざ
アップしている職人もいたと聞くが。 hevcかどっちか忘れたけど素のまま10bitエンコするだけでも
多少の良い効果は得られるらしい
だからデメリットはHWデコードが対応してないと重くなるぐらいかな？ onedriveにアドレス残ってた
http://peace.2ch.net/test/read.cgi/avi/1418252184/
ここの70番あたりを読むと8bitソースを10bitなモードでエンコードしても効果あるということらしい >>179
それ言う人がいるけど勘違いしてると思うよ
D-A変換されたものがそのまままた10bitにA-D変換されて記録されるだけの事だから
同じD-A変換のアルゴリズムを使ってる限り8bitエンコードも10bitエンコードも変わらないよ jpegをjpegで圧縮するような状態だったのを
jpegをpngで圧縮する程度の効果はあるってことではないの 主にアニメとかでバンディングを軽減するため10bitでエンコするんだよ
なので、バンディングが気にならない人は、やる必要はあまりないかと
理屈はともかくいろんな人が検証した結果効果があると認められてる
まあ、自分で試してみればいい 色深度の話は圧縮とは別で
たとえ可逆圧縮だったとして8bitを10bitで記録しても8bitの深度にしかならないよ
>>180で展開されてるのはデコード時のディザの話で
これはつまりデコード時にディザを付加してるのだからデコーダーの補間の話になる
このデコーダーで8bit映像をデコードするのとそれを10bitで縁jコードした映像は変わらない
つまりこのデコーダーを使う限り8bitのソースで充分という事になる >>184
8bitの元ソースを8bitでエンコードしてバンディングが出るのはビットレートが低すぎるからだろう
近似値の平滑化の度が過ぎて目で見て分かるほど差が出てしまったという事だ
10bitでエンコードするよりその分8bitでビットレートを高くした方が良いと思うがな flash3kyuuDeband()
dfttest()
smoothgrad()
GradFun3()
このあたり使えば、補間してくれるよ >>188
()がつくということは失笑するレベルなのか。 >>189
マジで言ってるのかAviSynth知らないのか判断に迷う >>184
lavつかって再生すると、結局あんまりでないんだよなぁ >>186
8bitでバンディングを出なくするにはディザを残す必要があるからBD並みのビットレートが必要
少なくともフルHDで10Mbps以上。x264だとcrf=12程度が限界
だからTSを圧縮するには実質的に使えない ■ このスレッドは過去ログ倉庫に格納されています
