X
x265 rev4
■ このスレッドは過去ログ倉庫に格納されています
0025名無しさん＠編集中 (ﾜｯﾁｮｲ 27ec-3a+g)
垢版 |
2017/11/25(土) 19:05:02.89ID:wxxEbk1K0
H.265/HEVCのコマンドラインエンコーダーであるx265について語るスレです。
AviUtlやx265guiExなどの話はスレ違いなのでそれぞれの専用スレへどうぞ。

[本家]
http://x265.org
https://bitbucket.org/multicoreware/x265/wiki/Home

[ソース]
https://bitbucket.org/multicoreware/x265/src
https://github.com/videolan/x265

[ドキュメント]
http://x265.readthedocs.org/en/default/index.html

[バイナリ]
http://rigaya34589.blog135.fc2.com (右側のメニューの"ビルドしたものとか")

[ビルド方法(MSVC)]
http://rigaya34589.blog135.fc2.com/?q=x265+ビルド

[諸注意]
x265のrevはMercurial(Bitbuket)とGit(Github)では算出方法が違います。
当スレではMercurial準拠で示すようにして下さい。
次スレは>>980が建てること。

[前スレ]
x265 rev3
http://mevius.2ch.net/test/read.cgi/avi/1462270195/
0026名無しさん＠編集中 (ﾜｯﾁｮｲ 27ec-3a+g)
垢版 |
2017/11/25(土) 19:06:25.65ID:wxxEbk1K0
[関連スレ]

・x265 HEVC Encoder (Doom9)
https://forum.doom9.org/showthread.php?t=168814

・H265/HEVC全般の話はこちらへ
【2016】 H.265/HEVC Part7 【7680x4320】
http://mevius.2ch.net/test/read.cgi/avi/1485191956/

・AviUtlの出力プラグインであるx265guiExについての話題はこちらへ
AviUtl総合スレッド86
http://egg.2ch.net/test/read.cgi/software/1500105624/
0032名無しさん＠編集中 (ﾆｸｸｴ 7f06-poFb)
垢版 |
2017/11/29(水) 14:17:10.24ID:PQuyMEHN0NIKU
Version 2.6
Release date - 29th November, 2017.

New features
1. x265 can now refine analysis from a previous HEVC encode (using options --refine-inter, and --refine-intra), or a previous AVC encode (using option --refine-mv-type).
　　The previous encode’s information can be packaged using the x265_analysis_data_t data field available in the x265_picture object.
2. Basic support for segmented (or chunked) encoding added with --vbv-end that can specify the status of CPB at the end of a segment.
　　String this together with --vbv-init to encode a title as chunks while maintaining VBV compliance!
3. --force-flush can be used to trigger a premature flush of the encoder.
　　This option is beneficial when input is known to be bursty, and may be at a rate slower than the encoder.
4. Experimental feature --lowpass-dct that uses truncated DCT for transformation.
0034名無しさん＠編集中 (ﾜｯﾁｮｲ b623-w4Uq)
垢版 |
2017/11/30(木) 18:02:19.23ID:iTtzk9/60
dllが認識しねえ
0035名無しさん＠編集中 (ﾜｯﾁｮｲ 7dec-XOTX)
垢版 |
2017/12/03(日) 11:18:37.48ID:TnTebv4Q0
AviUtlスレで報告があったんで試してみたんだけど、rigaya氏版の2.6+8はビルドがうまくいっていない模様。
うちだと2.5+3で3.8fps出てた--preset slowが、2.6+8だと0.6fpsしか出ない。
今朝がた2.6+8のバイナリが差し変わったようなんでそちらも試したんだけど、ダメっぽい。

--versionを見ると[noasm]になってるし、Doom9を見るとyasmからnasmに変わったみたいなことが
書いてるから、その影響なのかな？

x265 [info]: HEVC encoder version 2.6+8-fc0570b8d8f9
x265 [info]: build info [Windows][MSVC 1911][64 bit][noasm] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: none!
0044名無しさん＠編集中 (ﾜｯﾁｮｲ 6f11-buzn)
垢版 |
2017/12/26(火) 18:53:48.91ID:STljgCt10
ビットレート当たりの画質がかなり上がってるのね
ver2に上がるかどうかのころはcrf22ないと劣化が分かったけど
今はcrf24で目に見える劣化無しでエンコードできるようになってる
あくまで低ビットレート時の話だけど
0045名無しさん＠編集中 (ﾜｯﾁｮｲ f3e9-RBuR)
垢版 |
2017/12/27(水) 13:58:34.76ID:/ZZrfSta0
2018年後半に4K放送対応レコーダーを発売することが決まり、H.265のエンコード・でコードもサポートされるようになるみたいだが、
現段階でx265にて作成できるH.265ファイルはレコーダーやプレーヤーなどとの互換性は取れているのだろうか？
x264が出てもしばらくの間、プレーヤーなどとの互換性、インターレース信号の取り扱い等、結構長く問題を引きずっていたような記憶があるのだが。
0047名無しさん＠編集中 (ﾜｯﾁｮｲ 6f11-buzn)
垢版 |
2017/12/27(水) 21:12:17.50ID:Ecy8Wi210
x264の頃はメディアプレイヤーの存在自体が小さかったし
ソフトウェアのほうもメディアプレイヤーを前提とした作りしてなかったから問題となったけど
今のx265はオプションにさえ気を付けたらだいじょうぶじゃね
0049名無しさん＠編集中 (ﾜｯﾁｮｲ 67fa-MiNv)
垢版 |
2017/12/31(日) 11:43:53.69ID:90rtTOjH0
誰でも自分ＰＣで稼げる方法など
参考までに、
⇒　『政道のゴウイウセレイイ』 というＨＰで見ることができます。

グーグルで検索⇒『政道のゴウイウセレイイ』

8RNNMQEE3I
005044 (ﾜｯﾁｮｲ c611-Auke)
垢版 |
2017/12/31(日) 14:00:18.29ID:yaotpISH0
ちなみにオプションの--rectと--limited-ref（preset slowで有効になるやつ）は
他オプションを犠牲にしてでも使わないと
あんまりパッとしない感じだった
0051名無しさん＠編集中 (ﾜｯﾁｮｲ cbec-O50F)
垢版 |
2017/12/31(日) 14:32:32.59ID:dk79hbO30
>>50
--limited-refなんてオプションは無いし、--limit-refsのことならmediumもslowも値は3で差がない。
slowで有効になるオプションで似た名前のものだとしたら、--limit-modesじゃないの。
0055名無しさん＠編集中 (ﾜｯﾁｮｲ 15ec-wNYY)
垢版 |
2018/01/18(木) 03:19:00.26ID:COlz2Rab0
　
https://forum.doom9.org/showthread.php?p=1830632#post1830632
---
x265_Project

Hi everyone.
I've been the head of the x265 project and the head of MulticoreWare's video business from the start.
But I need to let you know that I've decided to move on, joining Beamr as VP Strategy.
x265 has a strong team, and it's in good hands.
I'll hand this Doom9 account over to someone on the MulticoreWare team.

Tom
---
0056名無しさん＠編集中 (ﾜｯﾁｮｲ 15ec-wNYY)
垢版 |
2018/01/18(木) 03:22:02.90ID:COlz2Rab0
えーと・・・？

>>55は、x265プロジェクトのトップで、当初からMulticoreWareのビデオビジネスのトップだった
Tomさんという人（Tom Vaughanさん？ http://x265.org/author/tom/ ）が、
ライバル社の Beamr ( https://beamr.com ) に転職するってことかな・・・？

去年の9月には
　Beamr compares their HEVC encoder to x265 - x265
　http://x265.org/beamr-hevc-encoder-comparison/
という記事も書いてたんだが・・・。

VPってのがいまいちわからんのだけど、joining Beamr as VP Strategyってどう訳せばいいんだろ？
「戦略担当のVice PresidentとしてBeamrに参加」であってる？

Doom9で使ってたx265_ProjectというアカウントはMulticoreWareチームに移譲するとあるし、
開発体制とかよく知らないんだけど、Tomさんが抜けることでx265にどれくらいの影響が出るんだろう？

結構でかい話だよねこれ？
0058名無しさん＠編集中 (ﾜｯﾁｮｲ 15ec-wNYY)
垢版 |
2018/01/18(木) 03:44:10.05ID:COlz2Rab0
●Tom Vaughan @tmvn

https://twitter.com/tmvn/status/953383728536940544
I'm pleased to announce that I've decided to join Beamr as VP Strategy!
Beamr has an incredible team, and industry-leading video software products.
No company is better positioned to provide efficient, high performance video compression solutions.

●Mark Donnigan @mdonnigan ←Beamrの人

https://twitter.com/mdonnigan/status/953364887131996160
2018 is blasting off in every vector at Beamr.
We will make several industry shaking announcements at #IBC2018 & #NAB2018,
perfectly timed to meet NFV and virtualization Initiatives that are in full swing.
Also, pleased to welcome Tom Vaughan as VP, Video…https://lnkd.in/gHsGS7e

https://twitter.com/mdonnigan/status/953462509217841152
Welcome to the Beamr team Tom Vaughan!
0061名無しさん＠編集中 (ﾜｯﾁｮｲ 15ec-wNYY)
垢版 |
2018/01/20(土) 17:49:24.71ID:XIH6s3g30
>>60
2.6以降ってことなら追加・変更は下の４つくらいかなあ。
　・--fullhelp
　・--gop-lookahead
　・--radl
　・--analysis-reuse-mode が消されて --analysis-save と --analysis-load に。
0064名無しさん＠編集中 (ﾜｯﾁｮｲ ffed-qi38)
垢版 |
2018/02/15(木) 19:09:13.07ID:kjnv49rj0
メディアプレイヤーとして大正義のPSがPS4proでも再生に対応してないのがだめだな
GPUが対応してるproだけでもとっととやるべき、ソフト再生でPS3まで対応してくれたら神なんだけどなぁ
0065名無しさん＠編集中 (ﾜｯﾁｮｲ f7e0-T3WU)
垢版 |
2018/02/16(金) 19:42:17.97ID:Ohttwh5c0
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
0070名無しさん＠編集中 (ﾜｯﾁｮｲ ecec-je3A)
垢版 |
2018/02/23(金) 21:05:02.63ID:pufaCppw0
http://x265.readthedocs.io/en/stable/releasenotes.html#version-2-7

Version 2.7
Release date - 21st Feb, 2018.

New features
1. --gop-lookahead can be used to extend the gop boundary(set by ?keyint). The GOP will be extended, if a scene-cut frame is found within this many number of frames.
2. Support for RADL pictures added in x265. --radl can be used to decide number of RADL pictures preceding the IDR picture.

Encoder enhancements
1. Moved from YASM to NASM assembler. Supports NASM assembler version 2.13 and greater.
2. Enable analysis save and load in a single run. Introduces two new cli options ?analysis-save <filename> and ?analysis-load <filename>.
3. Comply to HDR10+ LLC specification.
4. Reduced x265 build time by more than 50% by re-factoring ipfilter.asm.

Bug fixes
省略
0073名無しさん＠編集中 (ﾜｯﾁｮｲ ecec-je3A)
垢版 |
2018/02/24(土) 00:09:46.21ID:IJ/q997/0
●Tom Vaughan
　x265プロジェクトの元リーダー。
　>>55-59にあるように、2018年1月中旬にライバル社のBeamrに移籍した。

●Pradeep Ramachandran
　最近のバージョンのタグ付けをしたり、Doom9やx265ブログでリリース記事を書いていた人。
　x265ブログでTom Vaughan氏が書いていた過去記事も、今はこの人の名義に変わっている。
　この人がプロジェクトリーダーを引きついだのだろうか？

●Ashok Kumar Mishra
　2.7のタグ付けをした人クマー。
　新たなリリース担当なんだろうか？
　
　
現時点ではDoom9にもx265ブログにもリリースアナウンスは来てないね。
0084名無しさん＠編集中 (ﾜｯﾁｮｲ 5b11-N5B0)
垢版 |
2018/03/08(木) 14:50:23.01ID:WnQT6+5V0
あ、やっぱり？
バッチ実行がやけに停滞してるなとは思ってた
doom9では話題になってないからrigaya氏のビルドミスかな
0086名無しさん＠編集中 (ﾜｯﾁｮｲ cfec-Osi7)
垢版 |
2018/03/08(木) 16:11:42.24ID:wHUMYfkz0
【バイナリの入手元】 rigaya氏
【バージョンとx64/x86】 x265_2.6+49_x64
【コマンドオプション】 --preset slow/medium/veryfast --crf 18

これくらいの情報はちゃんと書いてほしいもんだよな・・・。
少なくとも上の条件では特に遅くなったりはしてないよ。
0087sage (ﾜｯﾁｮｲ 5b11-N5B0)
垢版 |
2018/03/08(木) 17:21:53.79ID:WnQT6+5V0
すんまそん
エンコード中だったから差し替えての実験は後じゃ後、と思って細かい情報を調べずに書いちゃった
さらに数日前に差し替えたから2.7かと・・
0092名無しさん＠編集中 (ﾜｯﾁｮｲ 0b68-eXi2)
垢版 |
2018/03/11(日) 03:28:34.13ID:KKe7Ux5L0
ビルドされたバイナリが来てるかチェックするくらいならソースのコミット状況みて
自前でビルドしたほうがはええだろｗｗ
「きてるな」なんていうくらいだから文句こそ言わないにしろ無駄にチェックしてる時間があったんだろ?
0093名無しさん＠編集中 (ﾜｯﾁｮｲ 6a7f-hn8E)
垢版 |
2018/03/11(日) 03:52:49.72ID:xNuwG3/a0
有名な公開されてるビルドがでた方が、みんな試すから不具合やら傾向やらわかるじゃん
そうしてから新しいバージョンを使っても遅くはない
そういう意味で、待つ意味はあると思うし、出てることを言って、試させようと思っただけ

そんな噛みつかれることなのか？
どしてほしいの、無能だからビルド出来ないとか言って欲しいの？
0094名無しさん＠編集中 (ﾜｯﾁｮｲWW 6af7-WxpO)
垢版 |
2018/03/11(日) 04:00:12.62ID:+k5ziIx80
ビルドしてくれ、ならともかくきてるな程度でここまで噛みつくの面倒くさすぎでは
専門板ってなんでこんなにコミュニケーション取るの大変な人多いんだろ
0097名無しさん＠編集中 (ﾜｯﾁｮｲ bbec-Osi7)
垢版 |
2018/03/11(日) 11:44:38.24ID:SslWpV+I0
ビルド環境作るの地味に面倒だし、常にコミットについていく必要もないし、
配布バイナリで済ませてる人の方が多いんじゃね。

>>93
俺としては>>89の書き込みは更新を知ることができて助かったよ。ありがとう。変なのはほっとけ。
0101名無しさん＠編集中 (ﾜｯﾁｮｲ 2b11-hKdO)
垢版 |
2018/03/16(金) 20:53:41.13ID:bn2kqBbr0
結果は誤差でした
aviutl経由（でのafsでテレシネ解除）でのエンコードだから
x265自体の性能テストとしては使えないけど


_x265-vs2017
yuv [info]: 1440x1080 fps 30000/1001 i420p8 unknown frame count
x265 [info]: HEVC encoder version 2.7+14-d7c26df32fae
x265 [info]: build info [Windows][MSVC 1913][64 bit] 8bit+10bit

encoded 8993 frames in 320.66s (28.05 fps), 640.58 kb/s, Avg QP:32.63
auo [info]: x265エンコード時間 : 0時間 5分20.8秒
-
_x265-vs2015
yuv [info]: 1440x1080 fps 30000/1001 i420p8 unknown frame count
x265 [info]: HEVC encoder version 2.7+14-d7c26df32fae
x265 [info]: build info [Windows][MSVC 1900][64 bit] 8bit+10bit+12bit

encoded 8993 frames in 321.85s (27.94 fps), 640.58 kb/s, Avg QP:32.63
auo [info]: x265エンコード時間 : 0時間 5分21.9秒
0104名無しさん＠編集中 (ﾜｯﾁｮｲ 9aec-h0dl)
垢版 |
2018/03/26(月) 01:10:10.16ID:xaZyoL940
rigaya氏のブログの「x265ビルド VC2017版」の記事に、

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

というコメントがあった。試してみたら、うちでも再現した。
2.7+14なら大丈夫らしいが、どちらが原因かはっきりするまで様子を見た方がよいかも。
0105名無しさん＠編集中 (ﾜｯﾁｮｲ 03ec-h0dl)
垢版 |
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が固まる。たまにクラッシュすることもある。
0107名無しさん＠編集中 (ﾜｯﾁｮｲ 37ec-h0dl)
垢版 |
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側のバグなのか。

自分はコードやストリームの解析まではできないので、作者や詳しい人の参戦を祈ることしかできぬ・・・。
0108名無しさん＠編集中 (ﾜｯﾁｮｲ 37ec-h0dl)
垢版 |
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のみ。
0111名無しさん＠編集中 (ﾜｯﾁｮｲ 9716-zkh5)
垢版 |
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 使うタイプなんでそのせいかな。
0112名無しさん＠編集中 (ﾜｯﾁｮｲ 03ec-h0dl)
垢版 |
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
0115名無しさん＠編集中 (ﾜｯﾁｮｲ 63ec-h0dl)
垢版 |
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
【画像】
0124名無しさん＠編集中 (ﾜｯﾁｮｲ caec-vJpg)
垢版 |
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%のスピードアップに成功したよという発表。
0125名無しさん＠編集中 (ﾜｯﾁｮｲ caec-vJpg)
垢版 |
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拡大のため業界のエキスパートに声をかけている。
0134名無しさん＠編集中 (ﾜｯﾁｮｲ 23ec-ycE0)
垢版 |
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/
0138名無しさん＠編集中 (ﾜｯﾁｮｲ a3ec-ycE0)
垢版 |
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で計測したほうがよさそうだ。
0139名無しさん＠編集中 (ﾜｯﾁｮｲ ffec-ycE0)
垢版 |
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を使ったということなんだろか？
（ビルドに詳しいわけじゃないので、ちょっと気になっただけ。変なこと言ってたらすまぬ。）
0140名無しさん＠編集中 (ﾜｯﾁｮｲ 73ec-ycE0)
垢版 |
2018/04/15(日) 02:04:37.98ID:3zo9kCKG0
rigaya氏の2.7+336のバイナリが最適化されたものに更新された模様。

> 2018/4/14 19:43にx265 2.7+336をここで紹介するgccで
> プロファイルによる最適化を実施した実行ファイルに差し替えました。
0142名無しさん＠編集中 (ﾜｯﾁｮｲ 7f16-ycE0)
垢版 |
2018/04/18(水) 15:36:59.22ID:YRWrQNWv0
ちょっと質問。
2.7+336-07defe235cde で --asm avx 付けてるとエラーで速攻落ちちゃうんだけどこれおま環?
ログみると「障害が発生しているモジュール名: ucrtbase.dll」とかでちょる。
--asm avx を外せばエンコできたけど Ryzen なんでどうしたもんかなと。
0144名無しさん＠編集中 (ﾜｯﾁｮｲ 73ec-ycE0)
垢版 |
2018/04/18(水) 17:18:59.94ID:HTI1sHZw0
うちのHaswellもrigaya氏の差し替え版バイナリで特に問題ないな。
ちゃんとコマンド書いてないからコマンド依存で発生する事象ならわからんが。
どういうソースをどこのバイナリでどういう設定で実行したのかくらいは書いた方がいいと思う。
0145名無しさん＠編集中 (ﾜｯﾁｮｲ 7f16-ycE0)
垢版 |
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 何れかを入れ込むとエラー落ちするぽいです。
他の人が問題無いなら当方の おま環 ということですね。
0147名無しさん＠編集中 (ﾜｯﾁｮｲ 7f16-ycE0)
垢版 |
2018/04/18(水) 18:15:27.44ID:YRWrQNWv0
試しに rigaya 氏ビルドの物に差し替えたら --asm avx を入れてもエラーが出ずにエンコできますた・・・
自分の単純なビルド方法で今までこう言った問題は起きたこと無かったんで咄嗟に書き込んでなんだか申し訳なくorz 失礼しました!
0148名無しさん＠編集中 (ｽｯﾌﾟ Sd5a-Jb0y)
垢版 |
2018/04/19(木) 12:02:15.65ID:CAIRBG+rd
>>145
VSでビルドすると壊れる問題は、今の所stableブランチにだけ、修正が入ってる。

stable持ってきてビルドすれば動くよ。
まぁ、そのうちdefaultにも入るだろうけど。
0154名無しさん＠編集中 (ﾜｯﾁｮｲ 57ec-9jjH)
垢版 |
2018/04/20(金) 17:32:44.04ID:PbP8t3sj0
「なんとなく速くなってると思いました。まる。」みたいなこと書かれても・・・。
必要なのは環境やバイナリのバージョンや設定やソース等の情報も含めた正確な比較条件だと思うよ。
0156名無しさん＠編集中 (ﾜｯﾁｮｲ 8311-9jjH)
垢版 |
2018/04/20(金) 18:47:30.17ID:+I7QsHZu0
別に伝わらなくていいと思ってる（ryzenに興味あって調べてるならベンチスレででも覗けばいいだけ）
カキコした私が誤差程度と判断したから情報としてまとめなかったけども
0158名無しさん＠編集中 (ﾜｯﾁｮｲW fae0-ZOBi)
垢版 |
2018/04/20(金) 20:18:13.59ID:5wKx8vum0
来年24コアryzen2TPが出たとしてx265の特に重いプリセットでは全然使い切れないだろうなぁ
0159名無しさん＠編集中 (ﾜｯﾁｮｲ b67f-GiJP)
垢版 |
2018/04/23(月) 11:28:44.66ID:BRPMKJ720
先週IntelからRyzenに変更したのですがエンコする際に--asm AVXをつけろ　とネットでみたのですが
その理由がわかりませんでした
これはどういう意味があるんでしょうか？
また実際につけた方がよいものなのでしょうか？
0160名無しさん＠編集中 (ﾜｯﾁｮｲ 4b16-9jjH)
垢版 |
2018/04/23(月) 12:19:03.19ID:p76LCKVz0
AVX2 を使うと逆にエンコード速度が落ちるからだよ〜
AVX までに制限してやることで数 fps ほど速度あがる。
実際に --asm avx の有無でエンコ比較してみると良いかも。
0163名無しさん＠編集中 (ﾜｯﾁｮｲ b7b5-9jjH)
垢版 |
2018/04/23(月) 15:47:10.80ID:QffvhQ240
AVX2必須、みたいなアプリもあったりするかも知れんし機能があるに越したことはないとは思う
x264やx265でAVX2使うと若干とはいえ遅くなりはするけど動作しないわけでもないし知識があれば回避できるわけだしな
0166名無しさん＠編集中 (ﾜｯﾁｮｲ 93d2-2tE1)
垢版 |
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
0173名無しさん＠編集中 (ﾜｯﾁｮｲ e111-Bw3Y)
垢版 |
2018/06/19(火) 18:25:04.97ID:uDXUEk/b0
やっぱり画質が良くなるオプションは重いのね
いつもなら終わってた量のタスクが終わってなかったは

それはそうと新AQモードの実装はまだかな
画質あがって早くなったら嬉しいんだけども
0180名無しさん＠編集中 (ﾜｯﾁｮｲ 4711-UVFs)
垢版 |
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
0184名無しさん＠編集中 (ﾜｯﾁｮｲ e716-UVFs)
垢版 |
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 を使った方が微妙に速くなるかもしれん。
0185名無しさん＠編集中 (ﾜｯﾁｮｲ e716-UVFs)
垢版 |
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 を削れそうですわ
0188名無しさん＠編集中 (ﾜｯﾁｮｲ 4711-UVFs)
垢版 |
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
0189名無しさん＠編集中 (ﾜｯﾁｮｲ 67ec-UVFs)
垢版 |
2018/07/08(日) 14:21:18.43ID:HkL359170
>>187
なんで笑ってんのかよくわからんけど、データを出すなら普通にあったほうがいい情報だと思うけどね。
言及し忘れたけど、オプション設定も書かれてないので、そういった情報もあればいいなあとは思う。
0190名無しさん＠編集中 (ﾜｯﾁｮｲ e716-UVFs)
垢版 |
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 使わないままだったと思うしｗ
0199名無しさん＠編集中 (ﾜｯﾁｮｲ 5d11-LQig)
垢版 |
2018/07/13(金) 20:09:01.25ID:phGGD7kZ0
low-bitrate帯でボケる？ それとも割り当てられるbitrateが少なくなるからボケるのどっち？

crf26でmax-merge 5だとボケた感じになった覚えはあるんだけど
0201名無しさん＠編集中 (ﾜｯﾁｮｲ 5d11-LQig)
垢版 |
2018/07/14(土) 22:41:08.93ID:YCb4PdI30
高ビットレートだとボケないのかな？っていうことを聞きたかったんだけど、そこまでは読み取れない？
上から目線であれだけど、英文の記号の使い方とかよー分らん
0203名無しさん＠編集中 (ｱｳｱｳｳｰ Sa21-0235)
垢版 |
2018/07/15(日) 14:13:15.85ID:jCJzclqYa
ビットレートに余裕があるときにどんな動きをするか聞きたいんじゃない
問答無用でマージしてビットレート下げに行くのか、余裕があるなら働かないのか
0209名無しさん＠編集中 (ﾜｯﾁｮｲ 52d4-53i4)
垢版 |
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でのビットレートとして使えますか？
0212名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MM6e-0lTB)
垢版 |
2018/07/29(日) 09:00:12.20ID:WkF14PaEM
x264は動画版lame(mp3高性能エンコーダー)みたく規格上のギリギリで高効率に圧縮してるからなぁ
x264はほぼ完成してるけどx265はまだ発展途上だからまだ半分は行けないよな
0213名無しさん＠編集中 (ﾜｯﾁｮｲ 7f11-53i4)
垢版 |
2018/07/29(日) 09:41:12.17ID:p8xSZ0wf0
>>209
real playerのころとは比べ物にならないぐらい圧縮率は向上してるから半分ぐらいでちょうどいいと思うけど
どのみちビットレート指定方式では仕組み的に高画質は無理（6Mbpsぐらいつぎ込めば話は別だけど
ま、基本的にcrfモードを使うのが推奨された使い方

x264なら crf=22~23、x265なら crf=24~26 がビットレートと画質のバランスがいい
0216名無しさん＠編集中 (ﾆｸｸｴ 52d4-53i4)
垢版 |
2018/07/29(日) 13:46:57.15ID:ofEesbc00NIKU
Shift+Enterしてしまったごめんなさい

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

詳しい方いましたら教えてください。
0220名無しさん＠編集中 (ﾆｸｸｴ MM43-Dn8R)
垢版 |
2018/07/29(日) 14:40:29.28ID:nivXCK+nMNIKU
最大ビットレートなんて、再生環境が使える上限値にしとくだけだよ
これ以上にすると再生できなくなるから超えないようにエンコードしなさいという値なのだから
2倍とか関係ない
0221名無しさん＠編集中 (ﾆｸｸｴ MM33-0lTB)
垢版 |
2018/07/29(日) 15:27:57.92ID:wdaToWzEMNIKU
例えば地デジtsなら上限10Mbpsで十分だな
てか何故かテレビ放送の実写はcrfの割に縮まないのは何故？
nlmeansなんかの縮むようなやつ使ってもcrf25で5Mbpsとかいくし、x264なんて8Mbps行くんだが
特に紀行番組や旅番組
0230名無しさん＠編集中 (ﾌﾟﾁﾌﾟﾁ ffeb-avOC)
垢版 |
2018/08/08(水) 18:12:29.32ID:g31F+e9100808
--asm AVXオプション使うと各コア均等に使うけど
使わないと偶数コアを優先的に使って結果ブーストが
効いているようにタスクマネージャからは見える


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

実際にエンコードするときは4〜6コア/exeくらいで並列でやるんだから、
ベンチマーク取るときもアフィニティ設定してコア数制限して測って欲しいわ
0235名無しさん＠編集中 (ｱｳｰｲﾓ MM2f-E5g5)
垢版 |
2018/08/14(火) 13:13:04.01ID:RAVBN7h8M
x265は、GPUによるエンコードの分担処理（※GPU内蔵のハードウェアエンコーダーは使わない）とかはできないんだよね？
1から10まで全部CPUでガリガリやるのではなく、部分的にGPUに任せる仕組みを導入してほしい
0237名無しさん＠編集中 (ﾜｯﾁｮｲ ff98-irNJ)
垢版 |
2018/08/14(火) 16:07:23.83ID:WtdvOqlK0
>>235
えーと
まぁ、いいや
0239名無しさん＠編集中 (ｱｰｸｾｰ Sx03-NQOt)
垢版 |
2018/08/14(火) 17:28:15.41ID:Ias8+6vNx
x264やx265ならGPGPU移植出来そうだが、マイニングソフトとちがって報酬ないからなぁ
1080tiならRyzenThreadripperを軽く越えるぐらいのエンコ速度出そうだけど
0244名無しさん＠編集中 (ﾜｯﾁｮｲ 9fec-2km2)
垢版 |
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）
といったところかな。
0246名無しさん＠編集中 (ﾜｯﾁｮｲ 9feb-WJ3a)
垢版 |
2018/08/17(金) 23:58:02.69ID:LnVWCjgx0
>>240
別に1から10まで全部GPUにやらせようって話ではない


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

個人的にはAMDが正しいと思うけど、とはいえAVX2くらいは普通に実装してほしかったかなぁ・・・
0248名無しさん＠編集中 (ﾜｯﾁｮｲ 3bc3-ipLS)
垢版 |
2018/08/18(土) 00:52:04.94ID:3rhQHUTk0
IntelやAMDがソフトウェアを実装するわけじゃないから、勝手なことをいくらでも言えるわな
AMDはGPUも使えって言うんだったらx265をGPU化してみろってんだよ
0251名無しさん＠編集中 (ﾜｯﾁｮｲWW cb1b-0Gel)
垢版 |
2018/08/18(土) 01:26:43.79ID:9fCL5XG50
多用されてる離散コサイン変換はGPGPUで結構高速化出来るし
動きベクトル探索も良い研究成果が上がってきてるよね
開発環境整ってくれば期待できそう
0252名無しさん＠編集中 (ﾜｯﾁｮｲ 8b11-ipLS)
垢版 |
2018/08/18(土) 10:12:54.04ID:pf+FKHdi0
>>250
意味ないね
で、CPUの処理の中からGPUに適した処理をアウトそーソングしやすくしよう！って考えたのがAMD（のブラフィックス内蔵SoC）
ところが規模の問題などから性能メリットが少なくその方針は下火になったけど
GPUへ自動で処理を投げるコンパイラは今も開発継続中（x265開発してる会社へ譲渡して、のはず）
0256名無しさん＠編集中 (ﾜｯﾁｮｲ 4a60-4tvA)
垢版 |
2018/08/24(金) 19:03:44.23ID:ehs1hyuL0
個人デベロッパーがGPLでAMDでx265のGPU対応化とかさせるのならどうにでもできると思うけど
それと同じことを法人が勝手にやると最悪、つまらない訴訟騒ぎに発展するだろうな。
0262名無しさん＠編集中 (ﾜｯﾁｮｲ 29c3-PcWx)
垢版 |
2018/08/25(土) 01:11:30.72ID:DovDn/Ya0
GPLは大雑把に言うと、「バイナリ配布したらソース公開は必須」ってライセンス
企業側から見た問題は（個人でも変わらんが）「ソース公開必須」って部分

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

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

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

実際はそれが問題だろうね
自社の製品が売れるようにならなくちゃ企業は動かない
0263名無しさん＠編集中 (ﾜｯﾁｮｲ 29c3-PcWx)
垢版 |
2018/08/25(土) 01:41:52.75ID:DovDn/Ya0
あと、MulticoreWare以外の外部が開発したGPLの改変部分は、MulticoreWareが取り込むことはできないから、
オープンコミュニティでメンテする必要があるだろうね

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

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

オープンソースと言ってもいろいろある
0265名無しさん＠編集中 (ﾜｯﾁｮｲ d998-Kyiw)
垢版 |
2018/08/25(土) 15:19:58.90ID:B/A2lGb50
俺の理解だと、学術研究目的なら著作権問題を回避できるからオープンソースでしか配布できない
オープンソースといえどもそのソースに著作権は発生してその形は様々
0267名無しさん＠編集中 (ﾜｯﾁｮｲ 4a60-4tvA)
垢版 |
2018/08/27(月) 22:45:13.94ID:UkDWU1xZ0
>>266
x264エンコのニーズは依然健在だろうけど、
5ちゃんねるのスレ建て＆20レス保守がクソめんどくさいだけじゃないかと
x264もx265もエンコパラメータ次第でどっちでもそれなりの画質を維持できるし
使いたい方を使えばいいと思うけど。ちゃっちゃとエンコを済ませるならx264が適当だろう。
0273名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MM35-gOc9)
垢版 |
2018/08/28(火) 11:42:07.42ID:OK6RUHGlM
>>272
45分ドラマ録画をエンコして400MBにするのか
へぇ
そしてBDとかにまとめ焼き？

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

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

自分は見ずに消すことなまずないな
かと言ってすぐ見るわけじゃなく、ある程度、話数が溜ってから・・とts保持し続けたらHDD容量が足りない
だからエンコードするわけだけど、せっかくエンコードしたものを消すのは忍びないって感じで見終わっても残してる
0279名無しさん＠編集中 (ﾜｯﾁｮｲ 6a11-PcWx)
垢版 |
2018/08/29(水) 10:08:51.88ID:PTb4PESu0
>>278
「いや」って否定される覚えはないが・・
VHSでとってたものは目ぼしいものだけサルベージした

ま、金銭感覚は人それぞれだから私は否定しないが
年単位でのコスパでいえば大した違いはないと思う（PCの初期投資は除く
0287名無しさん＠編集中 (ﾜｯﾁｮｲ 8bdc-P9Fo)
垢版 |
2018/09/02(日) 19:33:44.42ID:DuBTtQDB0
::::::::::::/　　　　　　　　　　ヽ::::::::::::
:::::::::::i　　キ　　じ　　ミ　　i::::::::::::
:::::::::::.ゝ　モ 　 つ 　.ネ　 ﾉ:::::::::::
:::::::::::/　 イ　　に 　 オ　ｲ:::::::::::::
:::::　 |　　な。　　　　は　ﾞi　　::::::
　　　＼_ 　　　　　　　 ,,-'
――--､..,ヽ__　　＿,,-''
:::::::,-‐､,‐､ヽ.　)ノ　　　　　　＿＿＿＿
:::::_|/ ｡|｡ヽ|-i､　　..　　　 ／ 淫厨
／. ` ' ● '　ﾆ ､　　　　（＿＿＿＿人
ニ　＿_ｌ＿_＿ノ　　　　（-◎-◎一
/￣　＿　　| i　　　　　（　(_　_)
|(￣`'　　）/ /　,..　　　 （　ε　 　（∴
`ー---―' / '（__ ）　　　ヽ＿＿＿＿
====（ i）==::::／　　　　　　,/ﾆ
:/ 　　 　ヽ:::i　　　　　　　/;;;;;;;;;;;;;;;;
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況