X

x265 rev4

■ このスレッドは過去ログ倉庫に格納されています
2017/11/21(火) 20:18:20.98ID:rz2nbV+s0
前スレ
https://mevius.5ch.net/test/read.cgi/avi/1462270195/
2018/03/26(月) 01:10:10.16ID:xaZyoL940
rigaya氏のブログの「x265ビルド VC2017版」の記事に、

　x265 2.7+17 と L-SMASH r1459 の組み合わせで、L-SMASHが固まる

というコメントがあった。試してみたら、うちでも再現した。
2.7+14なら大丈夫らしいが、どちらが原因かはっきりするまで様子を見た方がよいかも。
2018/03/26(月) 19:29:12.01ID:KAWe9XE/0
>>104
追加で少し試したので取り急ぎ100%再現パターンを。

●ソース： sample.avs （ffmpegでy4m化してx265へ）
ColorBarsHD(1280,720).Trim(0,500).ConvertToYV12()
ShowFrameNumber(scroll=true,size=128)

●x265コマンド(今のところ2passでしか再現できてない)
--pass1 --bitrate 1000
--pass2 --bitrate 1000

●muxerコマンド
muxer.exe -i "sample.265"?fps=30000/1001 -o sample.mp4

●結果
muxer.exeが固まる。たまにクラッシュすることもある。
2018/03/27(火) 14:22:05.18ID:hAwfzym80
L-SMASH 側でなんかコミットあったようだけど無関係?
https://github.com/l-smash/l-smash/commits/master
2018/03/27(火) 15:23:43.35ID:lGCQMxzy0
>>106
試しに最新のL-SMASH rev1466(50ee6cb)をビルドしてみたけど、
>>105でL-SMASHのmuxer.exeが固まるという現象は変わってなかった。

2.7+16(5be53f0)でSEIの書き込みのとこを変えたようなので、そこがおかしいのか、
それともL-SMASH側のバグなのか。

自分はコードやストリームの解析まではできないので、作者や詳しい人の参戦を祈ることしかできぬ・・・。
2018/03/27(火) 15:28:23.56ID:lGCQMxzy0
ちなみに2.7+17でも、

　ffmpeg-3.4.2.exe -r 30000/1001 -i sample.265 -c:v copy sample.mp4

　MP4Box-0.7.2-rev442-g508d7817.exe -add sample.265 -new sample.mp4

ではmuxも再生も特に問題なさそう。コケるのはL-SMASH muxerのみ。
2018/03/27(火) 15:36:01.63ID:G0IAA57sM
最近h265のこと知ったけど本当にすごいな
容量1/3でひと目じゃ違いがわからないほどの画質だわ
もっと早くに出会っていたかった
2018/03/27(火) 15:40:51.57ID:g+k3xdKBd
本当すごい
h.264でいいじゃんとか思ってたが画質の良さ段違い
2018/03/27(火) 18:34:20.56ID:hAwfzym80
>>107
折角俺も L-SMASH 常用なんで x265 と L-SMASH 共にさっき pull してビルドしたやつで
エンコから Mux してみたけど異常無しですわ。

x265 2.7+18 (1fb5ee43be2f) x64
muxer rev1466 (50ee6cb)

muxer.exe -i hogehoge.26x?fps=24000/1001 -o hoge.mp4
MP4 muxing mode
[HEVC: Info]: IDR: 1, CRA: 57, BLA: 0, I: 17, P: 1321, B: 3494, Unknown: 0
Track 1: H.265 High Efficiency Video Coding
Muxing completed!

なんて書いておいてあれだが 2pass はしないで crf 使うタイプなんでそのせいかな。
2018/03/27(火) 19:35:05.90ID:zm8guuOZ0
>>111
問題の発生原因がはっきりしてないので、まだなんとも言えないんだよねえ。

例えば>>105で書いた100%再現の2パスエンコでも、sample.avsの末尾に
　Spline36Resize(640,360)
をつけて360pにした場合は問題は再現しない。
720pのままでも、x265で --preset slow または --preset fast をつけると問題は起きない。

適当に試した限りでは--crfでは再現してないのだけど、
原因がはっきりするまでは、「crfなら安全」とは言い切れない。
いつコケるかわからないし、知らない間に「一応再生できるけど規格的に異常なファイル」が作られてしまう可能性もある。

とりあえずL-SMASHの方にもIssue出しておいた。

　muxer freeze(or crash) when using x265 2.7+17 - Issue #82 - l-smash/l-smash
　https://github.com/l-smash/l-smash/issues/82
2018/03/27(火) 20:02:39.73ID:wDAUP5Ia0
>>107
多分そこだと思う
ヘッダに16バイト分ゴミが混ざってて、そこを消すと正常になる
2018/03/28(水) 02:43:02.76ID:g/KUYe660
確認できたこと
・x265にバグがあって、不正なヘッダが出力される
・L-SMASHで問題が起こらないファイルも怪しい

参考
https://imgur.com/a/haoJR
2018/03/28(水) 14:01:27.08ID:bOMavOh+0
>>113-114
おお、ありがとう。x265側の問題か〜。オプションとかを格納してるSEIuserDataUnregisteredで
バッファ領域を超えて書き込んでるっぽいのかな？

できればそちらでDoom9かx265のIssueに出してきてもらえるとありがたいのだけど、どうだろう？

そちらで無理なようなら、その画像を以下のような出川ばりの英語で
Doom9に貼ってきてもいいんだけど、どうしよう。

---

x265 2.7+17 outputs broken SEI. (maybe SEIuserDataUnregistered)
Not only 2pass encoding.

Left side: 2pass encoding
Right side: 1pass encoding
【画像】
2018/03/28(水) 14:18:38.25ID:g/KUYe660
>>115
私は不慣れなので、すみませんが連絡をお願いします
2018/03/28(水) 15:17:15.09ID:wZNcV2S/0
doom9覗いたらすでに報告されてたから
じきに直るのでは
2018/03/28(水) 16:20:16.71ID:bOMavOh+0
>>116
報告しておきました。感謝。
　https://forum.doom9.org/showthread.php?p=1837693#post1837693
2018/03/28(水) 21:48:16.17ID:wZNcV2S/0
物事が一気に動き出した感が凄いね
解析人＆報告人おつかれ
2018/03/30(金) 21:44:43.67ID:MI5GTo4n0
　
2.7+15〜2.7+19で発生していた>>104-118のSEIバグは、2.7+20で修正されたようです。

　　https://bitbucket.org/multicoreware/x265/commits/3440a56acc7865dcdea725b8ce7755450209a8ee
2018/03/31(土) 13:09:26.20ID:ZmwRNZhu0
報告人乙
AVX512よりOpenCLアクセラレーションをだな・・
2018/04/02(月) 21:59:54.29ID:f5J0o+Po0
+22になってたが、
使ってるパラメータは昔から全然変えてないな
少しは見直したほうがいいのか・・・
2018/04/09(月) 21:13:37.30ID:LTQ45mIz0
AVX512のコードをレビュー中みたいだけど
AVX/AVX2のコードも含まれてるのかな
2018/04/10(火) 12:59:16.94ID:mvAZrsZe0
MulticoreWare achieves 18% performance boost on the x265 video codec with Intel AVX-512 Instructions for high quality encoding of 4K HDR content
https://multicorewareinc.com/news/multicoreware-achieves-18-performance-boost-x265-video-codec-intel-avx-512-instructions-high-quality-encoding-4k-hdr-content/

AVX-512を使って4K HDRコンテンツのエンコードで最大18%のスピードアップに成功したよという発表。
2018/04/10(火) 13:16:00.32ID:mvAZrsZe0
MulticoreWare Forms OpenX Media Advisory Board (OpenX -MAB) with Industry Experts to Guide Open-source Media Codec Development
https://multicorewareinc.com/news/multicoreware-forms-openx-media-advisory-board-openx-mab-industry-experts-guide-open-source-media-codec-development/

訳：
MulticoreWareがOpenX Media Advisory Board（OpenX -MAB）を設立。
業界の専門家と協力して、オープンソースのメディアコーデック開発を支援。

オープンソースHEVCエンコーダx265の作成者であるMulticoreWareが、
OpenX-Media Advisory Board（OpenX-MAB）の設立を発表しました。
OpenX-MABの焦点は、x265のような現在および将来のオープンソースのビデオエンコーダの
開発ロードマップを主導し、メディア業界における関連性や普及を確実にすることです。
OpenX-MABは当面はHEVCエンコーディングのためのx265のリーダーシップを継続することに
重点を置くが、将来は他のオープンソースコーデックを含むように拡張するかもしれない。
MulticoreWareはOpenX-MAB拡大のため業界のエキスパートに声をかけている。
2018/04/10(火) 13:20:34.68ID:xP4Na1DRa
>>124
18%か
そろそろ最新世代のCPUを検討するか
（AMDは対応してないんだよね？）
2018/04/10(火) 13:52:51.85ID:IB8fQ2qt0
CoffeelakeはAVX512非対応だよ
2018/04/10(火) 14:32:56.31ID:xP4Na1DRa
>>127
マジで？
では対応しているCPUって？
2018/04/10(火) 14:41:37.90ID:mvAZrsZe0
>>128
聞く前にググろうぜ。

AVX-512 - Wikipedia
https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512
2018/04/10(火) 18:05:05.59ID:HFQoF9+f0
>>124
ダイを倍の大きさにして18%は割に合わねぇ・・
SDR/2kだとどうなるんだろか
2018/04/10(火) 20:39:06.61ID:sYlLCMQI0
ryzen3000とicelakeの対決が楽しみやね
2018/04/12(木) 15:38:59.01ID:n+ScPlN90
AVX512向けパッチが入ったみたい
なかなか圧巻だけどAVX512だけでつまらない
2018/04/13(金) 02:01:43.85ID:NWyIYo2t0
AVX512の大量コミットで一気に x265 2.7+336 になったのか・・・ｗ
2018/04/13(金) 02:22:20.69ID:NWyIYo2t0
というか、もう3.0のリリース準備に入ってるのね。

VMAFスコアの計算機能も入った模様。
cmake時に ENABLE_LIBVMAF をつけて、libvmafをリンクする必要あり。

　Add VMAF suppport to report per frame and aggregate VMAF score
　https://bitbucket.org/multicoreware/x265/commits/8bc1289c7a4b176d77b48e74716aea30e42766e7

　参考：
　　新しい映像の品質評価 libvmaf
　　http://nico-lab.net/libvmaf_with_ffmpeg/
2018/04/13(金) 08:19:53.51ID:9wcAjWee0
>>134
それを追加すると、どんなメリットが発生するの？
2018/04/13(金) 08:37:04.29ID:5x5KpZpr0
>>135
SSIMやPSNRより参考になる可能性がある
2018/04/13(金) 09:09:50.94ID:9wcAjWee0
>>136
そういうことか
Thx
2018/04/13(金) 11:58:14.00ID:+CW60tiR0
ああ、でも ENABLE_LIBVMAF は完全にデバッグ用かも・・・？
ソースを読み違えてなければだけど、ENABLE_LIBVMAFをつけてビルドしたら
--recon（でかいYUVファイルも出力する）をつけないとエンコードできなくなるような・・・？
VMAF用のモデルパスも/usr/local/share/model/vmaf_v0.6.1.pkl固定みたいだし。
おとなしくffmpegで計測したほうがよさそうだ。
2018/04/13(金) 18:45:37.92ID:qCymtqNK0
rigaya氏の2.7+336のバイナリ、gccでビルドしたものと書かれてるけど、
--versionで見ると
　x265 [info]: build info [Windows][GCC 7.3.0][64 bit] 8bit+10bit+12bit
とかじゃなく
　x265 [info]: build info [Windows][MSVC 1913][64 bit] 8bit+10bit+12bit
になってるのは、MSVCからgccを使ったということなんだろか？
（ビルドに詳しいわけじゃないので、ちょっと気になっただけ。変なこと言ってたらすまぬ。）
2018/04/15(日) 02:04:37.98ID:3zo9kCKG0
rigaya氏の2.7+336のバイナリが最適化されたものに更新された模様。

> 2018/4/14 19:43にx265 2.7+336をここで紹介するgccで
> プロファイルによる最適化を実施した実行ファイルに差し替えました。
2018/04/15(日) 08:24:32.12ID:aTNvjuUP0
340で修正されたね
2018/04/18(水) 15:36:59.22ID:YRWrQNWv0
ちょっと質問。
2.7+336-07defe235cde で --asm avx 付けてるとエラーで速攻落ちちゃうんだけどこれおま環?
ログみると「障害が発生しているモジュール名: ucrtbase.dll」とかでちょる。
--asm avx を外せばエンコできたけど Ryzen なんでどうしたもんかなと。
2018/04/18(水) 16:34:27.96ID:cXV5p2iF0
aviutlのguiEX経由だけど問題なくエンコードできてるよ
2018/04/18(水) 17:18:59.94ID:HTI1sHZw0
うちのHaswellもrigaya氏の差し替え版バイナリで特に問題ないな。
ちゃんとコマンド書いてないからコマンド依存で発生する事象ならわからんが。
どういうソースをどこのバイナリでどういう設定で実行したのかくらいは書いた方がいいと思う。
2018/04/18(水) 17:52:15.27ID:YRWrQNWv0
x265.exe 自体はオフィシャルなリポジトリ https://bitbucket.org/multicoreware/x265/wiki/Home から
pull して make-solitions.bat から high_bit_depth を ON にして VC2017 から x64 の release ビルドをやった物です。
その後弄ってみたけど、どうも --asm と --no-asm 何れかを入れ込むとエラー落ちするぽいです。
他の人が問題無いなら当方の おま環 ということですね。
2018/04/18(水) 18:08:23.54ID:m5UZEJ3o0
https://msdn.microsoft.com/ja-jp/library/abx4dbyh.aspx

スタティックリンクしたら、大丈夫なのかな(未検証
2018/04/18(水) 18:15:27.44ID:YRWrQNWv0
試しに rigaya 氏ビルドの物に差し替えたら --asm avx を入れてもエラーが出ずにエンコできますた・・・
自分の単純なビルド方法で今までこう言った問題は起きたこと無かったんで咄嗟に書き込んでなんだか申し訳なくorz 失礼しました!
2018/04/19(木) 12:02:15.65ID:CAIRBG+rd
>>145
VSでビルドすると壊れる問題は、今の所stableブランチにだけ、修正が入ってる。

stable持ってきてビルドすれば動くよ。
まぁ、そのうちdefaultにも入るだろうけど。
2018/04/20(金) 03:43:40.27ID:p8ollzQJ0
+340-stable ビルドした
AVX512は装備してないけど、だいぶ速くなってる感触
まぁ、動画ソースの問題もあるかもしれなくて全然厳密じゃないが
2018/04/20(金) 10:30:35.72ID:+I7QsHZu0
Ryzenだと128bit実行のせいか0.5fps程度の違いだった（早くはなってる
2018/04/20(金) 13:58:16.07ID:PbP8t3sj0
「速くなった」って、いつのバイナリと比較してるんだ・・・？
最近ではAVX512以外に高速化要素なんて無いと思うんだけど。
2018/04/20(金) 14:11:15.36ID:hscY5VHv0
漏れも全然感じない
2018/04/20(金) 17:08:18.30ID:p8ollzQJ0
論理コアが多いほど速度向上を体感しやすいのかも
全く根拠はないが
2018/04/20(金) 17:32:44.04ID:PbP8t3sj0
「なんとなく速くなってると思いました。まる。」みたいなこと書かれても・・・。
必要なのは環境やバイナリのバージョンや設定やソース等の情報も含めた正確な比較条件だと思うよ。
2018/04/20(金) 18:10:17.26ID:CCChLuwY0
>>150
その表現じゃ伝わらん
1.0fpsと1.5fpsなのか100.0fpsと100.5fpsで全然話が違うぞ
2018/04/20(金) 18:47:30.17ID:+I7QsHZu0
別に伝わらなくていいと思ってる（ryzenに興味あって調べてるならベンチスレででも覗けばいいだけ）
カキコした私が誤差程度と判断したから情報としてまとめなかったけども
2018/04/20(金) 18:50:30.44ID:hscY5VHv0
Ryzenなら、メモリ回り詰めれば速くなる。
158名無しさん＠編集中 (ﾜｯﾁｮｲW fae0-ZOBi)
垢版 |
2018/04/20(金) 20:18:13.59ID:5wKx8vum0
来年24コアryzen2TPが出たとしてx265の特に重いプリセットでは全然使い切れないだろうなぁ
2018/04/23(月) 11:28:44.66ID:BRPMKJ720
先週IntelからRyzenに変更したのですがエンコする際に--asm AVXをつけろ　とネットでみたのですが
その理由がわかりませんでした
これはどういう意味があるんでしょうか？
また実際につけた方がよいものなのでしょうか？
2018/04/23(月) 12:19:03.19ID:p76LCKVz0
AVX2 を使うと逆にエンコード速度が落ちるからだよ〜
AVX までに制限してやることで数 fps ほど速度あがる。
実際に --asm avx の有無でエンコ比較してみると良いかも。
2018/04/23(月) 12:32:40.97ID:diM3xT4md
本当、何の為に実装したんだか
2018/04/23(月) 13:04:20.60ID:BRPMKJ720
>>160
ありがとうございます　そういう意味があったんですね
これで心置きなく試してこれそうです
2018/04/23(月) 15:47:10.80ID:QffvhQ240
AVX2必須、みたいなアプリもあったりするかも知れんし機能があるに越したことはないとは思う
x264やx265でAVX2使うと若干とはいえ遅くなりはするけど動作しないわけでもないし知識があれば回避できるわけだしな
2018/04/23(月) 18:56:54.20ID:ov3R+Oo10
>>162
x264はAVX2切った方が速いけどx265はAVX2の効果高い事多いので
on/off両方試して、自分の環境に合ってる方法とるべし
2018/04/27(金) 18:15:06.70ID:PLvUpLvx0
h.264とh.265でtune別　crf別にssim値をプロットしたようなグラフを昔に見た記憶がありそれを探してるのですが
わかる人いたら教えてください
2018/04/27(金) 20:48:13.46ID:1O42is100
過去ログにいくつかあるね
ただ作られたのがかなり前だしプリセットの内容も変わってるから今だと参考にならない

x265 rev2 [転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/avi/1418252184/301

301 名前：名無しさん＠編集中[sage] 投稿日：2015/03/31(火) 12:12:14.04 ID:9g7lReBC
Fasterは無いけど各プリセットのファイルサイズとSSIMのグラフ

http://2sen.dip.jp/cgi-bin/upgun/up1/source/up1461.jpg
http://i.imgur.com/ZQl3NLq.png
http://i.imgur.com/dTiyhbx.png

x265 rev3©2ch.net
http://mevius.2ch.net/test/read.cgi/avi/1462270195/633

633 名前：名無しさん＠編集中 (ﾜｯﾁｮｲ 9f3e-YTUC)[sage] 投稿日：2017/04/28(金) 23:26:59.96 ID:eUzMgdEP0
>>632
一応>>631のグラフにx265 veryslowも追加してみたけど、
SSIM/bitrateグラフでのラインとしてはslow,slowerと大して変わりない感じだね。

　http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3406.jpg
2018/05/21(月) 23:30:48.36ID:bTBIMDBb0
2.8 来たな。
VS 2016 Community で普通にビルドして --asm avx 付けてもエラー出なくなってたわ。よかった
2018/05/22(火) 00:30:38.73ID:6Qanf6ox0
Release Notes
Version 2.8 - 21/05/2018
http://x265.readthedocs.io/en/default/releasenotes.html#version-2-8
2018/05/22(火) 00:42:27.48ID:Q29sG+kB0
3.0じゃないんだ
170名無しさん＠編集中 (ﾜｯﾁｮｲ d610-/vbK)
垢版 |
2018/06/02(土) 07:58:01.86ID:ZfXg0V8T0
http://satch.tv/members/honeybee909/?mref=787
171名無しさん＠編集中 (ﾜｯﾁｮｲ 65d2-byqv)
垢版 |
2018/06/02(土) 09:21:02.21ID:rOXpoqpp0
http://satch.tv/?mref=115
172名無しさん＠編集中 (ﾜｯﾁｮｲ 65d2-byqv)
垢版 |
2018/06/02(土) 09:21:06.60ID:rOXpoqpp0
http://satch.tv/?mref=115
2018/06/19(火) 18:25:04.97ID:uDXUEk/b0
やっぱり画質が良くなるオプションは重いのね
いつもなら終わってた量のタスクが終わってなかったは

それはそうと新AQモードの実装はまだかな
画質あがって早くなったら嬉しいんだけども
2018/06/19(火) 19:44:41.68ID:E9MLTUx7M
なんのこっちゃ？
2018/06/19(火) 20:43:16.16ID:Xfn02oug0
新AQモードというのは>>74のことかな？その後どうなったんだろね。
2018/06/20(水) 07:29:13.09ID:vvaAAzN50
最近は更新激しくてパラメータよく解らなくなってきてるな
でもAQは影響デカイパラメータだよね
期待
2018/06/20(水) 23:03:45.23ID:GbvFn6Ss0
いうほど変わったっけ？
どうしてもx264全盛期と比べて遅く感じてしまう
2018/06/21(木) 20:45:03.70ID:rlr2EKZD0
x265のバラメータは不勉強だわ
一回本腰入れて覚えないと
2018/06/21(木) 23:07:50.33ID:xqqnzSI30
--sao-non-deblock

実写は↑+SAOおすすめ
逆にこれ使わないならSAOを使わないほうがいい
（テスト期間2日だけど
2018/07/08(日) 11:05:54.93ID:qBHDX1Nu0
ryzen環境だけどAVX2のほうが早かった
ブラウザ閉じたり厳密なテスト環境ではないけど

x265 [info]: HEVC encoder version 2.8+40-0106f9f2f867

x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
encoded 720 frames in 48.33s (14.90 fps), 2510.94 kb/s, Avg QP:27.02
encoded 720 frames in 48.85s (14.74 fps), 2510.94 kb/s, Avg QP:27.02

x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
encoded 720 frames in 45.10s (15.96 fps), 2510.94 kb/s, Avg QP:27.02
encoded 720 frames in 44.41s (16.21 fps), 2510.94 kb/s, Avg QP:27.02
2018/07/08(日) 11:15:03.97ID:a2fe6VVL0
ほお。
うちも Ryzen 環境だからちょっとビルドして試してみるかー
2018/07/08(日) 11:26:02.65ID:CHv2DBnH0
x264はAVX2無しの方が速いけどx265は付けないと駄目だよ
2018/07/08(日) 11:34:12.01ID:a2fe6VVL0
>>182
今まではそれが常識的な物だったけど
AVX2 使った方が速かったよってお話しじゃないの?

まぁ今ビルドおわったんでちょっと試してみるわ
2018/07/08(日) 12:01:26.32ID:a2fe6VVL0
俺環での同テスト
あくまで --asm avx 有無のみの差異。

x265 2.8+40-0106f9f2f867

--asm avx 有り
encoded 2000 frames in 64.96s (30.79 fps), 1828.98 kb/s, Avg QP:23.40
encoded 2000 frames in 65.35s (30.61 fps), 1828.98 kb/s, Avg QP:23.40

--asm avx 無しの AVX2 使用
encoded 2000 frames in 64.95s (30.79 fps), 1828.98 kb/s, Avg QP:23.40
encoded 2000 frames in 64.63s (30.94 fps), 1828.98 kb/s, Avg QP:23.40

（参考）
2.8+23-656b5b442f0b で AVX2 使用。
encoded 2000 frames in 65.81s (30.39 fps), 1828.98 kb/s, Avg QP:23.40
encoded 2000 frames in 65.85s (30.37 fps), 1828.98 kb/s, Avg QP:23.40

ということで現状はまだなんともだけど >>180 氏の言うとおり Ryzen 環境でも
AVX2 を使った方が微妙に速くなるかもしれん。
2018/07/08(日) 12:28:09.63ID:a2fe6VVL0
追試というか x265 に吐かせた csv なログがあるので昨日エンコしてたソースを再度 2.8+40 でエンコしたログの比較。

アニメソース 34523 フレーム

2.8+40-0106f9f2f867, AVX2 使用 = エンコ時間 840.63s, 平均 41.07fps
2.8+23-656b5b442f0b, AVX2 未使用 = エンコ時間 875.67s, 平均 39.42fps

コミットみると AVX2 周り色々良くワカランが弄られてるからなんか良くなったんかね。
家はこれで --asm avx を削れそうですわ
2018/07/08(日) 13:08:36.86ID:HkL359170
Ryzenつってもいくつかあるんだからモデルくらい明記したほうがいいだろうし、
解像度もちゃんと書いたほうがいいと思う・・・。
2018/07/08(日) 13:42:40.94ID:xXdNGq9Q0
AVX2を使うか否かでエンコード速度がーーって話にCPU型番と解像度って必要な話なのかなww
2018/07/08(日) 14:17:34.19ID:qBHDX1Nu0
まぁ、たしかに解像度などで処理の負荷や傾向も変わるからね

ryzen 1700X
実写1440x1080 （Aviutlのafsでテレシネ解除しguiEX出力）
オプションは設定のリセットを忘れて常用ので走らせたので、ログに記載されてるオプションをペタリ

--input-depth 16 --output-depth 10 --input-csp i420 --crf 25 --qcomp 0.72 --rc-lookahead 25 --vbv-bufsize 7000 --vbv-maxrate
7000 --aq-strength 1.2 --psy-rd 1 --deblock -2:0 --no-sao --subme 3 --merange 55 --rect --limit-modes --ref 4 --max-merge 3
--weightb --rd 2 --colormatrix bt709 --colorprim bt709 --transfer bt709 --sar 4:3 --no-opt-qp-pps
--no-opt-ref-list-length-pps --no-strong-intra-smoothing --input-res 1440x1080 --fps 30000/1001 -o
2018/07/08(日) 14:21:18.43ID:HkL359170
>>187
なんで笑ってんのかよくわからんけど、データを出すなら普通にあったほうがいい情報だと思うけどね。
言及し忘れたけど、オプション設定も書かれてないので、そういった情報もあればいいなあとは思う。
2018/07/08(日) 14:32:40.17ID:a2fe6VVL0
俺も環境かいとく流れかな

偶然俺も Ryzen 7 1700X で定格。
映像ソースはアニメで 1440x1080 から AVS で 960x720 にリサイズして SAR 4:3 としてる。

x265 に喰わせてる引数はこれだけ。>>184 でやったテストはこの引数に --asm avx を付けるかどうかってだけの違い。
--crf 19 --preset medium --input-depth 8 --output-depth 10 --aq-mode 3 --aq-strength 0.6 --sar 1:1 -o OUTPUT.265 INPUT.avs

AVS ファイルの中身は Trim してロゴ消しからのインタレ解除、ノイズ除去とスムーサー通してリサイズ、アンシャープマスクにデバンドやってる。
で Avisynth+ r2728-MT にやらせてる。

中でどういう処理させてるかでは多少なり変わってくるかもしれないけど、俺環では速くなったので
この事を書いてくれた >>180 氏には感謝。気付かなければずっと AVX2 使わないままだったと思うしｗ
2018/07/08(日) 14:33:57.66ID:a2fe6VVL0
引数間違えてた --sar 1:1 じゃなくて --sar 4:3 だた。
2018/07/08(日) 14:43:02.06ID:+0goipd80
>>189
ハイスペ側だとなにかしらのボトルネックで頭打ちが発生して大差なくなるとかあり得るものね
2018/07/08(日) 14:47:32.78ID:HkL359170
>>192
だよね。

情報書いてくれた方々ありがとう。
2018/07/08(日) 16:25:53.01ID:R57rVJt10
ryzenが出た頃に10bit出力ならAVX2ありの方が僅かに早い、ってrigaya氏がすでに言ってたの
意外と知られてなかったんだな
2018/07/08(日) 17:16:20.30ID:igBBszGI0
>>194
うちの環境ではそれでも AVX2 有りだと遅くなってたのよ。
2018/07/08(日) 18:41:50.71ID:qBHDX1Nu0
早いこともあれば遅いこともあったと思うけど
ここしばらくはAVX2使わないほうが早かった
2018/07/13(金) 19:06:48.35ID:phGGD7kZ0
There's also at least the value of --max-merge being raised in the slower presets which (at least in my opinion) affect by degrading quality. It will smooth things more --> lower bitrate.

これってどういう意味？

元URL　http://forum.doom9.org/showthread.php?p=1846405#post1846405
2018/07/13(金) 19:32:00.19ID:ev3/ZGri0
>>197
--max-mergeの値を上げると画像がボケる
2018/07/13(金) 20:09:01.25ID:phGGD7kZ0
low-bitrate帯でボケる？ それとも割り当てられるbitrateが少なくなるからボケるのどっち？

crf26でmax-merge 5だとボケた感じになった覚えはあるんだけど
2018/07/14(土) 20:04:30.79ID:ahvHITJu0
ボケる結果ビットレートが低くなる
2018/07/14(土) 22:41:08.93ID:YCb4PdI30
高ビットレートだとボケないのかな？っていうことを聞きたかったんだけど、そこまでは読み取れない？
上から目線であれだけど、英文の記号の使い方とかよー分らん
2018/07/15(日) 14:05:01.45ID:nLoHgNZz0
一度ボケたらいかにビットを割り振ろうと元には戻らないので、ディテールを残したければ--max-mergeを下げるべきだろう
2018/07/15(日) 14:13:15.85ID:jCJzclqYa
ビットレートに余裕があるときにどんな動きをするか聞きたいんじゃない
問答無用でマージしてビットレート下げに行くのか、余裕があるなら働かないのか
2018/07/15(日) 14:32:55.47ID:nLoHgNZz0
>>問答無用でマージしてビットレート下げに行く

英文を素直に解釈すればこっち
2018/07/15(日) 14:50:01.74ID:er4i/YnR0
>>202-204
ｔｈｘ
情報の共有と省略、粗のごまかしに心血を注いでるから
副作用なく高圧縮・高画質化ってのは難しいのね
2018/07/19(木) 01:21:23.72ID:VQByvLN90
久しぶりにx265のオプション見直そうと思ったけど
色々変わってるからpresetとcrfだけでいいような気もしてきた
2018/07/19(木) 23:38:19.76ID:WdSoljMy0
>>206
>179のオプションいいぞ
2018/07/23(月) 11:15:48.83ID:k8tyZ7ag0
http://forum.doom9.org/showthread.php?p=1846852#post1846852

これデブロッキング・フィルタを無効にしてるせいだと思うんだけどどうよ
2018/07/29(日) 03:19:48.57ID:ofEesbc00
質問です。
エンコードするときに設定するビットレートの目安を求めたいのですが、
ttp://web.archive.org/web/20130207145934/http://service.jp.real.com/help/faq/prod/faq_4226.html
とか
ttps://www.lizardk.net/2011/05/h264.html
に書いてある式と、それで求められる値は当てにして良いものですか？
コーデックの話であって、エンコーダによって全然違うとかあるなら微妙なんですが・・・。

さらに、ここで求めた値を50%〜60%くらいにすればx265でのビットレートとして使えますか？
2018/07/29(日) 08:38:34.01ID:EBUxRnOm0
固定ビットレートでエンコードするなら、目安になるのでは？

固定品質でエンコードの場合は、全然、目安にならないけど。
2018/07/29(日) 08:51:34.14ID:8BfhzM290
>>209
50〜60%は行き過ぎかな
H.265は公称ではH.264の半分のビットレートで同等の画質って言ってるが実際は30%減くらいだと思う
2018/07/29(日) 09:00:12.20ID:WkF14PaEM
x264は動画版lame(mp3高性能エンコーダー)みたく規格上のギリギリで高効率に圧縮してるからなぁ
x264はほぼ完成してるけどx265はまだ発展途上だからまだ半分は行けないよな
2018/07/29(日) 09:41:12.17ID:p8xSZ0wf0
>>209
real playerのころとは比べ物にならないぐらい圧縮率は向上してるから半分ぐらいでちょうどいいと思うけど
どのみちビットレート指定方式では仕組み的に高画質は無理（6Mbpsぐらいつぎ込めば話は別だけど
ま、基本的にcrfモードを使うのが推奨された使い方

x264なら crf=22~23、x265なら crf=24~26 がビットレートと画質のバランスがいい
2018/07/29(日) 11:42:11.98ID:UxujymIy0
エンコーダ間の比較っていう意味ではこんな資料が
https://wyohknott.github.io/video-formats-comparison/

でも最近のエンコーダだと、要求ビットレートが
総画素数/フレームレートに比例するかどうかは怪しい気がするけど…
2018/07/29(日) 13:45:21.35ID:ofEesbc00NIKU
なるほど、みなさんありがとうございます。

>>210
下のURLの方だと、「VBRの最大ビットレートはこの2倍くらいにします」とあるんですが、
2018/07/29(日) 13:46:57.15ID:ofEesbc00NIKU
Shift+Enterしてしまったごめんなさい

VBRの最大ビットレートはこの2倍くらいにします、とあるんですが、
CBRに比べたVBRやCQPのビットレートの振れ幅というのは2倍や0.5倍の範囲内に収まるものなんでしょうか。

詳しい方いましたら教えてください。
2018/07/29(日) 14:05:38.85ID:qungLzDW0NIKU
最大ビットレートは入力ソースの最大でいいよ。
2018/07/29(日) 14:06:19.56ID:p8xSZ0wf0NIKU
x264, x265のビットレート指定エンコードだと2倍もは変動しなかったはず
（crfな品質指定エンコードだと3倍ぐらい変動するけど）
2018/07/29(日) 14:11:12.64ID:MNacyzm00NIKU
ソースによる
2018/07/29(日) 14:40:29.28ID:nivXCK+nMNIKU
最大ビットレートなんて、再生環境が使える上限値にしとくだけだよ
これ以上にすると再生できなくなるから超えないようにエンコードしなさいという値なのだから
2倍とか関係ない
2018/07/29(日) 15:27:57.92ID:wdaToWzEMNIKU
例えば地デジtsなら上限10Mbpsで十分だな
てか何故かテレビ放送の実写はcrfの割に縮まないのは何故？
nlmeansなんかの縮むようなやつ使ってもcrf25で5Mbpsとかいくし、x264なんて8Mbps行くんだが
特に紀行番組や旅番組
2018/07/29(日) 15:34:59.15ID:wdaToWzEMNIKU
x264のcrfは24ね
2018/07/29(日) 15:48:29.94ID:MNacyzm00NIKU
そういうソースだから
2018/08/04(土) 04:01:41.74ID:OQuZqxL+0
HDでそこまで縮める必要があるのか
2018/08/07(火) 16:37:12.30ID:qrgN2wIh0
実写でnlmeansとか狂気を感じる
2018/08/07(火) 18:35:08.59ID:ckZCKShm0
Ryzen7 2700Xで--asm AVXの有無を比較してみた
x265_2.8+57,ソースは720x480で24000/1001pの5633frameなy4mを5回エンコした平均値

https://imgur.com/qEJ6sUs

HDだとまた傾向違うんやろかねぇ・・・
2018/08/07(火) 19:41:02.44ID:TiId8jg/M
そんなことよりスリッパ2だよ
2018/08/07(火) 20:13:00.92ID:ckZCKShm0
FHDのy4mをHDDから読み出すってのがボトルネックなので台風行ったらSSD買うか

>>227
んな金あるかいな・・・
2018/08/07(火) 20:42:55.08ID:58FOfn02a
一定期間スリッパ1とスリッパ2併売するみたいだから、スリッパ1に価格改定入れば…
2018/08/08(水) 18:12:29.32ID:g31F+e9100808
--asm AVXオプション使うと各コア均等に使うけど
使わないと偶数コアを優先的に使って結果ブーストが
効いているようにタスクマネージャからは見える


金があればスリッパ入れたいけど、2700xでも全コア使い切りってまずないんだよなぁ・・・
2018/08/08(水) 21:56:58.29ID:dOumIDyx00808
>>230
AVX2使ってると実行ユニットをロックする（非SMT状態になる）みたいな感じかな？
でも使うと遅くなってた頃もあるから
x265で最適化が入ったかAVX2のコードの効率性が上がったかのどちらかかな
2018/08/12(日) 00:10:58.10ID:aqFe3uD60
CPUのコア数が多いとどうしても余ってるコアが出てきちゃうから
ちゃんとした比較にならないんだよな

実際にエンコードするときは4〜6コア/exeくらいで並列でやるんだから、
ベンチマーク取るときもアフィニティ設定してコア数制限して測って欲しいわ
2018/08/12(日) 14:51:56.53ID:aNmboIWr0
8Kでも食わせればいいじゃん
2018/08/12(日) 17:23:20.03ID:+cgvO6cW0
まいうー
2018/08/14(火) 13:13:04.01ID:RAVBN7h8M
x265は、GPUによるエンコードの分担処理（※GPU内蔵のハードウェアエンコーダーは使わない）とかはできないんだよね？
1から10まで全部CPUでガリガリやるのではなく、部分的にGPUに任せる仕組みを導入してほしい
2018/08/14(火) 15:45:53.60ID:ozPr4VpNd
あえて脳筋動き探索アルゴリズムを採用して、GPGPUでゴリゴリ処理できないかのかね
237名無しさん＠編集中 (ﾜｯﾁｮｲ ff98-irNJ)
垢版 |
2018/08/14(火) 16:07:23.83ID:WtdvOqlK0
>>235
えーと
まぁ、いいや
2018/08/14(火) 17:17:04.26ID:rvDdFgo90
>>235
AMDが研究してたりしたんだけど
そのAMDの開発方針が変わったりで仕切り直しだと思う
2018/08/14(火) 17:28:15.41ID:Ias8+6vNx
x264やx265ならGPGPU移植出来そうだが、マイニングソフトとちがって報酬ないからなぁ
1080tiならRyzenThreadripperを軽く越えるぐらいのエンコ速度出そうだけど
2018/08/14(火) 17:43:04.22ID:ijxWFhcBa
gpgpuは木構造苦手みたいな話はもう解消されたの？
2018/08/14(火) 18:01:58.98ID:vtOGloibd
>>236 追記
ちょっと調べたら出てきた

https://www.researchgate.net/publication/268506361_Evaluating_modern_parallelization_techniques_on_block_matching_algorithms
2018/08/14(火) 21:42:46.76ID:5ruA6DB9M
x264は--openclってなかったっけ
2018/08/14(火) 21:46:46.31ID:5TbtNVQr0
>>235
x265のGPU版↓
https://bitbucket.org/vovagubin/x265-hevc-opencl-or-cuda-encoder/src/stable/
2018/08/15(水) 11:42:18.88ID:RPYkSQGg0
x264スレが落ちてるからこっちに書くけど、8/6にx264の更新(r2932？)があった模様。
主な内容としては、
　●i400(monochrome)エンコードのサポート （4:0:0 (monochrome) encoding support）
　●--avcintra-flavorの追加 （Add Sony XAVC, a flavour of AVC-Intra）
といったところかな。
2018/08/15(水) 22:12:56.23ID:tv8DRpSG0
x264スレが落ちるとか時代を感じる
2018/08/17(金) 23:58:02.69ID:LnVWCjgx0
>>240
別に1から10まで全部GPUにやらせようって話ではない


Intel「CPUで全部やる、AVXも512bitに拡張だ、まあ最適化したいならICC買ってね？」
AMD「CPU/GPUでリソース配分したほうが開発コストも演算コストも安くね？」

個人的にはAMDが正しいと思うけど、とはいえAVX2くらいは普通に実装してほしかったかなぁ・・・
2018/08/18(土) 00:30:16.42ID:A3Sygm0Ga
>>246
条件分岐だけcpuでやって並列単純処理だけgpuに回すなんて都合よくプログラムできるもんなの？
そのintelとamdの対比も意味がよくわからないんだけど
2018/08/18(土) 00:52:04.94ID:3rhQHUTk0
IntelやAMDがソフトウェアを実装するわけじゃないから、勝手なことをいくらでも言えるわな
AMDはGPUも使えって言うんだったらx265をGPU化してみろってんだよ
2018/08/18(土) 00:54:57.47ID:/edKj+Hi0
>>247
同じタスクをCPU1：GPU9みたいな具合に割り振るってだけだろ
2018/08/18(土) 01:17:41.12ID:A3Sygm0Ga
>>249
cpuとgpuで得意なタスクが違うのに同じタスクを割り振って意味あるのか？
2018/08/18(土) 01:26:43.79ID:9fCL5XG50
多用されてる離散コサイン変換はGPGPUで結構高速化出来るし
動きベクトル探索も良い研究成果が上がってきてるよね
開発環境整ってくれば期待できそう
2018/08/18(土) 10:12:54.04ID:pf+FKHdi0
>>250
意味ないね
で、CPUの処理の中からGPUに適した処理をアウトそーソングしやすくしよう！って考えたのがAMD（のブラフィックス内蔵SoC）
ところが規模の問題などから性能メリットが少なくその方針は下火になったけど
GPUへ自動で処理を投げるコンパイラは今も開発継続中（x265開発してる会社へ譲渡して、のはず）
2018/08/18(土) 10:38:39.75ID:meM6vY/0d
そもそもメモリ共有でないとオーバーヘッドが大き過ぎて思ったほど性能が出ないのよね
2018/08/18(土) 12:06:38.91ID:Eex2uJCGM
結論スレッドリッパーはゴミ
2018/08/24(金) 18:32:05.06ID:ehs1hyuL0
>>248
AMDがx265を正式にGPU対応化とかライセンスの問題で簡単にできないんじゃね？
2018/08/24(金) 19:03:44.23ID:ehs1hyuL0
個人デベロッパーがGPLでAMDでx265のGPU対応化とかさせるのならどうにでもできると思うけど
それと同じことを法人が勝手にやると最悪、つまらない訴訟騒ぎに発展するだろうな。
2018/08/24(金) 19:35:59.55ID:XoeRJrtA0
オープンソースなんだから法人でも個人でもできることは変わらないのでは
2018/08/24(金) 19:38:44.44ID:POsDmPVOa
オープンソースな事と改変配布が可能なのは別なんじゃないか
2018/08/24(金) 19:51:04.63ID:j6PGMWeXM
オープンソースとは、何をしてもいいということではない
つうか、そんなことをリーナス・ドーバルズ氏に言ったら、死ぬほど殴られるぞ
2018/08/24(金) 20:13:26.87ID:VrmpXpAnM
オープンソースなのはH.265の特許持ってる所から訴えられないようにするためじゃないの？
mp3のlameがそんな感じじゃなかった？
2018/08/24(金) 20:42:18.03ID:XoeRJrtA0
>>258
個人がセーフティーに（訴訟リスクなしで）やれる範囲内のことなら
企業も同じくできるでしょってこと
2018/08/25(土) 01:11:30.72ID:DovDn/Ya0
GPLは大雑把に言うと、「バイナリ配布したらソース公開は必須」ってライセンス
企業側から見た問題は（個人でも変わらんが）「ソース公開必須」って部分

元々公開する気なら何の問題もない
企業がコミットしてるオープンソースなんて世の中いっぱいあるし、
むしろ、まとまった機能は企業からコミットされることのほうが多い
x265だってメインの開発者はMulticoreWareって企業でしょ

HEVCのパテントについては、radeonには既にHEVCのエンコーダが乗ってるんだから、
AMDがradeonで動くHEVCのエンコーダをドライバと一緒に配布しても追加コストはあまりないはず

問題があるとすれば、公開されたGPU対応コードが他の企業によって移植されて
geforceでも動くようになってしまう確率が高いこと

実際はそれが問題だろうね
自社の製品が売れるようにならなくちゃ企業は動かない
2018/08/25(土) 01:41:52.75ID:DovDn/Ya0
あと、MulticoreWare以外の外部が開発したGPLの改変部分は、MulticoreWareが取り込むことはできないから、
オープンコミュニティでメンテする必要があるだろうね

MulticoreWareはx265の「ソースを公開する必要がないライセンス」も売ってるから、
他社が作ったGPLコードを取り込むと、それができなくなってしまう

個人の開発者も含めx265にコードを取り込んで欲しい場合は、
コードのライセンスを完全にMulticoreWareに譲渡する契約書を書かされるはず

オープンソースと言ってもいろいろある
2018/08/25(土) 13:20:10.27ID:5MBDxOvZ0
もう少し簡潔に推敲すれば？
265名無しさん＠編集中 (ﾜｯﾁｮｲ d998-Kyiw)
垢版 |
2018/08/25(土) 15:19:58.90ID:B/A2lGb50
俺の理解だと、学術研究目的なら著作権問題を回避できるからオープンソースでしか配布できない
オープンソースといえどもそのソースに著作権は発生してその形は様々
2018/08/27(月) 22:26:39.87ID:ECoRvFr4M
x264スレが落ちて放置されてるのは、もうH.264にエンコする需要がなくなってるからかね
まあ俺もH.264にはBDMV互換でしかエンコしないけどさ
2018/08/27(月) 22:45:13.94ID:UkDWU1xZ0
>>266
x264エンコのニーズは依然健在だろうけど、
5ちゃんねるのスレ建て＆20レス保守がクソめんどくさいだけじゃないかと
x264もx265もエンコパラメータ次第でどっちでもそれなりの画質を維持できるし
使いたい方を使えばいいと思うけど。ちゃっちゃとエンコを済ませるならx264が適当だろう。
2018/08/28(火) 01:09:35.25ID:V8FzL0Jv0
次スレから統合すればよいかと
分け続けるほどの話題もないし
2018/08/28(火) 01:18:26.66ID:npqNMEMi0
x264も軽くて綺麗だと思うが
時間かけてでも、ギチギチに高圧縮かける必要がある人って、ソースは放送なのか？自己撮影した素材なのか？
2018/08/28(火) 01:27:44.39ID:HZBqxdPN0
実写だとそんなに変わらないけど、アニメだとHEVCのほうが劇的にきれいだからね
エンコする素材にもよるんじゃない
2018/08/28(火) 01:27:44.93ID:d7OeQKlMa
海外の有料アダルトサイトのDLファイル
連中の上げるファイルのでかさたるや
2018/08/28(火) 10:21:03.53ID:mVsKTCut0
>>269
放送
45分ドラマ300~400MB程度が目標

xvid@480p q3.5 (2.5だったかな・・)
x264@720p crf23.5
x265@1080p crf26

こんな感じで進化してきた
2018/08/28(火) 11:42:07.42ID:OK6RUHGlM
>>272
45分ドラマ録画をエンコして400MBにするのか
へぇ
そしてBDとかにまとめ焼き？

基本的にはHDDに放送録画しても半分見ないで消すくらいだから、そうやってライブラリー残すために高圧縮でも綺麗という評価軸がなくなったよ

編集するのに、そこそこ軽くて扱うのが楽なCODECと設定だと、イントラ圧縮に落ち着く
XAVC-IもAVC-Intraも、イントラ内はH.264だと思ったけど違ったかな？
2018/08/28(火) 14:18:09.97ID:mVsKTCut0
>>273
普通にお外付けHDDに溜め込んでる

自分は見ずに消すことなまずないな
かと言ってすぐ見るわけじゃなく、ある程度、話数が溜ってから・・とts保持し続けたらHDD容量が足りない
だからエンコードするわけだけど、せっかくエンコードしたものを消すのは忍びないって感じで見終わっても残してる
2018/08/28(火) 14:19:04.25ID:mVsKTCut0
「お外付けHDD」と上品な感じになってるけど
ただの編集ミスです
2018/08/28(火) 14:24:26.40ID:pwjZprN2M
日本語が不自由すぎ
2018/08/28(火) 16:40:29.37ID:z9HPvOwX0
妙にお上品だな。
2018/08/29(水) 02:39:41.20ID:EeKVFGwZ0
>>274
いや、昔からテープやDVDやら録って残して来たんだけど
全部捨てた

NETFLIXやら加入してるし
必要な時に金払う
2018/08/29(水) 10:08:51.88ID:PTb4PESu0
>>278
「いや」って否定される覚えはないが・・
VHSでとってたものは目ぼしいものだけサルベージした

ま、金銭感覚は人それぞれだから私は否定しないが
年単位でのコスパでいえば大した違いはないと思う（PCの初期投資は除く
2018/08/29(水) 17:42:25.75ID:NUYlfpfS0NIKU
大昔にSVHSで購入した藻無しのVシネマとかはずっと残してるわ。
2018/08/29(水) 20:26:57.57ID:0PNBoQL7aNIKU
モザなしのVシネって何よ
2018/08/29(水) 20:29:03.71ID:NUYlfpfS0NIKU
詳しくは語らない。理由は察しろ。
2018/08/29(水) 20:31:34.31ID:qiStC0jQaNIKU
語らなくていいからうｐ
2018/08/29(水) 20:32:21.41ID:NUYlfpfS0NIKU
それこそアカンやろ。お縄にはなりたくないしなw
2018/08/29(水) 22:15:06.88ID:6JSKIv5S0NIKU
オナ輪になりたくないか・・・なるほど・・・
2018/08/30(木) 00:02:11.09ID:UmihVTzF0
なんか言うとるで…
2018/09/02(日) 19:33:44.42ID:DuBTtQDB0
::::::::::::/　　　　　　　　　　ヽ::::::::::::
:::::::::::i　　キ　　じ　　ミ　　i::::::::::::
:::::::::::.ゝ　モ 　 つ 　.ネ　 ﾉ:::::::::::
:::::::::::/　 イ　　に 　 オ　ｲ:::::::::::::
:::::　 |　　な。　　　　は　ﾞi　　::::::
　　　＼_ 　　　　　　　 ,,-'
――--､..,ヽ__　　＿,,-''
:::::::,-‐､,‐､ヽ.　)ノ　　　　　　＿＿＿＿
:::::_|/ ｡|｡ヽ|-i､　　..　　　 ／ 淫厨
／. ` ' ● '　ﾆ ､　　　　（＿＿＿＿人
ニ　＿_ｌ＿_＿ノ　　　　（-◎-◎一
/￣　＿　　| i　　　　　（　(_　_)
|(￣`'　　）/ /　,..　　　 （　ε　 　（∴
`ー---―' / '（__ ）　　　ヽ＿＿＿＿
====（ i）==::::／　　　　　　,/ﾆ
:/ 　　 　ヽ:::i　　　　　　　/;;;;;;;;;;;;;;;;
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況