x264 rev35

Q ニコニコ用の動画を作りたい。
A 板違い、Youtube板の"FLV/MP4作成スレ"でどぞ。

Q 圧縮codecありませんか。AviUtlで使いたい。x264gui.auoの使い方は？
A x264 VFW GUI専用スレでどうぞ。
http://hibari.2ch.net/test/read.cgi/avi/1318232220/

Q コマンドラインの使い方が分かりません
A 初心者スレでどうぞ
http://hibari.2ch.net/test/read.cgi/avi/1314616372/

[本家]
http://www.videolan.org/x264.html
http://git.videolan.org/gitweb.cgi?p=x264.git;a=summary (ソース/チェンジログ)
http://x264dev.multimedia.cx/ (開発者のブログ)
http://doom10.org/index.php (公式フォーラム)
irc://irc.freenode.net#x264(ユーザー用IRCチャンネル）
irc://irc.freenode.net#x264dev(開発者用IRCチャンネル）

[バイナリ]
Getting the latest x264
http://doom10.org/index.php?topic=3.0

前スレ
x264 rev34
http://toro.2ch.net/test/read.cgi/avi/1322304761/

H.264の再生法や規格などの話題は
MPEG-4 AVC/H.264 総合スレ Part8
http://hibari.2ch.net/test/read.cgi/avi/1263983676/

AviSynthの使い方等は
Avisynthを絶讃ιょぅょ Part30
http://hibari.2ch.net/test/read.cgi/avi/1298742587/

インタレ規格の話題は
インタレ解除しないスレの3っぽいスレ
http://hibari.2ch.net/test/read.cgi/avi/1186448899/

リサイズやアス比の話題は
アスペクト比 part6
http://hibari.2ch.net/test/read.cgi/avi/1301521076/

MP4コンテナの話題は
【MP4】ISOMPEG-4普及委員会4【M4A】【3GP】
http://hibari.2ch.net/test/read.cgi/avi/1087545021/

Matroskaの話題は
【mkv】MatroskaVideo総合スレ8【mka】
http://hibari.2ch.net/test/read.cgi/avi/1237123715/

PS3の話題は
【H.264】 PS3動画スレッド8 【1080p】
http://hibari.2ch.net/test/read.cgi/avi/1263892716/

なんで立てるんだよっ！

それは教えられん

そこにチンポがあるから

そこにまんこがあるなら、なら分かるんだがホモは勘弁

おお…

2本目が生えてきた・・・

4本足･･･だと･･･

>>1
乙

>>1おお・・・

x264はAvisynthのYUY2出力は読めないのでしょうか？
直接avsをinputとして指定すると、
resize [error]: output colorspace (null) is not supported
このようなエラーになります

avconv -i input.avs -f rawvideo -pix_fmt yuv420p - | x264 - --input-csp i422 --input-res 704x460 ...

のようにしてyuv420pに変換してからraw形式で渡すとYUV422を読めるのは確認しました
もっと楽な方法はありますか？

すみません間違えました
-pix_fmt yuv422p
です

avisynthを2.6に更新してYUY2ではなくYV16にすればいい
いまどきYUY2で出力するのは、AviUtlに渡す場合くらいでしょ

>>14
なるほど、2.6だとConvertToYV16()でplanar形式に変換してくれるのですね
ありがとうございます

わかってない予感

Avisynth2.6でConvertToYV16()を入れないとデフォのYUY2のままでダメなのですが
ConvertToYV16()でplanar形式のyuv422pに変換してやると上手くいくのを確認しました

>>16
何か間違っていたでしょうか……

いったいソースはなんなん？

ftp://vqeg.its.bldrdoc.gov/SDTV/VQEG_PhaseI/TestSequences/Reference
ここにあるインタレースD1、UYVY422な動画です

ところで↑にあるMobile & Calendar(SRC15_REF__525)ですが
--qp 0でロスレス圧縮すると、最後の方のフレームが緑がかってしまい、
実際にavconvで同じピクセル形式のYUVに戻してバイナリ比較しても
一致しないようです。

x264はr2146、公式のものとx264.fushizen.euのものを試しました。オプションは、
--output-csp=i422 --bff --qp=0 --sar=10:11
だけです。
念のためAvisynthを使わずavconvからのrawvideoパイプ入力も試しましたが同じ結果。
全ての動画を試したわけではないのですが、Susie(SRC21)あたりは
問題ありませんでした。

何か勘違いかもしれないので、もう少し調べてみます
すみません……

>>20
これはデコーダ側のバグじゃないのかな
--dump-yuvの出力をrawsource26.dllで読んだ場合は、特に問題ないみたいだけど

>>22
Avisynth26導入後ごっちゃになってしまったので、再確認していたのですが
YV16とffmpeg/libavのyuv422pはUVの順序が逆なのですね
avconvにavsを渡してConvertToYV16()の出力を読ませるとlibav側が
yuv422pと認識してしまうのがまず問題のような気がします
RawSource()ではyuv422pなYUVは"I422"指定で読めるようでした

もう少し問題を切り分けられないか試してみます

ConvertYV16()をやめて、あらためてやってみてもやはり緑になりますね
Avisynthを使わなくても同じです

avconv -pix_fmt uyvy422 -video_size 720x486 -i src15_ref__525.yuv -f rawvideo -pix_fmt yuv422p tmp.yuv
x264 tmp.yuv --input-csp=i422 --input-res=720x486 --sar=10:11 --bff --qp=0 --output-csp=i422 -o output.mp4

確かにx264ではなくて、libavがそれをデコードする時の問題かもしれません
同じソースでも、--qp 0でなければこの問題は起きないようです

https://github.com/DarkShikari/x264-devel/commit/4f0acfe8a11434da45c9312b944cbaddbc87c1db
これじゃないの？

YV16なavsをavconvに渡す場合はSwapUV()使えばいいよ

>>25
あ、それで>>12が治るというか、YUY2が読めるようになるかもしれないですね
planarなYUVに正規化しようとしてswscaleの設定をしようとしているんだけれども
上手くいかなくて謎のメッセージが出ているように見えたので

後のほうで話していた問題とは関係なさそうですが

>>26
ありがとうございます！
Avisynth26を使っていなかったので、知らない機能だらけです……

swapは2.5から使えるけどね

そうでしたか

エンコして総フレーム数は変わらないのに、途中からずっと1フレームずれてるという現象にあった人いる？
突然そういう現象にあってしまって何が原因か全くわからないんだ・・・
別に今までとエンコのやり方変えたわけでもないのに

「今まで出来てたのに急に出来なくなりました」は基本的に釣り

directshowで読み込んでるんじゃね

AVC-Intra来たね

>>31
エンコ中にunderflowがちょこちょこでちまってるだけじゃね？

おっぱいが鮮明に見えるオプションを教えてください

--opi 0.90 〜 1.00

--tune ssim

--no-bra

--π-乙

おお…

--titie twister

--chikubi 45:55

--tune chihaya (== --top 72 --cup 65AA)

スレ立てしたので、色空間とか色域関係はこっちでやってね。

色空間スレ 2bit-depth
http://toro.2ch.net/test/read.cgi/avi/1328162048/

仕切り厨ktkr

蹴り出すような真似するんなら、せめてテンプレとか基本情報ぐらい用意しようや
あまりにも無体な

まあでも立ったんだからもうここでやる理由もないな

ここでは何するの

雑談

x262の今後の進化を楽しみにしつつ、雑談

AVC-Intraが次回来るけどlibavでデコードできるようになる日は来るのかな？

x264とどう関係するの？
組み込まれるって事？

JEEBが責めでPOPが受けで

↓ここで何かヨブ氏が面白い事を↓

だが断る

ヨブ「おまえら、カレーパン買ってこい」

翻訳する機械仕事しろー

ヨブ”さん”氏だろ

さんしﾀﾝ

牛ﾀﾝ

x264のpush来るらしいぞ

KENくん　さんの流れを久々に思い出した

出力時にエンコードパラメータをファイルに残さない方法きぼんぬ

本当は残すべきという説教を小一時間(ry
どうせろくでもない理由だろうが

「時」ではないけどこの人の
ttp://www1.ocn.ne.jp/~mashi07/x264opt.html
試した事ないけど

ぐるぱ

ｒ2164

おお…

今度の更新で、ビット深度の変換がTVスケールの物に変更されたみたいだな。

暖かくなる話をしてください

r2164

>Clean up and optimize weightp, plus enable SSSE3 weight on SB/BDZ

の"BDZ"ってAMDのBulldozerのこと？

>>71
ソースのコメントに↓ってあるからそうだね
ssse3 weight seems to be faster again on Sandy Bridge and Bulldozer.

>>72
thx

ドラゴンボールかと思った

r2164を落として指定しなおしたはずが、r2146を指定していた・・・。

あるあ・・・ねーよ

男は黙って上書き

最新版使ってバグ報告に貢献汁

ライトユーザーなので二週間くらい待ってから更新します ^q^

通はファイル名を　ｘ264.exe　-> r2146.exe などに変更して
バッチファイルなどでパラメータを与えてソースごとにバージョンを使い分けるんだよ。

そーっすね

おお…

しま・・・

くだらん

ひでじ愛してる！

>>80
俺はx264_8_2164.exeというようにしてる

ちん

俺はPC数台でいくつか違うバージョンを入れてる

てかあまり使わないPCは更新するの忘れてる

あのタモリさんが不機嫌に 181 MB (190,836,553 バイト)pass sage
http://ichigo-up.com/1/download/1328414712.zip

60fpsの様ななめらかさ
これがインターレース保持の実力か！！

おお…

保持ならTSのままでいいよな…

通報しましま

F1やサッカーなら分かるけど
バラエティ番組でインタレ保持してもなぁ・・・

そこら辺言い始めると行き着く先は「TVを録画してもなぁ」になるからやめれ

単純に30pのカクカク感が気になる
再生側で倍速補完できるならともかく

>>90
これ７２０ｘ４８０にリサイズして縦解像度変わってるけど、形式はインタレ保持になってるけど、
インタレ情報潰れて、インタレ保持になってないと思うんだが。

ファイルに記録されるx264のEncoding settingsはx264optで消せるけど、
Encoded dateとかTagged dateとかWriting libraryなんかのタグを消す方法知ってる人いる？
そもそも埋め込まない方法もあるのかな？

>>97
フィールド分離して確認したが潰れてないよ
480Pだから細かいとこわからんけど

おお… 生tsうんたらかんたら

1280x720以下の解像度だったら、60pにしても大抵の環境で再生できる。

>>97,99
インタレは保持されてるし、きちんと再生は出来るんだけど、
tff/bffの判定用フラグを認識できず、手動でtffにしないとだめだった(ffdshow経由NV12HWデインタレ)。
このファイル、MBAFF、tff、nal_hard=vbrとなってるけど、
自前(core120_r2164)で作ったのとは違う挙動だ。

>>98
バイナリエディタ

>>103
出来れば、それ以外の方法でw
AtomicParsleyでWriting libraryはいじれたんだけど、他が見つからない。
一括処理にはperl使うしかないかなぁ・・・

tff/bffの誤判定、coreAVCが原因だった。
LAV、ffdshow、ともに問題なく、インタレ再生できたわ。
しかも、coreAVCより再生支援なしで軽かった・・・

ただ、TSから自前でこさえたやつだとcoreAVCでも問題なかったんだよなぁ。
オプションの違いだと思うけど、よくわからん。

米糠氏のx264も --log-fileオプション使えるんだね
ログ出力できるのはありがたい
今までkmod氏のビルドだけだと思ってたわ

> 一括処理にはperl使うしかないかなぁ・・・
おもしろそうだからだれか公開してくれ

おお・・・

>>105
自ビルドしようぜ！

>>104
ffmpegが使える状態で

ffmpeg -acodec copy -vcodec copy -i INFILE.mp4 OUTFILE.mp4

とINFILEからOUTFILEを生成してみた。
Encoded dateとかの日付は消えたけど、Writing libraryとEncoding settingsは残ったままだった…

ストリームに含まれてるんだからあたりまえ

>>105
バッチコマンドで 2>&1 とか使えよ

なんでそんなに必死になって、消さなきゃいけないの
犯罪証拠の隠滅か　？？？

PSPも以前のバージョンで60iが再生出来たと思うんだけど
そのバージョン誰か知らないか？

>>113
はぁ？どのバージョンだよｗ

PSPはMediainfoで最大が120fps超えない物なら大体行ける・・・はず

>>113
かなり昔と聞く。
3.xxとかかね？
自分は使ったことないからどんな挙動するかは分からない。

>>115
60fps超すと余裕でドロップする。
120fpsって要するに

Maximum frame rate : 119.880 fps

のこと言ってんだよな？
割れ臭しかしない。

再生出来てたのは覚えてんだよな
いつのまにか縞々になって再生出来なくなってた(´・ω・｀)ｼｮﾎﾞｰﾝ

>>111
ふぇぇぇ…ファイルデータがおっきすぎるよぉ…

不覚にも萌えを感じてしまったorz

>>115
Frame rate : 59.940 fps
Minimum frame rate : 19.980 fps
Maximum frame rate : 239.760 fps

つまりこういうアニメ・実写の混合動画だとアウトになるのか。
まさにゴミだなPSPｗ

239.760 fps
239.760 fps
239.760 fps

接合時にタイムコードが狂ったんだろ
そういえばタイムコード修正ソフトって聞いたことないな

直接いじって直せば良い

>>124
おまえ正気か30分30fpsで54000フレームだぞ
途中で狂ってたらそこから後ろ全部修正だぞ
手動修正は俺にはできんわ

タイムコードの狂いならmkvmergeでappendすれば自動調整してくれるのに？

cfr化してからtimecode v1を適当に書いてtc2mp4modじゃだめなん？

好きにしなさい

>>109
その状態から、Encoding settingsはx264optで消せる。
AtomicParsleyでWriting libraryは消せるけど、新たにTaged dateが追加される。
そんなわけで、完全には消せない。

tc2mp4modで修正できる。
と思ったら、L-SMASHのtimelineeditorでも修正できるでござるよ。

おっぱいは〜

aqmode4とはなんぞや？

3と4はbm氏のexperimentalなMOD

なるほど
3は知ってたけど4は知らなかったんでちょっと試してみよう

マッハバンドは錯視、バンディングは現象。
ちなみにバンディングによって引き起こされる錯視はシュブルール錯視という

今日の議題はx264職人のニート率の高さについてです。

職人って何だよ

ヨブ氏「俺の出番のようだな」

翻訳する機械仕事しろー

社内ニートなのは間違いない

僕は45のおっさん君は？

小学6年の女の子です

yonnsaidesyu」

１５万兆億歳

Not in Encoding, Editing or Threading

Bフレーム0よりも3の方がSSIM上がることに今ごろ気がついて絶望した

あたりまえだ

Bフレームが汚いって言われてたのはなんだったんだ

マヌケの戯言

おお…　生tsが一番高画質と思ってるのがいるのか

tsのままだとくすんでるから未視聴のものはエンコして綺麗にしてから見てる
サイズはそれなりだが

TSのままだと汚いからエンコしてからプラズマTVのKUROで見てる

http://unkar.org/r/avi/1296313162/ID:TE3mO5sP

なつい

そんな目的ならTVのランク上げるわ

＞未視聴のものはエンコして綺麗にしてから
もともと劣化のひどいTSソースをさらにエンコードして劣化するのに綺麗になるってｗ

多分淡い色変化が知覚できなくて、ギラギラになると綺麗って感じるんだと思う
あと適当なビットレートでエンコードすると細かいノイズ(モスキートとか)が表現しきれず省かれるから
それもまた綺麗と知覚する要因にはなる

バンディング低減とかそういう目的じゃねーの

シャープかければ綺麗って素人丸出しやな

バンディング低減はフィルタの仕事であってエンコーダの仕事じゃないんだから、
バンディングを潰したいだけならtsのまま再生してffdshowでDebandなりスクリプトを噛ませたらいいだけだ

・・・そうか？x264のオプションも多分に影響すると思うが
別にいいけど

＞ffdshowでDeband

これはないわ

逆にエンコーダが勝手に絵を弄るようでは、その方が迷惑だろ
本来階調になってるべき部分を勝手に塗りつぶされるようになっても困る
エンコーダはあくまで受け取った絵を忠実にh264に変換してくれるだけでいい

そんなの人それぞれ

お前が
>そんなの人それぞれ
って言葉を使う権利は>>160での書き込みによって失われている
氏ね

＞ffdshowでDeband

これはないわ

そんなの人それぞれ

コピペにマジレスかっこわるい

バンディング低減とか言うけど階調無くして平らになったのを滑ら
かとか勘違いしてる奴ばっかりだよね(´・ω・｀)

はい。

>>161
でもフィルタでのバンディング対策って誤魔化しでしかないよね
階調あるブロックに多めにビットレートを割り当てるみたいな正攻法での対策はエンコーダにしか出来ないんじゃないの？

試しにやってみれば分かるけど、ソースにバンディングが出てる状態だと
ロスレスでエンコしてもバンディングは消えない。

>>170
ソースを忠実に再現するんだから当然だね。
最終的に人間の目にどう見えるかが問題なんだからごまかしでもなんでもやらないよりはいい。

ロスレスを持ち出したのは>>169の
　　＞階調あるブロックに多めにビットレートを割り当てる
へのツッコミでしょ。
そもそもバンディング低減というのは
　　「ソースの段階でバンディングが発生しちゃってるので、そのままエンコーダーに渡してもそれが再現されるだけ。
　　　だからその前にフィルタ処理を入れてバンディングを低減しておく（ごまかしておく）。」
というものだと思うんだけど、>>169はそのへんわかってるんだろうか。

　　http://pop.4-bit.jp/archives/2008_09.html
　　http://pop.4-bit.jp/archives/2008_11.html

なんか話がつながってなくてわかりづらいな

ディザノイズを加えてやるんだろ
波形見てみれば？

ATiの3D RAGE Pro Turbo辺りは独自のバンディング除去技術で滑らかな諧調実現してたけどな
今はHDシリーズ使ってるけど、当時のフィルタがそのまま使われてるかは分からんし
とっくの昔に廃棄処分したから検証も出来んが

バンディングなんてAvsにスクリプト書いてffdshowで出力で何も問題ないじゃん
CPUパワーないならあれだが

バンディングがソースの段階で発生してるのを特定できるほどの環境の人がtsソースをバンディング低減しようとは思わないんじゃないの

安い韓国PCモニタで見てるから悩むんだよ

バンディングは「丸め（量子化）」によって起きると思えばいいんだよね
量子化によるデータの削減は非可逆圧縮の本質なので
そこでのバンディングはある程度避けがたいというか対立する概念のような気はする
でも他のステージ（制作時や、YUV→RGB変換により出力する時）であらわれる
バンディングは、本来ナイーブな丸めをせずきちんとディザってれば
いい話のようには思うんだけどな

たとえばYUV→RGB変換は、ナイーブに（たとえば全部四捨五入とか）で8bit整数に
落とすと、Yの値を1ずつ変えていった場合、7回に一回RGBが1でなく2変化する
箇所が出る（計算してみればわかる）
丸め方がナイーブでパターン化してるから、目に見えるアーティファクトに
なってしまうわけで、丸めかたを最適化するのが本来の意味でのディザ
ごく単純な例で言うと、1.1という値を10%の確率で1に丸めて90%の確率で2に丸める
これだけでもパターン化によって妙な周波数成分が出てしまう問題は避けられる
階調の乏しいところに適当にノイズ散らしてごまかそう、という意味じゃない

エンコード時の劣化で加わるバンディングの方が圧倒的に大きいでしょ
ソースに元々入ってるバンディングなんてよほどの画質比較マニアじゃなきゃ分からんが

完全に逆だと思うがね
最初からバンディングの出てるソースは軽く流して見ててもすぐ分かるし、
元々バンディングがなかった部分にエンコの結果としてバンディングが出てきたという
経験をしたことはない

ソースにバンディングがあるなら、フィルタをかければ改善する。

ソースにバンディングがないのに、エンコ後バンディングが
出るなら、ビットレート上げるか10bitでエンコすれば改善する。

それだけの話だと思うが…

>>180
放送ソースだとバンディングは結構あるよ。BDソースだと稀だけど。
ノングレアのディスプレイ使っているとわかりにくいかもしれん。グレアと
比べると、まるっきりノイズとかアラが見えなくなるから。

実写は知らんけどアニメBDならソースからバンディング出てるのは普通にあるよ
ソースといってもBDに入ってるのはH264/AVCなわけで、アニメの場合はね

>>183の補足、もちろんアニメBDが全部H.264/AVCエンコ収録とは限らない
が、テレビ放送されてる作品のアニメBDでH.264/AVCエンコ収録じゃないものにはお目にかかったことない

>>184
アニメBDの黎明期はMPEG2収録ばかりだったけどな
俺が持ってるやつだとAIRのBD-BOXとかうたわれるものとかがMPEG2

AIRなんかはmpeg2
http://av.watch.impress.co.jp/docs/20080821/pony.htm
最初期はAVCはまだノウハウが無かったので、避けられるケースが多かった

被った、すまね

さすがにx264関係ない気がしないでもないが

>>180は糞モニタで糞エンコしてるかレコーダー録画で糞エンコしてるかのどっちかだろう

>>185-186
そっか、黎明期はアニメBD買ってなかったんだよな
それはそうとスレチな話すまんかった

まあどんなに手間暇掛けようと自己満だかんな、忘れちゃ駄目だぞっ☆

スカパーHDの実写映画とか空にしょっちゅうバンディング出てるよ

今のx264で8bitエンコするとしたら
crf20くらいの常識的な圧縮率だとバンディングが出てくるのはどうやっても避けられないし
ffdshowでdabandするか見なかったことにするしかないように思うんだけど

そう結局のところ>>169が言ってることが正解
ソースに忠実にエンコードするためにはエンコーダでのバンディング対策が必要

フィルタでディザかけるのだって、エンコする時にその場所のビットレートを高くするため、という意味もあるからな

とっとと10bit再生環境が市販レコーダー等で一般化してくれれば、10bitエンコードを躊躇わずにできるのだが、
この先の展望がいまいち読みにくいので、保存用途含めて導入すべきか悩む

PCで見るから10bit一択

バンディングは、
--aq-mode 3 にして、--psy-rd を 1.0:0.2 位にすると
かなり改善される。

14bitはまだ？

256bitsでいい

ちょbitsﾏﾀﾞｰ？

じゃあ俺はFITでいいや

10bitと聞いてなんか前スレ終わりごろに偽物語EDのP/Bフレームがとかってのを思い出してやってみたら
まどかEDと同レベルのP率(--b-adapt 1)だった
こういうところを--b-adapt 2とかが無理にB使うようにすると比率が普段と違ってくるだけじゃないのかねぇ
そも数値で動画見るわけじゃないから綺麗ならなんでもいいはずだけど

x264 [info]: profile High 10, level 5.0, 4:2:0 10-bit
x264 [info]: frame I:41    Avg QP:29.22  size: 94294
x264 [info]: frame P:2096  Avg QP:36.32  size: 48436
x264 [info]: frame B:21    Avg QP:38.14  size: 22489

>>197
そのpsy-rdだとバンディングは良くなるけど、
細かい部分がザワついたりして汚くなるよ。

ならねえよ

ソース次第

ざわ…ざわ…

おお…

わさ…
　わさ…

可愛いおんにゃのこだと思った?残念!

ついてるんです

わぁい！

おちんちんランドはじまるよー！

開園

>>204
まあアニメだとPsy-trellis入れると>203みたいなことになるよ

股間周りのバンディングノイズが消せません。どのパラメータを弄れば綺麗に消せますか?

ブロックノイズじゃないのか

psy-trellisを盛るとゲームのHPゲージのような単一色同士の境界面でたまにおかしな味付けをする気がする

笑わせんな禿げ

.:　　　　　.:: ::::::::::::::::::::::.:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::!　ﾞi
　　　　:.　::: ::::::::::::::､::::::::::::ﾄ､::::::::::::::::::::::l、:i::::::::::::::::::::::::::::::::::| 　 ｝
.　　　 ::　:::::.::::::::::::::ﾄ＼::::::!i_}:::::::::::::::::::::ハ:ﾊ:::::i::::::::::::::::::::::::::|　　}
　.:　　:::. :::::::::::::::::ﾄ;:'､ヽ＼|ヾﾞ＼::::::::::::::|=斗‐i::|!:::::::::::::::::::::::::!　　l!
　:.　　:::::.::::::::::::::::f≦斧芸芯气 ヾ､:::::|:| ‐|!ｰ}:ﾊ:::ﾉ:::::::::::::::::::|　　 |
　::.　　::::::::::::::::::::::: ヽ 込zｲﾕ　　　 ＼||!i　　 ﾉ/ｲ::::::::::::::::::::::|　　 {
　:::.　 ::::::::::::::::::::::::::.､　　　　　　　　__.） i＿ ＿_/::::::::::::::::::::::i　　　}　　気をつけたほうがいいよ
　:::::.　 :::::::::::::::::::::::トヽ　　　 __ｨ=＝´｀ゝ─‐‐７イ::::::::::::::::::/　　　!　　　もうハゲ始めてるかもしれない
ヽ ::::::.　::::::::::::::::::::::ﾍｰ‐=＝"´　　　 ' 　 　 　 /::::::::::::::::::::/　　　 |
　＼:::::.. ::::::::::::::::::::::::ﾍ　　　　　　r__ｧ　　 　 ｲ:::::::::::::::::::ノ　　　　|!
　　 ＼::::.:::::::::::::::::::::::::ヾ､ .　　　　　　　　イ:::::::::::::::::::／　　　　 ‖
　　　　）:::::::::::::::::::::::::::{-|　 ＞‎　　　 ..イ::|!::|i::{::::::::::::（_　　　　　〃
　　ｰイ_,ｨ:::::ﾄ:::::::::::::::::::',ﾄ､　　　　¨/;ﾞ弋:{乂`/::::::λー'´.　 　//
　　　　〃＼! ）:廾`＼:::＼｀ヽ--､_У |:i:i:i≧／）'ヾ　　（､＿ノ"

>>217
trellisじゃなくてsubmeを変えてみたらどうかね

どっかのブログの薦めをみてfft3dとかつかうと
バンディングのないソースでもバンディングが出まくるもんなｗ

sigma=2とかにすりゃ出るだろうな

勧めおまんこサイト集！！無修正！！全部無料で見れ！！
ttp://blog.livedoor.jp/amd646464/archives/52258745.html

10bitってのは恒久的に定着するのかねぇ。
オーディオの18bitとか20bitみたいな一時だけの規格で、
いずれキリのいい24bitとか32bitになっていったみたいに
16bitあたりで定着するのだろうか？

と見せかけて1bit

>>225
1bitオーディオの技術を動画に応用するのか？！

行くところまで行くと最終的に1bitになる。
パラレルATAだってシリアルATAに移行してるだろ？

階調を1bitにして解像度を10倍にしよう
きっとレンダリング時の縮小アルゴリズムでフルカラー相当ぐらいになる

受け手側の脳内の情報を利用して映像構築するようになり、動画の画像情報が0bitになる日も来るな。

量子ビットを利用して、カメラに撮ってないシーンも再生出来るようになる

Pegasysｽﾚ面白いな
ｦﾁｽﾚ欲しいｗ

>>231
ヲチスレ経由で変なのが増えるから簡便
下手するとペガスレだけじゃなく板に居つくからここにも迷惑

1bitオーディオは可逆だからこそ成立する符号化だろ？
非可逆圧縮がほぼ必須な動画に意味ある技術なのか？

おい俺に構ってくれ
まだまだ先の話かも知れんアガ

マジレスする話じゃないだろ
やってることは全くの別物なんだし
100MビットROM使ってるネオジオって超高画質だったんだな！ってくらい意味不明

10bitが定着する前にH.265が来るんじゃないかなぁ

定着しようがしまいがPCでしか使わないから10ビット使ってる
この先H265が来て製品化されてもその製品が10ビット再生を
サポートしないなんて考えられない

H.265コーデックは8K対応で2013年登場
ttp://blog.livedoor.jp/amd646464/archives/52258745.html
最終策定は2013年1月
H.265では現行のH.264と比較して35〜40%ビデオストリーミング効率が向上しており、最大67%も向上している
こういう話があったな

10bitソフトが出ても今使ってるツールが
多分対応してないから困ると思う

8bit→10bitでも十分恩恵かるから
H.264は今のままでいい

>>238
おーこんな話もあるのか

10bitはそのうち廃れていくだろう

現状じゃ10bitは各種メディアプレーヤーで再生できないから使わないわ

各種メディアプレーヤー

民生機では全く相手にされないしな

PS3とか対応してないの

ふぇぇ…ママどこぉ…

お前のすぐ後ろに

Format : AVI
Format/Info : Audio Video Interleave
File size : 7.75 MiB
Duration : 1mn 26s
Overall bit rate : 752 Kbps
Writing library : VirtualDub build 32842/release

Video
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : H264
Duration : 1mn 26s
Bit rate : 612 Kbps
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.066
Stream size : 6.30 MiB (81%)
Writing library : x264 core 120 r2146kMod bcd41db

ごめん何を訴えたいのかわかんないや

　　　　　　　　 ,-､　　　　　　　　　　　　,.-､
　　　　　　　 ./:::::＼　　　　　　　　　 ／::::::ヽ
　　　　　　　/::::::::::::;ゝ--──-- ､._/::::::::::::::|
　　　　　　 /,.-‐''"´ 　　　　　　　　 ＼:::::::::::|
　　　　　／　 　　　　　　　　　　　　　　ヽ､::::|
　　　　/　　　　　　　　　　　　　　　　　　　ヽ|
　　 　 l　　　　　　　　　　 　 　 　 　 　 　 　 l
　　　 .|　　　 ●　　　　　　　　　　　　　　　　|　　　　んーとね・・
　 　 　l　　, , ,　　　　　　　　　　　●　　　　 l
　　　　` ､　　　　　　(_人__丿　　　　､､､ 　 /　
　　　　　　`ｰ ､__　　　　　　　　　　 　 　 ／
　　　　　　　　　/`'''ｰ‐‐──‐‐‐┬'''""´
　　　　　　　　 ,-､　　　　　　　　　　　　,.-､
　　　　　　　 ./:::::＼　　　　　　　　　 ／::::::ヽ
　　　　　　　/::::::::::::;ゝ--──-- ､._/::::::::::::::|
　　　　　　 /,.-‐''"´ 　　　　　　　　 ＼:::::::::::|
　　　　　／　 　　　　　　　　　　　　　　ヽ､::::|
　　　　/　　　　●　　　 　 　 　 　 　 　 　 ヽ|
　　 　 l　　　, , ,　　 　 　 　 　 　 ●　　　 　 l
　　　 .|　　　 　　　　(_人__丿　　　　　､､､　　|　　　　わかんない
　 　 　l　　　　　　　　　　　　　　　　　　　 　 l
　　　　` ､　　　　　　　　 　 　 　 　 　 　 　 /
　　　　　　`ｰ ､__　　　 　 　 　　　　　　　／
　　　　　　　　　/`'''ｰ‐‐──‐‐‐┬'''""´

たまらないな(*´д`*)

ふぇぇ…駄目だよぅ…

>>248
JEEB氏の2164使ってやれや

Bフレームすごいな
再生負荷はぐんと上がるけどサイズが一割強縮むってやばすぎ

え、Bフレームとかデフォで有効だろ

そうだよな普通なら逆の感想になる、Bフレーム使わないと結構サイズ増えるなって感じの。

ノートでも再生環境上がってきたからｂフレ敬遠してた人も使うようになってきたんじゃないか

MPEG1、２だってBフレ使ってるのに

ふぇぇ…ビーフレェェ…

らめぇ・・・P(ork)じゃなくてB(eef)がいいのぉ・・・・

うるせえチキン野郎

誰ウマw

ウマンダム！

スカパーHDはなぜかBフレーム使ってなかったり
しかもMainプロファイル

Iフレオンリーでお願いします

愛に溢れている

愛など要らぬ

容量足りてたらBフレームは要らないだろ
音声遅れるし

>>268
都市伝説？ソース求む

>>268
そういうやつは--qp 0でエンコすればいいじゃね

何年寝てたんだよ

bフレを使ってさらにb-adaptを盛りまくればさらに縮まるぜ。
ただし速度は盛れば盛るほど遅くなるがｗ

qp0でもBフレあったほうが良くね？

qp0だとBフレ無効にならね？

>>269
【初期ディレイ】bframes=3、b-pyramid＝normal の場合 ２フレーム遅延 ‐ ニコニコ動画(原宿)
http://www.nicovideo.jp/watch/sm15989567

これかな？

スカパーHDってmp4なのか？

ts

>>276
コンテナm2ts
コーデックH.264

>>275
Bフレームによる初期ディレイ(遅延)がわかりやすいように1fps、10フレームで。
通常はedtsで調整されるが、FlashPlayerはedtsを解釈しないため遅延が起きる。
↑が抜けてんぞ。
普通にPCで見るのにFlashPlayerなんか使わないから問題ない。

家電製品が遅延考慮して作ってあるっていうのか？

俺は>>264に対して言ってんのに何話すり替えてんだよ！

>>280
DVのころからデジタル録画では常識だよ

知らんがな。
お前の再生環境知らんし、メーカーにきけよ。

また偶々だがうちのiPod touchは遅延考慮してる
Bフレ3でBピラなしだけど

たしかにflashplayerは--dts-compress使わないと駄目だな

持ってないから知らんけど、>>268では、一部の環境では遅延するって言ったほうが良かったんじゃ。

>>232
そうね
じょだんでも言う事じゃ無い罠
すまん

>>268は音声が遅れるって言ってるけど、Bフレーム使用時に遅れるのは音ではなく映像のほうだという。

mkvまんせー

Bフレームで縮むものと縮まないものの差が大きいな
B挿入でIフレームをどれだけ減らせたか

意味が分からない。IフレームPフレームBフレームはそれぞれ大切

H.264-Iフレームオンリーだと、MJPGといい勝負か？
コンテナ選ぶかも知れんが

AVC-Intraやん それ

>>292
かなり前にx264のIフレームはJPEG2000より優れてるとこのスレにソースが貼られてたと思う
だからMJPEGと比べればかなり有利なんじゃね

ふぇぇ…ママどこぉ…

qcompを0.6から0.8に上げても画質向上やデータが縮むわけではないのか

割れ臭がする書き込みだな

Doom9's Forum - View Single Post - x264 "Macroblock Tree Ratecontrol" testing (committed)
http://forum.doom9.org/showpost.php?p=1310980&postcount=1

7.5.?Encoding with the x264 codec
http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html#menc-feat-x264-encoding-options-misc-preferences

割れってなに？

和レモン

qcompを0.6から0.8に上げるとSSIMが落ちる
けれど動きの速いシーンを静止画で比較するとノイズが軽減している

考えるな、感じろ

>>300
それは仕様だ

ttp://www.youtube.com/watch?v=2d5o8d1kitM

>>294
そうなんだ
でも、負荷的にはx264のほうが重そうだな

Vistaサポート延長大勝利で飯がうまい

俺の手持ちPCは7とXPの二極化しちゃったからもう遅いわ

>>305
ガセか思ったら...

>>305
vista割と気に入ってたのに仕方ないから7にしちゃったぞおい…

ふぇぇぇ…Vistaって何だったの…

さては8の開発がひどい状況なんだろうかｗ

企業関係からクレームがわんさかついたんじゃないの

VistaはAVXねーからなー

AVXは速くないしどーでもいいと思うぞ
遅くはないけど無くてもスピードに大差ない

AVXへの最適化もされてないのにもうTSXだからな
TSXなんて流行るのか？

3Dnowが最強って事で良いんですよね

その通り
K6-2さえあれば何でも出来る

どうでもいいが3Dnow!だろ

haswellになればx264の評価もまた相当上がるんだろうなぁ

どうでもいいが3DNow!だろ

どうでもいいがK15以降のCPUは3DNowに対応しないんだぜ
つまりもう要らない規格。終わった規格。忘れたい規格。サポートすらしたくない規格。

K15?

10bit出力したファイルをMPC-HCで再生したら全体的が緑色がかってたから
なんでだなんでだと3時間程悩んだ挙句
LAVfilter入れたら一発で修正された
もっと速くいれるべきだった…

あれ、MPC-HC内蔵って未だに10bit再生できないの？
CoreAVC使いの俺には関係ないけど

MPC-HC 1.5.2.3456では色々問題があったけど、1.6.0.4014なら10bitも問題なく再生できるよ。
全体が緑がかるという現象はもっと古いバージョンのような気がするが、>>322はいつのを使ってるんだ。
というかLAV Filtersを入れるだけで解決したってことは内蔵デコーダは使ってなかったんじゃねえの。

どうでもいいが3DNow!だろ

3DNo! 2DYes!

あれ？ウチじゃMPC-HC 1.5.2.3456で問題なく10bit出力できてるけど？
と思って、よく見たらffdshwのおかげだった。
俺も無意識に外部デコーダ使ってたってオチか。
つか8bitでもffdshow切ったらメチャ汚ねーの。
俺のエンコ設定って…orz

10bitはDXVA効かないんだよなあ

今時DXVAなんかいらないよー、8bitもいらないけど

10Bitは再生の汎用性が低いからお遊び用にしかならないだろ

汎用性

>>331
お前がそんなこともわからない馬鹿ならググれ

汎用性

つまんね

割れ厨はすっ込んでろ

俺の環境で綺麗に再生できれば良いんだよ

>>335
この流れで割れ厨発言とか馬鹿の極み

違法DLしてるような犯罪者にはBDに焼いてTV再生とか思い付かないんだろうな

ディスクそのまま使えばいいんじゃね？

ID:IeWSMsY1

さすがに全部のアニメBD買うのはきついなあ
放映から発売まで時間が空くのも多いし

万引き無料

>>342
おまわりさん、コイツです

　　　　　　　　　　　　　　　 ;;-､
　　　　　　　　　　 　　 　 ／ヽ;;)
　　　　　　　　∧＿∧ ／
　 ∧＿∧＿（◎・∀・∩
　（　・∀|[__|ｏ|＿∧つ　　　　　 ＿＿＿
　 |　つ　∩（　・∀・））　　　　　|　i ＼　＼
　と＿）＿）（　つ|三|O　　　　　|　i　　l ＝l
　　　　　　 と＿）￣） 　 　　 　 |　|__ノ　 ノ
　　　　　 　　　　￣ 　　　　　　|￣￣|￣￣|

＞ｺﾞﾊﾝﾖｰ
　　　　　　　　　　　　　　　 ;;-､
　　　　　　　　　　 　　 　 ／ヽ;;)
　　　　　　　　∧＿∧ ／
　 ∧＿∧＿（・∀・◎∩
　（・∀・|[__|ｏ|＿∧つ　　　　　 ＿＿＿
　 |　つ　∩（・∀・　））　　　　　|　i ＼　＼
　と＿）＿）（　つ|三|O　　　　　|　i　　l ＝l
　　　　　　 と＿）￣） 　 　　 　 |　|__ノ　 ノ
　　　　　 　　　　￣ 　　　　　　|￣￣|￣￣|

JEEB氏のサイト落ちてる？昨日からつながらない。

MPC-HCのhenryのとこだよね？

fushizen.eu入ってる鯖が丸ごと落ちてるみたいね

>>346
金払ってないから止められてるよ

>>338
おれはPCで再生してHDMI接続でTVで見てる
ディスク入れる手間もいらないし楽だぜ

>>349
そういうことなのかｗ

>>346
こういう落ちは結構あったりするけど、今回は長いみたい。
一応今のところまではたまに落ちる以外だと結構よかったりするけど。

>>349
それどこの情報ｗｗｗ　少なくともjarod氏の説明には入ってなかった。

まぁ、稀によくある

https://twitter.com/jeebjp/status/171217047156572160
未だにfushizen.euをホスティングしてもらってるところのサーバーが完全に落ちてるっぽいなぁ。
普段は数ヶ月に一回、一日ぐらいで戻ってくるけど。

オラァ！糞鯖！
ヨブさんに迷惑かけてんじゃねぇぞ！

MPC-HCのhenryビルド、お世話になってまっせ

お金払ってないから止められたなんて恥ずかしくて言えないだろ

世界お金持ちクラブ

黙って2senを使えばいいのにアホ杉

VLCが10bitに対応したとかなんとか

VLCってVFRの再生どうなんだっけ
今は再生できるのか？

>>361
24fpsと60fpsの混合なら普通に再生できてるよ。

【パテントフリー】 WebM 【VP8+OggVorbis】
http://toro.2ch.net/test/read.cgi/avi/1329899392/

ヨブさんサイト復活おめでとうございまる

POP氏がr2164スルーしてる件

　　　　　　　　　　　 ,. -─- ､._　　　　　　　　　　　　 　 ,. -─v─- ､._　　　　　＿
　 　 　 　 　 　 ,. ‐'´　　　　　　`‐､　　　　　　　　__, ‐'´　　 　 　 　 　 ヽ, ‐''´~　　 ｀´￣`‐､
　　　　　　　／　　　　　　　　　　　ヽ､_／)ﾉ　　 ≦　　　　　　　　　ヽ‐'´　　　　　　　　　 　 `‐､
　　　　　　/　　　　 ／￣~`'''‐- ､.._　　　ノ　　　≦　　　　　　　　 ≦　　　　　　　　　　　　　　 ヽ
　　　　　　i. 　　　／　　　　　　　　 ￣l　7　　　　１　 ｲ/l/|ﾍ ヽﾍ　≦　　　,　,ﾍ ､　　 　 　 　 　 i
　　　　　　,!ヘ.　/ ‐- ､._　　　u　　　　|/　　　　　 l |/ !　! | ヾ ヾ ヽ_､l　ｲ/l/|/ヽlﾍﾄ､　　　　　　│
.　　　　　 |〃､!ﾐ:　　 -─ゝ、　 　 ＿_ .l 　 　 　 　 ﾚ二ヽ、 ､__∠´＿ |/ |　! |　 | ヾ ヾﾍﾄ､　　　 l
　　　　　　!_ﾋ;　　　 Ｌ(.:)＿ `ｰ'"〈:)_,` /　　　　 　 rｉヽ_(:)_i　　'＿(:)_/ ! ‐;-､ 　 ､__,._-─‐ヽ.　,.-'､
　　　　　　/｀ﾞi　u 　 　 　 ´　　　 ヽ　 !　　　 　 　 !{　　　,!　　 `　　 （ } ' (:)〉　　´(.:)｀i　 　 |//ﾆ !
　　　　_／:::::::!　　　　　　 　 　 　 ,,..ゝ!　　　　　　 ﾞ!　　 ヽ '　　　　　 .ﾞ! 　７　　　 ￣　　　　| ﾄy'/
_,,. -‐ﾍ::::::::::::::ヽ、　　　 r'´~｀''‐､　 ／　　　　　　　 !、　 ‐=ﾆ⊃　 　 /!　 `ヽ"　　　　u　 　 ;-‐i´
　!　 　 ＼::::::::::::::ヽ　　　`ｰ─ '　／　　 　 　 　 　 　 ヽ　　‐-　　 ／　ヽ　 `￣二)　　　 　 /ヽﾄ､
　i､　　 　 ＼:::::::::::::::..､　　~"　／　　　　　　　　　　　　 ヽ.＿__,.／　　//ヽ、　ー

お金払ったんか？

>>365
おいらもPOP氏のを愛用しているのだが
利用者多いのかな？

自ビルドすればいいじゃない

やり方分からない(´・ω・｀)

みんな最初はわからないとこから始めたのよ
一度覚えれば、他人をあてにする乞食生活から脱出出来るよ
「やりかたわからない(´・ω・｀)」って言ってるやつに「自ビルドすればいいじゃない」って
得意ぶったレスできるようになるよ

git clone git://git.videolan.org/x264.git
cd x264
./configure
make

これが基本だ

時間逆行してんのか

やってるやってる(｀・ω・´)

互換性重視するとBフレームは3ぐらいに留めていた方が良いかと

バッファローとかの端末型メディアプレイヤーがHigh-5.1に対応すればいいのに(´・ω・｀)

Levelの概念がわかってないのか、はたまた数年後の世界を夢見ているのか。

それなりにBDプレーヤー等の対応機器も出ている、これに合わせるのも良いだろう。

http://en.wikipedia.org/wiki/DivX_Plus_HD#x264_compatibility

10bit対応プレーヤーも出るのかね？

>>378
それ日本向けの機器じゃないし、mkvじゃん

おお…

そんなにテレビで見たいならmicroATXで再生専用機組めば良くね｡汎用性超高いぞ

>>380
http://pioneer.jp/blu-ray/bdp_140/

>>382
俺か。
最終的にそこにたどり着く。
デュアルコアで充分といったところだな。

Format profile : High [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 9 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1h 39mn
Bit rate : 2 084 Kbps
Maximum bit rate : 15.1 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.094
Stream size : 1.45 GiB (78%)
Writing library : x264 core 120 r2164+649+26 fcfb618 tMod [10-bit@all X86_64]
Encoding settings : cabac=1 / ref=9 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=11 / psy=1 / fade_compensate=0.00 / 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=0 / chroma_qp_offset=-2 / threads=9 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 /
bframes=9 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 /
crf=16.0000 / qcomp=0.60 / qpmin=0 / qpmax=68 / qpstep=4 / ip_ratio=1.40 / aq=3:1.00
Language : Japanese
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

10ビット流行っとるな

10bit化はソースが10bitじゃないとやりにくい
どこかまともなキャプチャカード出してくれたらLDソース用に試してみたいんだが

>>386
＞10bit化はソースが10bitじゃないとやりにくい

なにがやりにくいと言うのだろう・・・。

効果が限定的って意味だろ

めちゃめちゃ画質上がると思うんだが
ちゃんと比較してんのかね？

TVで見られない・・・

どんなTVだよ

最近のテレビは、h.264なmp4を直接再生できるけど、
10bitは無理ってことじゃないの、PS3みたいに。

バンディングとか専用ハードなら再生時の補間でどうにかした方が速いから
主流にはならんだろうな。

主流とか関係ないし

イェーブの耳の裏ってどんな匂いがするの

>>382
構成おせーて

>>395
残念だが、おっさんのスメルがします

色空間スレがやられたようだな…

色空間ｗｗ
バカスｗｗ

馬鹿がまともにテンプレも作らずに立てたスレとはいえ、ずいぶん早く落ちたな・・・。
この板ってこんなに早く落ちることってあるんだっけ？レス数少ないまま放置されてたから？

>>389
ぜひ比較検証を

しかし奴は H.264/AVC 関連スレッドでも最弱……
次は HEVC スレが危ういのではないかと……
それもこれも全部 BLACKCAS でスレが乱立しているため……

今や世の中のソースの大半がBT.709/TVスケールだと言う事以外に、色空間を語り様が無い。

>>403
あとはxvYCCぐらいかな…

xvYCCのソースをエンコする機会なんぞねえだろ･･･

アニメのOP 720pで検証してみた

SSIMが0.9924548から.9936509に上昇
54.7MBから51.2MBに減少

DXVAの再生支援さえ機能してくれれば…ぐぬぬ

YUVの色域でさえろくに使い切れてないのにxvYCCはまだまだ早いんじゃないかな
10bitが普及するかいっそYUVをやめてRGB8bitにするのが先かと

と思ったけど720pくらいならceleron2コアでも充分再生に耐えるんだな
x264ってもっと再生負荷が高いものだと思い込んでたわ

h.264な

>>406
psnrもよろ

>>407
ttp://www.jeita.or.jp/japanese/hot/2006/0830/0830.pdf の21ページ目の表にあるように
sRGBでは67.5%しか包括率がないってことだから、色域の拡張は意味があると思う。

まあ、8bitのまま色域を広げると荒くなるので、10bit化の普及も進行して欲しいけど。

10bitでエンコする場合avsのほうでf3kdb(output_mode=2, output_depth=16)
とか言うのを設定しないといけないのか？
http://logsoku.com/thread/toro.2ch.net/avi/1308308879/#678
そのままだと8bit深度のままx264に渡しちゃうことになるのかな

>>406
PSNRは測ってないや
SSIMの次にあるカッコ内の値は21.223dbから21.973dbに増えてた

>>412
最新のx264なら色バグ直ってるからわざわざそんなことしなくてもいい
今までと同じやり方でＯＫ

>>413
色バグがあったんですね！ありがとうございます


8bitは(2^8)^3色、10bitは(2^10)^3色なら

*8bit -> 0***1***2***3** … 255
10bit -> 0123456789abcde …1023

だいたいこういう理解でいいんでしょうか
各色の階調の差がこんな感じなら階調割れバンディングが起こりにくいっていうのも理解できそう

あと、10bitでエンコしたものをスマホ用とかに再エンコしたい場合に
avisynthのffmpegsourse2()で読み込んだ場合、10bitとして読み込まれるんでしょうか
ffmpeg自体は2010年の時点で10bitに対応しているらしいけど

>>406検証結果

アニメ本編
*8bit : 404MB 0.9954544 (23.424db) 9.66 fps
10bit : 380MB 0.9961474 (24.142db) 8.02 fps

アニメOP
*8bit : 54.7MB 0.9924548 (21.223db) 6.46 fps
10bit : 51.2MB 0.9936509 (21.973db) 4.85 fps

720pならceleron2コアでも再生負荷は30％弱以下だったし
DXVAがなくても大丈夫そう

再生負荷はCPUよりグラボ次第じゃね？

>>414
RGBモニターでの表示だから8bityuv420で440万色程度だぞ

>>414
YUVで表現できる色の数について（8bit〜10bit depth）
　　ttp://csbarn.blogspot.com/2012/01/converttorgb.html
　　ttp://goldenhige.cocolog-nifty.com/blog/2012/01/rgb2416777216yu.html

YUV8bit同士のエンコでなぜバンディングが出るようになるのかいまいちイメージできない

>>417
なつほど…x264-10bitでやっとRGB24の(2^8)^3色を表現できるレベルなんですね
8bitだと乱暴に言えばRGB24の16万色のうち1/4弱ほどしか収録できないのか

>>414検証の続き
*サイズ (単位:byte 音声40MB弱含む)
　　　　8bit　　　　　10bit
06 314,574,993 262,548,537 -52,026,456 83.461%
07 305,863,959 252,595,533 -53,268,426 82.584%
08 319,385,891 267,049,657 -52,336,234 83.613%
09 334,856,411 279,985,704 -54,870,707 83.614%
10 316,174,924 260,648,125 -55,526,799 82.438%
11 302,020,128 247,943,009 -54,077,119 82.095%
12 329,271,803 270,798,086 -58,473,717 82.242%
13 339,586,142 289,760,315 -49,825,827 85.327%

*SSIM
06 Y:0.9953638 Y:0.9960988 +0.0007350 0.073788%
07 Y:0.9957001 Y:0.9963294 +0.0006293 0.063162%
08 Y:0.9952330 Y:0.9960153 +0.0007823 0.078543%
09 Y:0.9953008 Y:0.9960433 +0.0007425 0.074545%
10 Y:0.9956858 Y:0.9963554 +0.0006696 0.067205%
11 Y:0.9956196 Y:0.9962987 +0.0006791 0.068162%
12 Y:0.9956130 Y:0.9962901 +0.0006771 0.067962%
13 Y:0.9947741 Y:0.9957299 +0.0009558 0.095990%

*fps (8bitは作業しながらエンコしてたんで6/7/9/13くらいしか当てにならないと思う)
06 9.36fps 8.67fps -0.69 -7.372%
07 9.61fps 8.96fps -0.65 -6.764%
08 8.84fps 8.79fps -0.05 -0.566%
09 9.33fps 8.53fps -0.80 -8.574%
10 7.73fps 8.81fps +1.08 +13.972%
11 8.80fps 8.91fps +0.11 +1.250%
12 8.83fps 8.75fps -0.08 -0.906%
13 9.25fps 8.40fps -0.85 -9.189%

>>418
同じく。8bit版も内部10bit処理にして改善できないもんかね。
高音質CDとか見たいにさ。

>>421
半画素探索とかMPEG1の時代から実装されてるぞ

8bitでも量子化する際にアーティファクトのようなもので色域が変形？するからじゃないのかな
原理は分からん

>>422
検証のおかげで10bitの優位性は分かったが、元データが8bitだから釈然としないんだ
8bit版も10bit検証と同等まで上げられないのかなと
特に問題だと思うバンディングはYV12ソースから8bit出力だから色空間上劣化がないはずなのに
汚くなりすぎｗ

人間の目で見て劣化なくリニアに変化する場合は8bitで事足りる。
しかし、その8bitの情報を間引いて（＝つまり圧縮）記録し、再生すると8bit精度の情報が保たれておらず
7bitや6bit、圧縮率が高いともっと低いbit精度で記録したのと同程度の品位しか保てない。
続く

続き
結果、人間の目にはバンディングとして知覚される。
いったん10bit精度に引き上げてから間引きをして記録した場合、間引いた結果9bitや8bit精度の情報が残り、結果バンディングが知覚されない。
とかなんとか

DCT係数の直流付近の成分は間引かないようにすればバンディングは起きない？

なるほど
8bit(10bit)エンコードだから8bit(10bit)の情報がすべて残ってるんじゃなくて
そこから色数を間引いた情報しか残らないんですね
YUVの色空間が4:2:0なのも関係してるんでしょうか

別アニメで検証
>>420ほどサイズは縮んでいないけれども、そのぶんSSIMが上昇している気がする

10： 507,112,529 468,596,387 -38,516,142 92.405%
　　 Y:0.9941975 Y:0.9951210 +0.0009235 0.092803%
11： 645,067,295 605,339,201 -39,728,094 93.841%
　　 Y:0.9937299 Y:0.9945901 +0.0008602 0.086488% 8.85fps 7.47fps -1.38 -15.593%

>>428
関係してるYUV444ならほぼフルカラー発色する

>>429
4:2:0サンプリングが関係するというのは別にいいけど、
>>417にあるとおり、8bit-depthのTVレンジで表せる色はせいぜい300万色程度なんだが・・・。
「フルカラー発色する」ってのはどういう意味で言ってる？

色空間とか全然わかってない人間のどんぶり勘定ですけど

8bitRGBで計算すると
YUV=4:4:4 だと (2^8)^3=16,777,216色
YUV=4:2:2 なら 2^8x(2^8/2)^2=4,194,304色

なんで>>417の数字に近くなるのかな？

10bitで計算すれば
YUV=4:4:4 だと (2^8)^3=1,073,741,824色
YUV=4:2:2 なら 2^10x(2^10/2)^2=268,435,456色

>>431
さすがにその計算は考え方を間違えすぎ。

それとも10bit YUV=4:2:0 だと U:2^10/2=512 になるから
その情報をUとVの色差で分けあうと 512/2=256色になるので
256^3=16,777,216色 と8bitRGBと同じ色数が確保できると言うことなんでしょうか

>>433
・8bit-depthのYUVで表せるのは約300〜400万色。10bit-depthのYUVで表せるのは1677万色。
　これはYUV4:4:4だろうがYUV4:2:2だろうがYUV4:2:0だろうが変わらない。

・元ソースがRGBとかYUV4:4:4やYUV4:2:2なら、元ソースからYUV4:2:0にする際に
　色差のサンプリングによって色が混ざるので、元ソースとは見え方が異なってくる。

・>>424の
　　　＞YV12ソースから8bit出力だから色空間上劣化がないはずなのに汚くなりすぎｗ
　については、
　　　・本当にYV12をそのままx264に渡しているのであれば、色空間云々ではなく
　　　　圧縮処理の過程で情報が欠落している。
　　　・実は元ソースをプレビューしている際に、何らかの補間がかかって綺麗に見えているだけで
　　　　実際のソースは汚い。
　といったことが考えられる。

こんなとこだろうか。

動画を編集してx264で保存したんだけど150MBになったんだわ。
ニコ動でプレミアムでも100MB以下にしないといけないだけど
設定がおかしかったのかな？どっかに100MB以下に出来る設定あった？
んで、ニコエンコで150MBを100MBにしようとしたら、コーデックが違うとか言われた。
どうすりゃいいんだ。

ソースを設定変えて再エンコすればいいだけだろ

>>436
回答嬉しいんだけど、編集してたデータは消しちゃっててさ。
出来上がった動画を編集しようとしたらフォーマットが違うって言われる。
この出来上がった動画は何か形式が違うのか。
あと設定変えるってどこかあったっけ？

てかその程度ならプレイヤー側で処理させればいいんじゃない？

プレイヤー側ってのは、150MBの状態でニコ動にUPして再エンコして貰うってこと？

初心者スレレベルの内容だなもう
一々聞くよりググった方が速いよ

おお…プレイヤー側ってのは、150MBの状態でニコ動にUPして再エンコして貰うってこと？

>>439
いいや、違う。たとえばMPC-HCを使う場合は
プレイヤー側でC言語ライクなシェーダスクリプトを書いて動画に反映できる。
たとえばBT.601->BT.709変換程度ならこんなのを貼ってやればスグ反映される

sampler s0 : register(s0);
float4 p0 : register(c0);
#define height (p0[1])

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0 = tex2D(s0,tex);
float y=0.299*c0[0] + 0.587*c0[1] + 0.114*c0[2];
float Cb=-0.172*c0[0] -0.339*c0[1] +0.511*c0[2];
float Cr=0.511*c0[0] -0.428*c0[1] -0.083*c0[2];
float r=y+1.540*Cr;
float g=y-0.459*Cr-0.183*Cb;
float b=y+1.816*Cb;
return float4(r,g,b,0);
}

ffdshowのavisynthにスクリプトを埋め込むのもありだがあれは重いからなぁ

>>442
お前はいったい何をどう勘違いしているんだ

勘違いどころじゃねえ

そもそもニコニコのこと聞いてる人がスレ勘違いしてるんじゃ

勝手に深読みするが、ここはお前の来る所じゃないと小難しい話で暗に諌めてるんだよ

>>434
違うぞ8bitと10bitの違いは目盛りの細かさだYUVの広さは8bitでも10bitでも変わらない
厳密に言えばYUVはRGBより広いがRGBのレンジ外をダブって置き換えるだけ
http://vision.kuee.kyoto-u.ac.jp/~hiroaki/firewire/yuv.html
420と444では目盛りの細かさが違うこれが色数の差となってバンディングに影響をあたえる

>>434
maniac乙

http://59.106.182.77/f/2008-09/ycbcr_cube.jpg

この図で言うと
RGBの色空間に対してYUVの色空間が広い
8bit深度のYUV（YCbCr、各値256）では、RGB（各値256）の細かさに対応できない
なのでもっとグラデーションの細かい10bitのYUV色空間（測定/計算/単位）として扱うと
RGBの8x3=24bitグラデーションにも対応できるって事なんでしょうか

要はRGB 8x3=24bitにおけるグラデーションの細かさと
YUV 8bit空間におけるグラデーションの細かさは同一ではなくYUVのほうがあらゐけいいち
だからバンディング（階調割れ）が発生するのだと

わかったから色空間スレでやれよ。

>>449
それ実際にはRGBの外のYUVの色数は全体の１割も無いよ
詳しい数は忘れたけどね

x264スレでHLSLを見るとは思わなかった

>>420検証の続き
10bit（上）と8bit（下）のバンディング比較検証(MPC-HC + ffdshow)
http://www.dotup.org/uploda/www.dotup.org2698686.png

全体的に色が変わってるのはなんでだろう

>>453
画像部分に使われている色の数(RGB24空間内)は
8bitが11445色、10bitは12325色でした。　880色の差

アホで申し訳ないんだけど、10bitってのはどこのデータ幅のことなんだ？
YUV420だと Y 4*10bit, U 10bit, V 10bit (4px packed)扱いで内部処理するって
ことでOK?

>>455
階調だよ8bitなら白黒だと2^8で256色
RGBだと(2^8)^3で16777216色
10bitは(ry

http://www.dotup.org/uploda/www.dotup.org2698902.png
これを
ImageSource("rgb24.png")
converttoyv12()
crf=0で可逆エンコして
バンディングや色数の違いを検証しようと思ったけどよくわからなくなってしまった

bt709のPCレンジで出力だ
まあ色々やってみるのも検証のうちだけどね

最近pop氏の更新がないけどやっぱ時期的に忙しいのかな・・・(´・ω・｀)

>>456
ありがと。
bit幅が色空間の分割数＝階調数ってことは把握なんだけど、ピクセルとの対応
関係というか、ソースの各要素(RGBで言えばR分とG分とB分)がそれぞれ10bitって
ことだよね？って意図でして

地デジのアニメはMXですらソースの時点でバンディング結構でてたりするんだが、みんなどうしてる？

MXも結構クソソース流してるぜ
昔はSDを除き綺麗な方だったけど

BD買えばだいたい解決するよ！

あの夏8話の肝試しのところ、バンディングがすごいことになってるな
10bitエンコの威力を思い知らされたぜ

>>463
BD買ってもMXのバンディングはいつまでも無くならんだろ？
MXが放送画質を上げてくれるまでの投資を、俺一人の購買力で支えるの無理臭いんだが
とりあえずお前も頑張れよ。

8bitでも30Mとか40Mの映像見てると圧倒的だと思えるわ
エンコはエンコだな、とか

>>447
「YUV⇔RGB変換の計算式（深度含む）」と「色差サンプリング」を混同しないでくれ。

8bitと10bitの違いが目盛りの細かさというのは正しい。8bitだと目盛りが荒いため、RGB24の色を全て表すことが出来ず、
10bitなら目盛りが細かいのでRGB24の全ての色を表現できる。これは>>449も書いているとおり。

だが、それと色差サンプリング方式（4:4:4:、4:2:0など）とは関係ない。
RGBデータが元ソースだとすると、
　　YUV4:4:4・・・各ピクセルがY,U,Vを持つ。各ピクセルでRGB→YUV変換が行われるだけなので、
　　　　　　　　　　それぞれのピクセルの色はほぼ正確に保持される。
　　YUV4:2:0・・・2x2の合計4ピクセルを１つの集合とする。Yは各ピクセルで持つが、
　　　　　　　　　　U,Vは4ピクセルの集合でそれぞれ1つしか持てない。
　　　　　　　　　　U,Vの決め方にもよるが4ピクセルの色が混ざるような感じになり、色が変わる。
　　　　　　　　　　そのため各ピクセルの色を正確に保持することはできない。
という処理の違いがあるだけ。要するに、
　　「個々のピクセルの色を保持できるかどうか」
の違いがあるだけであり、「8bitと10bitの目盛りの細かさの違いや表現できる色数」は4:4:4でも4:2:0でも変わらない。
2x2の4ピクセルで同じ色を持つソースを考えれば、4:4:4でも4:2:0でも表現できる色数に変わりがないことはわかるでしょ。

要するに「YUV⇔RGB変換の計算式（深度含む）」と「色差サンプリング」はともに何らかの影響を与えるけど、
影響の与え方は全然異なるということ。

>>464
俺は8bitでやってるけど、ソースに元々あるバンディングから
エンコの過程で大きく増えたりはしてないけど。

ソースにあるバンディングは消そうとすると、暗い部分で
髪の毛の線が消えてしまうので諦めた…

そうなんだよ無理に消そうとするとそういった本来ある諧調まで失われてしまう
やっぱ俺はそのままで行くわ

我慢出来るバンディングと我慢出来ないバンディングがある

寧ろバンディングは味と認めるべき
アナログのフィルム傷やブレやグレインノイズと同じ

10bitでのSSIMが向上するのは>>449の図で言うと
Y軸の輝度階調が2^8=256色から2^10=1024色に細かくなったことで
受け渡しデータのRGB値をムリヤリYUV8bitの色にあわせて変色させなくて済むようになったからなのかな

>>471
それは勘弁
狙ってつけてないから
制作側も消そうとしてるものだし

>>472
yuvにダウンサンプリングしてるんだからそれはないんじゃない？
そうでなければロスレスエンコードが出来ない事になる

>>474
ダウンサンプリングって言うのは>>467さんが説明してくれた
色差情報(UVもしくはCbCr)の2x2ピクセル単位のダウンサンプリングのことではなくて？

動画(映像)でresample(再量子化)つーたら、普通は解像度の変更のことだよな
RGB<->YUVはconvert（変換）
8bit<->10bitなんかはrescaleかな？
sampleとscaleの違いって、なかなかわかりにくいけど

グレインを保持する為にpsy-rdを盛りまくってたら、別のシーンではバンディングが虹色になったなぁ

たとえばaviutl内部の色空間はYC48で各16bit深度のYCbCr(YUV)4:4:4なんですよね
avisynthの内部はよくわからないけれど、似たような処理なら
16bit深度のYUY2 4:2:2 or YV12 4:2:0の色情報から8bit x264に受け渡す際に

0 1 2 3 4 5 6 7 -> 0 0 2 2 4 4 6 6

こういう風に間引きされてしまってバンディング（階調割れ）となってしまう
加えてSSIMの評価値にも影響しているんじゃないかな？って思ったんです

H.264 Losslessの色空間はYCbCr4:4:4 (High 4:4:4 Profile)なのか

10bitのほうがRGBとの変換が高精度でできるという理屈は分かるけど
それでSSIMもよくなる理屈が分からない、というか別の話に見える

8-bit -> 9-bitで、丸め誤差が半分に減って、9-bit -> 10-bitでさらに半分になり、
結果として、SSIMが20%程良くなる。

精度上げたところでどうせDCT圧縮の過程で間引かれるもんかと思ってたんだけど
そうでもないということなのかな？

同じファイルサイズだと変わらないんじゃないの

丸め誤差
読み方：まるめごさ
【英】rounding error, round-off error

丸め誤差とは、数値の計算処理の都合上、ある程度で値を省略することにより、計算結果に現れてくる誤差のことである。

丸め誤差の「丸め」とは、任意の桁数以上の精度の数値を端数として処理してしまうことであり、四捨五入や切り上げ、切り捨てなどを含んでいる。丸め処理は主に数値の桁数を揃えるために行われる。

例えば0.1234という数値を「小数点第4位以下切り捨て」によって丸めると、数値は0.123となる。このとき0.004の誤差が生じる。丸め誤差を含んだ値を使って計算を繰り返し行うと、誤差が蓄積し、計算結果が本来の値とずれてしまうことがある。

>>481
精度上げればむしろ滑らかになるんじゃね？
精度が2倍になれば2, 2, 3, 3, 4, 4, 5, 5, 6, 6 だったものが2, 2.5, 3, 3.5, 4, 4.5, 5, 5.5, 6, 6.5になるでしょ
そのほうが圧縮しやすいんだから

内部精度だけを上げて出力は8bitとかそういうのが欲しい

H.264は整数演算のせいで精度が下がってるかもね
少数使うMPEG2に比べると内部精度下げる代わりにアルゴリズムでフォローっていう設計思想だったかも

>>457を --crf 0 --qp0でエンコ
10bit http://www.dotup.org/uploda/www.dotup.org2701236.png
8bit http://www.dotup.org/uploda/www.dotup.org2701231.png

8bitのほうでバンディングがほとんど目立たないのは
ビットレートを上げておけばバンディングは防げるみたいな感じなんでしょうか

バンディング出ちゃったらロスレスじゃないだろ

>>487
RGB24色空間内の色数は 8bit が 2683色 で 10bit が 6344色 でした
（元の>>457画像の色は 1021色）

これ各色のファイルに分けて検証した方がよかったかな…

>>488
YUV8bitの色空間尺度（スケール）としては可逆ですよ、って事なんですかね

>>489
crf 0 は 8bit と 10bit で別物って指摘

>>488
wav<->flacとかでも、24bit尺度の音声を16bit設定で可逆圧縮しちゃうと24bitサンプリングwavには戻せない
でも16bit尺度のwavにはロスレスに可逆展開できるよ、みたいな

>>490
参考にしているサイトさんで説明されていたので一応両方とも --crf 0 --qp0 でエンコしています

>>480
この資料で、「同じ画質ならビットレートを5%〜20%ほど削減できる」というのは見たけど、それと混同してない？
ていうかSSIMが20%上がるってなんぞ・・・。
　http://x264.nl/x264/10bit_03-422_10_bit_pristine_video_quality.pdf

>>490
可逆は --qp 0 だよね。--crf 0 は10bitでは可逆ではない。
まあ両方指定した場合は --qp 0 が優先されるはずだから問題ないとは思うけど。

ごめん嘘ついた気がする。

＞まあ両方指定した場合は --qp 0 が優先されるはずだから問題ないとは思うけど。

これは嘘で、試してみたら後で指定したほうが使われるのかな。間違ってたらごめん。

あ、qp指定してたのか 見落としてた

--crf 0 --qp 0 と --qp 0 両方ともサイズ同じでした
qp 0 は可逆指定だけど crf 0 は厳密に言うと加虐していじゃないんですね（qpの値によって左右される）
qpのほうがcrfよりも上位の設定なのかな

>>488
PNGでもRGB 8bit（256色）で圧縮しちゃうとRGB 24bit（16,777,216色）には戻せないとかあるじゃないですか
でも8bitのBMPとかTiffには可逆変換できるみたいな、あんな感じなのかなと

>>495
http://up-cat.net/x264%252Dchangelog%252Djp%2Br1700%252Dr1799.html

今回の方式では--qpと--crfの間の相関性を崩してしまい、それぞれ別の体系とすることになったようだ。
つまり10bitサポートでx264をビルドした場合、--qpは0〜63の値を取るが、--crfは-12〜51の値を取るようになる。
--crfはロスレスを除けばこれまでの感覚で使用できるが、そのかわり--crf 0でロスレスを示すことができなくなった。
ロスレスを使用したい場合には、--qp 0で指定する決まりとなった。

>>496
なるほど！ありがとうございます
10bitでもロスレスを除けばcrf値はこれまでと同じ感覚で使えるなら安心しました
バンディングはなくなるわ、色の再現性は上がるわ、SSIMも上がるわ、おまけにサイズは下がるわの
いいことずくめの中で絶対なんか罠があるだろうと訝しんでいたもので

ただし再生環境を選ぶ

人の環境の事なんてどうでもいいだろ

>>497
・エンコ後の画像キャプチャはどうやってる？
・画像キャプチャするときに、デコーダーは何を使っている？
・「RGB24色空間内の色数」を書いてるけど、どうやって数えてる？

>>500
・エンコ後の画像キャプチャはどうやってる？
・画像キャプチャするときに、デコーダーは何を使っている？

->MPC-HC FFDshowを alt+psc でスクリーンショットにしたあとirfanviewにコピペしています
aviutlやavspmodでは綺麗すぎる気がして…もっといいソフトがあったら教えてください

・「RGB24色空間内の色数」を書いてるけど、どうやって数えてる？

irfanviewのinformation機能の自動計算を参照しています

H.264 in AVIみたいやなｗ

>>501
ありがとう。そんな機能があるんだ。参考になりました。

色々試してたら --qp 0 --output-csp i422 で映像崩壊するケースがあったので報告。

　　Source： 以下のPNGファイルをImageReader()で読み込んだyokoshima.avs （Convert系は使わずRGB24のまま）
　　　　　　　　　　　ttp://www1.axfc.net/uploader/Img/so/137174.png
　　ScreenShot： ttp://www1.axfc.net/uploader/Img/so/137175.png
　　使用したx264.exe： x264.nlおよびJEEB氏Buildの r2164 32bit 8bit-depth
　　　　　　　　　　　　　　（32bit 10bit-depthでは問題無し）
　　Encode Option：
　　　　　x264.exe --qp 0 --output-csp i422 -o yokoshima.mp4 yokoshima.avs
　　試したデコーダー：
　　　　　・ffdshow tryouts rev4284、rev4354
　　　　　・MPC-HC 1.6.0.4014の内蔵H.264/AVCデコーダ
　　　　　・LAV Filteres 0.48
　　　　　・ffms-2.17
　　　　　・L-SMASH Works r102（POP氏ビルド）

--qp 1 とした場合は問題ありませんでした。
エンコーダーとデコーダーのどちらの問題なのかよくわかりませんが、
検証して再現するようならどなたかどこかに報告していただけるとありがたいです。

面倒だからそのファイル上げろよ

>>505
確かにでかいもんでもないし、上げるべきだった。ということでうｐ。Trim(0,99)してエンコしてます。
　　ttp://www1.axfc.net/uploader/File/so/76116.mp4

？Profile High 4:4:4になってるけど

>>507
H.264のLosslessは全部High 4:4:4 Predictive Profile (Hi444PP)になるのでは？
ChromaSubsamplingが4:2:2だから4:2:2のLosslessだと思ってるのだけど。

拙者色空間スレに紛れ込んだでござる(´･ω･`)

>>508
あ、ロスレスか 忘れてたわ

LAVのgitの最新commitでビルドした奴とL-SMASH-Works r111で試したけどおかしくなるね

>>420別アニメでの検証
　　　　8bit　　　　　10bit　　　　　byte　　　　　　　　SSIM 8bit　　　10bit
04 430,029,961 391,505,546 -38,524,415 91.041% Y:0.9945384 Y:0.9954224 +0.0008840 106.080449%
05 418,639,157 383,445,401 -35,193,756 91.593% Y:0.9943805 Y:0.9952870 +0.0009065 106.303675%
06 347,492,903 310,470,261 -37,022,642 89.346% Y:0.9950909 Y:0.9958910 +0.0008001 105.301871%
07 404,547,633 375,317,294 -29,230,339 92.775% Y:0.9944575 Y:0.9952649 +0.0008074 105.584645%
08 480,016,974 444,782,661 -35,234,313 92.660% Y:0.9944633 Y:0.9953061 +0.0008428 105.827163%
09 506,312,264 464,412,717 -41,899,547 91.725% Y:0.9939504 Y:0.9949206 +0.0009702 106.954639%
10 507,112,529 468,596,387 -38,516,142 92.405% Y:0.9941975 Y:0.9951210 +0.0009235 106.504666%
11 645,067,295 605,339,201 -39,728,094 93.841% Y:0.9937299 Y:0.9945901 +0.0008602 106.265159% 8.85fps 7.47fps -1.38 -15.593%
12 492,465,184 451,006,430 -41,458,754 91.581% Y:0.9941207 Y:0.9951222 +0.0010015 107.092425%

06 314,574,993 262,548,537 -52,026,456 83.461% Y:0.9953638 Y:0.9960988 +0.0007350 104.783973%
07 305,863,959 252,595,533 -53,268,426 82.584% Y:0.9957001 Y:0.9963294 +0.0006293 104.008255%
08 319,385,891 267,049,657 -52,336,234 83.613% Y:0.9952330 Y:0.9960153 +0.0007823 105.135561%
09 334,856,411 279,985,704 -54,870,707 83.614% Y:0.9953008 Y:0.9960433 +0.0007425 104.852687%
10 316,174,924 260,648,125 -55,526,799 82.438% Y:0.9956858 Y:0.9963554 +0.0006696 104.268829%
11 302,020,128 247,943,009 -54,077,119 82.095% Y:0.9956196 Y:0.9962987 +0.0006791 104.347743%
12 329,271,803 270,798,086 -58,473,717 82.242% Y:0.9956130 Y:0.9962901 +0.0006771 104.336771%
13 339,586,142 289,760,315 -49,825,827 85.327% Y:0.9947741 Y:0.9957299 +0.0009558 106.469430%

SSIMの変動%は =(［10bit SSIM］-0.98)/(［8bit SSIM］-0.98) で計算

>>504
avs4x264mod経由のx64版（たくあん氏build）では8/10bitとも破綻無し
ただcoreAVCで映像出ず

>>504
サンキュー。4:2:2なy4mでも再現するんでとりあえず#x264devへ投げてみた

>>504
libavcodecのバグと認定、JMでは正しくデコードされるらしい。

10bitエンコードが8bitエンコードよりもサイズを小さくできる＋SSIMを上げられるのは
8bitでは(2^8)^3精度でやっていた計算を10bitでは(2^10)^3の精度で行うようになることで
どんぶり勘定でなくなり（「釣りはいらねえよ」な人がお釣りをもらうようになって支出が減った感じ？）
端数切り捨て処理による丸め誤差が減少 -> 計算精度が上がる -> SSIM上昇＆サイズ減少＆RGB24bitの色もすべて再現できるようになってバンディング出なくなったじゃないですかヤッター

って感じなんですかね

遅くなってもいいから内部だけ高精度で8bit出力のものが欲しい

元々内部は16bitじゃないの？

一応こちらにも報告。
ffdshowスレに書いたのですが、現在最新のffdshow tryouts rev4360でも、
--output-csp rgb でエンコしたものがうまくデコードできないようです。
　　ttp://anago.2ch.net/test/read.cgi/software/1315982678/710-

>>510-513
検証と報告ありがとうございました。libavcodecのほうでしたか〜。

検証ラスト　バンディング比較
10bit ttp://www.dotup.org/uploda/www.dotup.org2702613.png 19795 色
*8bit ttp://www.dotup.org/uploda/www.dotup.org2702615.png 17405 色（RGB24空間で2390 色差）

avspmodのFFmpegSource2()で読み込んで
Video -> save image as...でpng保存してもバンディングの違いは確認できますね
ffindexに時間がかかるのがネックですが…

アドバイスありがとうございましたm(__)m
10bitは中途半端な数字なのだと勘違いしてたレベルでしたが、10bitエンコードのすばらしさが認識できた気がします

つ
リサイズするからバンディングでるんだろｗ

それぐらいの違いなら気にならんレベルだな

むしろ縮小するとバンディングは減るよ

ヱヴァのグレインノイズは優秀だよ
8ビットでもpsy-rdも軽い設定で済んで
バンディングはまず出ない
キューテックに爪の垢煎じて飲ませたい

>>492
バンディング提言についてググってたら見つけました
たぶんPSNRのことじゃないでしょうか

x264r1731
ditherとは所謂ディザリングのことで、バンディング低減に効果がある。
8bitのみの時代にも、ディザリングが有効であることは有名だったので、ご存知の方も多いだろう。
内部での10bit処理はそれ自体、丸め誤差などの関係で画質を向上する（PSNRで最大10-15%も…らしい）。
これにディザリングを併用すると、バンディング削減の効果は非常に大きくなるだろう。
ttp://up-cat.net/x264%252Dchangelog%252Djp%2Br1700%252Dr1799.html

マンガでバンディング気になるなら編集用のグリッド線でも出せば桶じゃね？
所詮はマンガなんだからノイズとか気にするなよ

アニメのことを漫画って言う奴は50代以上

同感

うちの親がそうだったわ
漫画ちゃうわ、と毎回心の中で叫んでた

漫画だろ

おまそう

活動漫画だよな

電気紙芝居って言われるよりはマシだな

avspmod のプレビューで rec601 -> rec709 や PC.709 -> rec709 を試したりして思ったんですけど
TVスケールの色空間でエンコードしてるって事は
YUV 8bit のうち Y:16-235 UV:16-240 までの範囲しか使っておらず、(それ以上のYUV範囲はRGB色空間で表示できないから？)
ttp://59.106.182.77/f/2008-09/ycbcr_cube.jpg
その範囲内の色だけをYC伸張して 0-255 のPCスケール（RGB24色空間）に変換して表示しているって事ですよね

8bitエンコードの YUV色空間にはYCｂCrそれぞれで 2^8 = 256 階調あると思っていたのが、
実は 輝度 Y: 256-(16+20) の 220階調、色差 CbCr: 256-(16+15) の 225階調ずつだったんですね

10bit YUVだと
輝度 Y: 256x2^2-(16x2^2+20x2^2) の 1024-（64+80) の 220x2^2 = 880階調 (Y:64-944)
色差 CbCr: 256x2^2-(16x2^2+15x2^2) の 1024-（64+60) の 225x2^2 = 900階調ずつ (UV:64-949)

になるので、YUVからRGBに変換する際にYC伸張を行うことの影響を踏まえると

8bitの Y: 220色 (16-235) -> 256色 (0-255) よりも
10bitの Y: 880色 (64-944) -> 1024色 (0-1023) の方が
細かいスケール尺度でグラデーションが確保できるぶん、バンディングも起こりにくくなるって感じなんでしょうか

>>533
訂正

色差 CbCr: 256x2^2-(16x2^2+15x2^2) の 1024-（64+60) の 225x2^2 = 900階調ずつ (UV:64-964)

それで合ってると思うけど、ffdshowで言うとRGBへの高画質変換（ディザ）を設定
してればYUV→RGB変換程度のバンディングは気にならないんじゃないのかな

あまり正確じゃないただの例えだけど、フォトショップとかで
フルカラーの画像を256色に落としてみれば、バンディングの物凄い極端な例は見れる
あるいはグレースケールの画像を白黒2値化してやるとか
ディザを使えばずっとマシで、元の階調性が認識可能な程度に維持される

グレースケールの画像にグレイン、つまり適当にノイズをばら撒いて単に普通に
白黒2値化するだけではダメなのはわかると思う。白／黒に量子化する際の丸め方が
問題で、ここで元の濃淡の度合いに応じてうまいこと面上に誤差を拡散させてやるのが
ディザ

グラデーションはバンディングがもともと出やすいので、フォトショップとかの
グラデーションツールはデフォルトでディザを使うようになってるよね

>>533
変換誤差の問題でしょ

R = Y + 1.5748 × PrG = Y - 0.1873 × Pb - 0.4681 × Pr
* B = Y + 1.8556 × Pb

R = Y + 1.5748 × Pr
G = Y - 0.1873 × Pb - 0.4681 × Pr
B = Y + 1.8556 × Pb

Y=0 Pb=0 と固定して　Prだけ値を変えてみればわかる

Pr

ありｇｓとうございｍす
エクセルで計算色作ってみたのですが

Y:Pb:Pr = 1:0:2 , Y:Pb:Pr = 0:2.5:1

この比率よりPrの数値を上げるとGの値がマイナスになってしまいました

Y=0 Pb=0のとき
Pr=0 R=0
Pr=1 R=2

YPrPbで(R,G,B) = (1,0,0)　が表現できない

Y=0 Pb=0のとき

・Pr=1
R : 1.5748 -> 四捨五入で2
G : -0.4681 -> マイナスは0とカウント
B : 0

・Pr=2
R : 3.1496
G : -0.9362
B : 0

こういう感じでしょうか

PbとPrを求める式を変形するとこんな感じ

Pb=(B-Y)*0.5389
Pr=(R-Y)*0.6350

「色差」だから B-Y, R-Y とするのが本来だけど
値の範囲が-0.5〜0.5に収まらいないから0.5389倍、0.6350倍に縮小してる

色が減ってる一要因だと思う

>>537
この変換式はフルスケール→フルスケールかな？
実際にはTVスケール→フル(PC)スケールへの伸長もあるので
16引いて256/225掛ける処理がさらに必要なんじゃね

フルスケール→フルスケールなら、少なくともYだけのモノクロ画像なら
階調が完全に保たれることになる（その式でもYの係数が1だ）
TVスケール→PCスケール伸長を考慮すると、係数が1にならないので
Yが16-235の値を取るモノクログラデーションを変換させた場合にも
ところどころ決まったところで色が飛ぶ。
例えば切り捨てで計算すると、7の倍数の色が抜ける。
切り捨てや四捨五入で計算すると抜ける場所が固定だから
グラデーションがはっきり階段状になりバンディングの要因になる

>>541
四捨五入でやると、そういう風に、本来は1.5748のような階調の値が2とかになる
わけだが、ディザを使えば複数のピクセルを使用してその階調を疑似的に表現できる
10ビット使おうがそれは整数である限りかならず丸め誤差は発生するのだから
ディザは使うべきで、
逆に言えばYUV→RGB変換に関してはディザを使っていれば8bitでも
視覚上の重大な問題があるとは俺には思えない
（問題をYUV→RGB変換だけに限った話だが）

なるほど…ありがとうございます

RGB<->YUV 変換式における小数点以下の端数の部分と
TVスケール→フル(PC)スケールの組み合わせで、
8bit YUVのx264だとどうしても表現できないRGB24空間の色が発生してしまうんですね
それを計算で求めたのが ttp://goldenhige.cocolog-nifty.com/blog/2012/01/rgb2416777216yu.html さんのサイトなのかな

>>541
8bitRGBカラーの頃なんかにもよく使われていましたよね
あらかじめ端数になる（バンディングになりやすい）色域を
8bit YUV -> RGB24で階調割れしないように上手く割り振って調整してくれる感じなんでしょうか

過去ログで紹介されていたavisynthプラグインとか
http://2chnull.info/r/avi/1308452706/301-400
http://forum.doom9.org/showthread.php?p=1386559#post1386559

こっちはどうなってるんだろう
http://up-cat.net/x264%252Dchangelog%252Djp%2Br1700%252Dr1799.html
Add a depth filter to dither input to x264.
x264にdither入力するためのdepth filterを追加。

色空間つぶしてここで続けるとか意味がわからん

全員出てけ
テンプレがどうこう言ってた奴はとっととテンプレ作って色空間スレ立てろや

嫌なら自分で立てて誘導すれば？

立てた

マジでウザいから以降色空間関係はこっちでやって


【YUY2 YV12】色空間スレ【RGB24 33】
http://toro.2ch.net/test/read.cgi/avi/1330760227/

移動させるなら上の議論も転載しといて

一過性の話題だろうし、どうせまたすぐ落ちるだろうな

頻繁に変換式が変わるとかならともかく色空間スレ単体であってもそもそも話の種が出てこないと思うんだが。

落ちてもまたその流れになったら立てるよ
スレチだから

それでもアスペクトスレは連綿と続いてる
テンプレループの無間地獄

該当スレが落ちようがどうなろうが、ここでは色空間ネタは間違いなくスレ違いなんだから
スレがなければ自分らで立ててそっちでやってくれや
そして、せっかくスレが立ったのに向こうでの書き込みが未だになんもないのは笑える

めんどくせーからx264総合スレ作ろうぜ、x264がほんのちょっとでも
関係してそうな話題ならなんでもおｋって事で

俺は分かってるんだぜって知識自慢したいだけだから、ギャラリーがいないそのスレには行かないんだろう

自治厨のほうがうぜぇ

どこの板/スレでもそうなんだけど、やたら板/スレ違い厨が沸く
利便性考えて柔軟に対応できない、お役所の老害と基本は同じ

俺はぜんぜん話わからんから、ふーん程度に見てる雑魚だけどなｗ

なら最後までふーんて見てろや雑魚

水道局に住民票もらいに行っても相手されないだろ
利便性とかバカじゃね

さすがにこの流れだとそろそろ誰かキレても不思議じゃないとは思ってたが、またスレ立てたのかよｗ
気が向いたらテンプレ作ってみるか・・・。

やめろバカスレ増やすな放置しろ

おお…
おお…
おお…
おお…
おお…
おお…
おお…
おお…
おお…
おお…
おお…

これを基点とする大喜利の方がよほどスレチだわな

だってコイツらのスレ違の定義って
ぼくがよくわからないものはすれち
だものｗ

もうさすがにあっちでやって欲しい

x264について話すと怒る人がいる理由はよくわからないけど
どうせスレ分けるなら色変換だけじゃなくて
前スレでやってたプリセット晒しとか比較検証上げられるスレがいいな

>>568
あなたがだらだら書いた長文はx264に直接関係ない色空間の話なのに、何故x264について話してると思うんだろうか

>>568
自分はあなた方の書き込みに感謝しているよ。とても勉強になった。

そもそも色空間の話になったの8bitと10bitのエンコの話とつながってるから
それほどスレ違いでもなかっただろ
いきなり色空間の話を始めたのならまだしも

>>569
x26410bitと8bitの違いに付いて語ることがx264と直接関係ない、という理屈がよくわからないです
馬鹿にもわかるように説明していただけませんか

あと、ID:tLr9JTW4さんが参加されている>>526-530の流れは
x264とどのような関係があるとお考えなのか、ぜひ教えていただけないでしょうか

もういいよ
今は別スレがあるんだから色空間の話はそっちでやれよ

阿呆を放置するとこうなる

>>517に書いた件がffdshow rev4363およびrev4365で修正されたようなのですが、
rev4363のchangelogによると、
　　note: x264 doesn't correctly convert YCbCr to RGB. It works only if the input is RGB.
と言われているようです。
実際に、ConvertToYV12()を入れたavsファイルを入力として
　　x264_r2164.exe --qp 0 --output-csp rgb -o YV12-rgb.mp4 YV12.avs
としてエンコードすると、ffdshow rev4365でもLAV Filters 0.48でも、
　　　　R→B
　　　　G→R
　　　　B→G
という色の入れかわり現象が発生するようです。

これは言われているとおりx264のバグになるのでしょうか？
ffdshow tryouts rev4363のchangelogには
　　Implement our own planar RGB to RGB32 conversion. libswscale of Libav is buggy for that part.
という文章もあるのでLibav側の問題だったりするのでしょうか？

サンプルファイルを以下に置いてあります。
　　ttp://www1.axfc.net/uploader/File/so/76192.zip

>>572
君等が話してるYUV色空間の0bitと8bitの違いに付いて語ってることであって
コーデックは他のものでも成り立つんだよ

>>575
お疲れ様です
x64 の x264 8bit r2164 --qp0 --output-csp rgb -- -> ffdshow svn 4225 / 4368 で試してみました
ttp://www.dotup.org/uploda/www.dotup.org2709144.png
ttp://www.dotup.org/uploda/www.dotup.org2709141.png
やはりRGBがずれてしまっているようです

>>577
お前>>544で
＞それを計算で求めたのが ttp://goldenhige.cocolog-nifty.com/blog/2012/01/rgb2416777216yu.html さんのサイトなのかな
とか書いてるけどさあ
お前自身がそのブログの筆者だろ？
いい加減うざい

＼　　 　 　 　 　 ／ 　 　 ／. : : : : : : : :ヽ-‐.: :_;. ---　.._: : : : : : : :＼　　　　　　　＼　　　　　　／
＿　 争　　も　　＿　　 /,　-‐＝=ミ: : : : _,ｨﾆ-‐……ｰ-: ､｀ヽ、: : : : ヽ、　 　 　 ＿　　　争　　 ＿
＿ 　え　　っ　　＿ 　 　 . .:´: : : : : : : ≠:7: : : : : : : : : : : : :ヽ、 ヽ| : i : : :,　　 　 ＿　　　 え　　 ＿
＿ 　 ：　.　と 　 ＿ 　 ／.: : : : -‐: :7´: : /:,ﾊ : : : :ヽ : : : ゝ-- :＼ | : :! : : : ,　　　＿　　　 ：　 　＿
＿　　：　　　 　　＿　/, -‐／.: : : : :ｉ : : /ィ:爪: : :＼ :＼ : : :＼: : :｀ト : !: : : :′ 　 ＿　　　：　 　 ＿
　　　 　　　　　　 　 〃　 /. : : : : : : |.:イ :ハ:|　＼: .､＼: : xｨ¬ト､: :| : : ! : : : : :, 　 　 　 　
／　　　 　 　 　 ＼　　 /.: :/.: : : : /ｌ : |/Гト､　　 　 　 /　|_,ノ0:::ヽ : : :i : : : : :′　／　 　 　 　 ＼
　／　 |　　|　　＼　 　 | .:/.:/. : : :i: i : |　|ノ0:::ﾄ　::::::::::::: 　 |: :∩::::::ﾄ: : : !: : : : : : :,　　／　|　|　＼
　　　　　　　　　　　　　∨ｉ: |: : : : |: :ヽ|　|::∩::|　::::::::::::::::　 !.::∪::::::| |: : :i : : : : : : ′　　　　　　　　　 　 ,ｨ　/〉
　　　　　　　　　　　　　　 |: |: : i : :', : |　 |::∪::|　::::::::::::::::　 !: : : : : :|｜: : i : : : : : : : :,　　　　　　　　　　/ レ厶イ
　　　　　　　　　　　 　 　 ヽﾊ: : :､: :ヽ|　 l : : : |::::: 　,　　::::└――┘ ! : : i : : : : : : : ′　　　　　　　　/　　 ⊂ﾆ､
　　　　　　　　　　　　　　　 い、: :＼/ 　￣￣　　　　 　 　 　 　 　 　 ', : : i : : : : : : : : ,　　　　 _, -‐'　 　 ⊂ニ,´
　　　　r ､　 _　　　　　　　　　　ヽ: :〈　　　　　　　 <　￣ フ 　 　 　 　 |: : : ! : : : : : : : :′,.-‐T　　　_,. -‐'´￣
　 　 くヾ;　U｜　　　　　　　　　　 | : ＼　　　　　　　　 　 　 　 　 　 ／| : : :i : : : : :_, -‐'　 　 |　 ／
　 　ｒ―'　　　ヽ、 　 　 　 　 　 　 | : : : ＼　　　　　　　　 　 　 　 イ: : :| : : :i_,. -‐　　　　　　 |／
　 　 ｀つ　＿　　￣￣Τ`ー―-- L: : : : : ｀: : . . .　 _＿　 　 .:〔: : :|: : :r┬'　 　 　 　 　 　 　 |

>>575
コレどこのカラーパターンだひど過ぎるぞ
ColorBarRGB-qp0-rgb.mp4
赤　166.37.38
緑　75.201.76
青　15.12.142

おお…

きなのっぽの…

ちんぽ･･･

検証にまで噛み付いててワロタ

>>580
使っているデコーダーが古いとそういう風におかしな色になる。ffdshow tryoutsのrev4363より前のやつとか。
それを報告したのが>>517。
あとはL-SMASH Worksのr102（POP氏ビルド）でAviUtlに読み込んだ場合もそんな感じになる。

ソースはColorbars()をベースに自分で色々書き足して作ったPNGファイルで、それも同梱してavsファイルもつけてます。
詳しくは同梱したmemo.txtに書いてあるのでそちらを参照してください。

>>585
ttp://goldenhige.cocolog-nifty.com/blog/2012/01/rgb2416777216yu.html のブログのやつも以前別のスレでそのカラーバー
の動画アップしてた
つまりお前が自演してることは確定的に明らか
うざいから来んな。

このブログのやつかよ

昨日あたりから変なのに絡まれてる人たちかわいそう

バッチに書くファイル名間違ってたし…起きたら半分ほどエンコされてないし…

あるあるｗｗｗｗｗ


あるあ・・・・

色空間スレは立てられてからレスすらついてませんね

バッチで出力ファイルの所変更してなくて同じファイルに上書き
ってのは何度かやってしまったわ
4時間返せみたいな

雑談スレを立てればよかったのにな

言い出しっぺの法則

やつらここにレスしたいだけだから

検証に難癖付けてるのがよくわからない

>>502
上書き防止対策くらい簡単だろ

公式版はいま64bitビルドって使えなかったりする？
clangでx264入りavconvを64bitビルドしてみたらx264でこける
原因はこれだろうか？

http://llvm.org/bugs/show_bug.cgi?id=11859

https://github.com/DarkShikari/x264-devel/commit/bf57981e353b674e8267e2bb5e48a57c2e860c11

要はアセンブラのミスってことだよね？

とりあえずgccでビルドして試せばいいのでは？

ttp://goldenhige.cocolog-nifty.com/blog/2012/01/rgb2416777216yu.html
ここの管理者も猿まねするんじゃなくて
このyuvデータをrgbに変更したら同じ色になりますよって
動画かavisynthスクリプト出すだけでもリンク元とは違った説得力が出せるのにな。

>>575の件、あまり意味のない検証かもしれませんが、Chikuzen氏のavs2pipemod 0.3.0を使ってraw渡しでエンコしてみました。

●RGBソース
　　avs2pipemod -rawvideo=vflip ColorBar640x360-RGB.avs | x264_r2164.exe - --demuxer raw
　　--input-csp bgr --input-depth 8 --input-res 640x360 --fps 1/1 --output-csp rgb --frames 10
　　-o RGB-avs2pipemod-bgrin-rgbout.mp4

　　　　→正常な色で再生される（LAV 0.48、ffdshow 4368）

●YV12ソース
　　avs2pipemod -rawvideo ColorBar640x360-YV12.avs | x264_r2164.exe - --demuxer raw
　　--input-csp i420 --input-depth 8 --input-res 640x360 --fps 1/1 --output-csp rgb --frames 10
　　-o YV12-avs2pipemod-i420in-rgbout.mp4

　　　　→再生すると>>575と同様にRGBが入れ替わってしまう

avsでもrawでもYV12からのエンコード時には
　　　resize [warning]: converting from yuv420p to rgb24
と出ますが、resizeでlibswscaleを利用してyuv420pをrgb24に変換した後、
R・G・Bを正しく並び替えずにエンコードしてしまっているということなんでしょうか？
本来は
　　Y=G、Cb=B、Cr=R
と格納すべきところが
　　Y=R、Cb=G、Cr=B
になってしまっている？

>>601
バグみたいなんで、パッチ書いて出しといた
http://pastebin.com/qPX5mK4y

>>600
スクリプト置いてあるじゃん

>>602
ありがとうございます。原因が特定できたなら何よりです。

>>602
バッチありがとうございます


All 16,777,216 RGB colours ≪ David Naylor: Blog

ttp://davidnaylor.org/blog/2005/02/all-16777216-rgb-colours/

こちらの24bit RGBフルカラー標本をお借りして
ttp://davidnaylor.org/temp/all16777216rgb.png (画像はすべて4096x4096px, 8MB近くあります)

計算もせずにざっくらばんに間引いて>>417のサイトの計算結果に近い 3047425色に（白は8bit x264では表現できない色を想定）
http://www.dotup.org/uploda/www.dotup.org2713768.png
1ブロック256^2 = 65536色につき、8割強にあたる53632色を間引いています

Nearest Neighbor法で 約√3048157 or √304642 -> 1746x1746pxに縮小
ttp://www.dotup.org/uploda/www.dotup.org2713739.png

ざっくらばんワロタ

くっどいなぁ

>>605
もはや何がしたいのかすらさっぱりわからん。
何度も言われてるように、x264と全然関係無いから、これ以上スレ荒らすのやめて色空間スレ行きなよ。
YUVの基礎知識についての話はそっちでやってください。

Strawberry Panic! (DVD 956x720 x264-10bit 422p AAC)
　　　　　　　　　　　　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
誰得

>>605
こんなに違いがあるもんなの？

アスペが住み着いたようだな

まだ色空間やってるのか
基地外もほどほどにしてもらいたい

元は10bit出力の話なんだから普通に範疇だろ
大体それ排除したら他にはおお…しかやる事ないじゃんこのスレ

>>609
あとRGB,444に対応してたら良い変態だった

>>605はこれから書き込む時goldenhigeとかコテ付けてくれ
NGにするから

検証の人は検証スレとか立てるといいんじゃないかな
ネガな荒らしがいちいち絡んでくるこのスレじゃやりにくいだろ

>>615
俺は淡々とoutput-cspのバグ検証報告してただけであって
10bitバンディングや色空間の人とは関係ないんだけど・・・。

>>617
スマンが、バグ検証報告するなら本家に報告してくれないか？
ここでバグ検証報告されても、あんたのオナニーを見せられてるこっちの身にもなってくれ

>>617
>>586の件は？
自演して何が楽しいの？IDって知ってる？動画の説明はどうすんの？

>>619
何を勘違いしてるのかよくわからないけど、
　　ttp://goldenhige.cocolog-nifty.com/blog/2012/01/rgb2416777216yu.html
のブログ書いたのと、output-csp絡みの報告してたのが俺。
10bitバンディングとか、それを広げてYUVの基本の話までしてたのは俺じゃないよ。

>>618
英語できれば本家行った方がいいんだろうけどね・・・。ここだと色々見てくれる人がいるので甘えてしまってるのは確か。

自演認定して騒いでる奴は単にブログ持ってる人間がスレに書き込むことを自演とか言ってるのか

そろそろ

おお…

の出番か

おお・・・

ぶれねり・・・

あなたの・・・

おなまえ…

しゃんぜりぜ

もうx264の話題は別スレ立ててそっちでやればいいんでない？

んんんん

かおがぬれてうんこがでない・・・

>>620
がんばれ

>>628
おいおい、スレタイみてから物申せよｗ

>>632
なに真面目に答えてるの

ふざけるのならvipでやれ。

えっ

ゑっ

集団生活出来なさそう

議論検証を追い出して何やるのかと思ったらこれだもんな

検証に文句付けてた方が荒らしじゃないか

そもそも色空間の話題はスレチなわけで

＼　　 　 　 　 　 ／ 　 　 ／. : : : : : : : :ヽ-‐.: :_;. ---　.._: : : : : : : :＼　　　　　　　＼　　　　　　／
＿　 争　　も　　＿　　 /,　-‐＝=ミ: : : : _,ｨﾆ-‐……ｰ-: ､｀ヽ、: : : : ヽ、　 　 　 ＿　　　争　　 ＿
＿ 　え　　っ　　＿ 　 　 . .:´: : : : : : : ≠:7: : : : : : : : : : : : :ヽ、 ヽ| : i : : :,　　 　 ＿　　　 え　　 ＿
＿ 　 ：　.　と 　 ＿ 　 ／.: : : : -‐: :7´: : /:,ﾊ : : : :ヽ : : : ゝ-- :＼ | : :! : : : ,　　　＿　　　 ：　 　＿
＿　　：　　　 　　＿　/, -‐／.: : : : :ｉ : : /ィ:爪: : :＼ :＼ : : :＼: : :｀ト : !: : : :′ 　 ＿　　　：　 　 ＿
　　　 　　　　　　 　 〃　 /. : : : : : : |.:イ :ハ:|　＼: .､＼: : xｨ¬ト､: :| : : ! : : : : :, 　 　 　 　
／　　　 　 　 　 ＼　　 /.: :/.: : : : /ｌ : |/Гト､　　 　 　 /　|_,ノ0:::ヽ : : :i : : : : :′　／　 　 　 　 ＼
　／　 |　　|　　＼　 　 | .:/.:/. : : :i: i : |　|ノ0:::ﾄ　::::::::::::: 　 |: :∩::::::ﾄ: : : !: : : : : : :,　　／　|　|　＼
　　　　　　　　　　　　　∨ｉ: |: : : : |: :ヽ|　|::∩::|　::::::::::::::::　 !.::∪::::::| |: : :i : : : : : : ′　　　　　　　　　 　 ,ｨ　/〉
　　　　　　　　　　　　　　 |: |: : i : :', : |　 |::∪::|　::::::::::::::::　 !: : : : : :|｜: : i : : : : : : : :,　　　　　　　　　　/ レ厶イ
　　　　　　　　　　　 　 　 ヽﾊ: : :､: :ヽ|　 l : : : |::::: 　,　　::::└――┘ ! : : i : : : : : : : ′　　　　　　　　/　　 ⊂ﾆ､
　　　　　　　　　　　　　　　 い、: :＼/ 　￣￣　　　　 　 　 　 　 　 　 ', : : i : : : : : : : : ,　　　　 _, -‐'　 　 ⊂ニ,´
　　　　r ､　 _　　　　　　　　　　ヽ: :〈　　　　　　　 <　￣ フ 　 　 　 　 |: : : ! : : : : : : : :′,.-‐T　　　_,. -‐'´￣
　 　 くヾ;　U｜　　　　　　　　　　 | : ＼　　　　　　　　 　 　 　 　 　 ／| : : :i : : : : :_, -‐'　 　 |　 ／
　 　ｒ―'　　　ヽ、 　 　 　 　 　 　 | : : : ＼　　　　　　　　 　 　 　 イ: : :| : : :i_,. -‐　　　　　　 |／
　 　 ｀つ　＿　　￣￣Τ`ー―-- L: : : : : ｀: : . . .　 _＿　 　 .:〔: : :|: : :r┬'　 　 　 　 　 　 　 |

べつに10bit出力の話はスレチじゃないだろう

「スレチ！スレチ！」→何の役にも立ってない
色空間厨は少なくとも役には立ってる
どーでもいいが端からみてるとそんな感じだわ

スレチな内容でも役に立てば何の話題でもおｋってことなら
俺が美味しい卵焼きの焼き方でもレクチャーしようか

ここは雑談したい粘着荒らしが常駐してるから
まともな話したいならx264検証スレ・技術スレみたいなスレ立ててそっちでやった方がいいぞ


>>644
x264-10bitの話がx264スレで役に立つのはわかるが
卵焼きとx264には何の関係があるんだ？

x264-10bitの話は存分にどうぞなんだが、そこから話を広げまくってYUVの基本仕様とかの話になるとスレチだろってことでは？

そもそもおまいらのエンコ環境(シェルスクリプトやAVSとかひっくるめて)は
もうとっくの昔に誰に意見される前に完成されているんだろ？
x264のバイナリの話題なんてほんとどうでもいいわ。って奴が８割ぐらいなんじゃね？

アニメでも実写でもソースに合わせて色空間とか10bitとか
その都度変えるような面倒な事をやる人は0.5割程度じゃない？

>>646
上のバンディングの違いに関するYUVの話はあくまでx264出力の範疇だろう
x264と関係ない雑談ならともかく、10bitの話がスレチは難癖にも程がある

x264の話だけがしたいなら専用の別スレ立てればいいのに

個人的な感想を言わせてもらうなら、分岐点は>>533だったと思う。
10bitエンコードとバンディング、ディザあたりの話についてはスレ違いとは思わなかったが
>>533からYUVの基礎の話を始めたので、さすがにそれは他でやるべき話だろうと思った。

>>548が立てるべきだったのは色空間スレではなくおお…スレだったな
こんなにも望まれてるし、きっとそれなりの勢いをキープする人気スレになるよ
真面目に

それだとこのスレでワイルドカードが使いにくくなるからダメ
有用な話題か新リビジョンが出るまでJEEB氏の性癖でも語ろうか

> 好きな東方キャラは藤原妹紅と聖白蓮
つまりババァ好きだ

色関係の話でもx264自体の仕様とかバグの検証ならここでやるべきだろうけど、
そこから逸脱して一般論や基本を延々やられちゃたまらんよ

まぁ、飛躍しすぎてaviutil向けのx264guiExについて語られるよりはマシだが

本体の更新が無いから悪いんや…

>>656がボヤいたおかげでは無いだろうが、更新が来たね。

2183か

x264.nlから落とせるバイナリ、1.6KBしかないんだが。
いつもはもっとでかいよな？

>>659
まぁ、中身これだからな
<title>Sudden server failure, mikoto serving now - fushizenなDTVエンコーダー</title>

diffとかじゃない？

http://www.mediafire.com/file/nu82du58ntrz83d/x264-r2183-Windows.7z

お、バージョン情報付くようになったのか

バージョン情報ってプロパティの詳細タブのやつ？
それなら2164から表示されてるよ

あれ、どうなってるの2183って

>>665
・うちのhttpサーバー設定のミス（デフォで有効になってる一行が（ｒｙ）
・jarod氏のx264.nlのスクリプトは全く何をもらったかを確認しない

新しいrevが出る→x264.nlで動いてるスクリプトがファイルを探しにいく→nginx
はうちのうっかりミスで404じゃなくて/index.htmlを出す→スクリプトはそいつを
よろこんで受け取る→md5ファイルもあるはずなのに一致してるかチェック
しない→index.htmlがそのまんまexe/md5になってる。

OTL

>>662は？

あの1.6KBしかないやつってどう使うの？
デカいファイルじゃないんだし何でx264.exeそのものを置かないだろ

現物を見てないから知らないけど
ビルドしてパッケージ化するほどの更新じゃないってことじゃないのか？

猫科はよ

ほい
ttp://mailman.videolan.org/pipermail/x264-devel/2012-March/009219.html

jarod氏がx264.nlの方を直すまで
ttp://x264.fushizen.eu/files/revision2183/ でおｋ

みんな詳しいなぁ
どっからこういうリンク引っ張ってくるの？
ありがたやです

L-SMASH版のrev2183のバイナリを置いてあるところある？

L-SMASH（）

俺もBDにはL-SMASH使ってる

適当にエンコしただけだが10％近く速くなってないか今回
この数ヶ月で高速化しすぎて怖いぐらいだ

nl早く直して

>>678
>>672

アニメ１本、8bitで約８分。目標は１分だから高速化は嬉しいぜ！

どうせほとんどフィルタとかいれてないんだろ？

どれぐらい速くなったかベンチスレで回してみたけど速くなってなかったわ｡
ベンチスレの設定は--me umh --subme 10だから適当に回したときに使ってた--me tesaか--subme 11が最適化したんかのう｡

そういや>>1のテンプレにエンコベンチスレのリンクがないんだな
【x264+Avisynth】実用エンコベンチ Part2
http://anago.2ch.net/test/read.cgi/jisaku/1321723244/

nlなおったね　ちゃんと10MBのファイルに置き換わった

r2164 → r2183 でえらい結果が違うなぁ
スピードは似たような物だが、サイズはより小さくなってる(Bフレームが増えてる)
2-3%程度減少でAve QPも数字上良い方向になってるが、減少ビットレート相応のぼけた感がする
同サイズまで盛ってどっちがいいのかまた見比べる作業か

気のせいと違い真っ赤

俺は速度は早くなったがssimとpsnrが若干落ちた感じがするな。ビットレートはそのまま
猫科かエロい人早く来て

猫科翻訳と解説頼むよ

>>685
そんなに違うの？

うちは速度が速くなって、サイズは小さくなったけど、
ssimは若干落ちて、見た目も若干落ちた気がする。

「気がする」「感じがする」とかそんなんばかりだな

第二の僕まかスレ

特定設定でのFix入る可能性が有るなら様子見かね人柱乙

プラシーボ効果

ちんちん効果

>>691
じゃあ正確にいうと--me tesa --subme 11を使用した場合速度が7%早くなりssimが0.005db程度psnrのu成分が0.007v成分が0.002程度落ちた
見比べて無いので見た目は知らん

687だった

ttp://logsoku.com/thread/toro.2ch.net/avi/1322304761/#835
1867→2146でも0.005程度落ちてるんだな

というか1867からcrfの基準がフレーム単位から一秒単位をfpsで割るようになっていたことを初めて知った
25fpsよりも多くフレームレートを取る場合はcrfを上げないと画質が低下するんだな
ttp://www.up-cat.net/x264%252Dchangelog%252Djp%2Br1800%252Dr1899.html
ttp://rigaya34589.blog135.fc2.com/blog-entry-78.html

>>698
これ最初のレスは俺だよ。rev2164でtrellisの最適化(だったと思う)で容量についてはrev2085→2146で改悪してた分の倍ぐらい改善したはず
改善点も情報ソースもうる覚えだがrev2146→2164で同ビットレートでの映像品質について数値上は上がりrev2164→2183で下がったのは確かだ

preset slow

■r1867 8bit
SSIM Mean Y:0.9844440 (18.081db)
PSNR Mean Y:44.411 U:48.786 V:48.258 Avg:45.328 Global:43.638 kb/s:1449.16
16.92 fps, 1449.16 kb/s

■r2164 8bit
SSIM Mean Y:0.9845078 (18.099db)
PSNR Mean Y:44.430 U:48.813 V:48.281 Avg:45.347 Global:43.658 kb/s:1456.36
17.51 fps, 1456.36 kb/s

■r2164 10bit
SSIM Mean Y:0.9859875 (18.535db)
PSNR Mean Y:44.667 U:49.150 V:48.618 Avg:45.598 Global:43.879 kb/s:1420.62
12.35 fps, 1420.62 kb/s

■r2183 10bit
SSIM Mean Y:0.9860168 (18.544db)
PSNR Mean Y:44.666 U:49.156 V:48.623 Avg:45.598 Global:43.887 kb/s:1418.21
12.14 fps, 1418.21 kb/s

preset veryslow

■r1867 8bit
SSIM Mean Y:0.9837194 (17.883db)
PSNR Mean Y:44.130 U:48.540 V:48.001 Avg:45.053 Global:43.345 kb/s:1313.00
5.07 fps, 1313.00 kb/s

■r2164 8bit
SSIM Mean Y:0.9838496 (17.918db)
PSNR Mean Y:44.175 U:48.566 V:48.035 Avg:45.095 Global:43.387 kb/s:1321.85
5.41 fps, 1321.85 kb/s

■r2164 10bit
SSIM Mean Y:0.9850555 (18.255db)
PSNR Mean Y:44.318 U:48.762 V:48.242 Avg:45.247 Global:43.504 kb/s:1296.36
3.17 fps, 1296.36 kb/s

■r2183 10bit
SSIM Mean Y:0.9851071 (18.270db)
PSNR Mean Y:44.325 U:48.769 V:48.263 Avg:45.257 Global:43.522 kb/s:1295.06
3.21 fps, 1295.06 kb/s

その結果はソースの映像がわからないんじゃ判断に困る。

>>700-701はガンダム00ブルーレイのop2で↓はED4

■r2164 10bit
SSIM Mean Y:0.9877558 (19.121db)
PSNR Mean Y:45.198 U:47.455 V:46.686 Avg:45.641 Global:43.759 kb/s:737.20
16.72 fps, 737.20 kb/s

■r2183 10bit
SSIM Mean Y:0.9878564 (19.157db)
PSNR Mean Y:45.251 U:47.514 V:46.739 Avg:45.694 Global:43.807 kb/s:737.80
16.98 fps, 737.80 kb/s

アニメソースで19dbってちょっと低すぎない？せめて22dbぐらいはでてほしいが

>>704
ビットレみろ22dbなんて出る訳ないだろｗ

22dbっていってもせいぜい0.994ぐらいだろ。
アニメソースならパラメータをケチらなけりゃ余裕で出るだろう。

俺の場合アニメソースでも20〜21db位なんだけど・・・

r2183のほうがSSIM Y:0.0000300〜Y:0.0000600位上昇
速度も0.10〜0.20fpsくらい上がる感じ

しかしたくあん氏かKMOD氏がbuildしてくださらないと--logfileオプションが指定できなくて詰んでしまう

誰だよKMOD氏って

　＼　　　　　　　　　　　　　　　　　　　　/
　　 ＼　　丶　　　　 　 i.　　 |　　　　　 /　　 　 ./　　　　 　 ／
　　　　＼　　ヽ　　　　　i. 　 .|　　　　　/　　　 /　　　　　 ／
　　　　　 ＼　　ヽ　　　　i　　|　　　　 /　　　/　　　　　／
　　　＼
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　-‐
　　ー
　_＿　　　　　　　　　　わ　た　し　で　す　　　　　　　　　　　　--
　　　　　二　　　　　　　 　　／￣＼　　　　　　　　　　　＝　二
　　￣　　　　　　　　　　　　|　＾o＾　|　　　　　　　　　　　　　　　　￣
　　　　-‐　　　　　　　　　　 ＼＿／ 　　　　　　　　　　　　　　　‐-

　　　　／
　　　　　　　　　　　　/　　　　　　　　　　　　　　　ヽ　　　　　 ＼
　　　　／　　　　　　　　　　　　　　　　　　　　丶　　　　 ＼
　　 ／　　　/　　　 /　　　　　　|　　　i,　　　 　 丶　　　　　＼
　／　　　 /　　　　/　　　　　　 |　　　 i,　　　　　　丶　　　　　＼　　

>>708
自ビルド覚えようぜ

>>708
パッチに頼らんでもリダイレクトしてログをファイルに出力すればいいじゃなイカ

2183来てるじゃん教えてくれよもう

>>713
メーリングリストに登録しろよ、ボケ。自動的にコミットが来れば教えてくれるぞ
ttp://mailman.videolan.org/listinfo/x264-devel

またはツイッターを使ってる場合コミットする本人をフォローしろ
ttps://twitter.com/darkshikari

>>711
x264_L-SMASHのビルド
http://mobilersencoder.info/p/x264build3.html
Ch's barn: x264_L-SMASHのビルド
http://csbarn.blogspot.com/2010/09/x264l-sm
Compiling x264 on 32 & 64 Bit Windows - Guide.
http://doom10.org/index.php?topic=26.0
x264 を Windows 上でビルドする - ..たれろぐ..
http://d.hatena.ne.jp/naga_sawa/20100422/1271910683

この辺読んでるけど全然わからんわ…

それでわからないなら諦めろ

ivy bridgeでenhanced avxってのが新しく備わるみたいだけど
x264の高速化に役立つもんなのかねぇ

そんなもんよりHaswellで実装予定の整数演算が強化されたAVX2のがよっぽど期待できるだろ

$ wget "http://up-cat.net/wiki.cgi?action=ATTACH&page=L-SMASH&file=x264_L-SMASH_clone.sh" -O x264_L-SMASH_clone.sh

msys.batでこれが通らないのはブラウザからDLしてくれば何とかなるとして

$ ./configure --prefix=/mingw/x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --cross-prefix=x86_64-w64-mingw32- --enable-win32thread --enable-strip --bit-depth=10

これがNo working C compiler foundで通らないのが難しい

拡張命令のコード名と別名をごっちゃにするとな？

>>719
msys.batは単にbashを起動するためのものだけど、それとwgetでdlすることにどういう関係があるんだ？

てか10bitって決め打ちかよ。ビルド後にパラメータで切り替えるような作りにすればいいのに

え

> $ ./configure --prefix=/mingw/x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --cross-prefix=x86_64-w64-mingw32- --enable-win32thread --enable-strip --bit-depth=10

これの --bit-depth=10 についてのレスな。

え

ガチガチに最適化してるからビット数を変数にするのは無理で、ビット数に応じたバイナリを持つ必要がある。
8ビットも10ビットも両方のコードをバイナリに含めることも可能だけど、バイナリサイズがでかくなるし、
それって結局別の実行ファイルにしても同じじゃね、ということでこういう風になっているんだと思う。

>>719
gitにパスが通ってないとか？

まず単純に./configureだけから始めろよ
いきなりゴテゴテオプションつけるな

でもmakeできる環境を用意するのが何よりも先だよな。
一番新しいcygwinにutf8対応パッチをあててしまえばあとは何なりとできるが

>>729
utf8対応パッチてなに？

バッチエンコと同じで一度環境さえ作れちゃえば楽なんだけどねえ

>>730
cygwinをインストール後に日本語の文字化けを治すためのパッチ。
昔からいろいろあるけど、なかなか改善されないんだよ。

うまくやればcygwinのbashとか起動しなくてtも
windowsのコマンドプロンプトなどから同様の操作ができて色々捗る

cygwin1.7はUTF-8対応なのに？
何年前の話なの、それ

俺もも1.7使ってるけど治ってないよ。

なにもしないままだと
bash上からはlsを発行すると日本語で表示されるが
コマンドプロンプトからlsを発行すると文字化けする。

これ以上はスレチなので対処法はcygwinの専スレで漁ってくれ

>>735
なんか腐ってんじゃねえの
うちでは何のもんだいもないぞ
日本語どころかウムラウトとか入っててもちゃんと表示される

Cygwin使っている人いますか?その20
http://toro.2ch.net/test/read.cgi/unix/1268282846/

x264の話題がいつのまにか・・・毎度のことだがそんなにx264の話題が嫌なのか？

x264の話題っつったって、値が下がっただの画質が下がった気がするだのの話くらいしかないんじゃ

そりゃx264がハードウェアアクセレレーションとかされたら喰いつくよ

不具合多そうだからそういうのいらない

x264+AVXorSSE4.2+GPUフィルタの組み合わせが一番安定する。

じゃあ話題提供してやろう
実はOpenCL対応が進行中だ
どっかの会社の人がやってる
一部の処理をGPUでやるもので、当然CPUも使う
もう既にGPU使った方が速かったりするケースもあるようだ
今までGPGPU計画は色々あったようだが今度こそ本当に有用なものになるんじゃないか
素人が横から見てて勝手に言ってるだけだから責任は持てないが
まだweightp使えなかったりするしいつ完成か知らないけど
ソースコードの一部がカレントディレクトリに必要という面倒くさい仕様だけどこれはどうにかなるのだろうか…

ソースが明示されてたとしてもフーンという程度の話なのに、ソースも書かずにそんな駄文書かれても
反応に困るっていうか、くだらない流れしか見えない。

kMod版 r2183 やっと来たねー

kazu居たｗ

あ、誤爆したすまん。 orz

ｋMod氏のビルドは8bitオンリーだった

>>689
静止画じゃないとはっきりとわからないと思うほどだけど
「動きの激しい」「複雑な場所」を上手く削ってるっぽいので動画としては正常進化だった
趣味でビットレートケチってるからたまたま気がつけたのかもしれないほど気のせいレベル

画像音声圧縮は如何に人間を騙すか、だからな

たくあん氏は2183スルーするみたいだな

たくあん氏はここの住民？

たくあん氏のツイート
　　https://twitter.com/K4095/status/178526403925516288
　　x264のr2183で99.8%くらいにクラッシュするのはこれ
　　　　ttps://github.com/silverfilain/x264_L-SMASH/commit/c522ad1fed167d0e985e4f9dcdee042473cf74db
　　が原因みたい．pthreads使えば問題ない．これをリバートすればwin32threadsでも問題ない．

よくわからないけどx264.nlのバイナリを使う分には問題ないのかな？

> 99.8%くらいにクラッシュ

いわゆる寸止めプレイという奴か

スレッド割り当ての方式が変わったせいかな
これはx264本体の更新だった気がする

x264_L-SMASHのレポあげたのはたまたま見ていたのがそこであっただけでx264側の問題です。
pthreads使ってるkomisar氏のビルドであれば問題ないです。

>>757
んで、バグ報告はしたの？
きちんとバグレポしとけば数分〜数時間で直るけど、しなけりゃ直らんぞ

開発チャンネルで聞いてみたけど、そういう関連の報告は一個も上がってない様子

誰か簡単に再現できるためのパックでも作ってくれ。
そうすれば報告するだけでも簡単になる。

taro氏もクラッシュするから公開中止してる

そして聞いてみたらBugMaster氏ｷﾀｰ
<BugMaster|work> Dark_Shikari / JEEB : http://privatepaste.com/820509a02a . Dunno why it crashed only on 64-bit and with win32threads because bug was everywhere

猫研更新されたぞ

翻訳する機械久々だな

猫科様、今後も何卒素早い翻訳と解説をお願い申し上げます

r2183でバグあるのx64だけ？x86でも使わない方が良いの？

全部バグがある
ただエンコ終了後の処理なのでクラッシュさえしなければエンコしたデータは大丈夫
多分ね

クラッシュ条件はどうなってるのか？
俺はクラッシュしなかったけどな

録画鯖に組み込んでかれこれ20本ほどエンコしてるが
今のところ問題なさそう

>>761　では、win32threads付きでx64上で（実行？ビルド？）した場合しか発現しないのが謎
とのことだが、さて？

r2184

ほう

r2183.64bit 10bit-depthはクラッシュしなかったけど出力映像に問題があった
これはr2184で解決した

＞出力映像に問題があった

マジで！？

nlの使ったけど64bit 10bit-depthはプログレ出力なのにインタレ風になった
32bit 10bit-depthはr2183でも問題なかったよ

インタレ風ってイミフ

>>774
参考画像上げてもらえませんか
r2184の更新履歴だと↓だと書いてあったんでx264のエンコードそのものが破綻するバグでは無かったと思っていたのですが

Only affected sliced threads during encoding , but could cause crashes on x264 encoder close even without sliced threads .

英検4級の俺の翻訳だとsliced threadsのオプションを指定した場合x264がクラッシュしてたから直しただと思う

まあその内猫研が翻訳するのが半公式日本語訳ということで

>>776
再現エンコードしたけど正常でした
一過性の症状だったみたいお騒がせしました

2133メモリが原因なのかも知れない…

x264だと、DDR3 2133 CL9とDDR3 1067 CL7で、4%も違わない。

http://www.xbitlabs.com/articles/memory/display/sandy-bridge-ddr3_6.html

４％の差は大きいだろう。

2chCPUでこの差なら4chCPUならさらに倍変わるかもしれんね

>>782
http://www.xbitlabs.com/articles/memory/display/lga2011-ddr3_6.html

ウオーズマン理論

あれ…fushizenのr2184で99.8％で止まってしまった
13ファイルくらいは全然問題なかったのに
（avs4x264mod.exe経由、x64 10bit）

なに
まだなにかあるの

fushizenのr2184って、>>672にあるようなfilesの下のやつのこと？
x264.nlに置かれてるのもこれと同じっていうかこれが元なんだよね？

http://x264.fushizen.eu/files/revision2184/64bit/10bit_depth/
ここからDLした

99.8％でクラッシュしても音声と結合させたら普通に再生できたし
あれから4ファイルくらいエンコしてるけど今のところクラッシュは出てない

>>788
うーん、
　　・ダウンロードのミス（r2184のつもりが実はr2183使ってる）
　　・ビルドミス or アップロードミス
　　・バグ修正ミス
　　・全然別のバグ
のどれなのかわからんけど、とりあえずx264 --versionでバージョン確認して、
間違いなくr2184なのであれば渡したコマンドとか書いておけば修正時の手がかりになるかもね。

すいません、確認したら99.8％でクラッシュしたファイルは（windows更新で）再起動した時にramdiskから消えてました

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Windows\System32>C:\x264bat\x264.exe --version
x264 0.122.2184 5c85e0a
(libswscale 2.1.0)
(libavformat 54.2.0)
(ffmpegsource 2.17.1.1)
built on Mar 12 2012, gcc: 4.6.3
configuration: --bit-depth=10 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 3 or later

--preset slow --crf 20 --ref 9 --bframes 3 --b-adapt 2 --b-pyramid normal --qcomp 0.7
--no-deblock --subme 7 --merange 24 --mixed-refs --weightb --colormatrix bt709 --colorprim bt709 --transfer bt709
--bluray-compat --ssim --psnr --vbv-maxrate 25000 --vbv-bufsize 31250

--vbv-bufsizeが異常な数値なんだが・・・

Auto VBV settingsのパッチだと自動でこの値設定されてたなそういえば。
それを参考にしてるんじゃない？

fushizenビルドだとAuto_highが使えないので直接指定です

>>785の同じファイルでもう一度うんこし直したらエラーでませんでした
何が原因だったんだろう

ウンコー

>>791がなぜ--vbv-bufsizeが異常な数値だと思ったのかの方が気になる

チンコー

HighLevel4の上限値じゃないの？

xvp8

スローワーでもFHDでの圧縮時に100%に張り付いて怖いんだけど
毎秒5フレームぐらいの超低速でいいから低発熱長時間エンコするオプションや裏技的な方法ないですか？

電源の管理で最大CPUを10％にすれば

OCツールでクロック数落とすとか

>>799
だったら--threads の値をコア数の半分にすれば？

>>799
上に張り付くのが怖いとかどんなマシンなんだよ
安心したいならCPUのクロック数とHzを落とせ
上に張り付いても発熱と故障係数は下がるかと

優先度がうんたらかんたら

>>799
Battle Encoder Shiraseを使う

発熱が気に成るならCPUのブースト設定切って>802か
タクスマネージャー成りで使用コア指定するなりで良いんじゃね？
100%に張り付くのが嫌なら単スレッド処理のデコーターなり
フィルターなり使えばそれなりになるだろうし。

つーかCPUとクーラーはなに使ってるんだよ

presetオプションを勘違いしている悪寒

>>785の症状が本日新たに2回発生

ふーん

>>805
懐かしい…昔使ってた

>>809だけの問題なの
ソースをエンコ後即消し原理主義者としては怖いんだけど

エンコが最後まで通ればできあがった物には問題がないっぽいし気にしなくていいだろ

>>812
エラーが発生したファイルはどちらも2フレーム欠けてました
最後の黒い部分だったから気にしなかったけどソーアスは残しておくか2164でエンコする方がいいかも

ノートPCとかだと発熱は気になるな
シングルコア時代は俺も >>805 使ってたよ
今はさすがにスレッド数調整すれば足りる
後でアフィニティ変更することもできるしね

ここに載っているヒートシンクのどれかを付けておけば、夏場でも温度は大丈夫だろう。

http://www.xbitlabs.com/articles/coolers/display/super-cooler-lga-2011_6.html

PH-TC14は日本で買えないぞ、米アマでポチれるけど
そこのサイト他でまったく冷えないってでてるCNPS12が
滅茶苦茶冷えてるな。

OCなら本格水冷が無難だろ

水冷をわざわざ本格水冷と呼ぶのはマジ基地

元祖水冷

俺の液冷

ちんちん水冷

H100ですが水冷名乗っていいすか

質問したものです。たくさんのレスありがとうございました
次回圧縮時にスレッド2指定を試して見ます

ところで4コアを50%まで利用と
4コアのうち2コアを100%まで利用だとどちらが優れているというかメリット多いのでしょうか？
先輩の方の考えを知りたいです

4コアを100%ですね。圧倒的にそうです、間違い有りません。

>>824
CPU使用率を制限する系のアプリだと適度に休止命令を実行してるはずなので、
タスクスイッチとか休止復帰のオーバーヘッドがある。
そのうえスレッドを増やしてもリニアに性能が上がるわけではない、
ということを考えると少ないスレッドで2コアをフルに利用したほうが速いと思われる。

冷却に難ありなら50％が無難だろ

>>824
マジレスしておくとだな。x264稼働時のスレッド数をどんな個数にしても
エンコード処理終了後のデータ量・圧縮率・画質などに差異は無いことだけは理解しておきな。
つまりスレッド数の調整はエンコードにかかる所要時間を短縮できるかできないかの差しかない。

もともとの話は発熱が怖いから低速低発熱でエンコしたいっつうことだったと思うが・・・。
２コアフルに使ってもそれなりに発熱するような気がするけどどうなんだ。
４コア５０％ってのはどうやって実現するのかよくわからんが。

>>828
スレッド数を増やしたらファイルサイズも若干大きくならない？
数百キロバイトだから誤差の範囲だけど……。

>>828 >>830
http://toro.2ch.net/test/read.cgi/avi/1314616372/473-477

引用されてる記事はちょっと古いから今とは少し違うとこもあるでしょうけど、
スレッド増やすと圧縮率が低下するのは今でも同じなんですっけ？

うむ、スレッド数を増やすとでかくなる

微々たるもんだし速さを取るわ俺

r2184は速度も品質も良くなってるみたいだけど
なぜかキケンな香りがするんだよな

>>834
グレイン殺しに拍車がかかってるのは確認した、まどかEDとかもんやり感がパない

流れぶった切りで恐縮ですが質問させてください。

10bit-depthのx264に、RGBなavsを渡して
　　x264_r2184_10bit.exe --qp 0 -o rgbTo420-10bit.mp4 rgb.avs
とエンコしてみたのですが、
　　resize [warning]: converting from bgr24 to yuv420p
と出て、前段階で「8bitのYUV420」に変換されたうえでエンコードされるようです。
そのため、8bit-depthと同等のわずかな色の変化が発生しています。
RGB24を直接YUV420P16などに変換すれば10bit-depthのメリットを生かせると思うのですが、
この動作は仕様となるのでしょうか？
（そこまで気にするなら8bit-depthでrgbエンコしたりすればいいのはわかるのですがちょっと気になったので・・・）

また、RGBソースをうまいこと10bit以上のYUVにしてx264に渡す方法はあるでしょうか？
AviUtlでx264guiExを使えばいけますが、コマンドラインやAVS側で対処できる方法があれば教えていただければ幸いです。

追記：
　flash3kyuu_debandを使えばいけるだろうかと思ったのですが、RGBはサポートしていないようでした。orz

まどかEDみたいな砂嵐のグレイン殺しはどんどんやってほしい
一気にビットレート上がるし

ConvertToYV24()からのf3kdbもしくはdither

>>839
それだとConvertToYV24()の時点で8bitYUVに落とされてしまってしょんぼりんぬなのです。

え

>>841
ちょっと前に色空間絡みで荒れてたのであまり言及したくないのですが、Avisynth 2.6で
　　ColorBars(640,360,"RGB32").Trim(0,9)
　　ConvertToYV24()
　　ConvertToRGB()
とやってみると、中央のRGB（16,180,16）がRGB(16,179,15)になってるのをはじめとして、
微妙に色が変わっているのがわかると思います。
これはConvertToYV24()の時点で8bitYUVになって情報が欠落し、元のRGB24の色を保持することができなくなるため。
ConvertToYV24()の後にf3kdb()を使っても、RGB(16,179,15)相当を元データだと考えてしまうので、
もとのRGB（16,180,16）に戻すことはできないということです。

>>836に書いたように、10bt-depthのx264にRGB24のavsを渡したときも、
事前にConvertToYV24()相当の処理がされてしまいます。
これを防ぐにはRGB24から直接10bit以上のYUVにする必要があるのですが、何か良い方法はないかなと。

Dither_convert_rgb_to_yuv(output="YV24, "lsb=true, mode=＊＊)
f3kdb(output_depth=16, output_mode=2, input_mode=1)

とかで 8bitRGB→16bitYUVにダイレクト変換してx264に渡せそうだが，
途中ディザリングで微妙にずれるような気もする。

誤字訂正

Dither_convert_rgb_to_yuv(output="YV24", lsb=true, mode=＊＊)
f3kdb(output_depth=16, output_mode=2, input_mode=1)

modeはどれが適切なのかは要検証。

>>842
x264_10bit input.avs --vf resize:csp=i420:16 -o output
長々書く前にfullhelp読め
いい加減にしろ

>>835
またAQあたりの設定で試行錯誤したいとなのか

>>843-844
ありがとうございます。調べてみようと思います。

>>845
ありがとうございます。fullhelpをちゃんと見てなかったのはこちらの不手際でした。すみませんでした。
教えていただいたとおり、x264 r2184 32bit 10bit-depth (x264.nl)を使って
　　x264_r2184_10bit.exe rgb24.avs --qp 0 --vf resize:csp=i420:16 --output-csp i420 -o test.mp4
としてみたところ、たしかに狙い通り
　　resize [warning]: converting from bgr24 to yuv420p16le
となり、直接16bitYUVに変換されているのですが、出来上がったMP4を再生してみると、
>>842と同じように色が微妙に変わってしまっていました。再生はMPC-HCでffdshow tryouts rev4371を使っており、
余計な処理をしないように、「RGB変換」で「YV12からRGBへの高画質変換」をオフにしています。

fittoboxをフィットボックスと読んでしまうほど寝ぼけているので何か間違ってるかもしれませんが、とりあえずご報告まで。
ここまでくると続きは色空間スレでやったほうがいいんだろか。

Dither_convert_rgb_to_yuv(output="YV24, "lsb=true, mode=0, matrix="709", tv_range=true)

こうやってデフォルトではundefinedになっているmatrixも指定しないと、正しい色にはならないと思う。

>>847
>続きは色空間スレでやったほうがいいんだろか。
Doom9

色の空間で思ったんだけど
同様に味を各成分に表し圧縮できないだろうか？

展開時は？

つ 【カルピス】

8bit出力の場合って、f3kdb使って16bit入力する恩恵はあるのかな？

678 ：名無しさん＠編集中：2012/03/16(金) 22:32:47.63 ID:BfHFguQP
最近、H264のコンテナに対する整合性がどんどんMP4よりになってきてるような・・・
同じH264でMP4はおｋでもmkvだと深刻な問題がでる事あるな
上の方でハマってる人が居るな

と、暇なので愚痴ってみたｗ



どういうことだってばよ?

なぜ元スレのアドレスを書かないのか

元からmkvなんてごった煮の闇鍋だろうに

もともとmp4はMPEG4ストリーム用なんだから、MPEG4 AVCと整合性?とやらがなければだめだろ
mkvなんていう野良規格と同列に語ってはいかん

>>854の元アドレスはこれ
【初心者歓迎・ダウソNG】総合質問スレッド-78-
http://toro.2ch.net/test/read.cgi/avi/1317166834/678

【レス抽出】
対象スレ：【初心者歓迎・ダウソNG】総合質問スレッド-78-
ID:BfHFguQP


673 名前：名無しさん＠編集中[sage] 投稿日：2012/03/16(金) 21:05:52.45 ID:BfHFguQP [1/3]
単品エンコーダやmuxerをかき集めてx264guiEx.iniを弄って・・
面倒だから詰合わせをやろう。　

つ　ttp://もってけｗ

676 名前：名無しさん＠編集中[sage] 投稿日：2012/03/16(金) 21:22:49.37 ID:BfHFguQP [2/3]
ビデオ圧縮のボタンを押して見ろと

てか、そうゆうレベルの話かいｗ

678 名前：名無しさん＠編集中[sage] 投稿日：2012/03/16(金) 22:32:47.63 ID:BfHFguQP [3/3]
最近、H264のコンテナに対する整合性がどんどんMP4よりになってきてるような・・・
同じH264でMP4はおｋでもmkvだと深刻な問題がでる事あるな
上の方でハマってる人が居るな

と、暇なので愚痴ってみたｗ

>>859
?

ちょっと実験で　1pass　--crf 22　5分の実写ソースでファイルサイズがどう変化するか試してるんだけど

--me umh --subme 5　でエンコすると　77.9MB
--me umh --subme 7　でエンコすると　86.7MB
--me umh --subme 8　でエンコすると　86.9MB
--me umh --subme 10　でエンコすると　80.9MB
--me umh --subme 11　でエンコすると　80.9MB

submeの数値を上げると検索範囲が広くなって、エンコが遅くなる代わりに
ファイルサイズを小さく出来る可能性が上がると思ってたんだけど、
なんか違うのね？
画質はぱっと見た感じ違いが分からんかった。

--no-psy

>861
x264はどのリビジョンを使っている？

>>861
subme>=10では
　　trellis=2　（デフォルトは１なので変えないと駄目）
　　aq-mode>0　（デフォルトは１なので普通は問題ない）
という条件が必要。
これを満たしてないとsubme=9相当になるはず。MediaInfoで見てもそうなるはず。
とりあえず全部--trellis 2をつけて比較してみたほうがいいのでは。

あと、よくわからんけどsubmeって検索範囲とは関係ないんじゃないの？

>>861
インタレ、プログレで結果が違うのだけどどちらでの話だい

ごめん、出かけてた。
>>862
あー　調べてたら5以下で挙動が変わるんですね。

>>363
x264 --versionで表示したら　x264 0.122.2183 c522ad1　と出ました。

>>864,865
設定ちゃんと書いてなくてごめんなさい。
AVIUTLの拡張x264出力のプリセットに入ってた「アニメ高画質」ってのを少し弄ってコマンドラインにコピペして試しました。
--tune animation --crf 22 --ipratio 1.5 --qpstep 12 --qcomp 0.75 --no-mbtree --rc-lookahead 60 --psy-rd 1:0.2 --min-keyint 4 --bframes 5 --b-adapt 2 --deblock 0:0 --me umh --subme 10 --direct auto --ref 5 --no-fast-pskip --no-dct-decimate --trellis 2
ソースはアニメじゃなくてCM付き5分程度の情報番組を29.97fpsでインタレ解除してます。

そこそこ高画質で速い設定を自分なりに探ろうと思って試してたんだよね。
同等の画質でファイルサイズの差が5%以下なら早いほうがいいかなと。
（PCがしょぼいので、その5%を縮めるためにエンコ時間が3倍4倍かかるときついから）

色々酷い設定だな

あらｗ

--no-mbtreeはやめとけ directはどうせspatialになるから指定しなくていい trellis 2にするなら submeは11 しないなら9でいい

crf22ならmbtreeつけたほうがいいと思う
20だと悩む
20未満だとつけないほうがいい
mbtreeでcrf16とかいうのはなんだかなと思う

＞情報番組を29.97fpsでインタレ解除

インタレ解除した実写ソースなら59.940fpsでエンコした方がいいぞ。
インタレ保持なら29.970fpsのままでも構わないが

mbtreeってcrf低い場合つけない方がいいの？

プログレ60fpsだと容量半端無いからインタレ保持29.97でよくね

情報番組は1.5倍速化 かつ インタレ解除の29.97fpsにしちゃうな。料理番組とか画質より縮めたいし

速度気にするならsubme 7で良い気はするし
実写で容量気にするならqcomp 0.75は多い気はするし
そもそもなぜ情報番組にアニメ用の設定をとか
まぁ個人の好みと拘りにもよるが

>>869,870
ありがとう　--no-mbtree　は外してみました。
エンコ速度は変わらなかったけど、ファイルサイズが4%ほど増えた。

crf値同じでも、たぶん各所で画質の差があるんだろうなー
細かく見比べないと全然気が付かないだろうけど。

>>873
容量なんてそんなに変わらん。とはいってもパラメータ次第だが
それに実写ソースに限らず動くテロップとか大急ぎで流れるエンドロールとかは
29.970fpsのままだとぎこちない動きを見せる。Ｍステのエンドロールとかで試してみ

>>877
それは再生環境が糞なだけでしょ

60iのものを30pにすりゃ環境が何もガクガクだろに

>>879
「インタレ保持29.97でよくね」って言ってるようだけど？

見てなかったスマン
crf26でインタレ保持より小さくしてるわ俺

ああ、俺も見てなかったわwてかcrf26って何の冗談だよ。
実写ならcrf19ぐらいだろ？アニメだとcrf16ぐらいにしているが

アニメｗｗｗ

なんで俺の設定こそ基本そして常識的な話に流れるんだろうな

え？

885は>>882へのレス

crf16とか何の冗談だよ

>>866
とりあえず--no-fast-pskipと--no-dct-decimateは切っとけ
--no-fast-pskipはスピードを犠牲にして、非常に稀な確率(ソース次第)でほんの少しだけ
質が改善するかもしれない可能性にかけるオプション
--no-dct-decimateはどうしてもディザを残したい奴が、crfを15かもっと下あたりまで下げて、
deadzoneとかも下げまくってからつけるもんだ
スピードとサイズを度外視出来ないのに、意味もなくつけるな

オプションに唯一無二の正解は無いから各自好きに付ければ良い

どっちも普通に効果あると思うけど

ソースと使うフィルタ、他の設定次第で変わるしな

一概にアニメと言ってもリマスターされてない様なセルアニメと最近のじゃ全然違うし
実写にしてもフィルムとHDカメラ撮影じゃ傾向違うし
一見シンプルな背景の舞台演劇でもグレイン残す様な設定だと妙に縮まなかったり
エンコは奥が深いやね

電力会社の影響のほうがでかいな

だな、オプションとか弄る前に電源とかSATAコードやHDDにメモリから厳選しろって話だな

最近行間読めないレスが多くて困る

>>888
ありがと
ちなみに　--no-xxx って名前のオプションは　xxxを切るって意味だよね？
エンコ速度向上に寄与する機能を切るって意味だから付けない方がいいわけね？

人が言ったからじゃなく両方試して速度的に変わらないと感じたなら
少しでも画質上がる方にしときゃ良い。
一旦設定つめたら後はただの作業だから今が一番楽しいときかも知れんし

>>887
crf16で24分アニメが1本あたり250MB前後で収まるだろ。
なにが不満なんだ？

>>898
煽りレスにムキになるなよ萌豚

>>898
もし物が鷹の爪だとしてもcrf16でそこまで縮まるのか？
SD化して背景が下手な油絵化するの許容すれば知らんけど

>>893
中国電力の管内でエンコした時の透明感のある映像が忘れられない
今は東電管内でエンコ速度が遅くなった感じ、出来上がりはバランスがとれてるんだが・・・

メモリーもいじってみたけど、
DDR2でエンコしてるときはUMAXが映像S/Nは一番よかった。
DDR3にしてからはエルピーダが消え入りそうな透明感を一番再現できてる

最近は攻殻機動隊やフルメタ（ふもっふは除外）みたいなアニメが無くてがったりだわ

>>898
収まるわけねーだろ情弱
どのタイトルなら250Mで収まるんだよ教えてもらいたいぞ

高crfで低容量なのはオプションがいい加減なだけだから触らない方がいい

>>903
偽物語などの動きが少ないソースだと、適度にノイズ除去すれば収まる気がするのだが。

>>905
あれのOPEDをまともな画質で入れようとしたら100%無理ぽ

Anotherのほうが縮むよ
crf18フィルタなし1280x720で250MBだった

mbtreeは基本的に動きのある部分に容量を振って少ない部分は節約する

これはビットレートが不足気味でも、動きのある部分が美しく作られるので綺麗に見える
同じcrfでもmb-treeオンだと容量節約できる

ただしcrf18等でファイルサイズ含め比較的高画質で保存したい場合mbtreeオンだと
すでに足りているにもかかわらず動きのある部分にさらに盛ろうとする傾向がある
なので、動きのない場所、動きとして検知されにくいフェードのとこ等は
crf16にしてもビットが足らないというような悪循環が起こる場合が多い

crf16 mbtree よりも crf18 --no-mbtree のほうを勧めるというのはそういう事だと思う

偽は回によって縮む回と膨らむ回がある
安定して縮むのはやっぱりAnotherだね

>>908
なるほど…
逆に動きが激しい部分のビットレートを上げたい目的で--qcomp 0.8なんかを使ってる場合は
わざわざ外すこともないて感じなんですね

>>908
動きのある部分のビットレートを下げるのがMBTreeだと思う。
映像の一部分しか動きの無いフレームの多いアニメ等で、より有利に働く機能。

x264 "Macroblock Tree Ratecontrol" testing (committed)
http://forum.doom9.org/showthread.php?t=148686

だね
>>908はまったくでたらめ

>>911
動きという表現は勘違いだった

複雑な箇所のビットを節約するというのが正しいね
結局どこに重点を置くかという問題になるのかな

多少ファイル大きくて構わないから細部まできれいにという時は切ったほうが良い

コンパクトにまとめたい、よつべ等のレート制限がある場合はつけたほうが良い

という感じだと思う

>>906
TVソースだと、元がビットレート不足による除去しきれないノイズだらけなので、
わざわざそのノイズを保つためにビットレートを増やさなくてもいいのではと個人的には思う。
「まともな画質」のソースであれば、それこそ比較的少ないビットレートで十分な画質は得られるのではと思う。

つーかcrf26と間違えたんだろｗ

http://static.techspot.com/articles-info/452/bench/Synthetic_04.png

http://www.anandtech.com/bench/Product/434?vs=443

エンコードならAMDの圧勝や！！！！！１１１１１１

元が汚いからさらに汚くしても良いとかDQN理論はやめて下さい

nl-meansサイコーや！

このスレのレベルよく変わるな

サイコーにつるぺたようじょ

>>914
OPは設定しだいだと思うがEDは画面全体動きまくりで低ビットレートじゃ厳しいと思うぞ
つか、元がTVの画質だと多少の事は妥協してエンコしてもこんな物かで済むけど
仮に元がノイズ一つ無い綺麗な物だったら逆にエンコ後の破綻やボケが丸分かりで
一話250MBに収まる様なビットレートじゃそれこそまともな画質と言えなくなる。

>>915
どこぞのフロントエンドの品質設定かなんかと間違えてるに一票

>>913
それはAQじゃね

ほれ16でエンコしたぞ

x264 [info]: frame I:318 Avg QP:14.16 size:172335 PSNR Mean Y:51.85 U:54.20 V:54.34 Avg:52.50 Global:52.18
x264 [info]: frame P:8924 Avg QP:17.08 size: 54202 PSNR Mean Y:50.02 U:52.28 V:52.41 Avg:50.63 Global:50.29
x264 [info]: frame B:25282 Avg QP:19.64 size: 14805 PSNR Mean Y:48.86 U:51.77 V:51.95 Avg:49.62 Global:49.23
x264 [info]: consecutive B-frames: 2.8% 3.2% 9.9% 45.3% 38.9%
x264 [info]: mb I I16..4: 13.8% 65.3% 20.9%
x264 [info]: mb P I16..4: 3.7% 7.6% 1.4% P16..4: 35.9% 29.3% 6.6% 1.2% 0.1% skip:14.2%
x264 [info]: mb B I16..4: 0.8% 0.8% 0.1% B16..8: 35.0% 12.6% 1.2% direct: 5.9% skip:43.6% L0:43.9% L1:50.1% BI: 5.9%
x264 [info]: 8x8 transform intra:57.9% inter:53.6%
x264 [info]: direct mvs spatial:100.0% temporal:0.0%
x264 [info]: coded y,uvDC,uvAC intra: 47.2% 61.4% 34.1% inter: 11.8% 23.3% 1.6%
x264 [info]: i16 v,h,dc,p: 24% 22% 5% 49%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 9% 18% 7% 9% 11% 10% 11% 13%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 13% 14% 7% 11% 11% 9% 8% 9%
x264 [info]: i8c dc,h,v,p: 22% 41% 23% 14%
x264 [info]: Weighted P-Frames: Y:1.5% UV:0.8%
x264 [info]: ref P L0: 51.7% 4.4% 29.1% 13.0% 1.8% 0.0%
x264 [info]: ref B L0: 78.1% 17.1% 4.8%
x264 [info]: ref B L1: 87.3% 12.7%
x264 [info]: SSIM Mean Y:0.9939426 (22.177db)
x264 [info]: PSNR Mean Y:49.189 U:51.924 V:52.091 Avg:49.908 Global:49.500 kb/s:5071.38

encoded 34524 frames, 5.59 fps, 5071.39 kb/s

ソース・フィルタ・オプション・ファイルサイズ

>>903
Working!!とか銀魂とかだな。crf16で250MBなら余裕で収まるわ。

銀魂はレンホー回で400M以上行ったぞ・・・

あとアマガミ＋や男子校でも250MB前後で収まるな

今期ならAnotherが一番縮む気がするが、まぁ容量がどれくらいになるかなんて
番組次第＆回次第だな。収まるって断言するのもおかしいし収まらないって断言するのもおかしい

だな
平均とか傾向で言うならまだしもな
細かくみれば局によっても変わるし

当たり前の事だがリサイズすれば縮むだろうし
ディテール潰れるのが嫌でサイズもノイズもそのままって人は縮まないだろうし
自分みたいに電脳コイル以降砂嵐がモヤに成らない様に設定してても縮まないし('A`)

8bitの糞画質なんてどーでもいい

BD全否定ﾜﾗﾀ

ソースは8bitだから見るに値しないので以下略
・・・みたいな人がそのうち沸いてくるんだろうか

どうせ表示は8bitなんだから今更10bitiなんて行っても仕方ない気もする

最近の液晶は16bitカラー並に落ちてるので8bitでもキャリーオーバーじゃなかろうか？

みんなナナオのColorEdge系で動画見てるんでしょ？

ところでさ、x264は10bit以上への対応予定はないの？
BDレコーダーとか12bit出力対応機とか出始めているようだが、x264で12bit対応してくれたらありがたいのだが。

>>937
出力だけで再生対応しとらんが

>>934
だからYUVの8bitとRGBの各8bitは違うとあれほど

再生機器が対応してもソフトが無けりゃ意味ないよなｗｗｗｗ

>>938
とはいえ、ソニーや東芝の対応状況を見ると、10bit出力対応はみかけないが、12bitはDeep-Color関係で見かけるし。

>>941
それって、再生する際に再生機器で色補間してるだけだろ？

BDプレイヤーとかのDeepColor(12bit)出力ってのは、8bitのソースに何らかの画像処理を加えて12bit出力してるだけ。
要するに8bitソースをなるべく綺麗に処理して出力してるというだけ。
>>938が言ってるようにプレイヤー自体が10bit以上のソースを再生できるわけじゃないんだから、
いくらx264が対応したって現状何も意味がない。
そもそも今の10bit-depthだって、ディスプレイからの出力まで全てをフル10bit化してるようなマニアはほとんどいないわけで。

8bit環境で比べてみても明らかに10bitの方が綺麗

>>942
現状はね

>>943
10bit化のメリット勘違いしてない？

>>944
8bitソース、8bit出力環境で使う場合にもメリットがあるのは理解してる。

>>945
行き違いがあるかもしれないので、何をどう勘違いしているというのか詳しく教えてほしい。
x264が12bit-depthに対応したとして、現状でそれをどう活用するつもりなのかなあと。

あと、どういう風にDeepColor出力すると考えてるのかなと。

>>946
別に現状すぐにどうこうってことじゃないよ。
ただ、民生機の流れでみると10bitを飛び越していきそうな流れなので、10bitがスルーされて
12bitとかより高いbitが終了になってしまうと、せっかくの10bit対応がもったいないなぁと思っただけ。

間違った。
×高いbitが終了
○高いbitが主流

ブルーレイや放送規格そのものが変わらないと無理だが
すでにそっちは4kとかH.265の世界に行ってるので
x.264がどうなろうがPCで閉じちゃうでしょうね

4kやらHigh bit-depthは民生機器で普及するのだろうか・・・。

>>950
閉じないでくれぇ〜

ipadの液晶サイズで2048 x 1536とかだから、ＰＣモニタなら割とすぐ4k時代が来るんじゃね？

>>951
High bit-depthは兎も角4kには行くでしょ
B-CASが死んでしまう2038以前に地デジの規格は変えたいだろうし

>>903
僕等がいた これ結構縮むからいけそうな気がする

でも鷹の爪が一番縮むんだぜ

アニメ用コーデック開発してくれないかな？
キャラと背景で別々に認識して処理するの
海月のエロゲアニメみたいなやつとか実際に圧縮出来そうなもんだけどな

言い出しっぺの法則

しかしここホントアニメの話題ばかりだな
実写はもう語り尽くされたのか

今度の2012Q2アニメは41本もあるんだから仕方ないだろう。

2012Q2
http://livedoor.blogimg.jp/manavisual/imgs/a/e/ae7d65de.png
2011Q2
http://livedoor.blogimg.jp/manavisual/imgs/8/1/813eb808.png

去年の春アニメにくらべれば少ない方だが。エンコ作業が忙しくなるよナ。

>>960
ざっと見てふと頭に浮かんだ事が「ニャル子さんなら200MB切りも可能かも」だった・・・。

そしてフラッシュアニメじゃ無い事を知ってなぜかがっかりした

そういえばべるぜバブ６０話で一旦終わるんだってな。
ジャンプアニメはどれも長編ばかりだから集め出すときりがないけど。
めだかと、黒子のバスケを何クールまでやるのかちょっと気になるところだ。

あまり長くなりそうなのはいつもesa@2pass@720pxで100MB前後に抑えるんだけどさ
crfより圧縮後の容量を決めやすいからわりと重宝する。

実写はcrf26でアニメはcrf22なサイズ重視の僕

実写はcrf22でアニメはcrf19なバランス重視の僕

実写は未定でアニメは未定な試行錯誤中の僕

実写を22まで下げられるならアニメも17まで下げていいと思うぞ

全部18

俺は実写は23アニメは20に落ち着いた

俺はts保存で落ち着いた

保存用TS 保存用エンコ 持ち出し用エンコ の3つは同じ動画あるだろ

保存用ってtsでいいじゃんｗ
外に映像を持ち出すっていう習慣があまり無いけど、BDは外でのプチ鑑賞会用にエンコードしてノートPCに入れたりはする。

マジレスしてんじゃねえよ

マジレスしてんじゃねえよじゃねえよ

マジレスしちゃうけど、BD買うの前提で放送ソースを正義とするならそれでいいんじゃね？
放送ソースが残念だと結局エンコするしかないわけで

おお…

ニコニコ動画まとめwiki事態が落ちてるんだが、どっこへ引っ越しした？
ttp://www.nicowiki.com/%E6%8B%A1%E5%BC%B5%20x264%20%E5%87%BA%E5%8A%9B%EF%BC%88GUI%EF%BC%89Ex%E3%81%AE%E8%A8%AD%E5%AE%9A%E9%A0%85%E7%9B%AE%E3%81%A8%E3%81%9D%E3%81%AE%E6%A9%9F%E8%83%BD%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6.html

何でもTSで保存してたら埒が明かないよ
保存は程度によってランク付けしないと

>>977
引っ越してない。サーバー自体はどっかにあるんだろうけどドメイン登録が切れてる。
4/14までに所有者が入金しないと消滅らしい。というかスレチ。
　　http://anago.2ch.net/test/read.cgi/streaming/1311877802/927-

x264 rev36
http://toro.2ch.net/test/read.cgi/avi/1332223627/

>979 理解。サンクス

https://www.google.com/reader/view/#stream/feed%2Fhttp%3A%2F%2Fjapanese.engadget.com%2Frss.xml

アニメの話題もアレだがスレチな雑談が多い
春休みだから仕方ないな

自称アニオタのJEEB氏もこっそりレスしてたりな

だいたx264関連のブロガーの9割はアニヲタだろうに

作者からしてこうだもの。仕方がないんじゃない
ttp://twitpic.com/5n0vqd

お、おう

クソワロタw tune touhouなんて出来るはずだわ

Nのコスプレがカッコイイな

そういやまだ闇然りさんここ見てるの？

>>990
仕事などが忙しくなってきてからは見てないと思ふ。翻訳依頼も来てないし。