X
H.265/HEVC Part9 【7680x4320】
■ このスレッドは過去ログ倉庫に格納されています
0019名無しさん＠編集中 (ｱｳｱｳｲｰ Sa4b-NP//)垢版2018/10/02(火) 21:11:28.78ID:a0XvO1h/a
この板、制限厳しいからね
ひと通りの実装ができてしまうと話すことがなくなるし
ソフトウェアとハードウェア合わせて「エンコーダー総合スレ★1」あたりでなんとかスレ落ちが回避できる状態かと
0020名無しさん＠編集中 (ﾜｯﾁｮｲ d906-SWBM)垢版2018/10/06(土) 14:02:18.81ID:rFxgAXN90
Version 2.9
Release date - 05/10/2018

New features
-------------
1. Support for chunked encoding

:option:`--chunk-start and --chunk-end`
Frames preceding first frame of chunk in display order will be encoded, however, they will be discarded in the bitstream.
Frames following last frame of the chunk in display order will be used in taking lookahead decisions, but, they will not be encoded.
This feature can be enabled only in closed GOP structures. Default disabled.

2. Support for HDR10+ version 1 SEI messages.

Encoder enhancements
--------------------
1. Create API function for allocating and freeing x265_analysis_data.
2. CEA 608/708 support: Read SEI messages from text file and encode it using userSEI message.

Bug fixes
---------
1. Disable noise reduction when vbv is enabled.
2. Support minLuma and maxLuma values changed by the commandline.
0021名無しさん＠編集中 (ﾜｯﾁｮｲ dfd2-uJ+0)垢版2018/10/12(金) 20:15:10.56ID:d/e/FwZh0
x265guiEx 3.87
> ・インタレ保持エンコを仮実装。
> 一応正常に動いている気がするけど、x265でもexperimentalらしいので、基本的には実験用。インタレ保持したいなら素直にx264使ったほうが良い気もする。
> なんとなく試してみたくなったのだが、avisynthでsperateFiledsとかごちゃごちゃ書くよりはx265guiExをいじったほうが速い気がした(当たり前だが気のせい)ので、実装してみた。



インタレ対応してるデコーダーあったっけ？
0022名無しさん＠編集中 (ﾜｯﾁｮｲ 27ec-4Hut)垢版2018/10/12(金) 21:28:31.89ID:GZyN42eo0
>>21
HMくらいかな。

一応ffplay 4.0.2とLAV 0.73.1で試してみたけど、3月に
　https://mevius.5ch.net/test/read.cgi/avi/1515759816/253-254
で試した時と状況は変わってないように見える。

QSVやNVDEC、AMF等のハードウェアアクセラレーションでの扱いは、うちでは試せないので不明。
対応環境でLAVのDXVAを有効にしたり、ffplayで -c:v hevc_qsv (or hevc_cuvid or hevc_amf)を指定すれば
うまく再生できたりするのかもしれない。（望み薄のような気はするけど、動作確認した情報ってあるっけ？）
0023名無しさん＠編集中 (ﾜｯﾁｮｲ f3e7-o90R)垢版2018/10/29(月) 10:49:38.55ID:fI4vNSR10
久々に動画のコーデックのことなんて考える必要に迫られて
このスレみつけてきてみたんですが、場(スレ)違いだったでしょうか
当方、HEVCモノの動画をVLCで再生したらカクついたり途中でとまったりして・・・
SkylakeのCPUを積んだWin10-x64(1809)+HEVC拡張導入済みの自作PCで
RAM16GB、ゲームしないのでファンレスのGeForceGT730という構成なのですが
快適再生に必要なのは何？再生ソフト？グラボ交換？M/BやCPUも交換？
0024名無しさん＠編集中 (ﾆｸｸｴ MM09-vV9E)垢版2018/10/29(月) 16:41:28.74ID:ggAlLoX/MNIKU
>>23
VLC再生中のCPUパフォーマンス、メモリー使用量、ディスクかSSDアクセス速度、VLCのCODEC表示と再生トータルビットレート、ドロップしたコマ数などをみて、そのマシンの弱いところを的確に診断して補強するか、取り替えるしかないかな

グラボかえてみたらCPU100%張り付いててパワー足りてなかったとか、実はディスクI/Oが遅かったとか
再生支援つきグラボにしたら全部解決したとか、複数が原因で１つじゃ解決しないとか
弱くないところに金使っても、全く改善しないからね

これってCODECの種類と解像度とビットレートの全ての組み合わせごとに、全ての要素をみる必要があることだから
のんきな人は、現実を直視出来ないくらい「大変だぁ！」となるのが、僕の周辺でよく見かける風物詩となってますw
002623 (ﾆｸｸｴ f3e7-o90R)垢版2018/10/29(月) 22:03:02.34ID:fI4vNSR10NIKU
>>24 レスありがとうございます。
これは一筋縄ではいかなさそうな感じなんですね。

>>25 そうですか？たまたまVLCがあったのでやってみただけで
もっとHEVCに向いた再生ソフトがあれば・・・という思いもあったのですが。
ぐぐれば無料のとかいくつか出てきますよ、でもなんかどれもいかがわしそうで。
002923 (ﾜｯﾁｮｲ 36e7-QXT6)垢版2018/11/02(金) 18:13:25.74ID:KxY4MzZb0
>>27-28
なんだかヒントをいただいたみたいで・・・
ありがとうございます
ファンレスだと1030がかろうじてあるようですので
iGPUも含めて検討してみます
0031名無しさん＠編集中 (ﾜｯﾁｮｲ d3e7-ki2E)垢版2018/11/14(水) 03:23:55.87ID:aTEJyBLF0
8/10/12bitとある中でビット数以外は同じ条件でエンコしたのだけど
生成ファイルサイズが大きい順に10bit>8bit>12bitだったのだよね。
予想では12bit>10bit>8bitか8bit>10bit>12bitだったのだけど
8bitが間で12bitが小さい（10bitが大きい）理由って分かる人いる？
0035名無しさん＠編集中 (ﾜｯﾁｮｲ 76a7-AIgs)垢版2019/01/02(水) 14:30:14.37ID:cJ3tV5fJ0
ほ
0045名無しさん＠編集中 (ﾜｯﾁｮｲ 678a-8ZX8)垢版2019/03/27(水) 17:57:32.55ID:AZzzJxhz0
この頃h265使い始めた初心者です
h265で撮ったアクションカムの動画で再生時の音ズレに困っています
CPU100％に近く跳ね上がるので、CPUの問題なのでしょうか
グラボを良いモノに変えてみたけどまったく変化無かったです
グラボに仕事させるようなソフトで改善できるモノなのかな
0047名無しさん＠編集中 (ﾜｯﾁｮｲ 8d61-k8NZ)垢版2019/04/07(日) 22:36:47.81ID:4yEsPMar0
3.0で-tunes animationが追加されたけど
効果はどんなもんなのかね。
0049名無しさん＠編集中 (ﾜｯﾁｮｲ 8d70-iMOx)垢版2019/04/07(日) 22:58:05.81ID:CVTI9voW0
x265 の引数で主要なとこだけ書くとこれで
--crf 19 --preset medium --output-depth 8 --tune animation --sar 4:3 --colorprim bt709 --transfer bt709 --colormatrix bt709

info で表示されたのがこれ。

Slices : 1
frame threads / pool features : 4 / wpp(17 rows)
Coding QT: max CU size, min CU size : 64 / 8
Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
ME / range / subpel / merge : hex / 57 / 2 / 2
Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
Lookahead / bframes / badapt : 20 / 6 / 2
b-pyramid / weightp / weightb : 1 / 1 / 0
References / ref-limit cu / depth : 3 / on / on
AQ: mode / str / qg-size / cu-tree : 2 / 0.4 / 32 / 1
Rate Control / qCompress : CRF-19.0 / 0.60
tools: rd=3 psy-rd=0.40 rskip signhide tmvp strong-intra-smoothing
tools: lslices=6 deblock(tC=1:B=1) sao
0050名無しさん＠編集中 (ﾜｯﾁｮｲ 8d70-iMOx)垢版2019/04/07(日) 23:46:46.27ID:CVTI9voW0
--crf19 --preset medium --aq-mode 3 --aq-strength 0.6 で今までエンコしてたんだけど
--crf19 --preset medium --tune animation って置き換えたら画質落ちたわ。
線がボケてブロックノイズとバンディングが目立っちゃってた。
ファイルサイズは 300MB ちょいのが 250MB ちょいまで落ちてたから色々情報削ってそうｗ
0052名無しさん＠編集中 (ﾜｯﾁｮｲ 01e7-k8NZ)垢版2019/04/08(月) 01:04:31.04ID:ePuriIh90
>>50
勘違いする人がいそうだから一応言っておくけど、それだけでは--tune animationの効果がよくないってことにはならないぞ。
--crfってのは絶対的な画質指標じゃないんだから、オプションが変われば得られる画質も変わる。
--tune animationの効果を調べるなら、出力ファイルサイズが同じくらいになるように--crfの値を調整して比較しないと。
0053名無しさん＠編集中 (ﾜｯﾁｮｲ 9970-iMOx)垢版2019/04/08(月) 10:48:27.89ID:RJpWkz+40
>>51,52
ファイルサイズが近くなるように調整するなら crf の値は小さくなっていくので、
そうなるとエンコ速度が低下しちゃうのよね。
ドキュメントにはエンコード速度に影響を与えずエンコード品質を最適化するとあるけど
最終的な画質まで加味して crf を調整するとトータルで速度が低下しちゃうからなんだかなと。
0054名無しさん＠編集中 (ｶﾞｯｸｼ 0659-KI0z)垢版2019/04/26(金) 10:54:59.36ID:iSECzt2j6
x264のスレって無いんでしたっけ？
005754 (ﾜｯﾁｮｲ 237f-KI0z)垢版2019/04/30(火) 14:26:02.10ID:9LL/DGwj0
25p入力を60i化するのに、
--pulldown 23232 みたいな事やりたいのだけど、
ハードテレシネ済の動画を入力する以外の方法だと、プログラム自体を書き換えないと
無理ですよね…。
0064名無しさん＠編集中 (ﾜｯﾁｮｲ 6752-ahOC)垢版2019/05/05(日) 04:29:41.98ID:AIvLPrI70
便乗して質問させていただきたいのですが、
threadの役割というのは主に、
分割された個々のフレームで関数を実行する、というような認識で合っていますか？
実際はもっと複雑なものだと思うのですが、詳しい方がいましたら教えて頂きたいです。
0068名無しさん＠編集中 (ﾜｯﾁｮｲ a201-siGz)垢版2019/05/08(水) 00:33:27.83ID:hqLwUoiL0
ナーシャ・ジベリが機種依存のソースコード書いてFFの飛空艇を8倍速移動させたように、
高速化できれば汎用性なんて関係ない例なんて幾らでもあるよね？
0069名無しさん＠編集中 (ﾜｯﾁｮｲ 4263-R0y6)垢版2019/05/08(水) 02:11:22.15ID:oXs9xS8q0
ナージャは参考にならんぐらい天才プログラマなので例えにするのはアレだけどなｗ
確かビザの関連で帰国した際に開発中のFFにバグが起きて
全部頭にプログラム入ってたナージャは問題箇所を電話で指示して修正したんだっけか
ネットかも無い時代だしな
0070名無しさん＠編集中 (ﾜｯﾁｮｲ b792-5AMV)垢版2019/05/14(火) 23:29:34.45ID:7At3OZ0w0
>>62
解像度が高いほどマルチスレッド化(タイル分割)しやすいから条件によるだろうね
低解像度だと6〜8コアぐらいでもCPU性能引き出せないこともある
320x180だとこんな感じかな、フルHDでもスリッパみたいなコア数の多いCPUだと使い切れないことがあるみたいだけど。
並列x2 https://imgur.com/L90TLmY.png
並列x5 https://imgur.com/BPfpEdD.png
並列x10 https://imgur.com/69llRRx.png
0075名無しさん＠編集中 (ﾜｯﾁｮｲ bbe7-bIfI)垢版2019/06/02(日) 20:43:18.46ID:+GwKPdan0
>>73
x265 HEVC Encoder - Page 336 - Doom9's Forum
https://forum.doom9.org/showthread.php?p=1864949&;highlight=3.0_Au#post1864949

> We are starting to use 3.0_Au (Gold) to signal that the default branch has moved to gold state.
> We are just trying to avoid merging back from stable to default as it is good practice to avoid merges.
> Hope this isn't too confusing!

よくわからんが金(Gold)の元素記号である Au ってことらしい。
0083名無しさん＠編集中 (ﾜｯﾁｮｲ 6370-hDDM)垢版2019/06/03(月) 16:53:33.16ID:e18q2nlD0
>>80
あ、ごめん
rigaya 氏のビルドバッチ使ってビルドしたやつでエンコすると確実に例外吐いておちてたけど
>>82 に貼った x265 同梱の multilib.bat だと大丈夫だった

3.0_Au+30 でエンコした avs 残ってたからそのまま RC+44 でエンコしたら
ログを見る限り 1.4fps ほど速くなってた。
0085名無しさん＠編集中 (ﾜｯﾁｮｲ 6370-hDDM)垢版2019/06/03(月) 17:19:49.65ID:e18q2nlD0
>>84
それもそうだｗ 失礼した

34,524 フレーム 24:00 ソースをエンコした速度
3.0_Au+30 = 21.53fps, 1736.76kbps
3.0_RC+44 = 22.91fps, 1687.1kbps

共にフィルタに変更無し、マシンも手を触れずに放って置いた時のもの。
ビットレート落ちてるけど静止画として同一フレーム見ても
画質的な違いが良くワカランので問題は無かったけど気にする人は一応確認しておくと良いかも。
静止画だけで画質を判断する物じゃないけどねｗ
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況