【2016】 H.265/HEVC Part7 【7680x4320】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
x264 243,226
x265 436,722
ファイルサイズも264の方が小さい・・・
ただ、どっちもcrf18なんだけど、265の方が見た目品質が劣化し辛いってだけなら、
264の22 = 265の28 （適当な例）になって、めっちゃ小さくなるって事なのかな？
（ちなアニメみたいなネタ動画をエンコして、小さくならなくておかしいなって思い始めて、
その動画の最初の１秒を切り抜いてテストしてみた） >>774
crfは揃ってるみたいだけどビットレートはどうなのよ >>768
レコーダーは8Kだけどカメラは8Kは無いんだな。
家庭用で8Kカメラが出るのはまだ4、5年は先になりそうだな。
発売されるときはH.266対応になるのかな？ --psy-rd 5
x264もこれでやってみろよｗ >>774
x265の↓が気になる
--qcomp 1 --psy-rd 5 というかx264の方だけ10bitだし、そもそもなんでこんなオプションの組み合わせで比較してるんだ。
解像度とかも書いてないし、FLV1なんてゴミ画質だろうし、１秒だけ切り出してのテストなんて話にならんだろう・・・。 >>779-780
エラー云々とかで頭うにってた、0.5と5を間違えてた・・・
>>781
それもx265が8bitじゃないのかと思って、10bitに変えたりして直してなかった
331,355までは縮んだけど、まだ大きい・・・きっと俺が間違ってるんだろうね
がんばってみる、ありがとう・・・ とりあえずqcompはデフォの60でいい（crf18なら ssim厳密に比較するんならpsyは切らないと話にならない HEVCがインタレ対応してくれたらなぁと思ってた時期もあったけど、
QTGMCでインタレ解除したら元の動画そのまま再生するより綺麗になってたし
時代はもうインタレ解除だね 実は対応してるみたいだぞ
再生側が対応してないこと多々なんで実用性はないが x265でインタレエンコードしたけどあまり縮まなかった
x264の方が断然きれいだったよ
再生側もそうだけど、エンコーダ側も対応が必要なんだと思う
規格に専用ツールが用意されてない時点でH264に勝てるのか分からんが 再生用のavsスクリプト書けばPCなら問題なく再生できんじゃね QTGMCをリアルタイムに処理できる化物PC持ってるなら解除で良いんじゃね Disable QP limitations for lowpass subband dct
https://bitbucket.org/multicoreware/x265/commits/4ed6afba60476fb7620889c533248c6c396474ab
ログ読んだ感じcrf22〜23で使う人にちょうどなんだろうか
いよいよ結果が楽しみ >>790
CUDA化したKTGMC使えばGTX1060でフルHDが100fps超えだよ
そんな化物PCじゃなくてもいい x265、ソース弄ってiccで最適化したけど、ロシア人がビルドしたヤツと0.1%くらいしか変わんないなー
vtuneでプロファイル取ってみると、ソース全体に処理回ってて、ボトルネックは見つかんないわ
まぁ意外とコストがかかる関数ポインタとか
オブジェクトのメンバ変数読み書きの部分を弄れば
もう0.1%くらいは稼げるかもだけど
そこまですんのもなー
x265、この先が楽しみ x264をもっと最適化出来ないのかな
x265と比べて明らかにCPU温度低くて回路が動いてない 時の流れって凄いよな
x264が激重でxvidｻｲﾂﾖな時代もあったのに x264はやってみたいけどmsvcでビルド出来なくなって久しいのがなー
あのレベルの入り組んだマクロから書き直すのは
流石にお給料貰わないと出来ないわ
Linuxも頻繁に使うからgccは嫌いじゃないんだけど
そこそこ大きいソース弄るとなればvisualstudio使った方が楽で‥
x265は全体がc++で書かれてるのがネックだよ
中途半端にC++で、ここは単純にcで書いた方が速そうってファイルもいくつかあったし CPUフルロードになってもx264よりx265の方が温度高くなるのは
x265の方がSIMDを多用してるからじゃなかったっけ --lowpass-dct普通に使ったら絵がボロボロになってた・・ そりゃ、上限以上のビットレートは全カットだから
上限内はVBRするってフィルタじゃなかったか？ 離散コサイン変換を近似変換にすることで、精度を犠牲にして計算量を少なくする?
計算科学に暗いので調べてみてもそれくらいしか分からなかった。 >>805
せやで。高周波の計算をカットするからローパス DCTの高周波を削ると言うには、AQとの相性は悪そう iosのhevcをffmpegで確認したけど全部キーフレームってことはBフレームなしってことであってるよな ハードウェアエンコだろうからBフレは存在しないはず >>809
どういうコマンドで確認したの？
>>810
「ハードウェアエンコだからBフレ無し」なんてことはないよ。QSVのHEVCではBフレーム使えるし。 >>811
それは知らなかったな
いつからQSVで使える様になったんだ？ >>809
コマンドを調べてみたけど
ffprobe.exe -select_streams v -show_frames -show_entries frame=key_frame,pict_type hevc.mp4 > result.log
でkey_frameかどうかとpict_type（I/P/B）が見れるみたいだから、それで調べればいいんじゃないだろうか。
全部キーフレームってのがよくわからんし、ちょっと気になるので調べた結果は教えてくれ。
iosのHEVCサンプルを探してみたんだけど、見つからなかったのでサンプルもあるとありがたいが。
>>812
skylakeでHEVCエンコに対応した時からじゃない？
QSVEncの過去記事見ても、Bフレ使えなかったようには見えないし。 っていうかhevcのBフレ非対応はnvidiaだけだった気がする >>814
Intel(QSV)、nVidia(NVEnc)、AMD(VCE/AMF)のBフレーム対応状況は>>397参照。
AMDのHEVCも現状ではBフレ非対応。 QSVでHEVCエンコード時にBフレームが使用できるというソースに記憶がないんだがなぁ。
対応してたらrigaya氏が真っ先に対応するだろうし。 >>816
そのrigayaさんのサイト行ってqsvencの記事片っ端から読んできたら >>816
rigaya氏のブログの2015-08-29の記事（QSVEncのHEVC対応直後）のログでもBフレ使ってるのがわかるし
夏頃にQSVスレで出てたログでもBフレ使われてたし、当初から普通に使えてたんだと思う。 >>811
ffmpeg -an -skip_frame nokey -i input.mov -vsync 0 out%05d.png
キーフレームじゃないフレームをスキップして切り出したら30fps10秒で約300枚だった >>813
Bフレあったわ( ´〜｀)ゞ
https://pastebin.com/sBxiRbXU
プライバシーの観点から真っ暗動画でも良いならあげるけど >>815
あー、なんかそれっぽいスライドを見た気がしてたけど
2passのほうだったみたいね 全部キーフレームって業務用機器で使うAll-Intraかな？
編集向き AppleがHEVC大量に採用したからライセンスの問題は無くなったって言ってるのかね
理屈がよくわからんが Video Codec Comparison (H.264, H.265, VP9 and AV1)
http://abulayek.com/vcodec/index.html AV1大丈夫かね
VP10なんかよりもdaalaをベースに作ったほうが良かったように思うのだけど >>823
採用実績が増えてるだけで、特許問題は解決してないよね >>828
昔daalaを試したことあるけどSSIM低かったし肉眼でもそこまで綺麗じゃなかった
非DCT系コーデックってまだ実用段階じゃないんだと思う
あんま詳しくないから推測だけど ネコさんだっけ？
x264のchangelog翻訳してた人は4k/8k以上でないと
非DCTの利点がない（出にくい）って言ってた気がする >>831
確かに4kでは試してなかったな
2kの時点で0.03fpsくらいしか出なかったから >>829
gifのような騙し討ちと違って最初からライセンスルールが決まってるならいいと思うけどね。 4K/8K放送用（BS/110CSの左旋とBS右旋のBS-7/17）・・・本放送2018年12月1日
VC-8350/VD-8350 H.265 (MPEG-H/HEVC) MMT対応 8K/4Kコーデック
ttp://jpn.nec.com/bv/hoso/product/vcvd8350.html?
H.265 Main10@L6.1 Main Tierに対応した8K放送送出用コーデックです。
8K/4K放送に向けて、8K/4K H.265符号化/復号化、22.2ch MPEG-4 AAC音声符号化/復号化、
MMT(MPEG Media Transport)入出力、といった最新の放送規格に対応しています。
--
8K映像入出力として、Dual Green(3G-SDI×8)、および、U-SDI(ARIB STD-B58 U2.17)に対応
4K映像入出力として、4K-SDI形式(3G-SDIx4)、および、U-SDI(ARIB STD-B58 U1.17)に対応
※U-SDIは、NHK技研が開発した光ケーブルによる伝送。
本放送は、１年後だから、もう少し改良されるでしょうね。 8K放送って何かと批判されてるけどNHKで実際にみて見ると立体感とか半端ないんだよね。
めちゃくちゃ楽しみにしてるけど、目標までたどり続ける体力が各方面にあるかどうか・・・ 4Kの伝送に今までのSDIだとかなりしんどいからねぇ
USDIの導入はカメラケーブルで代用できないし体力が無いよ
ゼロ遅延でHEVCで圧縮して伝送できりゃいいけど… >>835
少なくとも放送局には無いだろうな
NHKでもやっとじゃないの HEVC関係ないけどオレ様用メモ
511 名前:名無し~3.EXE [sage] :2017/11/30(木) 08:08:26.78 ID:HZwMEGNU
Web メディア拡張機能
https://www.microsoft.com/ja-jp/store/p/web/9n5tdp8vcmhs
この Web メディア拡張機能パッケージをインストールすると、ユーザーは Ogg コンテナーに届けられたコンテンツや、Vorbis または Theora のコーデックを使用してエンコードされたコンテンツを自然に再生することができるようになります。 ついにブラウザで再生できるようになったか
俺のPCだと720pで重くなってしまうが すげーなAV1
HD画質ならもう1Mbpsいらんのね
エンコード時間がヤバイけど… 数年後、まともに再生できる環境が疑わしいコーデックに時間をかけるのは無駄だと思うがね AV1の規格まだ固まってないだろうにようやるわｗ
コーデックMIMEタイプにgit hash含まれてるらしいしｗ 新しい物が出来たら試したくなるじゃん。永久保存版をダウンサイズする訳じゃないし。 はたしてHEVCはAV1に負けるのだろうか？
chromeとfirefoxがHEVCをサポートしないだろうからウェブでは流行らせようがないし 結局はネーミング
AV1とかセンス0の怪しい名前が普及するわけないのよ AVがいかがわしい意味を持つのって日本だけじゃないの？ safariとedgeはh.265をサポートしているのか？ >>860
Safariはどうだか知らんが
Edgeは>>762入れてみたら グーグルフォトがAV1の採用で60fpsに対応してくれることを期待 iMac Proと一緒に
HEVC対応Final Cut Pro X/Compressor/Motion出たね もう新しくロイヤリティ払いたくない派は
av1が来るまでｍｐ４やｖｐ９で行くんでねえ
８ｋ来るまで当分先だし 誰でも自分ＰＣで稼げる方法など
参考までに、
⇒ 『政道のゴウイウセレイイ』 というＨＰで見ることができます。
グーグルで検索⇒『政道のゴウイウセレイイ』
DV2315TNTB QSVのHEVCがBフレーム対応するのは、まだまだ先かねぇ？ >>872
>>397参照。QSVのHEVCはBフレーム対応してる。
HEVCでBフレームが使えないのはNVEncやAMFだな。 ■ このスレッドは過去ログ倉庫に格納されています
