x264 初心者質問スレ part6

1 ：2012/09/13 〜 最終レス ：2013/09/14

x264 初心者質問スレ part5
こちらはx264.exeを使い始めた初心者のためのスレです。
x264のコマンドライン（CUI）の質問はこちらでどうぞ。
[本家]
http://www.videolan.org/x264.html
[バイナリ]
http://doom10.org/index.php?topic=3.0
http://x264.nl/
[前スレ]
x264 初心者質問スレ part5
http://toro.2ch.net/test/read.cgi/avi/1314616372/
[本スレ]
x264 rev37
http://toro.2ch.net/test/read.cgi/avi/1338222831/
[関連スレ]
MeGUIスレッド
http://hibari.2ch.net/test/read.cgi/avi/1164533110/
x264vfw GUI専用スレ Part8
http://toro.2ch.net/test/read.cgi/avi/1318232220/

2 ：

[FAQ]
Q x264.exeをダブルクリックしてもインストーラーが立ち上がらない。
A コマンドプロンプト用の実行ファイルです、インストーラーでも圧縮ファイルでもありません。
cliツールの使い方がわからなければ、ココで勉強しましょう。　サイトの情報そのものは古いです。
http://www.geocities.jp/encmemo5whf6jvag8/index1a.html#04-04
Q アスペクトの指定ってどうやるの？
A 704x480を4:3で見る時は--sar 10:11。16:9で見る時は--sar 40:33
720x480であっても、4:3なら--sar 10:11、16:9なら--sar 40:33
1440x1080を16:9で見たい時は、--sar 4:3
[関連スレ]
アスペクト比 part6
http://hibari.2ch.net/test/read.cgi/avi/1301521076/
[使用方法]
how to batch encode using CLI?
http://doom10.org/index.php?topic=218.0
C:\tool\x264.exe --profile main --crf 20 -o "G:\100\test_01.mp4" "G:\100\test_01.avs"
C:\tool\x264.exe --profile main --crf 20 -o "G:\100\test_02.mp4" "G:\100\test_02.avs" など。
[参考サイト]
X264 Settings - MeWiki
http://mewiki.project357.com/wiki/X264_Settings
x264 64bits
http://doom10.org/index.php?topic=106.0

3 ：

以上テンプレ。
なんかミスってたらスマン。

4 ：

いちおつ

5 ：

1行目からミスってた…
×x264 初心者質問スレ part5
○x264 初心者質問スレ part6
です。
すみません

6 ：

>>5
乙。
そこは名前欄に書くところをミスっただけだから気にすんな

7 ：

MPEG4コンテナに格納することを前提とする場合、OPEN GOPを使ったらいけないのでしょうか？
この辺の事情がよく分かりません。

8 ：

やつが来るぞ！ｗ

9 ：

>>7
Open GOPに限った話じゃないが、よくわからないオプションは弄らない方がいいよ

10 ：

>>7
compatible_brandsにiso6入れればいい

11 ：

下のようにエンコした720x480 ピクセル比10:11のmp4をMPC-HCで再生すると
プログレのcolorbars.mp4はピクセル比が反映された654x480(映像領域は640x480)のウィンドウで再生されますが、
インタレのcolorbars-tff.mp4はMPC起動時720x480のウィンドウになってしまいます。
ただし映像領域は640x480でアスペクト比は合ってますし、MPC-HCの"100%表示"でプログレ同様654x480のウィンドウになります。
この挙動の差はx264やmp4boxの使い方に起因してるんスか兄貴。
スプリッタ？と思ってPowerDVDのものからMPC内蔵に変えても変わりませんでした。
--- colorbars.avs
AudioDub(Colorbars(704,480,"YV12").Trim(1,150).Addborders(8,0,8,0).KillAudio(), Tone(15100/3003.0,1000,48000,2,"sine",0.1))
---　colorbars.bat
x264 --qp 10 --fps 30000/1001 --sar 10:11 --colormatrix smpte170m -o colorbars.264 colorbars.avs
x264 --qp 10 --fps 30000/1001 --sar 10:11 --colormatrix smpte170m --tff -o colorbars-tff.264 colorbars.avs
avs2wav colorbars.avs colorbars.wav
neroaacenc -lc -br 192 -2pass -if colorbars.wav -of colorbars.aac
mp4box -fps 30000/1001 -par 1=10:11 -add colorbars.264#video -add colorbars.aac#audio -new colorvars.mp4
mp4box -fps 30000/1001 -par 1=10:11 -add colorbars-tff.264#video -add colorbars.aac#audio -new colorvars-tff.mp4

12 ：

> スプリッタ？と思ってPowerDVDのものからMPC内蔵に変えても変わりませんでした。
とりあえず変えたのデコーダーっぽいけどねｗ

13 ：

>>10
MP4boxなどでMUXする際の-brandの指定オプションということでしょうか？

14 ：

ほとんど初めてのmp4作成で、fps指定とかムチャクチャっスね（汗
>>12
デコーダーは変えてないけど、スプリッタ変えたつもりが変わってなかった（汗
MPC内蔵にしたら654x480で開きました。
x264.exeが出力した.264はインタレも654x480で開きます。(この時はMainConceptのスプリッタ。)
なのでどうもPDVD11のCyberlink MPEG-4 Splitter(clm4splt.ax)っぽいッス。
ちなみにTMPGEnc 4.0 Expressで出力したmp4はPDVD11のスプリッタでも654x480で開くので、
mp4boxのオプション抜け？かとも思ったり・・・。
>>13
TMPGEnc 4 Expressのmp4に合わせて-brand isom:0付けても変わらなかったッス
mp4boxのinfoでそれっぽい違いは・・・
--- x264+mp4box
Visual Track layout: x=0 y=0 width=654 height=480
AVC/H264 Video - Visual Size 720 x 480
Pixel Aspect Ratio 10:11 - Indicated track size 654 x 480
--- TMPGEnc 4.0 Express
Visual Track layout: x=0 y=0 width=720 height=480
AVC/H264 Video - Visual Size 720 x 480
Pixel Aspect Ratio 10:11 - Indicated track size 720 x 480
挙動からすると逆っぽいですけど、こうなってます。
まぁキー一発で654x480になるし別にいいんスけど、気になってしまうｗ
エンコファイル等 ttp://www1.axfc.net/uploader/Sc/so/378976.jpg

15 ：

jpgじゃなくて ttp://www1.axfc.net/uploader/Sc/so/378976.zip です（汗

16 ：

日本語不自由すぎていみわから
>>14は>>7とは別人なんだろ？それなのに>>13に答えてるし頭大丈夫か？
しかも-brand isom:0にしたって書いてるけどそれでcompatible_brandsにiso6が入るわけないし
糖質臭しかしないぞ

17 ：

ttp://fsm.vip2ch.com/-/sukima/sukima068154.jpg
この画像の鼻の辺りにある縦しまと
髪の辺りにある横しまは何と言うノイズでしょう？
それとこのノイズの消し方を知ってる方がいたら教えてください
TSファイルをaviutlで読み込み、x264GUIexのプリセット、
アニメ（高圧縮）で1280ｘ720にてエンコードしたものです
・動きの少ない単色ベタ塗りの所に発生します
・茶色っぽい色のところに発生します
・元のTSファイルにはこのノイズはありません
・品質基準VBRのQualityを23から16にしてみましたが無駄でした
・使っているフィルタはインタレ解除だけで、なしにしてみましたが無駄でした
たまにしか出ないノイズなのですが動きの少ないシーンに出るので気になります
どうかよろしくお願いします

18 ：

リサイズもやめて試してみたら

19 ：

>>17
自分とこでも最近気になって調べてるところだから間違ってたらスマンが
スミアノイズだとしたらdeblockのかけ過ぎらしい

20 ：

ありがとうございます
リザイズ無しとdeblockの値を減らして試してみます
ファイルサイズも小さく綺麗に出来るのですが
このノイズだけが気になるんですよね・・・困った

21 ：

こだわりたいならプリセット使うな

22 ：

deblock無しを試してみましたが変化無しでした
リサイズ無しにするとノイズが消えました
しかしファイルサイズが3倍近くに・・・
でもaviutl標準のノイズ除去をかけるとりサイズしてもノイズが無くなりました
x264関係無かったようですみません、助言してくださった方、ありがとうございました

23 ：

リサイズの方法って糞ほどあるから
色々とググったり試したりしたらいいよ

24 ：

refって盛っても意味ないの？
ref4を1に落としても全然画質変わらないんだけど

25 ：

サイズも変わらないのだろうか

26 ：

変わらないってのが何を持って変わらないって行ってるのかが大事だな

27 ：

どうやって変わらないと分かったのかね・・・

28 ：

x264にavsとかを使わずに複数のRawビデオを直接入力して、一本の連結した動画にして出力する事はできますか？

29 ：

x264に渡す前にくっつけておかないといけない

30 ：

ref 4にしたいのがb-pyramid strictで-1されるから補填で+1してref 5にするのは
1920x1080 Level 4.1でリミット超えのwraningでるけど
再生でDxVA1で崩れないから範囲に収まってるのかな
b-pyramid noneやnomalの場合は崩れるからストレートにref 5になってるんだろうけど

31 ：

>>30
1920x1080のLevel4.1はref=4、fps<=30が上限のはず。
x264スレの
　　http://toro.2ch.net/test/read.cgi/avi/1338222831/652-654
によると、b_pyramidによるrefはDPB制限のrefとは関係しないらしいがよくわからん。

32 ：

あれ？無関係なの
んーいけるように見えるけどなんか危なっかしいからref 5はやめとくyo

33 ：

>>31
そのリンク先の説明はそういう意味ではない

34 ：

>>33
マジか、ごめん。俺は
　　・MediaInfoのReFramesに表示される値は、b_pyramidが影響するため--refで指定した値と違う場合がある。
　　・レベルによるDPB制限の計算は、あくまでも--refに指定する値と関係するものであり、
　　　b_pyramidは無視して計算されるもの。
だと解釈してしまったのだけど、間違ってるなら解説してもらえると嬉しいですorz

35 ：

>>34
あー そういうことでだいたいあってる
こっちが>>31を曲解してた

36 ：

>>35
あー・・・自分で読み返して見ると>>31の書き方も中途半端で悪かったです。
すみませんでした。

37 ：

720×480の録画ファイルのエンコード時
アスペクト比は何体何に設定すれば良いでしょうか
何度か試しているのですが、一向に比率が合わず、教えて頂ければ幸いです

38 ：

937 ：名無しさん＠編集中：2009/07/09(木) 08:45:18 ID:EFGaAyYg
1:1 (1280x720)
12:11 (PAL 4:3)
10:11 (NTSC 4:3)
16:11 (PAL 16:9)
40:33 (NTSC 16:9)
4:3 (1440x1080をDAR 16:9に引き伸ばす)
SARはこれだけ覚えておけば良い。

39 ：

>>38
それを参考にして試してみます
レスありがとうございました

40 ：

最近のアニメDVDなんか見てると、40：33のものなんてほぼ皆無だけどな

41 ：

関係なくね

42 ：

こっちの方が詳しい
http://toro.2ch.net/test/read.cgi/avi/1301521076/

43 ：

>>40
マジで！？

44 ：

遅れましたが>>42さんもありがとうございました

45 ：

>>43
無効領域がなくて720x480いっぱいいっぱいに表示されてるからじゃない？
720x480のまま16:9にするならSARは32:27のはず。

46 ：

セルじゃないデジタルHD編集のDVDなら無効領域も糞も無い罠

47 ：

712x480から16:9にするとちょうどよくなるのが結構多い
SARだと320:267になるのかな

48 ：

sar3ケタはやめとけ

49 ：

命令セット AVX XOP FMA4 FMA3　をあえて無効にするコマンドはありますか？

50 ：

--no-asm
--asm

51 ：

言葉足らずですいません
--asm sse4.2 とすると切りたくないLZCNTやSSEMisalignまで切れてしまいます

52 ：

crfが一定なら、profileを変えても必要なビットレートが変わるだけで、
画質は変わらないのでしょうか？
試しにcrf=21に固定、他のオプションも同じにしてエンコードしてみたところ、
Baseline = 642Kbps、Main = 448Kbps、High = 458Kbps
で、画質にはほとんど差が無いように感じたのですが

53 ：

微妙に差は出るけどほとんど変わらない。が正しいかな

54 ：

>>53
やっぱりほとんど変わらないのですね
ありがとうございます

55 ：

同じ品質基準でも、高周波と低周波のどちらを重視するかとか
動いている部分をごまかすかどうかとか
差が出るだろ

56 ：

それを微妙な差と取るか大きな差と取るかはそれぞれの感覚
差が出ないなんて言ってない

57 ：

初歩的な質問ですいません
エンコード時にPCの負荷が高いと完成した動画の品質が落ちたりするのでしょうか？
例えば2つ同時にエンコードしたり、裏でエンコードしながら表で負荷のかかる作業した場合です
あくまでもエンコード時間が延びるだけで品質は変わらないのでしょうか？

58 ：

誰も差が出ないなんて言ってなくね

59 ：

変わらない
知っかかぶりして肝心な質問に答えれず煙に巻く人嫌い

60 ：

初心者はプロファイルなんて気にしないで全てBaselineで良いんだよ。
それで何も問題なんて無い。

61 ：

そりゃあんまりさね

62 ：

初心者はBaselineで良いはさすがに。
目的に合わせたプロファイルレベル決めるのがいいと思う。
再生したいデバイスがどのプロファイルに対応してるのかを調べるくらいなら初心者でも出来るでしょ。
>>57
これは >>52 で言われてるあんまり変わらないとかってレベルじゃなく、ホントにほぼ差は出ない。
--thread絞ったりすると若干結果変わるけど誤差レベル

63 ：

そうでしたか、ありがとうございます
PCがカクカクの重々になるのでちゃんと動画が出来上がるか心配でした
PCの前にいるとPCを触りたくなるし
PCの前にいない時は極限まで仕事させたかったので聞いてみました
ありがとうございました

64 ：

当然差は出る。だがそれをお前が感じ取れるかは別問題
ブルース・リーと一緒

65 ：

フィルムグレインが強く暗部が多い実写物(480i)ど、ファイルサイズが全然縮まない...orz
元ソース→1.24GB
エンコ後→987MB
おおまかな設定
profile=high/keyint=240/min-keyint=4/scenecut=70/b-adapt=2/ref=6/crf=17/rc_lookahead=60
vbv-maxrate=9800/vbv-bufsize=9800/qpstep=16/ipratio=1.50/aqmode=4/fade-compensate=1.0
qcomp=0.8/direct="auto"/weightp=0/me="umh"/merange=32/subme=11/psy-rd="1.00:0.25"/trellis=2
range="tv"/colorprim="smpte170m"/transfer="smpte170m"/colormatrix="smpte170m"/nal-hrd=vbr
acodec=none/input-range="tv"/sar="8:9"/level=4.1
その他
--trr --no-fast-pskip --no-dct-decimateを使用

66 ：

>>65
インターレース保持の720x480(アスペクト比4:3)でエンコ

67 ：

crfを19~20ぐらいにしてpsy-rdを1.00:0.03程度にしてみてはどうあｋ
さらに1kbpsでも節約したいなら横の解像度を640にリサイズ

68 ：

>>65
crf 20に変えて再度やってみたら780MBになった。
crfの値が1下げるだけで100MB以上縮むということってあるのかい？

69 ：

>>68
>crfの値が1下げるだけで100MB以上縮むということってあるのかい？
すまん、1じゃなくて2だった。

70 ：

>>68-69
3下げてないか
実写ソースなら20でも高いぐらいじゃないか？
視覚効果働くんだからもう少し低くても見る分には問題ないと思う。

71 ：

>>65
crf＝17、qcomp=0.8って高すぎかと
実写なら、crf21〜crf24、qcomp0.6〜0.8ぐらいの間で
調整して、自分で画質と大きさで妥協できる点を探したら。
ソースに寄るけど、qcompも0.1変わると大きさがかなり違う。

72 ：

chroma-qp-offsetも関係してるのかな？
>>65の設定だと-4になったけど

73 ：

フィルタでボケボケにしろ

74 ：

cabac=1 / ref=3 / deblock=1:-2:-2 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / psy_rd=0.50: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=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 /
bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=1 / scenecut=70 / intra_refresh=0 / rc_lookahead=48 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.80
/ qpmin=10 / qpmax=51 / qpstep=8 / ip_ratio=1.40 / aq=1:1.00
初心者です。↑こういう設定をコマンドラインにするにはどうしたらいいのでしょうか？

75 ：

頭に"--"を付けて"="を半角の空白に置き換えたらおｋ
こんな感じ↓
--preset slower --crf 20 --ref 3 -b 3 deblock -2:-2 --psy-rd 0.5:0.0 --qcomp 0.8

76 ：

コピペしてすぐに使えるように全部変換して書いとけって言いたいんじゃない？「初心者」だから

77 ：

AviUtlのx264guiEXプラグイン使えばMediainfoのその表記をそのままコピペで設定反映されるから
それを再度コピペすれば一応あまり手間かけずに出来るかな

78 ：

--bframes 3 --ref 6
--bframes 6 --ref 12
どっちが縮む？

79 ：

やってみればいいんじゃないのかな

80 ：

言われてから自分でやってみたよ
ソースは1分位のアニメのOP
bframesとref以外は同じ設定
--bframes 3 --ref 6…20.4MB
--bframes 6 --ref 12…19.8MB
後者のほうが少し縮んだ

81 ：

ref増やすと再生負荷が増えるってのはわかるけど
bframesと再生負荷は関係あるのかな？

82 ：

やってみればいいんじゃないのかな

83 ：

負荷というより再生環境によっては問題が出たりするな

84 ：

ちょっと質問
--bframes 3だと、うちの環境ではWMP9、XPだと、
最初の３秒ぐらいが早送りになるんだけど、MPCやKMPlayerなどでは正常
--bframes 0で早送りにはならずに、正常なんだけど、
ほかの人も同じ現象でてるの？
みんな--bframes 0でエンコしてるの？

85 ：

再生環境が糞
LAV Filtersでも入れればいいんじゃないかね

86 ：

>>84
edtsとかedit listでググれ
理解できなきゃLAVFiltersか、多少アレだがHaaliでも入れろ

87 ：

http://bule-ex.blogspot.jp/2010/03/mp4h264.html

88 ：

冒頭３秒早送りというのは古いHaaliのバグが原因じゃないだろうか。
　　Haali Media Splitterのedtsバグによる再生タイミングのずれの再現
　　http://www.nicovideo.jp/watch/sm10138237

89 ：

>>85>>86>>87>>88
さんくす、解決できる問題なんですね
まさしく>>88の左下の動画みたいになってた
ちょっと調べてみますありがとん

90 ：

chroma_qp_offsetの値はどこをいじることで変わるのでしょうか？

91 ：

rdo

92 ：

そのまま--chroma-qp-offset
それと--psy-rd

93 ：

正確に言うと直接的には--chroma-qp-offsetで指定するが、
--psy-rdを増やすとそこから更にマイナス方向に加算される。

94 ：

>>92-93
どうもありがとう

95 ：

--bframes 4 --ref 8
SD-8bitソースでもWMP12では真っ黒
merangeの値って32もいる？

96 ：

>>95
16とかでもいい気が。

97 ：

冒頭3秒早送りになる問題で、
バグなしの新しいHaaliを入れたら、正常に再生されるようになりました
でも、再生環境を変えるより、x264のバージョンをr1379より前のを使うと
正常に再生されるのでそれに落ち着きそうです

98 ：

>>97
いや、バグなんだからそこは再生環境をちゃんとしたものにしとかないと駄目だろ・・・。
r1379より古いものを使うメリットなんかないよ。

99 ：

古い情報に踊らされるな

100 ：

merange 24と32の比較
1分程度のソース
24
SSIM…0.9781199
fps…5.901 fps
ビットレート…1783.30 kb/s
ファイルサイズ…12.75 MB
32
SSIM…0.9781338
fps…5.864 fps
ビットレート…1779.41 kb/s
ファイルサイズ…12.72 MB
微妙な差だな

101 ：

古いHaaliと古いｘ264 or 新しいHaaliと新しいｘ264
選ぶなら迷わず後者のがいいと思うぞ

102 ：

LAVでいいだろ

103 ：

Haaliみたいにアイコン右クリックで色々と切り替えできないから
いまだにLAVに切り替えられない
おかげでALAC使えない

104 ：

プレイヤー側のショートカットキーで替えられるだろそんなもん・・・

105 ：

俺のプレーヤーじゃ出来ない

106 ：

Haaliってアラビアンな名前ですね

107 ：

>>103
HaaliとLAVどっちも入れればいいじゃん。
ついでに、MPC-hcのstand-alone filterとffdshow-tryoutsをいれれば、
どのプレーヤ使っても死角なし。

108 ：

>>98>>101
人の動画みたら、古いバージョンでエンコしてる人が多くて、これでいいかなと

109 ：

>>108
どこを見てるのか知らんが、お前が見てるもんがおかしい。
不安定で速度も遅いものをどうしても使いたいというマゾなら止めないが。

110 ：

>>108
AviUtlのx264guiプラグインでエンコードした物がそのリビジョンになるから見かけるの多いのかも

111 ：

>>109>>110
なるほど、ちょっといろいろ実験してみます

112 ：

ぜんぜんよくわかｒないけど
ウィ気どおりに、H264えんこする時には
まるちぱssでやってる
だって層かいてあるじゃん
でも品質基準ってやつの方がいいの？
どう違うの？
メリットとかあるの？

113 ：

あれ、GUIスレ落ちてんのか

114 ：

でき上がるものはどっちも同じだから
慣れたほうでやればいいだろ

115 ：

アホか

116 ：

容量指定したければマルチパス、品質指定したければ品質基準でやればいい

117 ：

その出来上がりの品質の基準となるものってある？
例えば実写ならこのくらいの数値なら烈火がほとんどない、とか
マルチパスの何bpsに当たるとか
後品質基準ってマルチパスに比べて早っかたりするの？えんこ

118 ：

Rーの満足度なんて個人差ありまくり

119 ：

2PASSやるよか速いよ

120 ：

>>113
あれ？少し見てなかったけどGUIスレいつ落ちた？10/30の982までしか取れてないや。

121 ：

>>120
多分それが最後。

122 ：

今までTSを960x540、-crf 21でエンコしてて、ファイルサイズは大体1/10でビットレートは1Mbpsくらい。
んで今日、重要度が低いから解像度をおもいっきり下げて640x360でエンコしたんだけど
出来た動画はいつもと同じ1Mbpsも出てて、ファイルサイズもTSの1/10で同じだった。
解像度を下げたからファイルサイズ つまりビットレートも下げて欲しいと思ったんだけど
-crfって解像度がなんであれビットレートはあまり変わらないの？
品質基準だから、解像度が下がればビットレートも下がると思ってた。

123 ：

>>117
crfいくつで劣化感じないかは映像次第だし個人差あるから試せ
実写ならcrf=21くらいでやってる
crfいくつでビットレートいくつと同等なのかはこれもまた映像次第で変わる。
動き少ないのならビットレート少なくていいし

>>122
同じ映像と同じ設定で解像度のみ変えたら分かる。違う映像で比べても無意味

124 ：

x264vfw GUI専用スレ Part9
http://toro.2ch.net/test/read.cgi/avi/1351856057/

125 ：

Hi10pやHi444pってどうなの？
圧縮率を上げるために使った方が良いのか
どうせH.265とか次世代規格がすぐ出て糞になるかもしれないから使わないでPC以外でも再生できるようにした方が良いのか
どっちが良いのん？

126 ：

そんなドマイナーなもので作った動画なんて使い道なくなるぞ

127 ：

PCがある限り何でも使えるだろ
DivXの時にそんな事思って使ってたか？

128 ：

refを3以下にしていても強制的に4にされる時があるのですが
どのオプションが影響しているのでしょう？

129 ：

このスレをrefで検索

130 ：

2passエンコードはできあがり容量を気にしなくて良い場合は基本的に必要ありませんか？
crfより綺麗とか、こういった動きのものには2passのほうが良いとかあります？

131 ：

2passのほうが映像の解析としてはビットレートの配分は良いらしいけど
普通はcrfで良いんじゃね

132 ：

返信ありがとうございます
FPSなど動きのめちゃくちゃ激しいものはcrfより2パスのほうが向いてるという感じですかね

133 ：

同一ビットレート、その他の設定も同一で、2passビットレート指定でやったものとcrfでやったものを比べるとcrfの方が綺麗に感じるという事もある
容量気にせず品質を気にするのなら迷わずcrfでエンコードだな

134 ：

そんなにこだわらないのが一番

135 ：

エンコなんかしないのが最善

136 ：

アニメと比べて実写のエンコって時間はかかるわサイズは殆ど減らないわで割に合わないな。

137 ：

まあ実写でもあんまり動きが激しくなくて固定ショットが多いと
わりと縮むけどね
今やってる是枝監督のゴーイングマイホームとか

138 ：

rigayaさんとこで、rev2229(64bit?)ではバグを抱えていたようだとコメントがあったんだが、
画質に関わるような深刻なものだったのかな？
32bit版使ってるけど、もうエンコしてしまったファイルが随分orz
rev2230なら今のところバグ報告は無いかな？

139 ：

将棋のエンコ最高

140 ：

test

141 ：

iPhone,iPadmini,XOOMなど
複数の画面の大きさが違うデバイスをもってる場合、
エンコする際の縦横幅はどういう設定にするのが基本？
それぞれエンコしないとダメ？

142 ：

好きにしろよ

143 ：

x264+avs2pipemodをBash/shell scriptでエンコードする方法を教えてください
avs2pipemodのx264rawオプションを使ってみたいので

144 ：

batじゃいかんのか？
bash使えるならそもそも質問しなくても分かるだろうしそれは最早x264関係ないよね？

145 ：

>>144
>bash使えるならそもそも質問しなくても分かるだろうし
x264に関係なくて失礼ですが、bashど初心者です

146 ：

何がしたいの？ひょっとしてLinuxでエンコしようとしてる？

147 ：

>144は要はスレチだから帰ってねってことだったんだが…
質問内容に一切x264関係しない

148 ：

>>146
違います
>>ID:BXj/vX4F
じゃあ、どこに行けばいいんだよ！

149 ：

てか、その質問内容じゃどこいっても同じ対応されるよ
bashでも良いけど一から教えてくれてんなら論外だし

150 ：

まずは自分でいろいろ試して穴だらけのスクリプトを作り
それから自分で該当するスレを探して質問するんだな

151 ：

こんなのレスするお前らの優しさに濡れた///

152 ：

>>148
UNIX板かプロクラム板へどうぞ

153 ：

PT2で記録したTSファイルをCMカットしてそのままBD-Rに焼いた場合と
そのTSを元にx264（mp4）に変換したのちBD-Rに直接焼いた場合とで
それぞれのディスクをPS3にマウントさせ直接読み込ませた場合に、
読み込み音がかなり違うのですが（TSが静か、x264（mp4）は壊れるのではと、常にガコガコ）
これはやはりこういうモノだと思って視聴するしかないでしょうか？

154 ：

そういうもんです

155 ：

High 10 Profileで--nal-hrd vbrを指定したときは--vbv-maxrateの値は通常の何倍の数値まで許可されてるのですか

156 ：

>>155
mainの3倍

157 ：

Hi10PはNAL-HRDの有る無しで変わったりしないんですねありがとうございます

158 ：

L-SMASHのcmdでmp4boxの-catみたいに結合できますか？
もし出来るならやり方を教えて下さい。
mp4boxで-catしていたのですが、PS3だと再生できなくなってしまうので
乗り換えたいと考えています。

159 ：

--help見ればわかるだろそれくらい
x264関係ないし

160 ：

nal hrdのオプションはインタレ保持エンコで必須？

161 ：

>>160
nal-hrdはストリーム内でVBV情報を正しく伝うためのものであって、
インタレかインタレでないとは全く無関係である。
ttp://mewiki.project357.com/wiki/X264_Settings#nal-hrd
特定の使用目的のみで利用する価値がある。

162 ：

以前はnal-hrdのパッチが無いと、フィールドオーダーの指定に必要なpic_structが付けられなかった。

163 ：

>>161-162
thk!

164 ：

Vapoursynthでエンコする時、以下のようなメッセージを出す場合はどうすればいい？
x264 [info]: started at Mon Dec 03 23:26:24 2012
[3.3%] 146/4407 frames, 5.190 fps, 2016.2 kb/s, 1.46 MB, eta 0:13:41, est.size 44.18 MB
x264は以下で配布しているものを使用
ttp://k4095-takuan.blogspot.jp/2012/11/x264vshigh-bit-depth-y4m.html

165 ：

>>162
いまでもアクティベートがおかしいのでNAL-HRDなしでエンコードすると規格違反ストリームが出る設定があるぞ。
x264チームにパッチ送ったがリジェクトされた＼(^o^)／

166 ：

そのパッチどこ？

167 ：

>>164
https://twitter.com/K4095/status/283932846362607616
https://twitter.com/K4095/status/283935823764783104

168 ：

>>167
vapoursynthのスクリプトが高度過ぎてワロタwwwwwwwwww
解説書ないと分かりにくい...orz

169 ：

上から下にフィルタ並べてるだけの俺に隙は無かった

170 ：

>>168
そんなに高度なことはしてないみたいよ
無理やり一つのファイルにまとめたせいか、バグも幾つか目に付くし

171 ：

>>170
書いた本人は当時酒に酔ってたからね

172 ：

>>166
俺のHDDの中とx264チームのメール受けた人んところにあるかもしれないね。
そもそもNAL-HRDなしでエンコードしない人だからどうでもいいといえばどうでもいい。

173 ：

>>172
x264-develには行ってないならそもそも開発者で多くの人には渡ってないと思ふ
ライセンスした企業でD_S氏本人に一つのパッチで渡しただけなら大体大きな
変更が付いてくるからそのまんまだと入れないでしょうしなぁ・・・
fixstarsのMVCパッチとか。
x264-devel、または#x264devには行ってないなら非常に残念ですよ。
オイラの単純なパッチでさえ入ったしなぁ。

174 ：

x264にavsファイルを食わしたら
=================
〜指定したコマンドライン〜
avs [error]: failed to load avisynth
x264 [error]: could not open input file `フルパス.avs'
=================
というエラーが出てエンコードできないんだけど原因はなんでしょうか
ちゃんとaviutlでは読み込めるからavsが壊れてはいないはずです
使ったオプション
x264.r2230_win64.exe --profile main --crf 20 -o "D:\フルパス\x264_out.mp4" "D:\フルパス\avs.avs"

175 ：

x264は64bit版みたいだけどAvisynthも64bit版使ってるんだよね？
後できればavsの中身も教えてほしいけど

176 ：

>>175
それです！それ！
32bit版で動きました！
即レスありがとう！pop氏にも感謝！

177 ：

>>176
avs2pipemodなどのパイプツール使えば32bit、64bitを別プロセスで処理できるから
32bit版Avisynthしか使ってなくても64bit版x264でエンコできるようになるよ

178 ：

>>177
レスありがと〜。。調べたらwav出力対応とか地味に便利そう
感謝感謝

179 ：

>>165
>>172
As the author of NAL-HRD I would be interested to know what the standard violations are.
Please contact me in #x264dev on freenode irc.

180 ：

rc-lookaheadを増やしたら画質上がりますか？

181 ：

>>179
なんかｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

182 ：

SAR比ってピクセルアスペクト比をそのまま入れればいいの？
720x480 4:3　の動画の額縁切って 720x416　にしたいときは 10:11
みたいな。

183 ：

720x480 4:3なら普通は左右合計16ピクセルカットした704x480だと思うが、まあ、そういうこと。
10:11入れればいい。
720x480のスクイーズなら40:33
1440x1080 16:9なら4:3

184 ：

それ普通でもないよ

185 ：

額縁切りたいならクロップしてからに1：1でエンコすればいいでしょ

186 ：

>>183
上下に32ピクセルずつの黒帯がついてるから切ってる。
へんてこな放送だけど切らないと再生するとき額縁だ。
横は映像あるから切れない。
ありがと。

187 ：

動画を10分ごとに自動的に分割してくれるようなソフトはありますか？
70分ある動画（学生演劇）を10分ごとに分割してYouTubeにアップロードしたいので
よろしくお願いします。

188 ：

録画した時に使ったカメラに付いてるソフトで

189 ：

>>187
Yambが使いやすいよ＾＾

190 ：

MKVToolnixにそんな機能あっただろう
多分それが一番簡単

191 ：

客観指標と視覚心理的最適値が異なるのは何故？

192 ：

別物だからじゃね

193 ：

客観指標でお勧め自炊でもやし炒め
視覚心理的最適値でお勧め高級料亭のコース料理
と下手なたとえを披露するとたとえ話に華が咲く

194 ：

>>191
客観指標　＝　容姿、性格を考慮に入れず、健康な子供を産めるかどうか
視覚心理的最適値　＝　見た目とか性格って大事だよね

195 ：

>>191
ソースがぐちゃぐちゃでよくわからない画だと、
それがエンコ後にぐちゃぐちゃに変わってても人間にはわかんない。
だったらそこはサイズを削るためにビットレート節約しよう！
てな感じ。
客観指標はソースからの変化すべてを見る。

196 ：

MP4Box.exe -add "input.mp4":par=8:9 -new "input.mp4"
で正しいARで再生できるMP4動画に変換できていたので、
「input」の部分だけを書き換えたテキストを大量に用意して、
コマンドプロンプトに貼り付けて一括処理していました。
途中までは正常に処理できていたのですが、突然エラーが出て、
そこから処理したファイルがすべて壊れたものになってしまいました。
サイズは処理前と大して変わっていないので、動画自体は無事だと思いたいのですが、まともに再生できません。
AviUtlにぶち込むと緑一色になり、VLCで再生すると上の方にノイズが出るだけです。
何とか修正することはできないでしょうか？
よろしくお願いします。

197 ：

ソースに上書きとかそんな恐ろしいことよくやるな

198 ：

分離して多重化し直してみたら　無理だろうけど

199 ：

動画にモザイクかけるツールはみなさんは何をお使いでしょうか？

200 ：

>>198
無理でした　もう諦めました
また数ヶ月かけてVHSキャプチャからやり直します　さようなら

201 ：

エンコードしてるときCPU使用率のメーターが100まで振り切れて
PCに負担かかってるみたいだがこれは仕方ないのかな。
軽減策とかありますか？

202 ：

使用率が100まで行かないことを普通は嫌がるんだが、何が不満なのだろうか…
使用率下げたいだけならスレッド数減らせば？

203 ：

ｗ

204 ：

CPU100%を人間の全力疾走とでも思ってるんじゃねぇか
定格100%なんてメーカーっていうマネージャーに指示(制限)されたランニング程度だろうな
OCしてるなら私設マネージャーによる素人のしごきだろうから過度な負担だろうけど

205 ：

心配ならCPUの温度が表示されるソフトを入れてみたら。
馬鹿みたいに熱くならなければ、問題ない。
個人的には70度超えると嫌かな。俺が今使っているCPUは
3770Kの電圧ちょっと下げで、100％状態で室温＋25度程度。

206 ：

夏場で家に居ない時に自動エンコするときなんかはちょっと考える

207 ：

mp4にass字幕を埋め込む方法って無い？
srtもassもただのテキストファイルなのにコンテナのmp4が選り好みするのは何故だ
拡張子をsrtにしてmp4box叩いてもエラー出しやがる

208 ：

>>207
MPEG-4 Timed Text以外の字幕を入れたいのなら、mkvに入れる。

209 ：

>>208
最低限assの、字幕の表示位置指定機能を使いたいんだけど対応してないじゃん
色太字打ち消し等デザインは基本機能ちゃんと揃ってるのに。

210 ：

プロファイル＞高画質　自動マルチパス　に設定
目標映像ピットレートの数値をどのくらいに設定していいのか
悩んでいます。数値大きくしすぎてエラーになったこともあるし、
高画質を望んでいるので低品質エンコもどうかと・・・
例えば、YouTubeサイズだとどの程度が最適ですか？
算出方法とかあるのでしょうか？ヘルプです。

211 ：

ビットレート計算機でも使いなさい

212 ：

YouTubeなんて2GBまで大丈夫なんだしよっぽど長時間じゃない限り適当にcrfでエンコすりゃいいだろ

213 ：

>>210
http://www.google.com/search?hl=ja&q=BPP+%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AC%E3%83%BC%E3%83%88

214 ：

>>213
参考になりました。有難うございます。

215 ：

40Mbps・FullHD・H.264ソースのアニメを10-bitエンコードをしたいと思っています
--preset slow --crf 18 --bframes 9 --b-adapt 2 --b-pyramid normal --qcomp 0.8 --qpstep 16 --subme 9 --aq-mode 1 --aq-strength 0.60 --psy-rd 1.0:0.0
--trellis 2 --deblock -1:-1 --merange 24 --ref 6 --mixed-refs --weightb --colormatrix bt709 --colorprim bt709 --transfer bt709 --bluray-compat --ssim --psnr
拡張 x264 出力（GUI）の設定項目とその機能について - ニコニコ動画まとめwiki
ttp://www.logsoku.com/r/avi/1277292200/#29
こちらを拝見して参考にしているのですが
ぐぐって過去ログを見ると0.5:00だと暗部が厳しいとのことで
psy-rdの値をどうしようか悩んでいます
どの程度の値が適正、というのは難しい質問だと思いますので
アニメではどの程度の値を使われることが多いでしょうか。ご指導お願いいたします
psy-rd 0.5:0.0
x264 [info]: SSIM Mean Y:0.9940935 (22.287db)
x264 [info]: PSNR Mean Y:48.988 U:50.791 V:50.189 Avg:49.333 Global:48.314 kb/s:2545.80
psy-rd 1.0:0.0
x264 [info]: SSIM Mean Y:0.9937291 (22.027db)
x264 [info]: PSNR Mean Y:48.853 U:50.746 V:50.146 Avg:49.221 Global:48.218 kb/s:2762.25

216 ：

>>215
そこのリンクにあるのは全部8bitの話で、10bitはまた違うから自分で色々試してみたらいい

217 ：

>>215
俺は--psy-rd 0.7:0.2にしてるけど
基本的にグレインを残すためのものだからアニメだったら0.5:0.0〜1.0:0.0あれば充分だと思うよ
高くするほどSSIMが下がるのは
ノイズを再現再圧縮する副作用で更にノイズが増えてしまうよりも
一面のっぺりの方が元画像に近い比較になるってだけ
□□□　　　 ○△□　
□■□　→　△■△
□□□　　　 □△○
　 ↓
□□□
□□□　　　　かなり極端な例だけどこんな感じ
□□□
暗部や星空でブロックノイズが出るかどうかを判断基準にするといいと思う
--crf 18 --qcomp 0.8 ならよっぽど複雑なシーンじゃない限りは大丈夫だろうけど

218 ：

とりあえず>>215をsubme11にした上で--psy-rd 0.5:0.0 と 1.0:0.0 で720pエンコしたものをキャプチャしてみた
ttp://www1.axfc.net/uploader/so/2801236
avspmodのffmpegsource2でデコードプレビューしてるからたぶん8bitYUVになってしまっていると思うけど
傾向はこんな感じのはず
個人的な価値観としてはほとんどのシーンで0.5の方が綺麗に（グレインのないのっぺりに）見えるけど
001098のロープ、001315のグラデーション、001470の鉄骨や使徒の胴体のギザギザ、
002081の髪の輪郭線なんかは1.0の方が潰れず綺麗に残ってると思う

219 ：

追加
ttp://www1.axfc.net/uploader/so/2803008
--psy-rd 0.5:0.0
--psy-rd 0.5:0.0 --aqmode 2
--psy-rd 0.5:0.0 --crf 16
--psy-rd 1.0:0.0
ソースをSpline36Resizeで縮小しただけのもの
身も蓋もないけど --crf 16 がやっぱり一番綺麗。
特に1325のロゴ周りの線や1471の使徒の使徒の胴体のギザギザのあたり。
ただsubme11でも映像だけでサイズが20％強上がってるので
そこまでこだわるメリットがあるかどうかは人それぞれだと思う

220 ：

ビットレートを一定にしないと意味が無いと思うんだが。
crfを0.1単位で調整して容量を揃えて実験した真面目な人もいたが、
普通に2passで比べれば良い。 crf**で大体のビットレートを算出→それぞれの設定でビットレート指定2pass　という手順で。

221 ：

改行が読みづらくてすまん。
あと、使用した設定も書いておいてくれるとわかりやすい。
また、aq/psyは静止画ではなく動画で比較すべき、と
DarkShikari氏(x264のデベロッパーの一人)は言っている。
そう言う本人も、静止画の比較画像を何個かアップロードしてるから、気にしなくて良いのかもしれないが^^;

222 ：

追加
ttp://www1.axfc.net/uploader/so/2803672
--psy-rd 0.5:0.0 --no-mbtree
--psy-rd 0.5:0.0 --crf 17
--psy-rd 0.5:0.0 --crf 17 --no-mbtree
やっぱり暗部の再現は --no-mbtree が一番有効かな
1325のロゴ周りの線にそれほど大きな変化はないけど
1471の使徒の胴体のギザギザのあたりは線がハッキリ見えるようになってる（同じcrf18のpsy-rd1.0:0.0よりもハッキリしてる）
ただどうしてもsubme11でもcrfを1下げる位の容量増加（10％強）はあるので
そこまでこだわるメリットがあるかどうかはやっぱり人それぞれだと思う
ただ、元々psy-rd1.0:0.0でやってたなら
0.5に落としてその分mbtreeを切るという選択肢は有りだと思う
それなら容量増加は1〜2％程度で済むから
>>220-221
設定は>>215をsubme11にした上で psy-rd crf それぞれ弄ってます
x264のバージョンはx264.nlのr2245 x64 10-bit

223 ：

>>222
画質比較をするならば、crfじゃなくて2passでやるべきだという指摘なのだが、なぜにcrf？

224 ：

>>223
パラメーターの特性を厳密に検証したいわけではないし（実用範囲で充分）
趣味でやっている以上あなたに従う義務もないので
2-passで検証したい人がいればその人がそうすればいいんじゃないでしょうか
あと1-pass CBRでやるならわかるけど2-passにする必要性もよくわからないし
ご指摘はありがたく頂戴した上で今度の検討材料とさせていただきます
どうもありがとうございましたm()m

225 ：

厳密に検証しないならblogかどっかでやってくれ
誰の得にも何の参考にもならない

226 ：

>>222
215です
わざわざ検証までしていただいてありがとうございます！
すごくわかりやすくて勉強になりました
--psy-rd 0.5:0.0 --no-mbtreeでcrf17か18でどっちがいいか試してみることにします

227 ：

>>226
おいこら>>224、どう責任取るんだｗ

228 ：

avs4x264かまして64bit版のx264使い始めたのですが、
コンソールには x264 [info] の出力は出ますが、
リダイレクトやパイプで取れません
とれるのはavs4x264のログだけになってしまいました。
どうやったら x264 のログ取れますか

229 ：

自己解決--log-file おぷそんあった

230 ：

オプション自体の効果を調べてるんじゃなくて
絶対にcrfを使うという前提での比較をしてるだけだと思えば
>>222でも別にどうでもいい
「検証」なんてものとはほど遠いとは思うが
crfしか使わない俺には参考になった

231 ：

>>230
言いたい事はわかるが、それでもそれは間違っている。
ともかく、大前提として容量を揃えないと、比較する意味が全くない。
オプション弄りました→ 容量増えました→ 画質上がりました
これでは、オプションが効果的だったのか、それとも普通にcrfを落としたほうが有益だったのか、さっぱりわからない。
容量を揃えれば、オプションを変える前と後とで、どちらの画質が良いのかを比べることが出来る。
その後、crfに戻して、どの画質や容量ならば納得できるのか、crf値を決めるのが正しいやり方。

232 ：

>>231
なんかもういちゃもんレベルだなあ…
no-mbtreeはともかくpsy-rd下げるのは容量増加になり得ないし
no-mbtreeだって複雑な部分や暗部にビットレート割り振るオプションなんだから考え方としてはcrf下げるのと近い
それでも納得いかなければ自分がエンコするときにcrf下げればいいだけの話じゃん
はっきり言うけど他人の検証に延々とケチ付けてるだけの人より
実際に比較上げてくれてる人の方がずっと参考になるよ

233 ：

素晴らしい検証結果だけど参考にしないほうがいいよ

234 ：

>no-mbtreeはともかくpsy-rd下げるのは容量増加になり得ないし
いや、減少増加でも同じことなんだが…
>no-mbtreeだって複雑な部分や暗部にビットレート割り振るオプション
ん？
>他人の検証に延々とケチ付けてるだけ
有益な検証ならそんな事はしない。
間違った検証で、間違った結論に達しているから反論している。
比較を上げるのは構わない。
ソースに合わせるためのオプションを、他の素材で試してどうするんだという思いはあるので面倒だが。
それより、比較動画生成用のbatでもアップしたほうが有益そうだが、どうする？
正直、そんなものは一々保存していないので今から作るのだがｗ

235 ：

減少増加でも　×
減少でも増加でも　○

236 ：

>>234
bat上げるとかそういった方向での建設的でいいと思う
他人の検証にケチ付けてるだけで具体性もなく反論にすらなってない粘着を延々とやられてもしつこいだけだし

237 ：

ID:UsCwEn4Dは検証した人間に絡むんじゃなくて質問者に応対すべきだったな

238 ：

このまま逃亡する　に一票
横槍入れるしか能の無い奴が検証用スクリプトはおろか設定だって晒す訳がｗ

239 ：

初心者スレだからか、自演だからか知らないが、本気で言っているのか？
subme11だと膨らむだとか、no-mbtreeが複雑な部分や暗部にビットレート割り振るだとか。
psy-rd, AQ検討用バッチ(?)
http://www1.axfc.net/uploader/so/2811078.zip
あと、presetが有用なのかどうなのか気になったから試してみた。
2シート目にsubmeの検証も入っている。
LibreOfficeで作ったから、MS-officeで開いたらどうなるかは知らない。
暗部については、avisynth10bitハック+x264 10bit使え で終わる話だし、
8bitで行くにしても、avisynthも絡んでくるのでスルーした。

240 ：

>>239
乙です
odsファイルはttp://www.henkan-muryo.com/spreadsheet-converter.phpこれで変換して読みました
txt形式で上げてもOKなら編集する（というかここに書き込む）よ

241 ：

>>239
subme11だと膨らむなんて誰も言ってないと思うんだけど…

242 ：

239じゃないが>>222だろ。
> ただどうしてもsubme11でもcrfを1下げる位の容量増加（10％強）はあるので

243 ：

>>242
それは--no-mbtreeにした場合、subme11でもcrfを1下げる位の容量増加（10％強）はあるってことじゃないの？
subme同士の比較してるならわかるけど>>222は--no-mbtreeと--mbtreeの比較みたいだし

244 ：

mbtreeはビット節約のための手抜き度を指定するもの
デフォだと手を抜いているのが見えすぎるが、上げるほど全体の効率は落ちていく

245 ：

つまりno-mbtree最強伝説

246 ：

それは違う
短時間で消える部分や、あまりにも複雑なフレームをまじめに再現するのはビットの無駄
サイズがいくら大きくなってもいいのでなければ、mbtreeを使うのは基本

247 ：

>>243
普通に読み違えてたorz
>>244
手抜き度を指定するのはqcomp。
mbtree→ 手抜き度をマクロブロック毎に設定
no-mbtree→ 手抜き度を一枚の絵全体で一括指定。
mbtreeをonにすると、"手抜き"が的確に効くようになるため、
no-mbtree時代に設定されたままのqcompを使用すると、効きが強すぎることになる。
どうしてもmbtreeが嫌いな人がいるなら、qcompを検証した上で、その問題の箇所を指摘してもらいたい。

248 ：

トータルとして考えれば、no-mbtreeで画質が向上するというのは
あながち間違いでも無い訳か

249 ：

つまりno-mbtree最強伝説

250 ：

どうしてそうなるんだよｗｗ
もういっそcrfやめてqp使った方が良いんじゃない？　って話になるぞ

251 ：

mbtree切るのってどんなにサイズが膨らんでもいいから少しでも画質を良くしたいって人だけじゃない？
別にエンコなんて趣味だから好きにすりゃいいけど
俺はmbtree切るは割に合わないというかサイズと画質のバランスは良くないと思うな〜

252 ：

>>250
だよね

253 ：

2passでnombtreeってどうなの

254 ：

>>251
いや、だから容量を揃えて比較しろと言っているのだが…；
mbtreeで容量が縮むのなら、no-mbtreeと同じ容量になるまで、
crfを下げれば良い話だ。　同じ容量になれば、mbtree onの方が画質は良い

255 ：

>>254
まあそりゃそーだ

256 ：

>>254
その理屈はおかしいだろ？ｗ
それだと2passでmbtreeするよりno-mbtreeの方が複雑な場面の画質が良いって話になっちゃう
全体の画質とmbtreeで対象にされる複雑な場面の画質を混同しちゃあかん

257 ：

>>254
静的なシーンの品質をこれ以上求めているのか
静的な部分は現状でいいから複雑なシーンの品質を求めるのかで評価は変わるから
一概に「〜の方が画質は良い」とは言えないだろうね
メリットデメリットの比較ではなく単純に優劣として一元単純化してしまうのは
「つまりno-mbtree最強伝説」の人と同じドツボにはまってると思う
=>>247
だから>>239の内容がsubme比較だったのか
言葉のドッヂボールは相手の意見の確認を行わないからシャドーボクシングになりやすいよね
外野としてはsubmeの比較データ見られて得だったけどｗ
odsファイルtextになおして再掲してもいいかな？

258 ：

まあ俺のレスは半分冗談なわけだが半分は本気だ

259 ：

>>257
上げた本人じゃないんだが、見やすい形で掲載してくれるとスレ的には財産になる

260 ：

>>257
>>240の人かな？　レス忘れてすまなかった。　大丈夫です。
mbtreeのon/offは、単純な優劣の問題。　メリットデメリットを言うなら、qcompの問題だな。
no-mbtreeで考えるなら、crfとqpのメリットデメリット。 まぁ、実際にはqpなんぞデメリットしかないのだが。
mbtreeは、crfの機能拡張だと考えれば良い。 mixed-refsに似てるといえば似てるか…？

261 ：

多分、口で言ってても仕方ないから動画で。
http://www1.axfc.net/uploader/so/2812666.zip
2passだと容量が一定にならなかったから3pass。
1000kbpsの0.1が、効果を一番把握しやすいと思うから、それから見て欲しい。
正直、ソース選択は間違ったかもしれない。 　アニメ本編とか最大限効果的だろうね。

262 ：

>>261
いや、静止部分と複雑な部分の対比としては良いソースだと思う
面白いね、かなり明快に差が出るのな
mbtree=1と0を比べると1は右の静止画部分が、0は時機周辺の弾やエフェクト部分が高精細
どちらが良いのかは俺には判断つかんが…

263 ：

良い悪いは個人で決めればいいという前置きをしつつ
人間の目は動くものを追いかけ動かないものは見えなくなる(色味を失いぼける)性質がある

264 ：

no-mbtreeは設定内のビットレートになら強い
が、ひとたびその枠を超える部分が来ると劣化が目立つようになる

265 ：

>>260-261
240の人とはちがうけどありがとう
>>239内[preset,subme検証.ods]のtxtファイル版
ttp://www1.axfc.net/uploader/so/2812809.txt
>>261
検証乙です
静的なシーンの品質をこれ以上求めているのか
静的な部分は現状でいいから複雑なシーンの品質を求めるのかを比較するのにいいソースだと思う
ビットレート指定とちがってcrf指定だとサイズが増減するからね

266 ：

>>263
だが、動いている状態でどれくらい識別できるのか？　という問題がある。
もし、速い動きもバッチリ見えてしまうなら、アニメの中割りなどは成立しない。
逆に、人物が良く動くにつれて、背景も急に手抜きになるアニメがあったら、どう思う？
え、そこ手を抜いちゃうの？ 別に手を抜かなくてもよくね？ てかまずくない　って思わない？
背景まで手を抜いちゃうのがno-mbtree。
あくまで、動きの速い部分はバレないから手を抜く。 バレるところ(動かない所Iは手を抜かない。
比較に作ったqcomp 0.1は論外、デフォルトの0.6でも強いから、目の良さに応じて、0.7〜に設定すべきだろう。

267 ：

>>265
未だにビットレート指定で検証している意味を理解してもらえてない気もするが…。
crfでこそ、mbtreeは生きるとも言えるけどね。
crfでなら、qp値の指定は動きがどれだけあるか(別問題としてAQとpsyの介入はあるが)によって決定される。
つまり、常に見た目には一定の品質が保証されるということだ。
(そのためにはqcompの設定を適切にしないといけない。)
no-mbtreeだとそうは行かない。
no-mbtreeの制御では、ビットレートを大量に消費するシーンではクオリティを下げ、そうでないシーンではクオリティを維持する。
結果、"VBRだが、固定ビットレートっぽい"挙動を示す事になる。
そもそも、qcomp 1.0は完全なVBRを意味し、qcomp 0.0はCBR(固定ビットレート)を意味する。
CBRは論外だけど、qpも合理的でない…というジレンマがno-mbtreeにはあるという話でした。

268 ：

>背景まで手を抜いちゃうのがno-mbtree。
それは1pass固定レートの話で、CRFで用いれば背景の劣化ではなく容量の増大に繋がるのでは？
2passであれば全体の品質低下は起こるが、背景がある1区間でのみ崩壊する様な不都合は無いかと

269 ：

>>268
劣化と容量の増大が共に起こる。
qcomp 0.0だと、容量は変化しないが劣化が起こり、
qcomp 1.0だと、劣化は起こらないが容量が増大する。
つまり、その間のqcompであれば、容量が増えはするが劣化が生じることになる。
もちろん、バレない範囲での劣化ということではあるのだが、動かない部分も混じっている以上、バレてしまう。

270 ：

2passについて言及し忘れてた。
2passでも、やはり激しい動きの部分のみ、背景が劣化することになる。
"固定ビットレートっぽい挙動"と呼んだのはコレのことを言いたかった。
いい加減しつこいが、これはqcomp 1.0にすれば起こらない。

271 ：

>>270
うーん、上げて貰えた動画を見返してみたんだけど
例えば実用範囲オプションの1000kbps-0.7mbtree/0.7no-mbtreeでは
画面右の静止部分での「急な手抜き」って4秒・8秒・12秒の各ポイントで双方で起こってるよな？
no-mbtreeオプションが原因とも思えないんだけど、それは程度問題という認識で良いんだろうか

272 ：

1000kbps程度でno-mbtreeとか言ってたのｗ

273 ：

ビットレートが足りてないもので比較しても意味ねーだろ
どちらかといえばmbtreeのが有利だが

274 ：

--no-mbtreeと--qcomp 1.0 安定か

275 ：

解像度にもよるけど1000kbps程度（しかもビットレート固定）ならmbtree使った方がいい

276 ：

>>271
それはkeyintによる、Iフレームの挿入。　手抜きどころか、真逆でテコ入れ。
これはno-mbtreeオプションは関係無い。 弄るとならipratio,pbratio,scenecut辺りかな？
>>274
qcomp1.0ならどっちでも同じなんだがなｗ　好きに汁
>>275
>（しかもビットレート固定）
いつになったらこの考え方から抜け出せるんだ？　全く理解できない。
SDソースで済まないが、もう一本グレラガンOPでやってみた。
やっぱりmbtreeの方が、qcompの数字を大きくしないと圧縮しすぎるね。
mbtreeの方は前半微妙に思えるかもしれないが、後半に均一にビットをとっておいているからそうなっている。
http://www1.axfc.net/uploader/so/2813178.zip

277 ：

>>271>>276
ごめん、ちょっと飛ばして読んでた。画面→か。
たしかにmbtreeでも、変わらないはずの静止部分の画質も少し変化しているね。
これは恐らくレートコントロールのため。
毎回全く同じqp値のIフレームを挿入するわけではないから、(pフレームを基準に考えるため)
今回のように全く動かない(=全てスキップMB)場合は、一旦Iフレームで決定された画質が修正されることがないため、こんなことになる。

278 ：

いや、なんか違う気がしてきた。 qpでAQもpsyもoffにしたら、ipbとqp値が綺麗に揃ったような気もする。
やっぱり理屈上では、静止部分は画質変わらないはずだと思う。
no-mbtreeのように、状況に引きづられて大幅に変化してるって事も無いけどね。
コード読めるわけでもないし、正直よくわからん。
一人でID真っ赤になるのって疲れるね！ ってことでいい加減寝ます。

279 ：

--no-mbtree --qcomp 0.8 より --qcomp 1.0 (--mbtree無効)の方がファイルサイズは小さいんだな
--no-mbtree --qcomp 0.8
x264 [info]: SSIM Mean Y:0.9903576 (20.158db)
x264 [info]: PSNR Mean Y:47.604 U:49.591 V:49.541 Avg:48.148 Global:47.917 kb/s:1259.11
--qcomp 1.0
x264 [info]: SSIM Mean Y:0.9895724 (19.818db)
x264 [info]: PSNR Mean Y:47.062 U:49.200 V:49.138 Avg:47.637 Global:47.435 kb/s:1147.32
しかしSSIMも1.0の方が下がってるのか

280 ：

と思ったけど別のソースでは順当に上がって行ってる
↑の場合はノイズが入るのが原因かな？
--mbtree --qcomp 0.8
x264 [info]: SSIM Mean Y:0.9931172 (21.622db)
x264 [info]: PSNR Mean Y:50.473 U:50.575 V:50.368 Avg:50.395 Global:49.392 kb/s:2301.50
--no-mbtree --qcomp 0.8　サイズ 1.0943倍
x264 [info]: SSIM Mean Y:0.9932227 (21.689db)
x264 [info]: PSNR Mean Y:51.087 U:51.410 V:51.240 Avg:51.111 Global:49.667 kb/s:2518.45
--qcomp 1.0　サイズ 1.133倍
x264 [info]: SSIM Mean Y:0.9933264 (21.756db)
x264 [info]: PSNR Mean Y:50.516 U:50.159 V:49.985 Avg:50.246 Global:49.482 kb/s:2604.97

281 ：

subme7以上では、 SSIMやPSNRは意味はないと開発者が言っていたような

282 ：

ゆるゆり♪♪ OP　　　　　　　SSIM　　　　　サイズ比
--qcomp 1 (--no-metree)　0.9897690　　1.107378625
--qcomp 0.8 --metree　　　0.9896832
咲-saki- 阿知賀編 ED2
0.9878268　　1.214733073
0.9876413
氷菓 OP1
0.9868882　　1.088022595
0.9871018
氷菓 ED2
0.9898708　　1.066129357
0.9901036
氷菓 OP2
0.9876465　　1.101488254
0.9876512
ノイズが入ったりエフェクトが入ったりして
ビットレートが一気に跳ね上がったり--vbv-maxrateまで行っちゃうようなソースだとSSIMが下がるのかな

283 ：

ゆるゆり♪♪ OP　　　　　　　SSIM　　　　　サイズ比
--qcomp 1 (--no-metree)　0.9897690　　1.107378625
--qcomp 0.9 --metree　　　0.9899077　　1.134244208
--qcomp 0.8 --metree　　　0.9896832
氷菓 OP1
0.9868882　　1.088022595
0.9875023　　1.112881632
0.9871018
氷菓 ED2
0.9898708　　1.066129357
0.9901788　　1.101478751
0.9901036
--qcomp 0.8→1.0でSSIMが上がったケース・下がったケースの両方で
0.9＞1.0という結果

284 ：

訂正
ゆるゆり♪♪ OP　　　　　　　SSIM　　　　　サイズ比
--qcomp 1 (--no-metree)　0.9899287　　　1.148040305
--qcomp 0.9 --metree　　　0.9899077　　　1.131674585
--qcomp 0.8 --metree　　　0.9896947

285 ：

metree ってオプションが最近出来たのかと思って
検索しちまったじゃねーかよ！

286 ：

ビットレートかSSIMのどちらかを揃えた方が分かりやすい比較になる

287 ：

SSIMの素の値って見づらいから対数表記(dB) に統一されるといいのにな
-10 * log10( 1 - ssim )
で計算されているそうで

288 ：

--qcomp 0.9 --metreeが今のところ一番無難なのか

289 ：

エラー出ないの？

290 ：

>>288
それマルチパスでエンコする場合の話？
そんな極端にqcomp上げたらcrfでエンコする意味無いんじゃないの
x264のパラメータって基本極端な値指定するとろくなことにならない気がする

291 ：

>>290
1ならともかく0.9で意味ないってことはないと思うけど
まあcrfの値次第かな

292 ：

qcompを0.8より高くするならcrf指定よりqp指定した方がエンコの目的に沿うと思う。
x264の画質は結局のところ色んなパラメータのバランスで成り立つものだから
一つのパラメータを極端に上げたり、あるいは下げたりするとバランスが崩れて目的を見失うんじゃないか。

293 ：

ぱっと見を保ちつつサイズを抑えるなら0.8でも高すぎる
SSIM的には0.6あたりが最大のようだから

294 ：

変化の大きいアニメなんかだと0.8もアリかと思うけど、
同時にqpminとqpmaxの調整とかzonesによる対応の検討もしたいねえ
mbtreeも素材によってはBフレームの劣化とサイズの増加を招くし、
結局一番無難な回答は「ソースによるから試行を重ねて好みに合うパラを探しましょう」に尽きる

295 ：

結局どれだけビットレート確保できるかって話だからなあ
qcomp0.9指定でもcrf16とcrf23じゃ全然違うし

296 ：

俺がテストした場合、他のパラメーターは同じで、
qcomp0.8、crf20 と qcomp0.6、crf18 で大体同じぐらいの
ビットレートになり、画質は前者の方がわずかに良いかなーって感じだった。

297 ：

>>295
いや、「画質劣化がわからないようにどこまで縮められるか」だと思うけどね。
最も縮む設定を探るには、ビットレート指定での比較をせざるを得ないという話。
最も縮む設定で、劣化をどこまで許容できるのかcrf値で指定、というアプローチが一番良いと思うよ。
目安の目標ファイルサイズを決めて、crfを検討するのも良いとは思うけどね。
ただし、QP値によって最適なオプションが変わるケースもあるから、
あまり目標画質と離れすぎた状態でオプションを比較するのはやめたほうが良いと思う。

298 ：

>>297
＞「画質劣化がわからないようにどこまで縮められるか」
これに重点を置くのならこっちのスレの方がふさわしいと思う
【目指せ】高画質アニメエンコスレPart18【軽量】
http://toro.2ch.net/test/read.cgi/avi/1313047835/

299 ：

誘導先はここじゃない
>>4

300 ：

誤爆したorz

301 ：

crf=21程度の実写ソースで随分と綺麗なエンコされてる動画を見つけたので
設定参考にしようとMediaInfoで覗いてみたところ「cqm」が2になっていた
この値の意味は0=flat 1=jvt 2=カスタムマトリックス で合ってるよね？
やはり、極めてる人はカスタムマトリックスを指定するのが基本なの？
アニメや実写、こんなソースにはこれがお勧めってのがあれば教えて欲しい

302 ：

>>298
いや、だからエンコードって何のためにするんだ？　縮めるためだよね？
で、でも画質が下がるのは嫌なんだろ？
そしたら、「画質劣化がわからないように出来るだけ縮める」
もしくは「画質劣化を最小限に収めながら目標ファイルサイズまで縮める」
となるんじゃないのか？

303 ：

実写でcrf21なら綺麗で当たり前

304 ：

>>301
実際のところ、cqmを作るのはとても難しい。
AQやpsy-rdで十分だし、cqmでそれらを上回れるかというと、別にそんなこともない。
あと、cqmを使った場合はcrf値は実際のところ参考にならなくなってしまうので、
やっぱりビットレートを見てください、って事になってしまう。

305 ：

>>303
俺も見た瞬間そう思ったｗ

306 ：

>>302
画質か容量を多少妥協する代わりに
エンコード時間を短くするという選択肢もあるな
画質はそのまま容量を0.5％削れるけど時間3倍とかだと
いやって人も居るだろう

307 ：

サイズ・圧縮率・画質のどれをとるかはひとそれぞれだよなあ

308 ：

640ｘ360のフレーム動画（10分弱）を幾つもつなぎ合わせて編集して
合計100分の動画ができました。
総ビットレート1693kbpsでエンコしてmp4動画を作成することができました。
エンコ時間に4時間以上も要したのですが、通常このぐらいかかるもの
なのでしょうか？使用するフィルタによると思いますが時短アドバイスとか
あれば聞きたいです。

309 ：

使ってるPCもオプションもわからんし、そういうものだとしかいえない。

310 ：

動画エンコは各個人によって設定の幅が大きすぎるんで、ここで聞くより
Q&A的なサイト見て自分に合った設定を見つけ出すのが一番かと。

311 ：

つんでれんこはesa使ってるから遅いのかね

312 ：

同じビットレートならnパスエンコの方がcrfで1パスの方が理論的には高画質ってことであってますか？

313 ：

日本語でおｋ

314 ：

>>312
マルチパスなら--direct autoがより効率的になるけど、たぶん全体的には変わらないと思う。

315 ：

ロスレス(再エンコードなし)でフレームレートだけ変更することはできますか？
いま29.97fpsのを25.00fpsに変更したいんです

316 ：

mp4boxとかmkvmergeで詰めるときにfps指定したらいいんじゃないの？

317 ：

>>316
あなた最高です！
mp4boxでは出来なかったんですけど、mkvmergeでは出来ました！
コンテナmkvになったけど画質そのままなのでかまいません
深夜にかかわらずどうもありがとうございました

318 ：

x264_L-SMASH_clone.shでソースを取得してコンパイルするとr2274にならないんだけど、どうすればなる？

319 ：

敵地に深く進めば成る

320 ：

あなる

321 ：

mbtree切ったら暗いシーンでも綺麗になったんだけどどゆことこれ

322 ：

>>321
暗いからビットレートが元から低いのに
MB-Treeでさらに削られるからそうなる

323 ：

実写の韓流ドラマ（日本語吹替版）に最適な設定を教えて頂けないでしょうか？
音声はdemuxしたAACを使います。
エンコ時間短縮とファイルサイズ縮小重視で、画質は俳優の顔面のディテールが分からない位（出来ればオイルペイント調）で良いです。

324 ：

>>323
640x360とかに縮小すれば

325 ：

>>324
--tune はanimationとかにでもしておけば良いのでしょうか？
動画ソースは、今朝からBSフジで始まったイタキスです。
吹替え担当者には興味有りますが、出演俳優はゴミですｗ

326 ：

それだったら取り出したAACだけを聞いていればいい。案外ラジオドラマみたいにして楽しめるかもしれない。

327 ：

720x480にしてDVD販売して捕まって下さい

328 ：

マジレスするとaviutlとかで線形フィルタかけまくってからエンコすればいいと思う

329 ：

>>323
オイルペイント調では無いと思うが、速さならFFT3DGPUでも使えば良いのでは
後はx264のdeblock上げてpsy-rd 0:0とかかな

330 ：

8bitでバンディング起こさないレベルの設定を探していたら
QCOMP 0.9でVAQ 1.0 PSY RDO 0.5 PSY TRELLIS 0.3みたいな阿呆な設定に行き着いた。
CRFは19のCQMはFLAT。
ファイルサイズバカみたいに食う。

331 ：

>>330
それのどこがアホウなんだ？
Psy-Trellis 0.3意外普通じゃねーか

332 ：

いや、そうかもしれんが結構ファイルサイズ食うようになるぞ？

333 ：

もしかしてアニメで？

334 ：

YES

335 ：

うん、ま、ほんのちょっとアポーだな

336 ：

アニメでバンディング起こさないならバンディング低減フィルタでディザ載せて
VAQ 1.0 PSYRDO 1.0 PSYTRELLIS 0.0 で大抵問題はない。
PSYRDO 0.5 PSY TRELLIS 0.3 とか使うよりファイルサイズは縮む。
CFRが19もあるならマジでこれで大丈夫だと思う。

337 ：

ソースと見比べてみる事をお勧めする

338 ：

ttp://loggialogic.blogspot.jp/2011/10/x264.html
vbv-maxrateは分かるのですがvbv-bufsizeはどのようにして決定しているのでしょうか？

339 ：

>>338
vbv-maxrateと同じでおｋ

340 ：

>>338
吐き出す映像の解像度やフレームレートでレベルが変わる。
レベルが変わるとvbv-maxrateやvbv-bufsizeで指定できる上限が変わるから注意な。

341 ：

パイプを使うにはどうすればいいですか？
自分なりに探してみた結果
x264 - [etc] --demuxer y4m -o out.mp4
だけでいけるように書いてあるんですが、それでは
x264 [error]: could not open input file `-'
と表示されうまくいきません。最初の"-"を省いてもヘルプが表示されエンコードが始まりません。
一度ファイルに書き出してから食わせた時にはうまくいくことを確認しています。
具体的には以下のようにしています。
set op=--preset slow --profile main --crf 20 --qcomp 0.7 --vbv-bufsize 10000 --vbv-maxrate 10000 --keyint -1 --min-keyint 4 --b-pyramid none --partitions p8x8,b8x8,i4x4 --ref 3 --weightp 0 --level 3
mplayer -benchmark -ao pcm:file=tmp-a.wav -vo yuv4mpeg:file=- -vf expand=aspect=480/272,scale=480:-2 %1 | x264 - %op% --demuxer y4m -o tmp-v.mp4

バージョン: x264 core:130 r2273 b3065e6 (x264.nl の8bit depth/64bit版)

342 ：

mplayerの代わりにffmpegでも使えば

343 ：

>>342
どういうこと？mplayer側の問題ってこと？
しばらくしたらffmpegの奴もためしてみるけど、リダイレクトを受け取れてない時点でx264側のパラメータの指定に問題があるように思えるんだが。
ファイルでは受け取れるけど標準入出力では受け取れない形式とかあるの？

344 ：

>>342
確認のために聞くけど
それは標準入力から受け取る場合のパラメータは>>341で間違いないと見てよろしい？

345 ：

https://sites.google.com/site/linuxencoding/x264-encoding-guide
ここだと
$ mplayer -nosound -benchmark -vo yuv4mpeg:file=>(x264 --demuxer y4m --crf 20 --threads auto --output output.264 - 2>x264.log) star-wars.mkv
みたいになってるが具体的には知らん

346 ：

mplayerは使ったことないんだけど -vo yuv4mpeg:file=- でちゃんと標準出力に吐き出せてるの？
ttp://htffmpegx.seesaa.net/article/18420754.html
とか参考にならないかなぁ、と思ったけどそもそまffmpegの方が楽な気がする。

347 ：

>>345
すまん。書き忘れたがWindowsなんだ。windowsでもbash使えるだろというツッコミはなしで
>>346
どうやらそれが原因らしい。一応、ビデオストリームも出力されてたんだが、頭の部分にmplayerのバージョンが入ってた orz
mplayerをパイプでつなぐには、頭の数行部分を無視するフィルターを間に挟む必要があるみたいです。
もしくはエラー出力に出力するように修正してコンパイルし直すか、名前付きパイプを使うか

348 ：

現在のx264にskip_depth_filterって入りましたか？

349 ：

>>348
本家に提出されてないから入ってない。

350 ：

サンクス。

351 ：

最近x264スレに質問している人を見て映像マルチパスの仕様を知りました。
音声のAAC圧縮も2PASSっていうのがありますが、音声も映像の2PASSと同じような処理ですよね？
2PASSは品質向上目的ではなくて指定ビットレートに近づけるためのものということで
音声2PASSのチェックを外すとパイプ処理のオンオフを選択できるようになりますが、パイプ処理ってどんなものなのでしょうか？
パイプを通してエンコーダに渡しますとありますが、どういう効果になるんでしょうか？

352 ：

スレチ

353 ：

>>351
釣り？それとも真面目？
>音声のAAC圧縮も2PASSっていうのがありますが、音声も映像の2PASSと同じような処理ですよね
漠然とした曖昧な質問だなぁ…
1pass目でストリームの複雑さを解析して、2pass目で予定していたビットレートでエンコードするのが定石だけど
実際どうするかはそのエンコーダ、実装次第。
>2PASSは品質向上目的ではなくて指定ビットレートに近づけるためのものということで
もちろん、品質向上のためでもあるよ？シングルパスでエンコードした場合、事前にストリーム全体の複雑さ
というか、今処理している部分が全体から見てどれだけ複雑なのか分からないからVBRでうまくエンコード出来ない。
じゃあどうするかというと、振れ幅を抑えて、狭い区間で調整するようにしてCBR的なエンコードをするか
ビットレートを指定より低めに基準をとって余裕を備蓄しつつ、比較的複雑そうなところで蓄えを消費するようにする。
結果として、指定ビットレートより多少ずれるし、品質も悪くなる。
>パイプを通してエンコーダに渡しますとありますが、どういう効果になるんでしょうか？
そのまんまなんだけど…標準入出力とかリダイレクトとかそういう基本的な事わかってる？
ネットで本屋でもいいからパソコン初心者向けの解説書よめば分かるよ。
一言で言えば、あるプログラムの標準出力を画面やファイルに書き込まないで、別のプログラムの標準入力に橋渡しするのがパイプ。

354 ：

真面目です
容量抑えるより音質とエンコ速度重視してパイプ処理使うことにしました

355 ：

linuxで YUV444の10bitソースをYUV420の8bitに変換したいんですが、
どのようなコマンドラインになるでしょうか。

356 ：

それx264の問題じゃなくね？

357 ：

>>355
--input-cspで正しい物(yuv444p10be)を指定すれば、変換できるかと

358 ：

正しい物(yuv444p10be等)に訂正 leかもしれないし

359 ：

かくつきの出る何だかスペックが足りてなさそうなAndroidデバイス向けに
極力軽いmp4を作ってそれでもかくつき出るのか試したいのですが、
解像度・プロファイル・ビットレート・bufsize/maxrate以外に要求デコード能力に
関わりそうなオプションは何かありますでしょか。

360 ：

bフレーム枚数とか参照距離とか

361 ：

offはお勧めしないけどデブロックフィルタ

362 ：

あとデブロックオプションの有無もハードウェアデコードの時に破綻が出る場合もあるそうだけど今スマートフォンに使われてるチップだと関係無いか

363 ：

>>359
profile baselineと好みのlevelとmaxrate/bufsizeを指定して--tune fastdecodeを
利用すれば出来るだけ軽くなるよ。
そういや、最初の頃fastdecodeってXboxのセロリンなどに向けてエンコするために
あったんだよなぁ・・・　懐かしい（笑）。

364 ：

baselineにしているのでBフレーム・参照距離は関係無いですよね？
loop=0とtune fastdecodeを試してみましたが結果変わらず…
解像度も小さくしたホントの低スペ仕様をコーデック内蔵プレーヤでソフトデコードさせると
問題無いのに大してハードデコードだと変わらずかくつく事があるので、タイマー周りに欠陥が
あってスキップ処理が誤発動してるとか、何かドライバ周りかハード自体に不都合があるのかな。

365 ：

それだったら解像度が怪しい
無断にSDサイズだったりするんじゃない？

366 ：

液晶の解像度は960x540のQHDで基本等倍でエンコしてますが、
テストに480x270・320x180迄下げても駄目でした。
毎回特定の所でかくつくわけでは無く、暫く再生してると何の変哲の無い所でかくつきだし、
数秒手前にシークしてもう一度見るとスムーズに通ったりします。
低ビットレートでも起こるとは言え発生頻度はやっぱり高ビットレートの方が多いです。

367 ：

ビットレートとバッファのサイズを調整するしかないと思う

368 ：

解決には結びつかないと思うが
ローカル・ドライブ上のファイルだと再生に支障が生じ
同じファイルをネットワーク越しだとスムーズに再生できることがある

369 ：

>>367
限界以下なら大丈夫ってわけじゃなく、低すぎても駄目な場合もあるんでしょうか？
>>368
WMPを鯖にして少しDLNAを試してみたんですが、再生出来るファイルの仕様がよく解らなかったので挫折…
FHDは再生出来る物のカクカクなんでQHDにしてみたら無理とか

370 ：

>>369
君のAndroid云々ってのを無視した、単にネットワーク越しのファイルを再生って話
画面のドット数で動画のドット数を決定しているようだが
動画として標準と思われるドット数にしたほうが何かとトラブルが出にくい

371 ：

＞テストに480x270・320x180迄下げても駄目でした。
とあるからその辺は一応わきまえてるんじゃないかね

372 ：

今度出るHaswellではAVX2とTSXが使えるそうですが
TSXというのはエンコードにおいて何か役に立つのでしょうか？
AVX2でエンコードが早くなるとはよく聞くのですが
同じHaswellでもTSXに対応するものとしないものがあるので何を選ぶか迷います

373 ：

大は小を兼ねる
だと思うけど

374 ：

Kが非対応なんじゃなかったっけ

375 ：

インストールしたのですが、After effectsのレンダリング設定に
コーデックとして追加されません。
原因がわかる方はいらっしゃいますか？

376 ：

何をインストールしたんだろう・・・

377 ：

>>373
>>374氏の通り、4770KはTSX非対応、4770無印は対応で、
大は小を兼ねるとはいきませんので質問させていただきました

378 ：

>>376
x264です。

379 ：

厳密に言いますと、7.0には追加されてて、ＣＳ6には追加されてないと言う感じなんです。
連スレすみません。

380 ：

それで正常

381 ：

TSX、同期オブジェクト周りで使えるかもしれないが、どうだろう。
CPUの性能みて同期オブジェクトの生成を切り替えるとかどうなんだろうね。

382 ：

変な名前になってたorz

383 ：

10bit や YUV444 ってのを再生するにはどうすれば良いのですか

384 ：

皆様に伺いたいことがあるのですが、私はTMPGEnc Video Mastering Works 5に
x264VfW - H.264/MPEG-4 AVC codec 38.2274を使用して、
エンコードをしているのですが、
aviに限って、mmname2で見てみると、704×396が【80x1408】となり、
また、【未対応ビデオコーデック(再エンコード必要)】
となり、また、【映像サイズがコンテナとコーデック詳細で異なる.
コンテナ 704x396.コーデック詳細 80x1408】と記載
されてます。
mediainfoで見ると704×396になっております。
ぐぐって、マクロブロックの８×８のチェックを外す改善されると
ありましたので
実行すると今度は【704×400】となります。
この原因はどこにあるのでしょうか？
よろしくご指導のほどお願いします。

385 ：

>>383
http://mpc-hc.org/
このプレイヤー使う

386 ：

mmname2が悪いんじゃないの?よくしらんけど

387 ：

MMname2なんて古いソフトじゃん。

388 ：

エンコードがめんで音声だけで上限を超えていますって表示されたのですが解決策が分かりません

389 ：

音声とx264関係なくね？

390 ：

いろいろキテるね

391 ：

音声ファイルだけでピットレート上限を超えますとの表示が出ていました
色々と確認し直した所解決しました、お騒がせしてしまい申し訳ない

392 ：

出来上がったファイルのプロパティを見るとEncoding settings が記載されています
これをどうにかして消したいのですが、何かいい方法はございますかな？

393 ：

>>392
自分でコンパイルする。

394 ：

ヘッダ情報覗いて該当部分だけ消すなり書き換えるなりすればいいんでないの？

395 ：

>>394
それをやってしまう人は大体間違ったやり方するから（以下略
あの情報がゼロで置き換えられたサンプルは何回もらったか・・・
（規格的な違反）

396 ：

何の意味があるの？そこのヘッダみて再生可能かどうか判別をする機器があるとか？

397 ：

PSPなんかそうじゃなかったっけ？

398 ：

>>397
ないわ。一時的にMP4の構造にはうざかったけど、v3辺りだったしなぁ。
もうかなり長い間普通にmuxすれば問題ない。x264が書き込む
SEI情報とは無関係。
>>396
大体アレ系でオレオレ設定を隠したいって人。個人を特定するような
情報書かれてないのになぁ。┐(´∀｀)┌ﾔﾚﾔﾚ

399 ：

人の設定が気になって仕方ない人もどうかと思うけどねぇ

400 ：

規格違反のものはH.264じゃないと見做してよいので、プレイヤーによっては突っ返してよい。
あるいはありえないデータが出てきたので破損データ扱いして突っ返してよい。

401 ：

間違ってpsnrオプションが有効になってたみたいなんだけど
これはpsnr計算をするだけで画質への影響は無いオプションだよな？

402 ：

ないよ

403 ：

>>402
テンクス

404 ：

http://nicowiki.com/拡張 x264 出力（GUI）の設定項目とその機能について
※psnr: psnr(エンコ前とエンコ後の映像を比較する時に使う計測値)が最大になるようにする。これを使用すると見た目は酷くなる事が多いので普通は使わない。
aq-mode 0, no-psy
※ssim: psnrと同様で、ssimが最大になるようにする。これまた使えば見た目はひどくなることが結構ある。
aq-mode 2, no-psy
らしいですがどういう事？

405 ：

数学的な高画質（劣化が少ない）と視覚的な高画質（人間が綺麗と感じる）が違うんだってさ
そしてPSNRやSSIMは数学的な指標でしかなく、それを追求してx264と比較する某コーデックに対抗するために
tune psnr/ssimでは視覚心理的なチューニングすべてオフ、psnrではAQ無効、ssimではAQ mode2が有効ってことでしょ

406 ：

--psnrと--tune psnrは違うぞ

407 ：

映像がぱっと見キレイで動きの少ないトーク番組なのに放送局？によって縮まない傾向があるのは何故ですか？
自分が感じた範囲だとSDで言えばテレビ朝日の難視聴向け
HDだと日本映画専門CHの本編以外(本編は24pにすれば凄く縮む）のインタビューなどです
dgindex + avisynth + Smple x264 launcher でAssumeTFF以外フィルタリングはしてません

408 ：

>>407
そのチャンネルがどうってのは知らんけど、
一見綺麗に見えても3次元ノイズリダクションを軽くかけるだけで1割近く縮むもの。
静止してる部分でも通常視聴する分には気にならないけどチラチラとノイズが乗ってるから
たいていそういうノイズが邪魔して縮まないだけじゃないの？
試しにcombolution3dでも軽くかけてみたら？

409 ：

aviutlからの出力で、下の画像のように横一直線の色の切れ目が出てしまうのですが
何が原因でこうなってるのでいるのか見当がつきません
ttp://fx.104ban.com/up/src/up29344.jpg　（下：ソース）
切れ目は再生しても同じ場所に現れ、場面の切れ変わりで消えたりします

410 ：

ロゴ消しフィルタに変なサンプル使ってんじゃね？

411 ：

>>410
サンプル取りなおしたら改善しました
ありがとうございます

412 ：

x264でエンコードされたファイルにはEncoding settingsが記述されていますが、
この情報やその他メディア情報を元に、全く同じエンコード設定を作る事は可能なのでしょうか
自分でエンコした物とニコやつべから拾った物では何かが致命的に違う様なのですが、
何が違うのかよく解らない…

413 ：

同じソースが用意できて、エンコード設定がわかったとしても、
その人がどんなフィルタ処理をしたのかはわからない。

414 ：

>>413
画質じゃなく何かフォーマット的な物だと思うのでその辺は構いません
特定の環境で自分がエンコした物は再生出来ないのに、ニコ等で拾った物は問題無く
再生出来何が違うのかさっぱりな状態です

415 ：

コンテナが違うんじゃないかな。
ニコ動で拾ったものを自分が使ってるmuxerでmuxしなおしてみ。

416 ：

>>415
お察しの通りでした。が、色んなツールでmuxし直して見てもどうしても再生出来る様に出来ない…

417 ：

どんなん作ってんのか十数秒くらいの適当なサンプルうｐってみれ。

418 ：

MP4Boxでmuxしたら再生出来る様になりました。　基本どころですみません；
各ツール、何か細かい所で違うんですかね。

419 ：

今まで何でmuxしてたのだろう・・・
最近はmp4だとMP4BoxかL-SMASHのmuxer・remuxerくらいしか使われてないと思うが

420 ：

どうもWebOptimizedと言う、本来ファイルの尻にあるデータを先頭に持ってきているタイプじゃないと駄目だったらしい

421 ：

それはProgressive Download対応だな
ffmpeg界隈ではツールの名前からqt-faststartなどと呼ばれていた
mp4は一般にヘッダと呼ばれるようなメタ情報をmoovという領域に入れるが
これはエンコード結果によりサイズが可変なので1パスではファイルの最初に書けない
最後に書くことはできるので普通のツールではそうしているが、
HTTPでダウンロードしながら再生する場合、moovは最後にダウンロードすることになり、
ダウンロードしながら再生ができない
PCでローカル再生する分にはランダムアクセスできるから問題ない
remuxすると、賢いツールではmoovが最初に来るように調整してくれる
x264_L-SMASHではデフォルトで最後に自動remuxする

422 ：

muxerでも --optimize-pdつければいいよ
そうか最後にremuxerでremuxすればいい

423 ：

元の解像度がでかい動画をモバイル目的などで極力小さくしたい場合(500kbps程度)
解像度は大きめでcrfを下げるのと、crfは高めで解像度を下げる(再生時に拡大する)のと
どっちが綺麗になるかな
ソースの性質によっても変わるんだろうけど

424 ：

そのモバイル端末の解像度に下げて
容量制限があるなら2パス

425 ：

まずそのままのサイズでエンコ
画質がひど過ぎると思ったら少し解像度を縮めてエンコ
以下くり返し
これでいいと思った画質のところで完成

426 ：

縮めたいなら解像度下げるのもいいけどノイズ除去系のフィルタかけるのもいいよ
とくに3D計ノイズ除去なんて効果絶大

427 ：

質問なんですが、mp4でエンコードすると最初に6〜8フレーム分の無音が入っていて
毎回音ズレしてしまうですが、どうしたら直るのでしょうか？
動画はavi 59.940fps　音声データ無し
音声は別ファイルのwav
L-SMASH woksでファイル読み込み。L-SMASH muxerで結合しています。

428 ：

>>424-426
遅くなったがトンクス
でもなるべく手抜きして処理したいんだよねえ
それで実際>>425のように試してみたが個人的には低解像度・高crfの方が好みだった
crf下げるとどうしても輪郭がぼけちゃうな
低解像度で気になるのは斜めの直線の粗さくらいだけど、
あまり重要な要素ではないのでそっちを妥協することにした

429 ：

だれかx264 rev39立てろよｗ

430 ：

たったらしいが落ちたのしらなかった
http://toro.2ch.net/test/read.cgi/avi/1374779753/

431 ：

解像度が1440*1080の場合、
ttp://www.x264bluray.com/home/1080i
の設定だけだとTMPGEnc MPEG Smart Renderer 4でBDMV/BDAVの規格外判定受けるね・・・
プリセットだと--ref 16 になってるのを--ref 4指定しないとダメみたいだし・・・
--open-gop も外しておかないとMPEG4コンテナにも規格外扱いになるし・・・
http://www.x264bluray.com/
ここから Feedback and Comments を送っといた方がいいのかしら
日本語でも・・・だめか

432 ：

BDMV/BDAVが特殊なだけでは？？

433 ：

>>431
> プリセットだと--ref 16 になってるのを--ref 4指定しないとダメみたいだし・・・
補足しておくと、--level 4.1 を指定してるので --ref は16⇒5に補正される。
それでもNAL-HRD制限を超えた値なので、BD用には不適合なデータとなるのでしょう。
コードをチェックしてみたら --bluray-compat の補正は上限(6)チェックだけだったので、
levelと出力解像度を考慮した補正が必要になる模様。
以下、猫研記載のBD用互換設定を参考にでっち上げてみたコード。
ttp://pastebin.com/s3wAvHp1
(参考) ttp://up-cat.net/x264%25A4%25C8Blu%252Dray.html
ただし参考情報の内容で正しいのかはまったく判断できてません。
動作確認も(非常にてけとーな)出力チェックしか行ってません。
なので信用しない事。

434 ：

探しても古い記事しかないのでビルドする方法教えて下さい

435 ：

まずプロテインを飲みます

436 ：

お腹いっぱい飲んだら、あとはぐっすり眠りましょう。
起きた頃にはビルドなどどうでもよくなっていることでしょう。

437 ：

ビルドアップ

438 ：

10bitにすると
AVS Video ConverterでDVD形式にしたいときにチャプター設定で再生されないんだが、
エンコの問題？それともAVS Video Converter の問題？

439 ：

VBRとマルチパスってどっちの方がいいの？
容量を決めたいならマルチパスでとかいう話聞くけど
VBRとマルチパス比べると
VBRの方がビットレート高いのに
マルチパスのほうが綺麗なんだけど
品質基準だから動きが激しいと変わってくるの？
でも動きが激しいシーンより普通のシーンのほうが多いよね
しかも動きが激しいシーンなんてすぐ終わるし
細かい劣化はキャプでもしない限り気づかないよね
普通のシーンがきれいな方がいいんじゃね

440 ：

好きにしろよ

441 ：

>>439
この手のレス前にも見たけど釣か？
なんか勘違いしているようだが、マルチパスとVBRは比べる対象ではないぞ。
初心者向けの解説サイトでもいいから目を通してこい。

442 ：

比べる対象でないってどういうことだよ
いろんなエンコードや設定を試して綺麗なのはどれか比べてるのに
対象でないとかわけわかめ

443 ：

容量を無視して常に一定の品質でエンコしたいと思ったらcrf値指定するのが楽だって話なだけなんだがなぁ

444 ：

>>439
マルチパスだと品質基準VBRよりビットレートのふり幅が小さくなるから、視覚的に綺麗に見えることは多い
ただし、ソースに合わせてビットレートを調整しないとビットレートのムダ食いになったり、劣化が目立ったりすることも多い。
で、その調整をソフトに任せるのがワンパス-品質基準。（つまりラク）
ところで、テストに使用したファイルの解像度とビットレート/cfr値を聞かせてもらおうか

445 ：

>>442
>対象でないとかわけわかめ
それを分かるために少しでも自分で調べろって言ってるんだよ。
>VBRとマルチパスってどっちの方がいいの？
これはエアコンとアザラシはどっちが人参に近いかって言ってるようなものだよ。
まずは、そのオプションが何を意味してるか、それ以前に何を指定しているか大体でも理解してから出ないと比較検討はできんよ。
ビットレート指定のVBRの"マルチパス"と"シングルパス"を比べるのは分かる、結果はそりゃマルチパスのほうが容量あたりの画質は良くなる。
"crf指定(品質指定)のシングルパス"と"ビットレート指定のVBRのマルチパス"を比べるのも分かる。
これは同じサイズになったら多少VBRの方が有利。全体を見通せるマルチパスのほうがよりアグレッシブな割り振りができるから。
ただ、crfは出来上がってみないとサイズは分からないし、VBRは倍程度の時間がかかる。
だから、結局はサイズのばらつきを許容出来るかどうか、時間に余裕があるかどうかで選べばいい。

446 ：

>>445
容量とか時間とかお前も比べてるじゃん
何がエアコンとアザラシだよ
あほか

447 ：

>>446
はぁ…あなた本当に釣りではないんですか？本当にマルチパスとVBRが何なのか分かっていますか？
VBRとマルチパスは併用するものであって、どちらか片方をとるものではありません。
だからどちらがいいという議論はそもそも成りたなないのです。(さらに言えばh.264/x264はVBRしかできませんが)
>>445の場合には「容量のばらつきを抑えるために倍近い時間をかけることを良しとするかどうか」であって
1時間と1MBを比べているわけではないですよ？例えばディスク容量分ピッタリ使うには品質固定は向いていません。
逆にそれ以外の大抵の場合は品質固定で事足ります。

448 ：

いい加減スルーしろ阿呆

449 ：

>>447
容量とか時間とかお前も比べてるじゃん
何がエアコンとアザラシだよ
あほか
容量とか時間とかお前も比べてるじゃん
何がエアコンとアザラシだよ
あほか
そもそも質問が
品質基準のシングルパスVBRと
マルチパスのビットレートエンコ
についてなのに併用とかアホか
そもそもエンコの概念なんて聞いてないんだよ
聞きかじった知識ひけらかすために的はずれな回答した上
わけのわからんたとえ持ちだすな
比較したことないならお前にはわかんねぇんだろ
わからないならレスすんなボケ

450 ：

＞　VBRとマルチパスってどっちの方がいいの？
可笑しいだろｗ

451 ：

>>450
そこだけ読んだらおかしいけど
>>439全部読んだら分かるだろ
一から十まで全部検証するのがめんどいから聞いただけなのにまともな回答は>>440だけだったよ
もう検証し終わったからどうでもいいわ

452 ：

で、検証結果はどういう結果が出たんだ

453 ：

>>451
いやわからんよw　もう一度自分で読み返してみろよw　
VBRの代わりにcrfと書けばまだ通じたかもしれんが
VBR　VBR　連呼してもそれが品質固定を意味してるなんてわからんだろ。
コミュ障とかレッテル貼ってる奴は嫌いだが、本当にコミュ障っていたんだな。

454 ：

ネタが無いからっていつまでアホ話を続けるんだ？

455 ：

>>453
品質基準だから動きが激しいと変わってくるの？
って書いてあるだろ
わからないならレスすんなボケ
わからないならレスすんなボケ
わからないならレスすんなボケ

456 ：

で、結果はどうだったんだよ
質問&rarr;自己解決 だと糞呼ばわりされても仕方が無いぞ？

457 ：

>>456
お前らの誰一人質問自体がわかってないのに結果なんて書いても意味ないだろ
何時間も検証した結果を何一つわかってない奴らに教える気はないよ
俺がアホなコミュ障だったで終わらせろよ

458 ：

今後お前さんのような理知的な人がこのスレ頼ってきた時の為に書くんだよ

459 ：

>>457
すごく興味深いので是非検証結果を教えてください！

460 ：

久しぶりに動いたと思ったらキチガイが通りすぎただけなのね・・・
目を合わさずスルーに限るな

461 ：

>>460
そのレスを書かずに飲み込んでこそスルーが完了するというのに

462 ：

初心者質問スレなのに質問したやつ叩いたり調べろと言ったりそりゃ過疎るわ

463 ：

初心者質問に初心者しか答えないスレ
にすればいいのに
過疎るだろうけど

464 ：

>>463
意味不明すぎワロタ
選民意識でもあるのか

465 ：

このスレはあくまで初心者が対象なんで
自分で調べる気も理解する気もない教えて君は対象外

466 ：

>>465
ここは質問スレだよ

467 ：

質問スレだけど隔離スレでもあるんだな

468 ：

スレタイに質問スレってあるのに
答える気もない奴らだからな
隔離されてるんだな

469 ：

x264って何ですか？ぐぐってもわかりませんでした

470 ：

初心忘るべからず、ということわざがだね

471 ：

XBOX360の仲間だろうな。

472 ：

マジかよ！糞箱売ってくる

473 ：

x264でRGBでエンコードする人がほとんどいないのは何故？

474 ：

細かいことを気にするとハゲるから

475 ：

ソースがRGBならRGBでエンコするんじゃないの？
YUVソースしかエンコしたことないからよくわからんけど

476 ：

RGBソースっつーとゲームのキャプとか？

477 ：

>>476
うん
この場合は、RGB24？

478 ：

>>477
輝度色差で分かれてないので圧縮効率が悪くなるのと再生互換性が悪い(Hi444PP+カスタム色空間)からじゃない？
ソースによるだろうけどサイズとのバランスを考えると10bit　4:4:4/4:2:2のYCbCr辺りでもいい気がする

479 ：

>>477
出力したファイルで何をしたいかにもよるだろ。
どうしてもRGBのまま保存したいならRGBでエンコすればいい。
ただ、>>478が言ってるようにデメリットだらけだし、はっきり言ってまず意味はない。
ハードウェアアクセラレーションも効かないし、特に理由がないなら
一般的な8bit 4:2:0でエンコしとけばええねん。

480 ：

>>478は10bit推しのようですが

481 ：

>>480
10bitはハードウェアアクセラレーション効かないだろ。
そもそもそこまでこだわって10bitやら4:4:4やら4:2:2にする必要性があるかどうかってこった。
相当なこだわりでもない限り、再生互換性の高い8bit 4:2:0にしとけばいい。
どうしても満足いかなかった場合は10bitなりなんなり好きに検討すればいいんじゃね？
ただ、自分で見比べてみれば、ほとんどの場合10bitやらにする必要性を感じないと思うけど。

482 ：

PCしか使わない自分には8bitやらにする必要性を感じないなあ

483 ：

好きにしろ

484 ：

>>482
いや、もちろんそのへん判断して選択できてるならそれでいいと思うよ。
「RGBソースだったら10bit 4:4:4あたり」みたいに短絡的に考えちゃうとまずいと思って注意喚起してるだけ。
ソースがなんだろうが、自分がどういう形で残したいのかってのが一番だから。

485 ：

だったらごちゃごちゃいう必要ないだろ

486 ：

(´・x・`)

487 ：

単発

488 ：

PC以外で再生しないなら圧縮率良くて場所取らないから10bitの方が良い
Androidとかに入れて再生するかもしれないなら設定は一切変えずに8bitにすればいい

489 ：

PC用の10bitとiPad用の8bitの両方あるわ
iPad用は消化したらすぐに消すけど

490 ：

10bitは圧縮率良いのもあるけど、そんなことより画質を最優先に考えた結果に過ぎない
人によって何を優先するかは違うから好きにエンコすればいいべ

491 ：

10bitはflash playerで正常に再生できるようになってくれれば完璧なんだけどな

492 ：

>>491
FlashPlayerの10bit再生バグは優先度低いと言われて放置されてる。
ただ、バグ改修されるにこしたことはないけど、活用場面ってあるかな？
FlashPlayerってことは、ニコ動あたりに10bitでアップしたいってこと？
ハードウェアアクセラレーションも効かないし、視聴者もそんな微妙な差は気にしないと思うけど。
よりよい画質でアップしておきたいという考えは理解できなくもないけど。

493 ：

ハードウェアアクセラレーションハードウェアアクセラレーション
うるさいよ

494 ：

じゃ、ハードアセロラローション！！！

495 ：

オーロラエクスキュージョンでいいよもう

496 ：

僕はキスショットアセロラオリオンハートアンダーブレードちゃん！

497 ：

最近のDTV板どうしたの？
こんなノリばっか

498 ：

DTVは冬の季節
燃料がなくなったし

499 ：

色々検索したんですが、うまく見つからなかったので教えて下さい。
著名ビルダーの方のx264　r2359やr2358を使ったら、r2348まで出来てた
--acodec copyとmp4出力などが出来なくなっていたので
x264raw出力した後にedts、mp4box使っての音声結合のやり方に戻したんだけど、
その他良い方法ありましたらご教授ください。

500 ：

>>499
x264はどこのサイトから取得しましたか？
--acodec copyはともかく、mp4出力ができないビルドはそうないと思うのですが
あとrawストリームのコンテナ格納や結合はL-SMASHのCLIを使う方法もあります
興味があれば調べてみてください

501 ：

>>500
アドバイスありがとうございます。
taro06さんのをいつも使ってたのでr2359を
mp4出力を行うと、うちの環境で以下の様なエラーがでてました。
--エラーメッセージ　ここから
raw [info]: 1280x720p 1:1 @ 30000/1001 fps (cfr)
raw [info]: color matrix: bt709
mp4 [error]: cannot open output file `D:\Temp\進撃の巨人\2013年09月08日\out.mp4'
.
x264 [error]: could not open output file `D:\Temp\進撃の巨人\2013年09月08日\out.mp4'
avs [error]: Error occurred while writing frame 0
(Maybe x264 closed)
--エラーメッセージ　ここまで
x264raw出力すると問題なかったでした。
L-SMASHのCLIについて勉強してみます。
ありがとうございます。

502 ：

ちょっと試してみましたが、出力パスに2バイト文字が含まれていると同様のエラーが出ました
パスに2バイト文字を使わない場合は正常にmp4出力できました
たとえばですが、
D:\Temp\singekinokyojin\out.mp4
みたいにしてあげるとmp4出力できると思います

503 ：

>>502
調べてテストまでしていただき本当に感謝です。
x264 rev39スレの237に同じようなことが書かれているのを今発見しました。
もう少し他のスレもまめにチェックしてればよかったんですが、
すみませんでした。
http://toro.2ch.net/test/read.cgi/avi/1374779753/237
>taroさんのx264_rev2359+704_tMod、
>-o <outoput> <input>
>のoutoputの拡張子がmp4の時だけ、パスに日本語が入ってると弾かれてしまう・・・

504 ：

taro以外の使えばいい

505 ：

そいやx264のmp4出力で2G以上書き出すとエラー吐くバグがあったと思うんだが、もう直ってる？

506 ：

>>503
英語で出して、日本語でリネームすればいいだけじゃん

507 ：

>>506
>>502

508 ：

>>507
>>504

509 ：

>>505
そんなエラーあったんだ
mp4出力で2G以上書き出しても別になんともないようだけど

510 ：

>>505
うちの環境だと特に問題ないです。
>>508
そうだね。

511 ：

ここであってるのかもわかりませんが教えて下さい
aviutlで音声(ラジオ)に画像を合わせた物を作っていざこれでエンコしても音声と動画が分離してしまいます
プロファイルでニコ動プレミア6分以上アニメにして動画120、音声128でしてます。これ以外弄ってません
特にエラーなところもなく原因がわからないです
検索して音声だけの場合に
1passにnulオン→バッチ→2passでnulオフ→バッヂ→出力
をしたらいいとあったので試したところ
1passのところに出力ファイルがみつかりませんと出ます
これ以外の方法も出てきません。音声と動画を分けたいばかりです
どうかご教授してください

512 ：

すまんが正直、何を言っているのかわからん
分離って何？

513 ：

正直な話わけわかんないんだが、分離したのを合わせたいなら別のソフト（mp4boxとか）でまとめるんじゃダメなの？
とっちにしろスレチと思われ

514 ：

スレチでしたかすみません
音声と動画のファイルが別々になってしまうという話です
音声はMP4で出るのに動画が2.264ってのになります
ですが、違うので消えます

515 ：

そんなことで悩むレベルだったらまとめてやってくれるフロントエンドでも使えば

516 ：

>>515
そういうフロントエンド使ってて結合されなくてアタフタしてるんだろ

517 ：

>>516
そうなのか。それは悪かった。じゃ、そのフロントエンドのスレで聞くしかないな。
ちなみにmp4はあんまりやったことはないが、>>513がいうようにmp4boxあたりで
結合できるんじゃないか…。自分の場合、m2tsを作るのが主なので、音声や字幕は
最終段階で結合してるな。VFRなんかの音ズレを意識するのが面倒なので自分で
結合ツールは作ったから参考にならんと思うが。

518 ：

何が言いたいの

519 ：

x264 GUIでMP4 BOXの場所指定がきちんとできてなくて参照できないとかじゃないの？

520 ：

x264vfw GUI専用スレ Part9
http://toro.2ch.net/test/read.cgi/avi/1351856057/
ここかね
AviUtl使ってるなら何のプラグインで出力しようとしてるかとかバージョンとかも書かないとダメだ

521 ：

こいつにCLIツールが使えるとは思えん

522 ：

>>505
2GBって32bitWindowsの制限じゃなかった？

523 ：

2GBのバグはMP4Box(GPAC)にあったと思う

524 ：

ちがう
あるとしたら公式のGPACの問題
日本のビルダーなら公式のGPACなんて使ってないだろうしありえるとしたらnlのものかな
何にせよ最新のrevisionでこれに該当するものは現状存在しない

525 ：2013/09/14

>>522
Windowsではなく、C言語の制限
2GB超のファイルの扱い方は標準化されてないのでコンパイラによって違いがある
普通、クロスプラットフォームを謳うソフトウェアは最低でもMSVCとGCCくらいは考慮して
そこらへんの違いを吸収できるコードになってるけど、GPACはそんな初歩的なコードすら
書けてなかったりする