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だと、画質が良くなり、エンコ速度も速いてことか？
doomで散々議論されてる 限界まで圧縮高めればノイズも出易い
サイズが縮まるのと画質が良くなるのはイコールじゃないって事 submeを「限界まで圧縮高める」ものだと思ってるのか >>344
サブピクセルに対して動き予測を行う精度が高い→圧縮率を高める可能性がある→高圧縮
無能で理解できてない癖に揚げ足取ってる俺カッケーってかwww どうやらsubme上げると圧縮高まってノイズが出やすいらしい
新説だなｗｗ けど実際にガッツリ削れてブロックノイズが出たた気がする submeなんて「ソースによる」としか・・・。
別に11だけに限らず、「7より8にしたほうがエンコ速度が速くなった」とか過去に自分もあったし・・・。 自分の目にはsubmeは9が一番画質いいように見える >>349
動き予測妥協してるんだから速度は早くなるだろ 昨日久々にaviutl一から環境作り直したけど
エンコした動画重い設定じゃないのにシークがクッソ重くて参った、なんでや！ keyintのデフォ値はなんであんなキチガイみたいな値なんだろうな ゴミCPU使ってなきゃGOP300でも気にならんがなぁ >>356
palだかの25fpsの10秒分で250って話らしいね
デフォルトとしては確かに自分も微妙な値だと思うｗ シークの重さなんて、設定とか環境とか使ってる再生ソフト次第でもあるし、それらを明示しないとなあ。 keyintはBDだと1秒分のフレーム数だし、私もそれに合わせている そうだね。以前はOpenGOPがMP4で定義されていなかったりしたけど、今は特にデメリットを思いつかない 動画配信とかの用途ではopengopを使うと不具合が起きるみたいだね
ローカル保存のエンコードなら基本的にopengopでいいだろうねー BDだと最大キーフレームは最大2秒でしょ
60p除く keyintは最大GOPサイズの指定であって、それ以下でも必要と判断したら勝手にIフレームにするから
ほとんど動かないシーンが長時間続いた場合にどこまでシークしやすくするかを制御するものだろう
>>367
確かに全てがfps非依存であるべきというのは言い過ぎだった(refとかbframesとか)
けどkeyint/min-keyintの用途からいってfps依存にする必要ある？って思うわけよ 単に最大間隔を広げるだけだと思ってる奴が多いが
実際には「必要と判断する」部分で「直前のkeyからの距離のkeyintに対する比」を使うので
keyintをでかくすると必要な部分にも入りづらくなる というかその必要な部分の判別はどうやってやるの？
それとも思い込み？ > それとも思い込み？
こういうことを平気で書く輩に対しては、何も答えたくないだろうな x264 [info]: frame I:31 Avg QP:31.14 size: 50769
x264 [info]: frame P:1337 Avg QP:33.32 size: 15607
x264 [info]: frame B:2813 Avg QP:33.49 size: 4962
x264 [info]: consecutive B-frames: 10.3% 13.1% 7.8% 25.2% 12.1% 16.2% 6.2% 4.4% 0.4% 1.4% 0.8% 0.6% 0.0% 0.3% 0.0% 0.8% 0.4%
x264 [info]: frame I:49 Avg QP:30.33 size: 48096
x264 [info]: frame P:1472 Avg QP:33.25 size: 14425
x264 [info]: frame B:4233 Avg QP:32.26 size: 3227
x264 [info]: consecutive B-frames: 7.5% 9.7% 5.7% 20.1% 9.4% 13.2% 5.6% 4.2% 1.1% 2.3% 2.3% 1.9% 0.5% 0.5% 1.8% 2.5% 11.8%
同一ソースを動いていないフレームをタイムコードで引き伸ばしたのと、ループして周波数合わせたやつを同パラでエンコしたのだが、
Keyint狭くした方がいいのかな >>372
どっちがどっちなのよ
あとx264にわたってるfpsは同じなの？
x264は入力fpsでcrfの品質基準が変わるから注意 x264ってタイムコード入力できるからfpsって必要ないんじゃないの？
それともタイムコードはレート制御に使われないの？ >>373
フレーム数を見ていただければ分かるように、上がフレームを削ったもの、下がループしたものです >>375
どこまでインテリジェントに対応してくれるんだろう・・
入力されたファイルのfpsが30fpsだった場合、不明・24fpsの場合と比べて
crfの数字に0.2～0.3ほど内部で増やされるんだけど、その適応もしてくるれるんだろうか >>370
IDRフレームが挿入されるタイミングは、
100 * (1 - (Pフレームのビットサイズ) / (Iフレームのビットサイズ) ) < scenecut * (直前のIDRフレームとの間隔) / keyint
の式で求まるらしい。
IDRフレームってのはH.264/AVCから追加されたフレームで、特定のフラグを持ったIフレームとしても機能するフレームの様だ。
IDRフレームとIフレームしっかり区別して解説しているWEBページは少ないようだ。
ちなみにH.264のGOPの境目はIDRフレームになっている。なのでこれがキーフレームなどと呼ばれる。
さっきの式を計算してもらえば分かると思うが、keyintを大きくすると「直前のIDRフレームとの間隔」が近づきにくくなるので、IDRフレームが挿入されにくくなる。
それを>>369は説明していたのだと思う。 そのIDRフレームってのは、H.264はIフレームでも前後フレームと関連つけてあるから、関連性をリセットするIフレームってことでしょ？ OpenGOPだとIDRフレームは生成されないよ
GOPはあるし、シークできるけどね IDRフレームでしかシークできないわけではないし、OpenGOPは「GOPが無い」わけではないからね。 BDMV互換重視してるから
UHD-BDにオーサリング出来るようになってx265がUHD-BDのフォーマットに完全互換出来たら乗り換えるわ
まあ、UHD-BDはインターレースをサポート外したから、インタレ素材は実質アプコンしないといけないからH.265にする意味があんまりなさそう >>383
使ってるよ
別にこのスレに書いてるからと言ってx265を使っていないことにはならない youtubeのことかと思ったらyou達（たち）だったのね 何年も前から使えるなら移行する気満々で環境だけは整えてるけど
使い物にならん、使える環境が激狭いまんまなんでどうにもならん できるならH265にしてるだろうけど、エンコードも再生もそこそこ性能が必要だから現状厳しい 一番の問題はx265の完成度が低すぎる所
規格上はH.264の二倍近い圧縮効率と謳ってるが、
x264とx265で似たようなSSIMになるようにエンコしても、
速度倍かかるのに対して容量3割程度しか削減出来てない H.265が「H.264の2倍の圧縮率」てのを発表したのはSSIMではなくてPSNRでの評価。
んで、そういう機械評価ではなくて、実際の主観的な評価（眼で見た時）はどうなのかと、圧縮率をH.264の倍にしてテストも、92.5%はテストクリア（半分にしても違いが分からない）という結果が出ている。
ttp://www.bbc.co.uk/rd/blog/2016-01-h-dot-265-slash-hevc-vs-h-dot-264-slash-avc-50-percent-bit-rate-savings-verified >>390
8bitでエンコしてあればx265のエンコ動画はスマホでも余裕で再生できるけど？ 馬鹿でも出来るという言葉があるが馬鹿の程度にもよるしな x264vfwの最新版が7月で64bit版は15年で止まってるんですが
もう作らないという事でしょうか？自分がよく使っているソフトは64bitなので
最新版は使えないっぽいですが >>396
統合されたので、最新版を入れれば32bitと64bitの両方が入るよ。 あ、そうなんだ㌧クス 翻訳サイトで読んだけどちょっとよく分かりませんでした >>392
規格作った所の公式テストの話じゃなくて、x264に比べてx265の最適化が発展途上って話なんだが >>392
どうせ比較したH.264エンコーダーが糞なんだろうな
x264はmp3でいうLAMEみたいに規格内で極限まで最適化を志向するエンコーダー 規格とエンコーダの違いがわかってなくて規格(机上の空論)だけで比較した気になってる人でしょう 1passVBRのcrf指定でエンコする場合、presetはどれに設定しても
crfが同じなら容量は変わっても画質はほぼ同じになるの？ >>403
画質という表現だとちょっとあれだが、前にSSIMを調べた時には
fasterより早いプリセットは他に比べて明らかに値が低くなってしまっていた気がする。 >>403
機能的にはそのはずだけど画質はfasterとslowではそれなりに差が出る
使える機能を絞ってるわけだから当然なのかなと思ってる ありがとう。MicroSDも随分大容量になった昨今、エコ的には容量に
振った方が良いのかな、と思ったんだけど微妙だね。 ハズレ石の6700Kで夏場は水冷でも熱暴走しまくって、OCを4400MHzに抑えてたが、
ようやく涼しくなって常用最大の4600MHzまでやっても落ちなくなったわ 電源をずしんと重いやつに変えれば夏でも安定すんじゃね？ >>408
オンボ環境で1000Wの電源積んでる(将来のグラボ追加のための皮算用)んですがね ライゼンはええわ
1700@3.6GHzで地デジソースがveryslow＆お気に入りフィルタの重めの設定でリアルタイムfps出てるわ
6700K@4.6GHzだと実時間の倍掛かるのに 流石にその比較で2倍違うのはおかしい
もちろん実時間の倍かかるというのが1.6倍とかのことなら分かるが こんな人間いるのかな？って突如疑問に思ったんで質問してみる
BDにはいってるAVCをx264で再エンコしてる人
こんな人いる？
これってもうガッツリと容量削減だけが目的？ BDのH.264ってとりあえず最高ビットレートで入れとけって感じだから、再エンコでも結構縮む
そもそも深度8bitの時点で知れてるし >>424
ああ そういう感覚なのか
容量あるから考えなしにビットレート高くしとけっていう事ね
ありがとすっきりした 720p付近で作ってるアニメなら容赦なく720pにしちゃう >>423
BD-BOXをエンコしてBD-R SL1枚にまとめれたら最高じゃね？
あとは特典だけ手元に残してBD-BOXをオクに流せばいいだけ。 一度HDDにエンコして入れとけば見たい時にサクッと見られるからな
毎回blu-rayディスク引っ張り出してディスクセットがめんどい BDを再エンコするのはノートPCでいつでも気軽に見られる様に入れておきたいって用途しか無いなあ
だから容量削るのに720Pにしちゃうし画質はそこそこで早さ優先にしてる 何でエンコするかは各自の自由な。
俺もエンコはx265(アニメならpreset 8+12bit+crf16)の一択になってしまったが。
BDソースだとavsフィルタとか無理に加える必要もないしエンコもだいぶ省略できる。 x264はaviutlでサクッと編集して4:4:4 Predictive+10bit+crf16ぐらいで妥協してたな。
24分アニメあたり800～1.3GB前後で収まれば御の字だし 俺はアニメなんてエンコしなくてもエンコ職人がP2Pで流してるからそれ拾うわ
自分でやるの時間の無駄だし面倒だから 地デジソースとかエンコ職人がアップしたやつを見たこと有るけど
60iテロ処理とか雑に処理しててドン引きした。 テロ入っちまった時点でゴミだからそんなもんに手間かけても仕方ないがな
静止シーンでコピペして潰せるとかならともかく いや、テロといっても横スクロールのやつな。地デジでは恒例だろ。 補間フレーム生成したりVFRにしたりとかしてまでテロなんぞを滑らかに動かさなくてもいいよ
存在してるだけでイラつくゴミが、これ見よがしにヌルヌル動いてたら余計腹立つわ
きったねー縞々で何書いてあるかわからないぐらいの方がざまあみろって感じでいいんだよ >>438
テロップに惨敗して負け惜しみ言ってるようにしか見えない 何度も見る事やないんやけんある程度見れてたらそれでええわ ■ このスレッドは過去ログ倉庫に格納されています
