【2016】 H.265/HEVC Part7 【7680x4320】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>714
Windows95や98向けのソフトが今でも使われていると思えばしょうがない >>714
対応文字コードでも対応bit数でもアプリの優劣は語れない ひょっとして今ryzenみたいなマルチコア環境もってる人間だったりしたら
TEMPegとかPowerDirectorやらプレミアでh264エンコした方が激早だったりする？
ああ違うか h264やh265は対応してて
aviutlで編集するときがそうじゃないってだけか・・・
そのわりにaviutlってかなり快適なのはなぜなんだある意味凄いんだが
先月TEMPegとPowerDirectorだけはデモ版いれて編集操作の感じをみてみたけどシークとか激重で使う気にならなかった・・・ >>718
そりゃ基礎部分はPentiun2や同3という骨董CPUで快適に動くようにガチガチに最適化されてるからね
逆にそのせいで64bit化できなかったみたいだけど、軽さと直感的な操作性は異常に良い http://i.imgur.com/IopxFkM.jpg
この画像みててちょっと勘違いしてるのか理解できないところがあるんだ
x265(16)って10bitカラーの事？
x265(8)ってのは8bitカラーだと思ってるけど
であるならばどしてx265(16)の方が総じてビットレートが低く抑えられてるんだろ？って疑問に思った >>719
いや、直感的操作は無理だろ
GUIは糞じゃん ポストムーアってことで圧縮規格の熟成も早めていくんだろうか >>721
なんの操作なのよ
基本操作はペガサスのtmpgencよりずっと直感的
>>720
16はそのまま16bitでしょう
ビットレート周りは開発者の調節次第だから細かいことは気にしない
ま、基本的にbit数が大きいほうがエンコーダとして優秀だから
ビット当たりの画質は上がる >>720 >>724
>> x265(16)って10bitカラーの事？
> 16はそのまま16bitでしょう
その画像作った者だけど、x265(16)は10bit出力（Main10）のことだよ。
当時は10bit出力用のバイナリ（12bit出力はまだできなかった）が
x265_1.5+445_x64_16bpp.exeといった感じで16bpp（内部処理の深度？）という名前で配布されていた。 なんだ ひょっとして10ビットカラーでエンコした方がファイルサイズ小さくできる？ ファイルサイズは、基本小さくなると思うよ。
その代わりエンコ時間が、結構延びるけどな。
後は再生環境による。 感覚的にPowerDirectorはAviutl比でH265のエンコ時間は半分。H264なら1/5位の爆速。
ただし最高ビットレートでも使わない限りは破綻部分も多い。容量は大きくなりがち。 8bitと10bitだと--crfの範囲が変わるから、同じcrf値なら10bitのほうが不利かと思ったけどそうでもない？ 8-bitと10-bitだと、全く同じ条件で圧縮すると10-bitの方が8-bitよりも25%多くデータ使っちゃうのかな？ 8K対応の動画管理ソフト「TMPGEnc KARMA.. Plus 2」。HEVC 4K出力も - AV Watch
ttp://av.watch.impress.co.jp/docs/news/1085956.html >>733
このソフト編集時の遅さがイラつきをマッハ超えるから使いたくねえよ >>734
そうなの？
面白そうだから買おうかと思ってたんだけど >>735
今度でるとかいう最新バーは知らないけど
その直前のデモでさわったけどマウスカーソルでぱぱっと次々にシークカーソル移動させてもカックカクだよ
aviutlがはやすぎるのかしれないけどなんで無料と同じパフォーマンスで処理できないんだ >>734 >>736
>>733は動画管理ソフトであって編集機能なんて無いようだが、
TMPGEnc Video Mastering Worksあたりと混同してるんじゃないか？ 久々にx265が途中終了したので報告。タスクマネージャーは未使用
x265guiEXのログにはこんな感じでメッセージが出る
auo [error]: x265が予期せず途中終了しました。x265に不正なパラメータ(オプション)が渡された可能性があります。 下のはイベントビューアに残ってたログ
---------------------------
障害が発生しているアプリケーション名: x265-64bit-10bit-latest.exe、バージョン: 2.5.0.27、タイム スタンプ: 0x59e30a51
障害が発生しているモジュール名: unknown、バージョン: 0.0.0.0、タイム スタンプ: 0x00000000
例外コード: 0xc0000005
障害オフセット: 0x000001e136ebf6e0
障害が発生しているプロセス ID: 0x1ea4
障害が発生しているアプリケーションの開始時刻: 0x01d34659e0c5e87e
障害が発生しているアプリケーション パス: C:\xxxxx\AviUtl\exe_files\x265-64bit-10bit-latest.exe
障害が発生しているモジュール パス: unknown
レポート ID: bb349991-0a2e-4fcf-a9c6-06ed0f23ff49
障害が発生しているパッケージの完全な名前:
障害が発生しているパッケージに関連するアプリケーション ID: 続き
-------------------
障害バケット 116462238078、種類 5
イベント名: BEX64
応答: 使用不可
Cab ID: 0
問題の署名:
P1: x265-64bit-10bit-latest.exe
P2: 2.5.0.27
P3: 59e30a51
P4: StackHash_3ebb
P5: 0.0.0.0
P6: 00000000
P7: PCH_7B_FROM_ntdll+0x00000000000A5EF4
P8: c0000005
P9: 0000000000000008
P10:
-------------------
このログからどんな原因のエラーか分かる人おるかあ？ 無理
むしろ開発者の方に問題の起きたソース(動画)とエンコ時のオプション送ってデバッグしてもらったらとしか 再現性がないんじゃデバッグも難しいだろうな
まぁ、もう一度エンコしたらエラーなく終わるならそれで良くね マルチスレッドの同期処理に関わるエラーぽいな
なんでもメモリに責任を求めるのは思考停止だ まず、エンコードのエラーでCPUやメモリーを先に疑うってのが頭悪い 質問「パソコンが落ちるんですけどどうしたらいいですか？」
大先生1「メモリー変えろ」
大先生2「グリス塗り直せ」
大先生3「CMOSクリアしろ」
大先生4「windowsを再インストールしろ」 ,.,.,.,.,.,.,.,.,__
,,;f::::::::::::::::::::::ヽ
i::::::::/'"￣￣ヾi
|:::::::| ,,,,,_ ,,,,,,|
|r-==（ ｡);（ ｡)
( ヽ :::__)..:: }
,＿＿__／ヽ ー== ; ほほう それでそれで？
r'"ヽ t､ ＼＿＿_ !
/ ､､i ヽ＿＿,,/
/ ヽﾉ j , j |ヽ
|⌒`'､__ / / /r |
{ ￣''ｰ-､,,_,ﾍ＾ |
ゝ-,,,＿＿＿＿_）--､j
/ ＼__ /
| "'ｰ‐‐---'' マルチスレッドは適当に作ってもだいたい動くけど、
長時間テストするとたまに落ちる
安全にやろうとすると待ち時間が発生して遅くなる インターレス対応してくれたらな
でも４Kとか８Kは６０ｐだから考えてないのか vlcプレイヤーで再生できません
みんなどうやって再生してるの？ HEVC入力に対応している動画編集ソフトってしばらくはでないさそうなのかな スレタイとは関係ないけど
MS純正Windows 10用mpeg2 コーデック(TSデコード可)
https://www.microsoft.com/ja-jp/store/p/mpeg-2-ビデオ拡張機能/9n95q1zzpmh4 https://av.watch.impress.co.jp/docs/news/1089016.html
ﾊﾟﾅｿﾆｯｸ､AVC-Intraで8K収録できるﾚｺｰﾀﾞ｡4K/8K機器をInterBEE出展
貯金しておかないと。 ここで聞くのもあれだと思うがNvEncでH.265のハードウェアエンコを開始するとLiveKernelEventが発生してエンコード不可能になっちまったんだが知恵をくれ
試したアプリ (どちらも同じエラーが発生)
XMedia Recode 3.3.7.8
Aviutl 1.00 NVEnc.auo 3.23
環境
Windows10 16299.19 (FCUの大型アップデート以前も発生していた)
GeforceGTX 1060 388.13
メモリ 16GB
OS再インストールしてもビデオドライバを古いのにしても発生
信頼性モニタを見ると「ハードウェアエラー」と表示されていたんでグラボが壊れたのか？でも3Dゲームは普通にあそべてるしなあ
LiveKernelEventでぐぐるとこっちもハードウェアエラーの模様 書き忘れた
ディスプレイ ドライバー nvlddmkm が応答を停止しましたが、正常に回復しました。
これが同時刻にイベントビューアに書き込まれる >>771
おまえ本当にググったのかよ
レジストリいじれって腐るほど出てくるだろうが x264
--preset placebo --tune animation --profile high10 --crf 18
--qpstep 51 --qcomp 1 --aq-mode 3 --keyint -1 --bframes 16 --ref 16
SSIM Y:0.990466 (20.207389) U:0.993723 (22.022448) V:0.993808 (22.081948) All:0.991566 (20.739725)
x265
--preset placebo --crf 18 --qcomp 1 --aq-mode 3 --aq-strength 0.75 --psy-rd 5 --psy-rdoq 0
--rdoq-level 0 --keyint 300 --deblock -1:-1 --no-sao
--me sea --subme 7 --merange 128 --ref 6
SSIM Y:0.987739 (19.114777) U:0.992287 (21.128044) V:0.992294 (21.131487) All:0.989256 (19.688449)
昔のflv1を↑で固めたんだけど、ssim自体はx264の方がいい・・・設定が間違ってるのかな？
それとも、x265って、見た目が劣化しづらいってだけで、各ドットの劣化は265の方が大きいのかな？ 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だけだった気がする ■ このスレッドは過去ログ倉庫に格納されています
