【2016】 H.265/HEVC Part7 【7680x4320】 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
DTVのすべてのスレがIP開示になるまでは何も信じられない ,．-''"´￣｀`ヽ､
,r'´ _ ＼
／.:.:..:. :,r'´_,ｲ水ヽ､ ＼
!.:.::.:::,／ ヾY / ｀ヽ !
｀ーｲ＿,,,､､､､､､､,,_ ,j!,／
ト // / /｀Tｲ
/￣￣（0）(0） イ
／ ::::⌒｀´⌒::::＼
| ,-） （ -|
│ i〈 ､ ＿＿＿_ 〉/
! ヽ ｀ ⌒´ /
ヽ /
/ヽ;;､ /
, イ ヽ ＿_,, /ｿ !
,､‐'´.:.:.:＼ Tｰｧ､/l ,/`ー- ､_
,､-‐''´.:.:.:::::::::::::::::｀ー‐:.'::::77j::::::::::::::::::.:.:.:.:ヾj､
/ヾヽ､.:.:.:::::::::::::::::::::::::::::::::::::::::ヾ}!:::::::::::.:.:,,､-‐'''" i
/ ヾ≧＼｀`'''ー──-- ､::::::::::i|:::::::.::::/ l| ∧∧∧∧
＜ ＞
＜ ー|-ヽ ＞
＜ d⌒) ＞ ,.-ー-､
＜ ＞ ／/::;､:::::::::＼
＜ ﾆ|ﾆ ＞ ／/::{::::l| }:::::::jﾉハ､
＜ Cト .＞ // ヽﾘ心' 七 lｿ l l
＜ ヽ ＞ | | l人_r‐┐八 l l
＜ ー7 ＞ l/ ／l l二 | |｀ヽ リ
＜ /ﾍ＿ ＞ /::::/j |o| !ﾊ:::::ヽ
＜ | ＞ く:::::{_/ |o| ｀ヽi::::::>
＜ | ＞ 7Y._ l ! ハ ',
ノ | つ ＼ / / jﾟ | 彡|l ',
｀∨∨∨∨∨´ / /j |ol |i l
/ / ﾉ j l |l j
（__ﾉ/ | | lｿしﾉ_
｀T''ー-|__,j-‐‐'"::::::::::::7
|::::/:::|::::/l::::::|＼::::;:'´ IDとワッチョイが違うが同じスレが2立てたって言ってるやつおるけど同一人物なんか？ ねみみんだけど【興味があります。】
用途目的はなんなの？4k8k画質の転送効率アップ？それともwebコンテンツの高画質化？ >>12
両方かな
あとHEVCのライセンス料で揉めててネットの次世代コーデックの候補がHEVCとAV1で争ってるからその動向とかに関して話たりするスレ ,．-''"´￣｀`ヽ､
,r'´ _ ＼
／.:.:..:. :,r'´_,ｲ水ヽ､ ＼
!.:.::.:::,／ ヾY / ｀ヽ !
｀ーｲ＿,,,､､､､､､､,,_ ,j!,／
ト // / /｀Tｲ
/￣￣（0）(0） イ
／ ::::⌒｀´⌒::::＼
| ,-） （ -|
│ i〈 ､ ＿＿＿_ 〉/
! ヽ ｀ ⌒´ /
ヽ /
/ヽ;;､ /
, イ ヽ ＿_,, /ｿ !
,､‐'´.:.:.:＼ Tｰｧ､/l ,/`ー- ､_
,､-‐''´.:.:.:::::::::::::::::｀ー‐:.'::::77j::::::::::::::::::.:.:.:.:ヾj､
/ヾヽ､.:.:.:::::::::::::::::::::::::::::::::::::::::ヾ}!:::::::::::.:.:,,､-‐'''" i
/ ヾ≧＼｀`'''ー──-- ､::::::::::i|:::::::.::::/ l| ∧∧∧∧
＜ ＞
＜ ー|-ヽ ＞
＜ d⌒) ＞ ,.-ー-､
＜ ＞ ／/::;､:::::::::＼
＜ ﾆ|ﾆ ＞ ／/::{::::l| }:::::::jﾉハ､
＜ Cト .＞ // ヽﾘ心' 七 lｿ l l
＜ ヽ ＞ | | l人_r‐┐八 l l
＜ ー7 ＞ l/ ／l l二 | |｀ヽ リ
＜ /ﾍ＿ ＞ /::::/j |o| !ﾊ:::::ヽ
＜ | ＞ く:::::{_/ |o| ｀ヽi::::::>
＜ | ＞ 7Y._ l ! ハ ',
ノ | つ ＼ / / jﾟ | 彡|l ',
｀∨∨∨∨∨´ / /j |ol |i l
/ / ﾉ j l |l j
（__ﾉ/ | | lｿしﾉ_
｀T''ー-|__,j-‐‐'"::::::::::::7
|::::/:::|::::/l::::::|＼::::;:'´ >>13
なるほどねー
ATRACとAAC、mp3みたいな状況なのかな
【ありがとう。】色々調べてまた来ます /ﾆＹﾆヽ 「逃げ」
/（ 。)(。）ヽ 逃げて怒られるのは
／::::⌒｀´⌒::::＼ 人間ぐらい
| ,-）＿＿＿（-、| ほかの生き物たちは
| l |-┬-| l | ＿＿ 本能で逃げないと
＼ `ー'´ /￣￣⌒/⌒ / 生きていけないのに
（⌒ / / / どうして人は
i＼ ＼ ,(つ / ⊂) 「逃げてはいけない」
| ＼ y(つ＿＿./,＿＿⊆) なんて答えに
| ヽ＿ノ | たどりついたのだろう
| |_
ヽ、___ ￣ ヽ ヽ
と_＿＿_＿＿＿ノ＿ノ 通りすがりのねみみんだけど、イントラ圧縮だけでも優れてるからマジでHEVCには頑張って頂きたい /ﾆＹﾆヽ
/（ ﾟ )( ﾟ ）ヽ
／::::⌒｀´⌒::::＼
| ,-）＿＿＿（-、|
| l |-┬-| l |
＼ `ー'´ ／
／ く
／ ｡ ＼
/ 。∫∫ﾟ ヽ
/ ／＾ー:ｒ￣￣￣i l
| i ／ ,ﾉ､＿＿ノ | 個人的にはJPEGをBPGで置き換えて欲しいんだけどなー 主要ブラウザが対応して大手サイトが使用するようになればあるいは ライセンスで揉めてるならHEVCはmpeg2みたいになるのかな？
個人使用はフリーのAV1になるのか……YouTube次第な気がしなくもないですね >>29
AV1を共同で開発してる企業の中にGoogleが入っているからYouTubeがAV1を採用する可能性はあると思う。
Alliance for Open Media - About Us
http://aomedia.org/about-us/ なーる……Web関係はAV1がデファクトスタンダードになりそうね
普段ネ実しか見ないから新鮮で楽しいなw
また来ますね【ありがとう。】 ,．-''"´￣｀`ヽ､
,r'´ _ ＼
／.:.:..:. :,r'´_,ｲ水ヽ､ ＼
!.:.::.:::,／ ヾY / ｀ヽ !
｀ーｲ＿,,,､､､､､､､,,_ ,j!,／
ト // / /｀Tｲ
/￣￣（0）(0） イ
／ ::::⌒｀´⌒::::＼
| ,-） （ -|
│ i〈 ､ ＿＿＿_ 〉/
! ヽ ｀ ⌒´ /
ヽ /
/ヽ;;､ /
, イ ヽ ＿_,, /ｿ !
,､‐'´.:.:.:＼ Tｰｧ､/l ,/`ー- ､_
,､-‐''´.:.:.:::::::::::::::::｀ー‐:.'::::77j::::::::::::::::::.:.:.:.:ヾj､
/ヾヽ､.:.:.:::::::::::::::::::::::::::::::::::::::::ヾ}!:::::::::::.:.:,,､-‐'''" i
/ ヾ≧＼｀`'''ー──-- ､::::::::::i|:::::::.::::/ l| (；´Д`)イェ〜エェエェェ・・・・・(こんき〜ん こぉん･･･)
(；ﾟДﾟ)ヲィ〜ヲィィ〜イィィィ〜 (；´Д`)ィィィ･･･
だんっだ、だんっだ、だららららっ！
どぅっだだらだ、どらだった どぅっだだらだ、どらだった
どぅっだだらだ、どらだった どぅっだだらだ、どらだった (･∀･)しゃらーらっ！
ゴォオ(；ﾟДﾟ)ハッ！ ズズ(；ﾟДﾟ)ハッ！ (；ﾟДﾟ)ハッ！ ズズ(；ﾟДﾟ)ハッ！
ゴォオ(；ﾟДﾟ)ハッ！ ズズ(；ﾟДﾟ)ハッ！ (；ﾟДﾟ)ハッ！ ずぅ、しゅるりるりるっ！
だーった、たた しゅぅ ガー、だーった、たた しゅぅ きん、ガー、(；ﾟ∀ﾟ)がぼ！
だーった、たた しゅぅ ガー、だーった、たた しゅぅ きん、ガー、(；ﾟ∀ﾟ)がぼ！
たたしゅぅ きん、(；ﾟ∀ﾟ)がぼ！ しゅぅ きん、(；ﾟ∀ﾟ)がぼ！ しゅぅ きん、(；ﾟ∀ﾟ)がぼ！
だだんっ！ ブイィィィィィィィィン HEVCの圧縮を使ったBPGも結局あんま流行らないねえ
GIFの時みたいに元々の代替手段がない状況じゃないと難しいか Post-HEVC technology development: JVET "Next Generation Video Codec"
http://forum.doom9.org/showthread.php?t=174245
もう次の規格を作っているのね なんかわざとらしいレスばかりだね
今更圧縮率に感動って・・・ パイオニア製ドライブにバンドルが決定
サイバーリンク、Ultra HD Blu-ray再生ソフトを出荷開始
http://ascii.jp/elem/000/001/423/1423798/ NVEncってGPUの性能に比例して処理速度変わったりするの？
GTX 1060 1070 を内蔵してるノートPCをを買おうと思ってるんですが完全にハードエンコだったら
処理能力に依存すると思うので1070のが速いでしょうけどGPU＋CPU(ソフトエンコ的な)もの
ならばGPUは一部部分しか利用されないのであれば1060でもいいかなと思いました
NVEnc動画エンコ、OBS-StudioでのNVEnc利用しての配信、ニコ生などストリームを多重視聴など
を主用途としてGPUを選択しようと思ってます、ゲームはしませんｗ
より高性能な1070,1080(これはちょっと)は必要でしょうか？ >>51
HEVCとなんの関係があるの？
スレチにも程があると思うんだけど NVEncのスレもあったみたいだけど落ちちゃったみたいね。
ちなみにそんなに変わらないらしい。
NVENC/CUDA [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/avi/1475726080/
17 名前：名無しさん＠編集中[sage] 投稿日：2016/12/30(金) 12:27:15.55 ID:wxSPyd46
NVENCの速度ってやっぱ高くて新しいヤツのほうが際立って早いんですか？
18 名前：名無しさん＠編集中[sage] 投稿日：2017/01/06(金) 04:52:50.65 ID:aesFY/0d
際立つほどの差があってほしいけどそうでもない ゲーム配信がそもそもの目的でほとんど負荷がないことが売りだからな
その代わり画質や圧縮率はソフトウェアと比べてはもちろんQSVEnc比でもかなり寂しい 違法な無反応チューナーやB-CASの規約に違反するTS抜きに関するスレッドを皆で追い出しましょう。
【自治】DTV板自治スレ5©2ch.net
http://echo.2ch.net/test/read.cgi/avi/1485486086/ 情弱は何故ノートPCで重い処理を行おうとするのか謎である ママに見つからずこっそりゲームしたいキッズが多いからね SIMD演算が多少弱いのかもしれないがRyzenのおかげでHEVCやっと普及する？それとももっとコア必要？ 待ってたけどｚｅｎは思ってたより結構高くなるようだから
諦めて別の買ったよ RyzenのスペックがホラじゃなくてIntelと再び対抗してくれたら性能も値段も良くなるかもね 業者はともかく個人ユーザーでH265でだめな理由が特にないしな 何が悲しくてインタレースなんて過去の遺物にしがみつかなきゃならないんだよ >>68
放送がインターレースなんだから仕方ないだろ？ >>65
止めはしないがVPやDviXみたいに再生環境限られる＆自然消滅するだろうからオススメはしないかな 企業1社単独で開発してるならともかくあれだけの本気のメンツで普及しないとかありえるのかな GPU支援とかのハード側がもっと柔軟になれば後付けで対応環境増やしたり出来そうだけどね
負荷や消費電力は専用ハードより増えるけど H.265やAV1にとって、H.264で十分だと考える層を切り崩すのは大変 UHD BDやBDにとって、DVDで十分だと考える層を切り崩すのは大変 画質が悪くても気にしないという層は置いといて、既存コーデックを熟成するのと世代交代するのと
現時点でどちらが高画質なわけ？というのが課題になってるんだよね
H264は当初のMPEG2の半分の容量で同等の画質なんてどころの話じゃ無くなっていて
HDで４時間4.7GBに入れてもSDMPEG2より画質が良いなんて事になってしまっている
コーデックの熟成でここまで高画質化出来る一方で、世代交代すれば理論上もっと高画質になるだろうが
実際はこれからまた新たに熟成が必要になり一からやり直しする事になる
これもちょっとうんざりする話なんだよね H264のHDからSD相当の解像度をトリミングしてSDMPEG2と比較しても
MPEG2より低ビットレートのH264の方が綺麗という事実だよ MPEG2だって圧縮してんだから、より高画質圧縮なH.264の方が綺麗で当たり前 おいおいそんな難しい話じゃ無いだろう。
当初はH264はMPEG2の半分のビットレートで同等の画質と言われた。
しかし、今やMPEG２エンコーダーの開発は終了しており、一方H264エンコーダーの開発は続けられている。
その結果、今では1920×1080の3Mbit/sのH264ファイルから720×480を部分切り出しして
720×480MPEG2の4.7Mbit/sファイルと比較してもH264の方が綺麗という結果になっている。
データー量にして6倍のものをビットレートは更に1/1.5、つまりMPEG2より9倍圧縮してもH264の方が綺麗なくらい
H264の開発は熟成されている。
ここに新しい世代のエンコード形式を世代交代で投入すると、開発は一からやり直しとなる。
新たに各パラメーターやアルゴリズムの最適値を探す事となるが、既に進んでいるH264を開発を更に進める事と
どちらが難易度が高いだろうか。
H265の開発が進んで一段綺麗になる頃には、H264の方がより綺麗になっているのでは無いか。 なんかこう・・・あれだな・・・３歳児が選挙演説してるのを見てる気分というか・・・ >>86
もうちょっとこう、そういう煽りじゃ無くてちゃんとしたレスをして貰えんかね。
どこが間違ってるとか、そこは実はこうなってるとか。
あなた自身がちゃんと理解して言ってるのか、甚だ心許無い。 古い車でも改造とチューンを繰り返していけばそのうちF1マシンより速くなるって言ってるようなもんじゃね？
無理だと思うわ
仮に速くなったとしてもその頃にはすでに古い車の面影無いどころか別の車になってる状態だと思う
より高画質にしようとするなら当然既出の規格には無いパラメータを追加しなくてはならない
そうなると違う規格になるのは当たり前だと思う >>89
それを言うならH264が既存のF1マシンで新規格がロータリーエンジン搭載みたいな新機軸。
どうもね、今までのエンコーダーの歴史を見てると、同じ規格内でもソフトやエンコードエンジンによって
画質に雲泥の差があったりするでしょ。
それこそ規格そのものよりチューンの方が重要なんだよね。
H265が出て来た時点でH264より段違いに綺麗というわけでも無かったし、これからチューンして行かなきゃいけない
規格だからH264との差が広まるのは随分先の事だと思うよ。 H.264の時もMPEG2のほうが成熟されていると言われていたみたいだけど代替わりしたし、まあ時間はかかるけどまた次世代に移行するんじゃないかな H.264の本格普及のきっかけみたいのあったの？
プロセスルールが5nmぐらいにまでなって、CPUエンコでも十分高速になるまで
無理とか？ H.264の本格普及のきっかけみたいのあったの？
H.265はプロセスルールが5nmぐらいにまでなって、CPUエンコでも十分高速になるまで
無理とか？ CPUで実時間以内の速度でエンコ出来る様になったから
H.265はまだまだ発展途上、AMD RYZENが起爆剤になってintelが本気出せば流行るだろう
264と265の関係はDVDとBDと似てるな ffmpeg -y -i 123.ts -vcodec libx265 -preset veryfast
これだとエンコが高速になるんですか？ veryfastだからその名の通り速いんでしょうねぇ >>93
縦720以上はXvid/divxなどのMpeg4 ASPでは力不足だったから
h.264への移行は必然だった ASPはMPEG公式のレベルだと最大の5でもSDまでしか対応しない規格だし、BDやHDTVでは使われないのも必然だった 「役不足」と「力不足」の誤用は有名だけど
もしかして「力不足」って言葉自体が誤用だと思ってるんだろうか・・ 力不足は知らなかったぽいけど、必至だなぐらいは適切に使えるんだな 力不足は知らなかったぽいけど、必死だなぐらいは適切に使えるんだな 何かおかしいのかなって辞典で調べてもおかしいところはなさそうだった
ので、どうおかしいか具体的な内容を俺も知りたいな
まぁ、言えないだろうから
次あたりスレ違いとかしつこいとか言ってくるに１００ペリカ
最近こういう手合い増えて困る デリケートな話だが、知能指数が低めの者は周囲からなじられる事が多いので攻撃的な性格にになりがちなんだそうだ
昔はPCを扱うにも知識や論理的思考、あと費用も必要だったから、ネットもある程度の知能を持つ者のみが参加出来た
しかしもう昔ほどPCを扱うのは難しく無いし、スマホもあって以前には居なかった様な知能指数が低い者も気軽に参加して
現実社会では出来ない様な憂さ晴らしをここぞとばかりにやる
でもなあ、そんな知能指数が低い者がエンコーダーに興味を持ったところで理解出来るものじゃ無いと思うんだがな
なんでこんなスレに居るのか不思議だ AMDのRyZenってコスパものすごく評価されてるみたいだが
エンコ速度もcore i7よりコスパ良く高速なのか？ エンコ速度は元々マルチスレッド性能に注力してたAMDの方が速かったような気がする >>113
6950X等、8コア以上での比較だとおそらくi7が高速だろうけど、それ未満のi7より高速なCPUをより安価に買える
28日にレビュー解禁みたいだし、それを待ってみたら >>114
そうだったか
欠点目立つイメージだけど確かにマルチスレッドごり押し路線だからエンコには強かったのか
>>115
それならなかなか期待できそう
解禁は2/28だったか。3/3が日本か
楽しみだ〜 レビュー解禁も3/2という話もあるようだから
気長に待つべし intelがryzenを警戒してCPU値下げきたー ttp://www.itmedia.co.jp/lifestyle/articles/1702/28/news140.html NVENCのH.265エンコーダーってなんでBフレーム使えないんだ 目的が違うから。
元々、ゲームのライブ配信を目的に付けてる物だから、
レイテンシが伸びるBフレは邪魔ってだけかと。 きたねー動画送って受信側でWaifu2xみたいなAIフィルタをかますやつでしょ x264の速度結果みたらもっと速いかと思ったがx265 はやっぱり苦手らしい… それは今後x265のバージョンアップで対応するんじゃね
最適化してもavx2使った方が遅いって場合ならcpuチェックでryzenだったら自動でavx2オプションがオフになるだけだろうし AVX2そのものは有るけど、
実行は128bit x2回で実装されてるから、
効率悪いだけ。
intelは256bitを1回で処理する。
intelのAVX2に最適化されてる物は、
みんな影響あるでしょ、恐らく。 AVX2使うと発熱で速度落とすintel
AVX2の速度は遅いが低電力尚且つ全コアフルロードできるAMD NVENCはBフレ無いんだからx264より当然奇麗だろ、輪郭をよく見てみろ 265の方が肌の質感がのっぺりしているし右足の膝当たりの暗い部分にブロックが目立っている x265でまともな設定でエンコやって比較しろよ
このスレの住人はクソ画質なハードウェアエンコはつかわないだろ x265ってインターレース プログレッシブどう見分けんの？
MediaInfoに書いてないんだけど インタレ非対応なはず
規格にあったとしても圧縮アルゴリズムと相性が悪すぎて
まず実装されない あるで
--interlace <false|tff|bff>, --no-interlace
0.progressive pictures (default)
1.top field first
2.bottom field first
HEVC encodes interlaced content as fields. Fields must be provided to the encoder in the correct temporal order.
The source dimensions must be field dimensions and the FPS must be in units of fields per second. The decoder must re-combine the fields in their correct orientation for display.
ただしデコーダがあるかは謎 >>141-144
今のところ無いって事か
thx all >>144
x265 rev3©2ch.net
http://echo.2ch.net/test/read.cgi/avi/1462270195/188
188 名前：名無しさん＠編集中[sage] 投稿日：2016/10/09(日) 02:11:19.92 ID:zdE5+A6z
https://trac.ffmpeg.org/ticket/5514
HEVCのリファレンス実装のhmなら正しくデコード出来るらしい GB単位のMPEG2-TSを全部NVENCで爆速エンコしたおかげでHDD容量空きまくりワラタ >>148
GTX10X0？9X0？
H.262からH.265でそんなに変わるんか
ffmpegでNVENC使うとなんか緑色になって映像破綻するんだよね… x264でも動きさえ少なければ1.5Mbpsで十分だよ NVENC使ってエンコードした場合、例えば1050と1080でどれ位速度差って有るんですかね？
CUDAのコア数だと3倍以上違いますが、そんな単純なことではないですよね？ NVENCのh.265はBフレないんだから、そりゃ綺麗だわな Bフレがないから綺麗っていうのがわからん
圧縮効率悪いんじゃないの？ 圧縮されないという事は画質を維持出来るって事だ、あとはググれ そんなに得意げに頭悪いこと言われても、その・・・笑うしかないんだけど・・・ 一秒間のビットレート上限決めた場合はbフレあった方が、iとかpとかにビットレート割り振れて画質良くなるんじゃないの？ >>153
NVEncはそれ用のVideoEngineが載っててエンコだけならグラフィックカードの世代が変わらない限り一緒 NVENCのH.265はむしろBフレ使えない割に
同ビットレートでの画質が綺麗みたいな評価だったような
同じくBフレ使えないQSVのH.265がBフレ使えるH.264で設定追い込んだ方がマシじゃね
みたいな扱いなのに対して >>154
>>160
ありがとうございます、CUDAとは違う所で動いてるんですね。
NVENCの速度比較が検索しても出てこないわけですね。。 >>158
頭いいこと言えない奴にそんなこも言われても…その…笑うしかないんだけど… bフレームが無いから同容量ではソフトウェアに比べてハードウェアエンコードは画質が悪いと言われてるのに、>>157て言っちゃうお前はググって何を見つけたんだ？
>>151のソースをソフトウェアx265でbフレーム使って1.5mbpsでエンコしたほうが、元になるフレームの画質維持できるから画質は上がるよ NVENCの話なのにソフトウェアエンコの方が画質が良いとか当たり前のこと得意げに言われても…その…笑うしかないんだけど… この際ファイルサイズは小さくならないのか画質は綺麗にできないのか両方なのかはっきりくっきりエンコさせろ >>165
そのソフトウェアの方が高画質になる理由の一つがbフレームの存在だろ、>>155,157はどういう意味での発言なの？
bフレームが無いから綺麗って具体的なソースurl頂戴 x265でBフレーム有りと無しでエンコードしてSSIMを比較したけど有りのほうが高かった。 I、P、Bの中でBフレームの画質が一番悪いという話と混同してるだけじゃ？
Bフレーム有の方が容量当たりの画質は良いに決まってるし Bフレームあった方が綺麗だろさすがに
Bフレームあった方が縮むし 普通はそうなんだがググったら出るらしいぞ！俺は見つけられなかったが インタレース対応だけど、フレームからフィールドへの分割と
フィールドからフレームへの合成は自前でやれば、現時点でも問題なく使えるっぽい
x265でエンコードしてL-SMASHでmuxしてFFMPEGでデコードしてみたけど特に問題はなかった
できたMP4をちゃんと再生できるソフトがないのが問題っちゃ問題だけどw
ちなみに1440x1080@29.97fps(DAR=16:9)のインタレースHEVCなMP4をMediaInfoで見るとこんな感じ↓
http://i.imgur.com/iKgqhs4.png FFMPEGでデコードしたときフィールドごとにAVFrameが出力されて、
トップフィールドはAVFrame.top_field_first=1、ボトムフィールドはAVFrame.top_field_first=0に
なってて一応区別できるようになってるっぽいけどこれは仕様なのか？ H.265のインタレ対応って簡易的なものらしいから高度なインタレのH.264と比べて最終的な圧縮効率は同等くらいなのでは勝手に思ってる 方式からして当たり前かもだけど参照距離=1でやると酷いことになることはわかった H.264のインタレも
QSVなんかのハードエンコで採用されてる簡素なPAFFと
x264なんかで採用してる高効率なMBAFFとあるからな 比較
1. オリジナルTS
2. x264 2pass 1500kbps
3. x265 2pass 1500kbps -> QSVEnc h264 icq=10 (そのままだと再生できないので）
4. TMPGEnc 24p化 x265 2pass 1500kbps
mpc-hpで再生してprint screenした
1: http://i.imgur.com/NwWMBQ5.png
2: http://i.imgur.com/UxQj1Ib.png
3: http://i.imgur.com/yPsDmHm.png
4: http://i.imgur.com/rwvwh3J.png 昔はエンコの破綻みるのはハルヒのOPだったけど
最近は実際なのか その辺の知ったか情弱サイトがやってる画質比較だと画像に平気でJPEG使ってて「あっ・・・（察し）」ってなる yuvの赤のにじみを軽減させるフィルタの効果を説明してるサイトの画像がjpegだったのは笑ったわ
フィルタ掛けてもjpegでまたにじませてるんじゃ意味無いのになｗ >>185
動きが少ないところはVP9、動きが早いところはx265が良い Galaxyを買う気はないが大手のスマホメーカーの1つがライセンス契約を結んだからこの流れに追随する動きが出てくるといいな
SoC自体はHEVCのハードウェアデコード/エンコードに対応してるのになかなか活用されてないのが現状だから
Samsungが4K UHD注力へ加速 HEVC Advanceと提携
http://ascii.jp/elem/000/001/464/1464258/ 4Kとか欲張りすぎただけ、3Kで我慢しとくべきだった。 >>189
この件についてなぜVP9にGoogleが関わっているのか、Alliance for Open Mediaの立ち上げに関わったのがAmazon、Cisco、Google、Intel、Microsoft、Mozilla、Netflixなのかというワケを考えたほうがいい
HEVCに限らず動画圧縮は特許だらけでコストがかかっていて、今のまんまじゃ4Kネット動画市場を躊躇しないで拡大したらH.265の特許侵害で裁判おこされまくることになる。
今のままじゃ、これこそトイレットペーパーの芯に特許料を要求されるようなものになる。
そこでフリーの動画圧縮コーデックでかかっているコストを劇的に落とす必要があるってわけ。
特にアメリカ国内では「10Mbps程度でも8K動画が可能」といった極端なほど圧縮比が高い動画圧縮コーデックの需要がある
・・・というのも、これにはアメリカの事情がある。アメリカでは回線速度が10Mbpsでもブロードバンドで通用するレベルの国だからだ。 アメリカは国土が巨大すぎて通信インフラのリプレースがノロくて、通信回線は3〜20Mbpsが平均で、100Mbps以上のFTTHが普及しているのは大都市だけ。
そしてアメリカの通信インフラはコムキャストが独占しているんだが「全米最悪のクソ企業」という烙印を押されているくらい悪評高い企業で、かつての日本の旧電電公社級に酷く・・・
丸っきり競争相手がいないから、安直に儲けるために回線速度を上げる・高速回線を安値で提供する努力をしていないのが原因。
カスタマーサービスや顧客サービスに至っては「通信回線を“使わせて”やっている」従業員はネ申、顧客は土砂と同じ扱い
なぜトランプ大統領がソフトバンクの米携帯電話会社買収を歓迎したかといえば、こんな酷いアメリカの通信インフラを少しでもマトモな水準にしたいという期待から。
アメリカの通信インフラは韓国や台湾の国民から「なんでFTTH入れないんだよアメリカ人！！後進国m9(^Д^)ﾌﾟｷﾞｬｰ!!」
「アンタ騙されてるよ！！俺の国じゃ1Gbpsがブロードバンドなのに、きょうび10Mbpsなんてナローバンドなんだよ！！無知m9(^Д^)ﾌﾟｷﾞｬｰ!!」とバカにされてもおかしくないくらいショボい。 米国のブロードバンドを取り巻く現実について一番怒りまくってるのは、Google。有り余るカネを使って自前でコムキャストに対抗するFTTHのISPを始めることにしたくらい
コムキャストみたいな汚く儲ける悪徳企業を放置しておくと、これこそ自社の将来性、アメリカの未来、インターネットの未来が危機に晒される
（提供範囲は米国の一部） かつての東京めたりっく通信がADSLでNTTのISDNを脅かした様に、googleが光通信始めればいいじゃん コムキャストは「米国一のワースト企業」を決める「Worst Company in America」で何度もワースト１に輝いてる
この「Worst Company in America」は投票で決まるんだが、とにかく米国のインフラ系企業は評判が悪い
コムキャストは日本ではなじみが薄いかもしれませんが、ＮＢＣやユニバーサル・ピクチャーズの親会社です。
S&P 100、NASDAQ 100の構成銘柄です。
ユニバーサルの映画のオープニングロゴのなかに「A COMCAST COMPANY」と文字が入ってます。
https://consumerist.com/tag/worst-company-in-america/
https://billfixers.com/blog/21-times-comcast-worst-company-america
https://www.prdaily.com/Main/Articles/Comcast_earns_Worst_Company_in_America_designation_16451.aspx
https://consumerist.com/2014/05/07/watch-antenna-company-deliver-a-worst-company-congrats-cake-to-comcast-hq/
ちなみに、この「Worst Company in America」を主宰するのは、世界最強の消費者団体「コンシューマーズ・ユニオン」だ！！ NTTは半官営？企業なので、
NTTの線・局舎を他社にも使わせる、みたいな手が使えたが、
アメリカでコムキャストの足回りを他社にも使わせる、みたいな手が
使えるとは思えん >>196
コムキャストはアメリカで最も嫌われている鼻摘みモノの悪徳企業で、まさに“そびえ立つ糞”そのもの。
･･･。
コムキャスト本体も独占インフラに粗悪なサービスと時代遅れの通信インフラ、抱き合わせ番組だらけの高額チャンネルプランだらけのCATVで豪快に儲ける糞企業だが、系列会社も安直な金儲けしか頭にない糞企業揃い。
大口献金先の民主党を御輿に乗せて持ち上げて、トランプ大統領と共和党をコケ下ろす偏向報道ばかりしていた糞マスゴミのNBCユニバーサル
製作予算はかかっているけどハリウッドテンプレートそのままの内容の脚本で鑑賞を始めたら30分以内にオチがわかる糞映画ばかり作るユニバーサルスタジオ
さらにAT＆TやTモバイルも傘下に収めていて相変わらず時代遅れの通信回線で糞みたいに儲けている
共和党政権になったから、遅かれ早かれトラスト法が適用されて会社がバラバラに解体されるのも時間の問題 >>190
>>200
アメリカでは回線速度が10Mbpsでも「ブロードバンド」で通用する以上
「10Mbps程度でも8K動画視聴が可能」といった極端なほど圧縮比が高い動画圧縮技術の需要があるってわけだ。
「60分の8K動画を視聴しようとしたら、ダウンロードするのに48時間以上かかる」じゃ普及するわけがないからな
Alliance for Open Mediaが狙うのはロイヤリティーフリーというだけでなくHEVC/H.265より高圧縮比だろう
YoutubeもVP9の後継はAlliance for Open Mediaが開発したものになるはずだからな
・・・だからVGAやCPUを買うなら待ったほうがいい。
Alliance for Open MediaにAMD,ARM,NVIDIA,Intelがいる以上、ハードウェアサポートされるのも時間の問題だからな
ちなみにAlliance for Open Mediaについて一番露骨に不快感を示しているのはApple。理由は、H.264やHEVC/H.265のパテントプールで、特許を所有する企業の1社だから。 AV1のハードウェアサポートはそのうちされるとは思うけど規格完成が当初の予定より遅れてるみたいだからなあ
いつまで待てばいいのやら 再生環境が整うなら別にどっちでも良いんだけどねぇ。 Alliance for Open Media Members
Adobe Allegro Amazon AMD Amlogic ARM
Ateme BBC Broadcom Chips&Media Cisco
Google Intel Ittiam Microsoft Mozilla Netflix
NVIDIA Polycom Socionext VeriSilicon Vidyo XILINX
http://aomedia.org/about-us/
仲間が増えたよ！！
やったねたえちゃん！！ 地上テレビジョン放送の高度化技術に関する提案募集の結果
ttp://www.soumu.go.jp/menu_news/s-news/01ryutsu08_02000173.html
◇現行 12セグ(MPEG2) + １セグ(H.264)
↓
◆提案1 水平偏波 7セグ(MPEG2※) + 5セグ(4K放送一部帯域) + 1セグ(H.264)
垂直偏波 4放送専用帯域
--
※MPEG2は新エンコーダ
問題点 4K受信には、水平、垂直両偏波対応UHFアンテナへの交換が必要
２Ｋの画質が劣化する。（ＭＸテレビ並みに）
◆提案2
韓国が次世代の世界標準をめざして実験している技術
ttp://japan.hellodd.com/news/news_view.asp?t=dd_jp_news&mark=3758
不具合で、実証実験延期中 ■ コーデック別音質 ■
（NAB資料）・・・http://i.imgur.com/6nE8rpq.jpg
※AAC 5.1ch 320kbps≒DTS 5.1ch 448kbps AAC 2ch 256kbpsはこだわらなければまずまずの音質だね
AAC 2ch 192kbpsは音質悪すぎる
映像のほうは、2020年以降は、HEVC対応チューナー積んだテレビ・レコーダ等のみ製造・輸入許可、
2030年頃にmpeg2を終了してHEVC移行でいいよ 放送する側があきらかに音質落としてから流してるから ATSCのAC3やDVBのMP2と比べると、ISDBの音声がAACで良かったと思う もうね高画質化は欲しい人達だけでケーブル使ってやってよ ソースがノイズの無い1080pなら4kテレビで見ても綺麗だしな
無理して高画素で放送するくらいなら、放送は2kを高画質化して、4k以上はメディア買うかテレビの補完機能でって方向のほうが幸せになる人は多いんじゃないか 三菱のls1を毎日使っての感想だよ
むしろ4k見てない人ほど>>215みたいなこと言う印象 アホ扱いする前に4kテレビにpc繋いで2kと4k入れてみなよ
ソースにノイズが少なければ1mも離れると、補完機能のおかげで気になるほどの違いなんてないから ならアホお前一人じゃん、なんで地デジの話に絡んだ
というか動画の場合、pcモニタにしても戻れないほど違うか？ VP9ってあんだけ時間かかるのにYoutubeで使われてるVP9はどうやってあんな膨大の量の動画をVP9でエンコしてんの？クラスタ？ >>223
What Does YouTube Do To Your Video After You Upload It? - YouTube
https://www.youtube.com/watch?v=aFLU6T15seY
分割処理っぽいね 環境整えたユーザーはH.265でのDRに移行できるようにならないかなあ
熟れているH.264でもいいんだけどとにかくMPEG2使うのをやめたい 1080p60fps 50Mbpsの動画をffmpegでh264_nvenc 12mでエンコすると200fps位でるけど
aviutlのnvencだと80fps位しかでないんだけど何が違うんだ。 >>226
AviUtlは内部色空間が広くて高精度だから高速エンコードには向いてないよ
高速ハードエンコしたいなら動画の入力から出力までなるべくGPUで一貫して処理できる方がいい Nvencc早すぎだろ、今まで俺は何やってたんだ・・・ 画質や圧縮率はしょっぱいけどな
リアルタイム配信用の機能を利用してるものだし 実時間の４倍５倍のエンコ時間が当り前だった世代から言わせてもらえば
ソフトエンコが実時間以下のエンコスピードでやってくれれば充分だな
Nvenccって画質はっきり劣化するし圧縮率下げてまで１０倍のスピードでエンコする意味はあまり感じない
むしろありあまるCUDAの能力は画質向上に使って欲しい
でも画質なんて見られりゃいいんだから手っ取り早く終わらしたいんだという人の気持ちも分らないでは無い ひと昔前のCPU+現行の安物GPUで細々とゲームやる自分にとっては画質なんて見れりゃいいからありがたい なんでもいいならつべに非公開でアップロードして
すきなサイズをダウンロードとかできないのかな GPUを画質向上には使えないんだろうな。使えりゃやってるでしょ nvencはgpuに載っけた専用チップ使ってるからgpu性能とは関係ないんじゃなかった？
もともとゲームしながら録画圧縮するための機能だからgpuに負荷かける方向には行かないだろうな x265をそのままCUDAやOpenCLで最適化できないものかなあという素人考え（倍精度が速くないと無理か） 一応、そこまで考えられた規格ではあるらしいが・・
ハード的にまだそこまでの域に達してないからね >>230,231
NVENCは確かに画質は多少は劣化はするが一昔前よりは画質はかなりマシになっている。少なくとも見れないほど汚いってもんじゃない。 >>236
NVENCは、Nvidiaのビデオエンコードエンジン。Tegra 3に統合されたエンコードエンジンをベースに，1080pのエンコードを4〜8倍速で実現できる。
また，消費電力も、わずか数Wに抑えられるので，CPUを利用したエンコードよりも省電力になる。NVENCは、Kepler世代以降(GTX600番台以降)のビデオカードに搭載されている。
ハードウェアエンコードは、昔と比べたらマシになってるがソフトウェアエンコードと比べたらビットレートあたりの画質が悪いという弱点がある。
そのため、ニコニコ動画への投稿にはオススメできないものの、Youtubeなどの比較的容量制限が緩いサイトへの投稿
編集中の確認出力、画質や容量をさほど気にせず、単純に高速でエンコードしたい場合などには十分使い物になる。 >>223
YouTubeの中の人が一番節約したいのはマシンリソースよりも回線容量と転送するデータの容量だからね
VP9でもかなりの圧縮比率だが、YouTubeの中の人はまだVP9でも満足していない。しかもH.265はロイヤリティが発生するから使いたくない。
だからAV1に手を出している >>235
っSmoothVideo Project
っ古井戸 nvencってqsvencと比べても微妙なイメージだったんだがそんなこと無いの？ 話の論点としてはSWより30%ぐらい大きくなるのを許容するかどうか
それさえ許容できるならQSV、NVEncともに十分a画質を保てる x264と同程度の画質をエンコ時間はかかるものの半分近いサイズで実現できるx265か
x264と同程度の画質に同じくらいのサイズが必要だけど爆速エンコできるNVENCのH265か
設定にもよる雑な比較だけどこんな感じじゃないかなあ >>246
違う、それならNVENC最高じゃないか
実際には、x264と同程度の画質に1.5〜2倍サイズが必要だけど爆速エンコできるのがNVENCのH265 >>248
逆に同サイズなら倍のクオリティに仕上がるから、H.265にしたら264エンコには戻れなくなる まあでも現状は再生環境が糞だから選択肢に入らない。 amazon fire tvぐらいしか思いつかないわん >>248
企画上同程度でサイズ半分いけるという謳い文句だけど現実はまだまだ アニメならビットレート半分でもそれなりに頑張れるけど実写は仕組み的に無理 つべ、Safari切り捨てか
vp9はハードウェアデコード対応してないの多いんだよな openCLで1pass目のベクトル解析をして2pass目はcpuでブラシュアップしてくれたら良いのに。 Bitmovin Supports AV1 Encoding for VoD and Live and Joins the Alliance for Open Media - Bitmovin
https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live-joins-alliance-open-media/
AV1と他のコーデックのPSNR、SSIM比較
画像もちょっとある 4月24-27日にラスベガスで開催されるNABショー（SU9007CM）のブースで、
放送品質で1.5Mbpsで1080pの再生を実現する初のAV1ライブストリームを展示する予定です。
現在、同じ品質を提供するためにH264などの従来のコーデックで約4〜15 Mbpsが必要です。
AV1はCDNとストレージのコストを最大10倍まで削減できます。
来週か楽しみgoogle翻訳スゲー まだ最適化されてないっぽくて0.02fpsくらいしか出なかった(aom-git-r20413_3666192)
エンコードしたファイル置いとくから見たい人は見て
https://www.dropbox.com/sh/syo2qb185vo0n3f/AADu3TprRyrTRIiz5-y4NI8Oa?dl=0&;lst=
デコーダーはここのLAVFilters-0.69-24-av1_test26-git-r3830(8da3109)を使ってね
http://tmod.nmm-hd.org/LAVFilters/old/ AV1は遅いままでも静止画なら使えそうだから
静止画像形式として早出ししてほしい >>266
$ aomdec .../tos_12000_yv12_aomenc_2pass_2000kbps.webm | mpv -
Playing: -
[file] Reading from stdin...
Warning: Failed to decode frame 2: Corrupt frame detected
Warning: Additional information: Reference buffer frame ID mismatch
(+) Video --vid=1 (rawvideo)
VO: [opengl] 1920x1080 yuv420p
Exiting... (End of file)
一瞬ちらつくだけだけどやり方あってる？ >>268
自分でビルドするか、もしくはここ
http://tmod.nmm-hd.org/aom/
>>269
まだ規格完成してないからリビジョンが変わると中身も変わる
だからエンコーダーとデコーダーのリビジョンが合わないと正常にデコード出来ないんだけどその辺大丈夫？ >>270
ありがとう。合って無かった
>やり方あってる
エンコードのやり方じゃなくて、自分の再生方法があってるかどうか聞いたつもりでいたけど、
聞き方良くなかったですね。
ごめんね >>267
vp8ベースのwebpが未だに定着しないのにまた増やしてどうするんだよ 保守ついでに若干スレ違い気味だけど
Real-Time Adaptive Image Compression
https://arxiv.org/abs/1705.05823
http://i.imgur.com/EOxPeRT.png
http://i.imgur.com/omivT0w.png
これ、静止画の圧縮の話だけどh.265より性能良いらしい
動画の圧縮もディープラーニングでブレイクスルー起きてほしいな どんなに高性能で使えるはずの新規格でも広まらなかったら意味が無いんですよってJpeg2000さんがいってた >>273
こんなに小さくて画質違うのは、相当深くて重いんだろうな なかなかすごいな
特徴だけ抽出してあとは本物っぽく見えるようにニューラルネットにお絵描きさせてるから
量子化ノイズまみれになったりせず輪郭もクッキリなんだね >>273
なるほど、ディープラーニングで失われたディテールを想像して描き直している感じなのか
猫の方の顔の毛並みがLSI模様みたいになってるのが気になるかな 初めてエンコードしてみたんだけどh.264って画質悪すぎ
h.265が出るまで待てなかった人はどんな気持ちでショボCPUでゴミ作ってたのか気になる 16コアのRyzenがもうすぐ出るらしいけどこれならH265エンコも楽になるだろうな。
まあでもH265は再生環境が糞だから結局H264でやるんだがｗ いい加減、主要ブラウザと主要OSメーカーがタッグくんで普及させろや・・
まずは、新画像フォーマットから。 もはや古くなってしまったといっていいJpeg2000すら全くといっていいほど普及してないからな ライセンス懸念が残っている限りそもそも商用サービスが広がらない。
趣味の世界だけになるかも知れないな。 DVDとBDみたいな関係になっちゃったよね
SD画質並でも明らかに265の方が綺麗なんだけど >>291
使い勝手で言えばそこまで差があるとは思えないな グラボ安いのでも積んでるけど
PSだけしか頭にないなら無理じゃね ちょっと早いかもと思ったけど次世代コーデックスレ建ててみた
ttps://echo.2ch.net/test/read.cgi/avi/1495774670/ エンコはデータサイズ圧縮出来てなんぼって考え方だから265しか使ってないわ
264でエンコするぐらいならオリジナルでよくねって思う >>299
このスレが実質的に次世代コーデックスレだからいらないでしょ >>300
H.265専用スレかと思ってたけど次世代OKならここにするか
1時間毎に建てるの面倒だし OKじゃないだろ
アンチが荒らしてるだけ
いい加減ウザいから他所でやって >>1
>圧縮効率がH.264の2倍な次世代ビデオコーデックH.265/HEVC、
>並びに同等の圧縮効率でフリーの次世代コーデック、VP9/Daalaを語ろうぜ たしかに最近エンコードに対する情熱が薄れて来た
8TBのハードディスクが3万しないで買える時代にそこまで躍起になって
圧縮のかかったソースを再圧縮する必要性を見出だせなくなって来たな
好事家の趣味の世界になって来た気がするよ 次スレではスレタイ変えたほうがいいだろうな。スレの後半で議論すればいいと思うけど
【4K/8K】H.265/HEVC その他次世代コーデックスレ
とかでいいんじゃないの。 2スレ目で既にこういう話が出てるね
【2016】 H.265/HEVC Part2 【8192x4096】
http://peace.2ch.net/test/read.cgi/avi/1359375342/795-796
795 名前：名無しさん＠編集中[sage] 投稿日：2013/09/08(日) 00:01:49.77 ID:3WDJPz9O [1/2]
次スレから「次世代コーデック総合」にしちゃえ
796 名前：名無しさん＠編集中[sage] 投稿日：2013/09/08(日) 02:24:21.00 ID:6G6XCF+f
【H.265/HEVC/VP9/Daala】次世代コーデック総合 Part3【2016/8192x4096】
こうか？ もうつべにあげてエンコされたのダウンロードしたらいいんじゃ まだ次世代コーデックの話は早い感じだけどあと数年で次世代コーデック出して貰いたいね
来年から4K8K放送が始まるけどH.265だから画質を落とさず圧縮するの無理になる
落ちたスレのタイトルにVP10って入れたけどVP10って開発が無くなってav1になってたの？ >>311 「H.265だから画質を落とさず圧縮するの無理になる」
これってどう言うこと？tsなら画質落とさず圧縮できるのかな
エンコ初心者でごめん >>312
今の放送はMPEG2っていうかなり古い技術を使っているから最先端の圧縮技術を使えばもっと効率良く圧縮し直せるけど、4K8K放送では最新のH.265を使うことになるからそういうことが出来ないってこと
あとtsって中身の映像コーデックは選べるから、ts=MPEG2って訳じゃないからね 放送用のH.265エンコーダの出来や設定によるだろうけど、
同じH.265でもより高効率な設定である程度圧縮することは出来るんじゃないの。
やる意義があるほどには縮まないかもしれないし、
そもそも4K/8K放送がそのまま抜けるようになるのかどうかは知らんけど。 >>314
まあそうだね
出来ないっていうは語弊があったスマン 放送のMPEG2採用はタイムスケジュール的に仕方なかったけど、ワンセグだけでもとなんとかH.264をねじ込めた
HDVでさえMPEG2で、当時とても重くて編集に向かないと言われていたな ビットレートが少なすぎるのとmain profileのせいで
ほとんど使い物になってないけどね 今度BSデジタルのビットレートも落ちるから、BSは高画質って事もなくなるんだよな
地デジももう少しビットレートないと、ちょっとカメラがパンしただけでバリバリとブロックノイズだらけ
むしろ解像度下げてでも、適正な帯域確保して欲しいものだ ビットレート落ちる時にエンコーダーも一新されるんじゃない？
ある程度は維持されないかな(希望的観測) 地デジがH264、H265になったとして再生できるテレビはどのくらいあるんだろ >>320
全くないよ
4K本放送受信出来るTVがまだ市販されてない理由が、まだ放送方式が固まってないから >>321
その通り、地デジ並みに帯域絞られるらしい
というか、総務省にNHK BSの広帯域を召し上げられてしまう、というべきか 地デジ相当まで絞られてなおフルHDって悲惨なことになりそう
悪いと言われてるMXクラスになりそうやね 解像度下げたほうが画質が良くなるケースって
圧縮アルゴリズムに改善の余地がある証拠ってことなのだろうか。 MPEG2のHD解像度なら、せめて今の3割増はビットレートがないと適正とは言えない気がする
HDVカメラが25Mbpsなのと比べると半分だし >>326
混雑しすぎや・・
>>328
ビットレートが少ないなら無理せず解像度を下げたほうが奇麗
どんあに優秀なコーデックでもビットレートが少なければアラが発生する firefoxが最新版でAV1に対応したみたいなんだがそろそろ仕様が固まったのかね？ >>331
まだ固まってないと思うよ。
自動翻訳だからよく分からないけど2017年10月を目指してるっぽい？
https://youtu.be/lzPaldsmJbk?t=42m19s 現状では、H265のハードウェアリアルタイムエンコーダより、
H264のソフトウェアエンコーダのほうが高画質 ハードウェアリアルタイムエンコーダ持ってるの？
まさかグラボの？ｗ iOS 11でついにHEVCのサポート来るね
Apple純正のカメラアプリでHEVCでの撮影が可能になるらしいから
今回のiPad Proと次期iPhoneはHEVCのハードウェアエンコードができるんだろう
Apple introduces iOS 11 | TechCrunch
https://techcrunch.com/2017/06/05/apple-introduces-ios-11/
Apple、iOSデバイス用OSの最新版「iOS 11」を発表 | iOS | Macお宝鑑定団 blog（羅針盤）
http://www.macotakara.jp/blog/category-54/entry-32649.html HEVCのパテントプールが更に増えて混乱してるっぽい？
Third HEVC Patent Pool Launches With Ericsson, Panasonic, Qualcomm, Sharp & Sony - Dan Rayburn - StreamingMediaBlog.com
http://blog.streamingmedia.com/2017/05/velos-media-hevc-patent-pool.html
H.265/HEVC特許暗黒時代 - Qiita
http://qiita.com/yohhoy/items/c2579097a507b1fbdddb iOS11は静止画もHEVCを利用したHEIFを採用するのね HEIFってリミテッドレンジのYUVを記録して画像表示時にYC伸長してるっぽいけど階調表現とか大丈夫なのかな。
試しにフルレンジで作ってみたら二重伸長しちゃっておかしなことになるし。
いや作り方が間違ってるのかもしれないけど。 現状自分にはHEIFをデコードする方法すらよくわからんｗ HEIFとBPGは圧縮技術的には同じものなのだろうか この記事読んだ限りではHEIFはコンテナの事を指してるみたい
【解説】iPhoneのAV機能は「iOS 11」でこう変わる (2/3)
http://www.phileweb.com/sp/review/article/201706/09/2567_2.html HEIFにx265で作った.h265ファイルも格納出来たよ。
ここを参照した。
Converting a JPEG to the new HEIF image format
http://jpgtoheif.com/
あとnokiaのサイトにBPGとの機能比較があって、BPGのとこに注釈で制約付きみたいなこと書いてあるからHEIFのほうがプロファイルとかレベルが上のものが扱えるのかもしれない。よく分からないけど。
HEIF Technical Information - High Efficiency Image File Format
https://nokiatech.github.io/heif/technical.html インタレ保持H264とbob化して60fpsにしたH265、どっちがきれいに残せる？ HEIF試してみたけど機能詰め込みすぎじゃないかねこれ
ブラウザとかで実装難しくて駄目になりそう
webpも機能をフルサポートできているのはchromeだけだし高機能画像フォーマットは流行らないよ
その前にライセンスの問題がありそうだけどね H.265の特許を持っているAppleは良いだろうけど、そうでないGoogle、Mozilla、MSは使わないかも。 いや、H265は放送規格でしょうよ
MSやGOOGLEがイヤイヤ言ったってデファクトスタンダードで決まったんだから迎合するしか無いよ Ｈ．２６４よりも高額なライセンスを払うぐらいなら、放送局も使わないのでは。
事実上のデファクトを決めるのはユーザーである放送局。 ライセンス料は機材費に上乗せされてるから局にライセンス料云々の観念は無いよ
H265に決まったらH265の放送用システムを購入するだけ
局は商売でやってるから小さいライセンス料をケチって節約するより
H265で帯域節約してチャンネル数を増やし商機を多くした方が儲かる h265は使用料が小さくなるか不明だし、交渉が必要な窓口が複数あるんだろ
>>339が解決しないと放送局も移行難しいんじゃないの ネットならともかく放送局は機材を購入するだけだから関係なくね？ いやいや放送局にそんな自由度は無いよ。決まった放送規格に準拠しなきゃいけないんで
国際規格であるISO規格に従わなきゃいけない決まりになってる
NTSCとPALみたいなもんで局が独自判断でうちはNTSCで送信しますとかPALで送信しますとかは出来ないのと同じ様に
H265送信が決まってるんだから局単独でうちはしないなんて言える自由度は無い ユーザーとしては早く一本化してほしいところ
pascalグラボだからしばらくは大丈夫だろうが 特許を持つところが全て放送局には請求しないと言ってる？
そのあたりは曖昧なのかと思ってたけど。 特許を払うのは放送局じゃ無くて機材を納入しているメーカーの方よ Apple的にはHEIFはiOS端末で必要な機能に全部対応できる理想的なフォーマットだな
ハードウェアデコードはA9搭載機から対応してるし秋頃にはiTunes StoreのコンテンツもHEVC版が用意されるのかも 放送規格として採用されれば受信機が大量に売れるんだからウハウハだろうな こんなパテントプールなんて結局、対してウハウハにならんと思うけど。
1社あたりがどれくらい収入があるの？？
大企業から見れば大した金額にならねぇんじゃねぇかな？？ 対してGoogleは自社製品と自社サービスで帯域減らせればそれでいいってスタンスだから
優れたフォーマット作っても広める気がまるでないってのがね >>377
たぶんH.264でたいした金額にならなかったので、今から分裂しているのだろう。 HEIF画像規格を読めるアプリってライセンス料はらわないといけないの？ パテントプールA「1ドル徴収！」
パテントプールB「1ドル徴収！」
パテントプールC「1ドル徴収！」
パテントプールD「1ドル徴収！」
パテントプールA「うちで使おうとすると支払いが3ドルになるんだが？」
パテントプールB・C・D「な、ナンダッテー！？」 パテントプールA「エンコーダからは1ドル徴収、配信事業者は正規ライセンス受けたエンコーダ使ってる限り徴収しないよ」
パテントプールB「エンコーダからは1ドル徴収、配信事業者は売上の1%徴収するよ」
こんな感じだろ デコーダーはどうなの？
電子書籍のばあいライセンス料どうなるんだろ x265ここ2年ほど色々試してたんだけど
使いこなせないから動画のエンコードに使うの諦めたわ
うちのモニタだと暗部がエンコーダが想定してるより明るく表示されるせい？なのか
階調つぶれが目立って見れたものじゃなくなる
スマートフォンで見ると特に問題はないから、悪いのはうちの環境なんだとは思うが…… 10bit色深度でやればいい
画質的にかなり底上げできる 決定版なんてない事一つ上のレスみりゃ分かることじゃん・・・
ソースやその人の環境や目によるっつーの
bit深度上げるっていうのは試してみても良いとは自分も思う
あと自分は暗部のブロックノイズ酷くなりそうなソースならやっぱりAQ3使ってる >>385
それは8bitの限界だよ。すでにモニタの表示能力は8bitの表現力を大きく上回ってる
ならした上で10bitでエンコすればいい HEVCの分散エンコーディングできる、
業務用じゃない安価なソフトウェア探してます
リリース予定情報とかでも構いません
Apple CompressorがHEVC対応してくる予定だけど
他にクラスタが組めるソフトウェアってあります?
安くプールを構築したいので出来ればWindowsで >>390
Cambria FTCみたいな業務用しかないんじゃないか？
そういうのが望みじゃないならソースを分割して複数台エンコ後結合しかないだろうな
ま、そんな事するくらいならコア数多いCPU使っか方が圧倒的に速そうだけども GPUに支援させてBフレームありでエンコードさせる技術は無いの? そんなもんは無いからHWエンコは速いんだと思ってた
refにもよるけどbframesとb-adaptって結構重いオプションだと思う
かといってbframes0ならソフトウェアエンコで同じ速度が出るとも思わないけど GPGPUを利用して、各種物理シミュレーションや機械学習やその他いろんな計算を
代行させてるのに、Bフレームだけは出来ないとは思えない 出来るんならgoogleあたりがとっくに実用化してるんじゃないか
gpgpuで何でもできるなら量子コンピューターの開発よりgpuに投資するんじゃないかな パスカル設計のNVENCはcudaによるBフレーム処理をサポートしていたような。
英語出来ない自分が英語版ウィキを読んだだけだから読み間違えてるかもしれんけど。 >>392
■QSV
H.264/HEVC(main)/HEVC(main10)の全てでBフレーム使用可。
■NVEnc
H.264ではBフレーム使用可。
HEVCでは最大Bフレーム数がゼロとなっており、少なくとも現時点ではBフレームは使えない。
■VCE
H.264ではBフレーム使用可・・・らしいのだが、Polarisでは何故か使えないらしい。
ただPolaris以前のものでもBフレームありにした方が画質が悪かったという声あり。
HEVCではBフレームは使えない。（AMF1.4ではHEVCでBフレームを使うためのAPIが無い）
こんな感じだったと思う。間違ってたら訂正してくれ。 QSVのHEVCはBフレームなしのNVEncより画質悪い。なんでだ？ >>399
Bフレーム使えるからってCPUみたく複雑な計算が出来るようになる訳じゃないから >>352
bob化して60fpsにしたHEVCの方が圧倒的にきれいだよ NVEncとかが役に立たないからCPUパワーに任せて、
Ryzenの8コアとかでエンコードしてるのが現状だしな
GPUが使えれば、たくさん載せて爆速にできるのに >>403
CPUエンコとGPUエンコじゃ目的が違うんだからずっと平行線、比べる意味がない
よって、>>402が希望する目的でGPUエンコ出来る日も、一生来ない CPUによるディープラーニングとGPUによるディープラーニングも平行線なのか? >>404
俺が言ってるのはNVencみたいなのじゃなくてGPUでやるソフトウェアエンコードだよ
CUDAやOpenCLでやるやつ >>405
流れ的にエンコだけの話、ディープラーニングは知らん
>>406
しかし、そんなのこそ絶望的じゃなかったか？
CPUと同じ計算をGPUでやりたいんだろ？
コア数が数千倍多いのに計算結果は100倍遅いんだぜ… どの程度用途が限定されてるのかはよく判らんけど、
今NVIDIAが世界的に注目されてるのは、ゲームだけが理由ではないのは確か 動画圧縮は動き探索がキモだけど、GPUだと難しいからね
抜本的な並列性の改善が必要だけど、実装する人がいるか 注目されてるのはディープラーニングでしょ。動画圧縮関係ないじゃん >>273のやつは動画分野でも研究してるっぽいよ
http://www.wave.one/icml2017
静止画と違って既存技術との比較がないからまだ成果は出てないようだけど、まあ後10年くらいで実用化されてもおかしくないんじゃね 動画圧縮はMPEGの時代から長いこと動き補償がメインだったからな
ディープラーニングっていうこれまでとは全く違う方法で動画圧縮に
ブレークスルーが起こればいいなって思うよ GPUの中身が、何か画像処理だけに特化されたような作りになってると思うのは幻想だ
ただの演算なんだから汎用的な計算のレベルまで分解できて、だからこそ
GPGPU（General-purpose computing on graphics processing units; GPU汎用計算)という
アイディアが生まれる
GPUがディープラーニングにしか使えないと思っちゃうのは、もう理解不能 アルゴリズムは複雑ではないが計算量が膨大で並列可能なものに、機械学習や画像処理、物理演算が当てはまるからその分野ではgpgpuが威力発揮するんじゃないの
cpuのようなこともgpuで出来るようになってるから注目浴びてるみたいなソースでもあるの？ >>413
ディープラーニングが流行ったおかげで脚光を浴びるようになったのは事実
NVIDIAが「謎のAI半導体メーカー」って言われちゃうくらいだからｗ
http://www.huffingtonpost.jp/2017/05/22/nvidia_n_16746954.html >>415
並列化できるかどうかが問題でしょ
CPUみたいなせいぜい数十スレッド規模じゃなくて、数千・数万スレッド規模で 画面全体をいきなり扱うみたいなホログラフなことをしてる訳じゃなくて、
小さいエリアに分解してるんだから並列処理の代表みたいなもんでしょ
そもそも、NVEncでやってることをGPGPUにするとできなくなる訳がない NVEncの品質でいいならGPGPUでできると思うよ
でもNVEncがあるんだからGPGPUでやる必要ないでしょ
俺が言っているのはx265の品質をGPGPUで実現するのが難しいってこと
動き探索は複雑なアルゴリズムで計算量減らしてるから
単純化して並列化してもCPUに勝てないんだよ なんでそう考え方がアナログ的になっちゃうんだ
CPUがやってる計算をそのままGPUに代行させれば、1bitも違わずに同じものができる
それがコンピュータ そりゃそうだが、その代わり全く速くならないどことか、10倍以上遅くなると思う
数百動画くらい並列にエンコすれば速くなるかもしれないね つまり、並列化ができれば速いができない筈という予想な訳だ
画像処理は並列化は普通に大得意だと思う 一向にGPGPUを使った爆速エンコーダーが出てこないとこみると、
GPGPUは条件分岐が苦手で、エンコーダーが苦手なアルゴリズムが
含まれてるんだろうと予想はしてる 画像処理は並列化が得意とか、そんな一般的な話をしてるんじゃなくて
動き探索は並列化が難しいって話をしてるんだけど・・・ いや、Bフレームが無くていいなら、現状で爆速エンコーダはある
なんでBフレームを付けてくれなかったかというと、
それが難しいからというのもあるだろうけど、
サイズを縮めることはグラフィックボードの本懐ではないから
とにかく速く、リアルタイムで、ということを追求してるので、
既に帯域が足りてるところに遅くなるだけの処理を増やしたりはしない
やればできる子なのにやらないので、GPGPUにやらせようと あの大量に積んだGPUが穴掘りじゃなくエンコードに有効だったらよかったのに CUDAを使ったエンコーダーは実際に映像編集ソフトなどで既にあるんだが
確かにエンコードスピードは早くなるが一番良くて数倍程度で
併せてCPUの稼働もフルに近くなる
数千コアも使ってるにしては期待はずれな結果なんだが
何故こうなるかと言うとメモリが関係してくる
グラフィックカードの搭載メモリ量は多くて数Gバイトだが
これを何千もあるCUDAコアに割り当てると1コア当りでは１MBレベルになってしまう
エンコード作業に使うバッファとしては全く足りず頻繁にスワップが発生して速度低下し、
数千コア分のスワップを処理するCPUもパンク状態になってしまう
結局のところ、数千のコアが充分に動作出来るのは1コアが使うのが1MB程度の処理に限られ
それ以上の事をさせるにはコア以外の部分でスパコン並に大掛かりなシステムが必要になってしまうわけだ GPUが大の苦手なのは、条件分岐だってバッバが言ってた。
そしてソフトウェアエンコは条件分岐の塊だってジッジが言ってた。 全部自分でやるか全部任せるかの二択である必要はなくて
これ計算しといて、と切り分ける部分は先輩がやって、
新入りは意味も判らずひたすら計算、という図式が効率的 まだx265は開発中だしのんびり行きましょう
ちょうど10年前のx264も言うほど賞賛されていたわけじゃなかったし
今後メインストリーム帯のCPUコアが増えていくだろうからエンコの負担が減ることに期待してる >>432
先輩後輩間でコミュニケーション爆発が起きて低速化するというオチ GPUの並列計算はCPUのそれとは違って、似た事しかさせられんのよ
例えば(1,5,25,8,-3,0)といった入力値全てに対して2をかけろ
というようなことね
分岐が苦手なのもこれが原因
CPUに比べて沢山コアがある代わりに１つ１つの計算は遅い、なんて理解は間違い ほんと色んなとこにいるけどGPUを銀の弾丸みたいに思ってる人多い いまだにGPUに積んであるハードウェアエンコーダによるエンコードと
GPGPUによるエンコードがごっちゃにされてるくらいだし どんな用途にも使えるとは思わないけど、
動画の圧縮用途には向いてる気がする 単に削るだけの処理ならGPUは速い。
どうやって劣化を抑えて削るか判断する処理がGPUじゃお話にならないって事。
そしてソフトエンコする層は2つめを特に重視するので
WinWinにはならんの、どうあがいても。 GPUが分岐が苦手というのは原理の話だが現状もうその欠点を補う技術が開発されたうえでの話なわけで
原理だけで絶対論のように言うのはちと語弊があるんじゃないか だから得意な処理で役割分担しようってのがヘテロジニアス・コンピューティング 感覚的だなあ
GPUのエンコードは速いし綺麗
既に実証されてる
但し、サイズは相対的に大きい
Bフレームが無いから
無いのは困難だからじゃなくて、設計思想と合わないから
GPUはリアルタイムのエンコード処理を想定してる訳で、
それはつまり今撮影した動画をそのまま配信、とかのケース
未来のフレームなんてまだない
そもそも、片方向のエンコードはできるのに、両方向にした途端に
分岐が複雑すぎて処理できなくなる訳がない
近いうちにBフレーム付きのH.265がNVEncにも出るから、
その時に恥じ入ってくれ 恥じ入る準備は万全だが、〜訳がないてのは感覚的じゃないのか もし、H.265でCPUより高速で綺麗なGPGPUエンコーダーが出るなら、
H.264で既に出てる。 つか、この話は本当に動画圧縮アルゴリズムに詳しい人いないと無理だろ。
俺は長年プログラミングやってるけど、動画圧縮のアルゴリズムの詳細は
さすがに知らんわ。
画像処理くらいならSIMD使って最適化したことあるし、
画像処理の畳み込み演算とかまさしくGPGPU得意なのはわかるが、
動画圧縮はぽかーん？だわ。 2時間映画を同じビットレートでエンコしても30?ぐらいしか変わらない気する H.265のNVEncとx265比較で >>430に書いたようにCUDAを使ったGPUエンコーダーは業務用途で既にあって
別にリアルタイムエンコードに限った用途なんて事は無いし、
またH264では出てないなんて事も無いんだが >>448
徒歩と自転車で同じ時速で移動したけど到達時間がほとんど変わらなかったって言ってるようなもの >>451
それって、Kepler以前にCUDAでGPUエンコしてた時のGPUアクセラレー卜機能の事言ってだろ？
違うならその業務用ソフト言ってみ >>442
>>397で
・QSVならHEVCでもBフレームが使える
・H.264ならQSVでもNVEncでもVCEEncでもBフレームが使える（ただし環境にもよる）
と書いたのに、なんで「（GPUエンコでは）Bフレームが無い」とか言ってるの？ NVENCがHEVCでBフレームなしだからでしょ
NVENCは専用HWでGPUコア使ってないからGPGPUじゃないんだけどな
>>451
俺もどういうのか知りたい。x264やx265のmediumより速いのか？ >>430
これはエンコードじゃなくてフィルタ処理をGPUでやってて
エンコード自体はCPUでやってたってオチじゃね 【2013】 H.265/HEVC 【7680x4320】
http://toro.2ch.net/test/read.cgi/avi/1317066231/
185
圧縮率は「H.264」の2倍、超高精細やスマホを視野 動画圧縮技術の次世代国際標準「HEVC」
鈴木 輝彦 氏ソニー システム＆ソフトウェアテクノロジープラットフォーム 共通要素技術部門 信号処理技術1部 主任技師
http://techon.nikkeibp.co.jp/article/HONSHI/20120412/212513/
http://techon.nikkeibp.co.jp/article/NED/20120409/211909/
189
読んだけど一部要約すると
AVCは今から１０年以上前に仕様提起され標準化されたものでエンコードに使う演算装置がシングルコアで進化していく、
クロック数が右肩に上がっていくものと想定して難しいエンコード方法を採用して標準化されたんだとさ
HEVCは既存技術に魔法のような新技術を加えて劇的な圧縮率向上をはかるのではなく
既存技術を今主流のマルチコアCPU、GPU、並列処理への最適化と処理の簡略化、この１０年での改善をはかるみたい
最後のエントロピー符号化はCAVLCは廃止、進化したCABACへ一本化
その他新技術ももちろんある >>457
今回はわりと豊作だった
さて次はなにが入るんだろうか >>451消えたな
>>453が図星で顔真っ赤なんだろう >>453
>>455
イマジカで組んだシステムでCUDAを使ったプログラムを独自に書き起こしたって話のものだが
しかしやけに喧嘩腰だな
民生用ソリューションの話だけしか知らずプログラ上の詳細を語れる知識があるわけでも無い人間が
原理的な話で自説を固辞するのはあまりに無理があるだろう
技術の話なんだから理論的に考えれば答が出るので喧嘩腰になる意味は無いんだが
いたずらに感情的になるタイプの人間は技術の事を考えるには不向きじゃないかね
いらぬ対抗意識を燃やす人間の相手をするのは正直面倒だしこちらに益も少なく
うんざりするのであまりやりたく無いんだが イマジカがcudaエンコーダ書き起こしたってソース見つからないんだけどリンク頂戴
長い割に中身皆無の書き込みよりソース持ってきたほうがお互いのためじゃない？ >>461
証拠だけ出せば良いものを感情的になってダラダラ長文書いてるアホはおまえ なんでもかんでも宣伝していて素人がネットで情報を読めると思っているのは世間知らずだろう
ちゃんとお金払って長年付き合わないと分からない世界があるって事は知っといた方がいいよ
ここまでCUDAをエンコードに使えないという理由をまともに説明している意見は無いが
単純に自分の知る範囲で見かけないから出来ないに違い無いとたかをくくってるようにしか見えないな
なんの理由があって専門でも無い事をそこまで言い張りたいのか分からないがとても真摯な姿勢とは思えない
ただ言いはりたいだけの喧嘩腰の分らずやにこっちがわざわざ理解をしてもらう努力をする理由は無いね
なんの得にもならない
出来ないと言うなら他人に資料求めて無いで、素人考えの一人合点で無くちゃんと勉強したプログラム上の理屈を提示しなさいな
その方が早いよ ｱｳｱｳｳｰT Sa08-svru
恥ずかしい勘違いで引っ込みつかなくなったアホ そんなにGPU使いたいならOpenCLオプション付けてエンコードすれば >>467
あなたの書き込みは蓮舫の会見と似てるんだよね
抽象的なことばかり長文で書き込んで、具体的には何も示さない 一応まともにつっこんでみたつもりだけどスルーされてるみたいだし、
横からつっこんでる人も無駄に相手しないでスルーしたほうがいいんじゃないかなって。 なんか中傷ばかりだねえ
業務用機器があると言っても信用せず一般販売の機器でも無いのにカタログを見せろと来る
かと言って出来ない理屈が説明出来るわけでも無し、それにしては出来ないと言い張る
自分からはソースは愚かなにも確かな説明もせず、ただ出来ない信じられないと言い張ってるだけだが
自分は何も説明する気も無く相手にばかり自分に理解出来る分かり易い説明ばかり求めるのは
全くフェアじゃ無いね
お客様のつもりなのか知らないがどうにも傲慢だ
改めて聞くがそこまで出来ないと信じる根拠はなんなのかね
それとも出来たらなにか都合の悪い事でもあるのかね
こっちにしてみればそちらの根拠の無い出来ないという信じ方の方がよほど宗教がかってて意味不明だ 俺はCUDAエンコーダーはあってもいいと思うが、それはあくまで
ハイブリッドで、みんなが期待してるような一番画質や圧縮率に関わり
一番時間かかる部分はどうせCPUだろってオチなんだろと思う。 だから、言葉の問題になるが、
もしこんな感じのシステムならCUDAエンコーダシステムとも呼んで問題ないが、
これじゃ、俺の中じゃGPGPUは今までどおりエンコードは苦手と言わざるを得ないな。 >>474
プログラムに強いと思い込みたい業界通気取りっぽいから何言っても無駄じゃない
「苦手」に反応するスクリプトみたいなもんだと思ってスルーした方がいいのかも つい先日、QSVスレで協力してもらって、x264/x265/VP9/QSVEnc/NVEnc/VCEEncの
SSIM/ビットレートグラフを作ったけど、アニメのような比較的圧縮しやすいソースでは
NVEncのHEVC(main10)が結構良い結果を出してたよ。
http://mevius.2ch.net/test/read.cgi/avi/1486130737/335
まあ、あくまでもトータルのSSIMを計算しただけのグラフにすぎないから、
諸々のシーンでの仕上がりとか最終的な画質は目視で確認しないとわからないけど。
実写のような複雑な映像だとやっぱり苦しいし、HEVCについてはどのHWエンコーダも
H.264に比べて調整不足な感じはする。
NVEncのHEVCでBフレームが使えるようになったり、各社で調整が進んでいくと、結構良いものになるかもね。
さすがにソフトウェアエンコーダを超えるほどにはならないと思うけど。
どうせ個人向けのGPGPU実装エンコーダ、しかも質の良いものなんて出てくる可能性はまず無いんだし、
既存のHWエンコーダの改善が進むことを期待してたほうがいいよねっていう。 >>461
そういう業務用ってことは、例えば2時間の映画を3日とか1週間とかかけてエンコするやつかな
それだったらCUDAで高速化も納得 >>474
先ずCUDAを使ったエンコーディングはCUDAが常にCPUから情報を貰いCPUからの命令で動く以上
構造的にハイブリッドでしか在り得ないよ
そしてCPUより苦手とされる部分はCPUの何千倍もあるコア数をぶん回す事によって
スケールメリットで克服するんだが、>>430で書いたようにいかんせん使えるメモリー量が少ない
結果ハウスメイドのシステムを作っても速度の上昇は数倍に留まってしまう
これはエンジニアから受けた説明だよ
業務で使うには数倍の速度向上でも充分有り難いが汎用品にするにはあまりにも無駄が多く
コストに見合わない（大量生産品としての流通が見込めない）事になり具体化の例も限られるだろうから
一般人がこれを無視するのは正しい
ただ、そういった詳細を知らないままなんとなくの憶測でGPU処理はCPUを超えないと断定してしまうのは正しい事では無いね >>478
かける時間は長くても実時間と同じから数倍という所かな
その間に何パス出来るかという感じだね
設定数値としては100パス以上設定出来るが
かけられる時間との見合いで何パスと決めるかは経験則によるところが大きい様だった >>479
もし分かればそのハウスメイドシステムの構成を教えていただきたい
CPUは何とか、GPUは何をいくつとか >>479
論点をズラしだしたから
クソ雑魚ナメクジなんだなと分かったので
もう結構ですよ multicoreware / x265 / wiki / RoadMap ? Bitbucket
https://bitbucket.org/multicoreware/x265/wiki/RoadMap
>4. OpenCL acceleration
>
>Because of the proprietary nature of the OpenCL target hardware, this last work will happen in a private fork.
>The fork will be opened as soon as the target hardware is available for sale, or when the fork is used commercially,
>whichever happens first (or perhaps sooner). Non-proprietary changes will be periodically posted to the mailing list for review and merge.
これだとGPUで多少早くなる事すら期待薄か… 少なくともこんなもんを知ってるというだけのことで変な優越感を持って
他人を見下すようなみっともない真似だけはしたくないものだな・・・ 誰かFPGAで簡単にHEVCエンコード並列処理できるようにしてくんないかな
超コスパ高そう。予算ある限り積み上げて性能高められるし
https://www.parallella.org ソフトの2つの例としてURLを2つ貼ったけど両者に関連性はないよたぶん 堂々とリッピングソフト売れるのってもう中国くらいでしょ
http://www.multipelife.com/sitemap
Telが国番号86になってる AMDがRaven Ridge辺りでCPUとGPU得意な部分を任せたBフレーム付きのエンコーダ出してくれないかなぁ、
とも思ったがIntelも出来てないしなぁ。両社ともソフトウェアはあまり得意じゃないイメージはあるが。
CPU内部バスがデータのやり取り時に飽和しちゃって遅くなるのかねぇ、とかいう思いつきばかりの素人考え。 内部バスとメモコンの細さはいつも問題と言われてるね
ヘテロジニアス・コンピューティングに最も近いところにいるAMDの（APUの）場合
ダイサイズの制約でミドル・ローのCPUとGPUとなってたのが痛い
GPGPUはあくまでCPUでの処理能力の底上げだから、その支えられるべきCPUの処理能力が足りなかったからね
だからRyzen APUでも問題の解決にはならず6/8コアCPU+iGPU+オンダイメモリ（HBM）になるまで現状のままだろうけど
一応、研究はしてるんだぜという動画↓
https://www.youtube.com/watch?v=A3_w5qWwYc8 >>496
素人の妄想に付き合っていただきありがとうございます。
なるほど。英語はさっぱり分からんので早々に拝見するのはリタイアしましたｗ
AMDだと7nm世代でHBM2搭載APUが出てくれる可能性にかけるしかないのかな。
GPUの雄NVIDAもARMコアライセンス取得してるからそっちの方にも期待はしたいけど、
あっちはしばらく自動運転とかGPGPU性能を高める方向に行くようだから、
やはり2〜3年後のAMDに期待しておこう。AMDファンだしｗ できるできないで言えばできそう
けどバッファとI/Oが絶対的に足りなくてパフォーマンスは全然出ないと想像してみる 持って帰って一人でこつこつやれる仕事じゃないと駄目なんだよな
いちいち質問しないと進まないなら事務所に来てやれということになる 外部接続するcpuてわけじゃないから無理じゃないかな
これ使うくらいならnvencとかでいいんじゃない ディープラーニング系のものは、明確な数値計算で成り立ってる
HEVCエンコードには使えない気がするけど、よくわかってない。 ttp://news.mynavi.jp/articles/2014/09/05/hotchips26_myraid2/
画像認識に特化してるようだから、数値計算なら何でもってわけじゃないんじゃないかな ttps://www.kickstarter.com/projects/1235889177/mustang-200-affordable-scalable-adv-computing-acce/rewards
これが実現して、安く出回るようになれば面白いよね >>504
何だこのPCI-ex4にノートPC付けちゃいましたみたいのは！？
すげぇ欲しい CPUをコプロ代わりに使ってるのか。
学術計算用でこの手の高価な物は昔からあったけど、あとは値段次第だな。 差すだけで速くなるなら凄いけど、専用のプログラムを自分で書くんだろ? 現実的な問題として、本当にそういう外部HWを使ってまでエンコしたいのかって話がな・・・ 古いaviとかをH.265に縮めるプロジェクト進行中
もう2ヶ月くらいPC動きっぱなしなのにまだ終わらない
これが数日で終わるなら有り難いけど、その数日のレンタルで構わないな
日常的にはエンコードしたい量は大したことない 紫10TBって電力結構要求するの?
玄人志向のKURO-DACHIっていう2ベイお立ち台系ケースなんだけど
2台挿すとスピンアップ繰り返し続けて起動しなくて1台だといける
KURO-DACHIは初代と新しいのと2世代あるがどちらもダメだった ソフトウェアエンコなら、ryzen 7 1700でも買ってエンコしろ スロットに差すとエンコードが速くなるようなデバイスが発売されればいいのに 今更だけどMP4BoxでもHEIF作れるみたい
jsonとか用意しなくていいし、ビルドする必要も無いので>>351の方法より簡単だと思う
GPAC support for HEIF | GPAC
https://gpac.wp.imt.fr/2017/06/09/gpac-support-for-heif/
あとFFmpegでも対応予定っぽい？
#6521 (HEIF support) – FFmpeg
https://trac.ffmpeg.org/ticket/6521 >>513
h264の時はあったのにHEVCは出ないな podcastがopus採用するらしい
これに続いてネットラジオ各位はopus導入してくれ A hands-on introduction to video technology: image, video, codec (av1, vp9, h265) and more (ffmpeg encoding).
https://github.com/leandromoreira/digital_video_introduction >>514
初期のh264 HWエンコはひどかった。
HDでh264エンコするよりも、SDでMPEG2エンコしたほうが画質も良くて、
ファイルサイズも小さいんだもん。 h264も熟成に10年かかった
h265もあと5年はかかる、RYZEN効果でやっとCPUが追い付いて来たしな リアルタイムに間に合えば質は問わない、というのが基本スタンスだからな
保存用に使うのが間違い できるだけ高速でエンコさせたいんだけど、下の機材でなんとかできないかな？
・Sandy i5のデスクトップ。
・ivy i5のノート
・iPad Pro
能力的にはiPad Proが最強なんだけど、エンコ用には使えないよね？ それでiPad選ぶって、単にiPadでエンコしたいだけでしょ？
iMovieでやればいいんじゃない 処理能力的にもiPadProが文字通り桁違いで劣ってるよ
提灯ベンチマーク記事を真に受けてない？ HWエンコードならiPad Proが最速になれるぞ
Sandy/Ivyにはエンコーダが無いからな
SWエンコードは…無理させんなとしか HEVCはskylake以降でないとQSVできない >>530
H.264ならQSV使える
が、このスレは「次世代ビデオコーデックのスレ」なんだよな
次世代コーデックが特に絡まない話題なら別の所でやろうぜってなる それは偏にHEVCスレでHEVC未対応のQSVの話を持ち出そうとする人が現れることを想定していなかった私の落ち度です
ごめんね CPUを高速なのにする度に全部買い換える人は自動的にOSも変わるけど、
自作の人は必要なとこしか買えないからOSの乗り換えは遅くなる 7からWIN10に変えてから長いけど、久々に友達のWIN7機を触ったらOSが使いやすいのな！ 久々に7見るとエアログラスがいいなって思うことはある。8以降の四角いデザインは未だに好きになれないな スレチだが俺も8以降の見た目が嫌いだなぁ。
win10は7で主要ソフトが動かなくなってからで良いわ。 7も意図的にドライバを切り捨てる儲け思想が気に入らないけど、
SSDにちゃんと対応してるのが7以降だから仕方ない
XPだって技術的には対応できるけど、そこは商売として受け入れる ７まではUIも滑らかなデザインで美しいし
機能へのアクセスもいい 7のスタートだけはゴミだと思うけどな
社畜SE専用だろ、あれ だいぶ前に開発関係でNTTかどっかの中の人がＨ264とかＨ265についてはっちゃけて解りやすく書いてたodfかんか貼ってあったんだけど知らない？ http://home.catv.ne.jp/dd/pub/cod/coding.html
これは分かりやすいと思ってブクマしてたけど・・
あと、もう一つあったはずだけどブクマに埋もれて見つからず >>540
窓たくさんすこしずつずらして開いてると、タイトルバーとかメニューバーがフラットだとどこが窓枠なのかわかりにくいよね。 xpのlunaが美的センス最低だが視認性は最高
7のUIはリボン推しとその他旧式などなど操作系がチグハグでそんなに褒めるほどのもんでもないな…10もだが
エアログラスはかっこいい
てかwin8もβの最初は7の丸みだけ取れたような見た目だったのにな AV1てやっぱりエンコードの計算力凄まじそうだな
NetflixとかYouTubeみたいな大規模な配信じゃないと利用するメリットないんじゃないか？ AV1はHEVCよ20%効率的、計算量は3〜5倍
2017年12月31日にビットストリームが決定、数日以内にChromeとFirefoxで利用可能に
YoutubeとNetflixで使われるまで出荷しない。問題があれば開発継続
こんな感じか >>計算量は3〜5倍
まじで？？
HEVCですらアップアップなのにその3-5倍とか・・ この20パーセントてのは、元動画をhevcが30パーセント圧縮できるときにav1は50パーセント圧縮できるてのと、元動画をhevcが30パーセント圧縮できるときにav1は36パーセント圧縮できるのどっち？ その計算だと、80%圧縮できる時に100%圧縮できちゃうな 同じビットレートで比較してSSIMが20%良くなったか、80%のビットレートで同じSSIMのどちらかではないか いや、100/120=83.3%のビットレートで同じSSIMなのではないか >>549の概要
●AV1のビットストリーム仕様の確定は2017/12/31までを目標としている
●ただ、YoutubeやNetflixといった主要メンバーが納得するレベルにならないとリリースされない。
●Netflixの担当者は「HEVCより20%効率的で、計算量は3〜5倍」というレベルを目安としている。
Youtubeの考えは不明。
●これまでの評価は
Netflix「AV1はVP9より20%効率が良い」
Google「AV1はVP9より30〜35%効率が良い」
とされているが、4月のBitmovin AV1での検証ではそこまで良いものではなかった。
当時77あった実験的コーディングツールのうち8つしか使ってなかったので
改善の余地は大いにあるが、これらの機能の統合や最適化は難しい作業になるだろう。
●ビットストリーム仕様確定後の見通しは以下の通り。
・ChromeやFirefoxは数日中に再生をサポート
・チップの開発に12〜18か月、更にそれを利用したHWリリースに6か月。 (>>559の続き)
●4月のNABでのBitmovinの実験では1080p24のリアルタイムエンコードに最大200コア程度が
必要だったが、そう遠くないうちに8-32コアでできるようになるだろうというコメントもあった。
http://www.streamingmedia.com/Articles/Articles/Editorial/Featured-Articles/Bitmovin-Pushes-AV1-Forward-Joins-Alliance-for-Open-Media-117634.aspx
■参考：>>262の記事にある4月時点のAV1のエンコード速度
https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live-joins-alliance-open-media/
・LenovoのT540pノート(i7-4800MQ, 8GB RAM, Ubuntu 14.04)で
1080p24の40秒クリップをエンコードするのに8時間42分かかる。
つまりエンコード速度は0.032fps。
・デコードは上記環境でも問題ない。 >>560
完全に出たてのh.264やh.265と同じじゃないか
俺らがまともに使える様にあるには5〜10年かかるだろ それでもav1の開発を進めなきゃならないほどhevcの権利関係が鬱陶しいんだろうか >>563
>>339によると特許プールが3つか4つに分裂しているらしい
＞H.265/HEVCコーデックでは合意形成に失敗しており特許行使者の利害関係調整が失敗することが起こりえる
つまり私利私欲に走りライセンス料を吊り上げる企業が出てきてもおかしくないのか
これMicrosoft良い立ち位置にいるよなー
H.265とAV1どっちが普及してもおいしい >>559,560
翻訳ｔｈｘ
>>564
VC-1の時のゴタゴタと比べると凄い進歩
こういうマイナーっぽい新規事業に日本企業の腰が重いのが残念
技術力自体は悪くないのに 日本企業だカスタムチップで実績のあるソシオネクストが参加している
http://aomedia.org/about-us/
NHKとサイバーエージェントもはよ NHKなんてH.265のライセンシーなんだから無理無理
H.265のライセンスプールについて調べれば分かるけど参加企業のうち約20%が日本企業
日本はH.265のライセンスを囲い込む側
AV1のようなプロジェクトに日本企業が積極的に参加するなんてことは期待しない方がいい 何がかんだ言ってもネームバリューがモノを言う
H.265は世界的に広まってるから狙うなら語呂が悪いH.266の代わりを目指さないと H.264/AVC
H.265/HEVC
H.266/???? >>566
日本企業もいたのか（言われて探したけど企業ロゴ薄すぎ）
>>567
念のために書いとくと、日本企業が加わることでホルホルしたいんじゃなく
AV1の完成度が高まってほしいってのが大きい しかし、そうやって日本企業が絡むとまた権利関係面倒臭くなりそう
少なくともnhkは絡まないでくれ
あと受信料下げてくれ >>569
H.264/AVC
H.265/HEVC
H.266/AV1
になったりしてw 懐かしい
20年ぶりぐらいに聞いたような
NTTだっけ >>572
フリーでやろうって言ってるグループ内でそれは言わないんじゃない？
言えないからこそ参加しないんだろうけど AV1は個人でソフトウェアエンコードするにはだいぶ厳しいな
gifみたいな用途の低解像度で短い動画なら使えるかもしれないけど
メインで使うならハードウェアエンコしかねえな エンコードはAmazonやgoogleがクラウドでぱぱっとやってくれそう
個人はAIチップ？に期待。両方ともだいぶ先の話だけどね アップロードと同時にエンコード済みの分をダウンロードできるような仕組みだと、
回線速度くらいでエンコードできるな AIチップはそんなに遠くないんじゃない？
HuaweiのKirinとか搭載始めるし VP9もそうだったけどAV1はgoogleやその関連企業（配信関係）が
少しでも画質と帯域の効率を良くするための目的で作られてて
一般ユーザーが使うことは想定していないんじゃないかな
Youtubeにしろニコ動にしろもうユーザー側で最適なエンコしたものをUPするんじゃなくて
できるだけ高画質でUPしてもらったものを配信側で最適化するって流れだし >>584
非営利系や同人系は一般ユーザーに近いと思う
たしかRPGツクールはVPxコーデックしか選択肢がなかった気がする（透過WebM）
あと一般向けなのかはよくしらないけどWebRTC アルファチャンネル付き動画ってHEVCではつくれないんだっけ
画像フォーマットのHEIFではできるらしいのに >>551
コーデックは1世代上がると効率2倍、計算量10倍って聞いてたのに効率20％で計算量3〜5倍じゃ期待はずれも良いところ
あまり急いで出さないでじっくり開発してもっと良いのを開発して欲しい 1世代上がるタイミングが等間隔だとは言ってないんだろ
2倍になるまで待ってたら30年かかるから、1.2倍になった時点でとりあえずリリース
別に悪くない >>589
リリースしても>>587レベルのメリットがなければ普及しないって事じゃないの
後継規格がなければ緩やかに普及はしていくかもしれないけど いちいち規格としてリセットしないといけないなら面倒だな
マイナーバージョンアップでじりじりと改良していけばいいのに
CPUなんか殆ど変わらんだろレベルで少しずつ速くなってる プロファイルの追加はマイナーバージョンアップに相当すると思う Netflixなら動画の数に対して再生数が凄いだろうから
計算量が増えてもメリットあるんでは ゲームだとbink videoが多いが光栄が動画にWMV9使ってるな
エロゲーはいまだに画質も容量も無駄が多いMPEG1を使い続けてる文化がある VP8やVP9を無料で使えるのにMPEG-1に執着する合理的な理由はあるのだろうか VP9のHWデコード対応したのは割と最近のGPUだっけ
でもCore 2あたりでもCPUに任せてもゲーム想定の動画程度なら大丈夫そうだけどなぁ
余程楽にゲームに組み込む仕組み作らないとゲーム制作側が動かないだけかも >>601
fixed function decoder（完全HW処理、CPU負荷ほぼゼロ）搭載してるのは
Intel KabyLake・ApolloLake、NVIDIA Pascal以降だけ
hybrid partial acceleration（一部HW処理、CPU負荷も掛かる）なら
Intel Broadwell・Skylake、AMD Polaris・Vegaとあるが 再生数が多い動画、たくさんの再生が見込まれる動画だけAV1で圧縮すればいいんじゃね？
そうすれば計算量の多い問題は解決する そういえばWeb動画が絶対って業界認識があるのか
データ量が増えがちな422,444とかHWデコードできないGPUの場合があるね 422はHW使えないの多すぎて結局CPU処理だな…
KabyでもCPU食ってるし PCならいまどきのをつかってれば2kならソフトウェアデコードできるのでは？
消費電力制限が大きいスマホ・タブレット・ノートPCだと、ハードウェアデコード必須だな デコード重くなるようなエンコードオプション設定して無ければまず大丈夫だけど
PC作業は色々同時にやるときがあるし他の処理も同時実行してると少々辛くなる時があるかも知れないね 結局ネット配信におけるHEVC普及はパテント問題で合意せずに失敗、
HEVCは放送やハードウェア、ソフトウェアに留まり、
ネット配信は規格乱立か？ コーデックとして切り出されてるんだから、統一されてる必要はない
現状だっていっぱい共存してる 現実世界と見分けがつかないVRには全然まだスペックが足りないという >>612
でも本体10万とかだし、それくらい出来てもらわないと ネットでH.265を使うのは現実的に無理だから
H.264 Apple様用
VP9 その他一般OS用
AV1 再生数が多い動画用
これでいいな VP9で作って確保する必要性がない
h.264でええやん どう考えてもVP9よりh.264のほうがサポートデバイスが多いはず しかし、h.265やVP9の画質を知っちゃうとh.264には戻れない 将来再生できなくなるリスクを考慮するとH264が安全だろうね。
たとえばWindowsのバージョンが上がってcodecがインストールできなくなったら
それだけで多くの動画が再生できなくなる。
さらに時が経ってWindows自体が消滅する可能性だってある。
数十年後でも確実に再生できるのは今のところMPEG2とH264くらいじゃないかと。
うちにβビデオ、8mmビデオ、カセットテープ、DAT、MD、DVが全部あったが
PCに取り込むのに状態の良い中古品を探すのにめっちゃ苦労した。
画質音質の少々の違いには目をつぶって、汎用性を優先するのが正しい。 ハードとソフトじゃ全然違うでしょ
TwinVQが未だにFFmpegでメンテされ続けてるところを見るとソフトは大丈夫だって分かる 多額の費用を使って工場ラインを維持しなきゃいけないハードと違ってプログラムを書ける人間が一人居れば事足りる話だからな
移植やらをボランティアでやる人も大勢いるしその辺は心配しなくていいんじゃないかな XVDでエンコードしてた人は今も再生出来てるのかな？ >>621
>将来再生できなくなるリスクを考慮するとH264が安全だろうね
新しいCPU、GPU、ARMなどにH265とVP9のHWデコが順次搭載
されているから心配無用
>数十年後でも確実に再生できるのは今のところMPEG2とH264くらいじゃないかと。
いつまで生き続けるつもり？
>うちにβビデオ、8mmビデオ、カセットテープ、DAT、MD、DVが全部あったが
>PCに取り込むのに状態の良い中古品を探すのにめっちゃ苦労した。
今はM-DISCがある。数十年は大丈夫。 glacierってなんであんな高いの？
ストレージ料金だけでも高いんだけど。
Amazonの新プランの方が1TBあたりの値段安くね？ そうなのか
選んだ時はよそよりも1桁以上圧倒的に安かったのに、
よそもがんがん値下げしてるんだな >Glacierのストレージ料金 東京 $0.005 : GB あたり/月
あれ、今見るとAmazon Cloud Driveの新プランと同じ値段になってるね。
すまん。
ちょっと前はもっと高かった気がしたんだけど。 デコーダーが非対応なだけなのか分からないけど、H.265のインターレース保持エンコードがまだ現実的じゃないから、まだ移行に踏み切れないムービーデータがあるなぁ。。。 そういうものは60pで対応するのがH.265の思想だと思う >>637
やっぱりアーカイブ的な用途で使われてるのかな?情報ありがとう。
これからの映像はプログレッシブというのはここの住人と同じ考えだけど、インタレ解除手法も日々進化してるからソースがインタレならインタレは保持して見るときだけリアルタイムで解除したい。 インタレ保持H264よりインタレ解除H265の方がきれいだから、そろそろ潮時だって思う アーカイブは元ソースに出来るだけ手を加えないってのが原則だからなあ
インタレ解除の59.94Pでやる走査線補完は元ソースに無い絵柄を付け足してるという事で別物の扱いになる デコードした後、元ソースにはない走査線を消しちゃえば同じになるんじゃね QTGMCでプログレ化してx265でエンコすると日が暮れる インタレ解除は24pと60iで話が全然噛み合わないからな。
二次で抜いてるアニヲタは逆テレシネで華麗に解除、
三次で抜いてる実写派はいろいろ試して結局インタレ保持で保存。 24pのインタレ解除は簡単だからね
60pみたいに「ない絵」を作り出す必要がないから処理量もぜんぜん違う そもそも論として8x8みたいなブロック単位で圧縮するmpeg系との相性が悪い
今までは何だかんだで対応して武夫、hevcではそっち方面で進化しすぎてインタレ対応する余地がなくなった感じっぽい せっかくエンコーダーで高度な動きベクトル予測やってんだから、そこに
インタレ解除も一体化して組み込むのが正しい姿なんだがな。
まずインタレ解除してその後エンコ、みたいなのは筋が悪い。 タイムマシンで戻ってインターレースを発明した奴を倒す インタレ解除したら絵自体が変わっちゃうし、
エンコーダはデータ量最小化のベクトル予測で目的関数がちょっと違うから、
なかかな共通化は難しいんじゃないか
エンコパスが1パス増えたと思うしかないな >>647
歴史の復元力が働き、誰か他のやつがインタレを発明する事になる かなり早い時点で要らない技術になってたのに、
後方互換性を気にしすぎて未だに現役で生きてて迷惑をかけている
どう見ても急場しのぎの設計なのに、こんなに続くとは思わなかっただろうな
2000年問題みたいな感じ 今でこそFHD60pで記録出来るカメラが当たり前になったけど、地デジ推進の頃の磁気テープにHDを書く時代にはまだ処理的に厳しかったんじゃないの? VHSテープ1本80GBぐらいのデータ量とかどこかで見たな 高級LDプレイヤーにマスモニで非圧縮キャプチャするとちびるほどのデータ量になるらしい 非圧縮の時点で現実的ではないな
SD画像でも1フレーム1MBもある
1秒30MB
30分で52GB
音声なら0.3GB
この桁違いの差により、動画は当面はデジタル化は無理と言われていた >>656
120分のVHSテープは25GB
薄いD-VHS用テープが最大50GB 情報量はS/N比で決まるので、テープよりはデッキ次第
超高級デッキなら同じテープに1TBでも入る筈 規格が出て来た時は1080IがSONY主導で720Pが松下主導だったっけか
PCなんか使わないでデッキでダビングが主流だった当時のユーザーには解像度の高い1080Iの方が断然人気あって
720PはPCとの親和性を考えてわざわざ作っただけの規格でしょみたいな感じだった ピュアオーディオのAV機器版というか画質マニアガチ勢で非圧縮保存してる人いるけどね
ストレージが大幅に技術革新しないとありゃ無理だなと思った ホログラフィックで云々みたいなの一時期はやってたけど実用化に近づいたのはあるのかな？ 非圧縮のソースなんてどこにあるんだ？ゲームでも録画するのか？
非圧縮映像はNHKのスーパーハイビジョンの展示くらいでしか見たことないな
当時は8K対応のエンコーダ・デコーダがないから非圧縮っていうｗ >>664
W-VHSの様な往年のテープメディアをPCキャプチャするみたいな話なんじゃないかな >>668
当時のLDプレイヤの最高機種（できれば業務用）と業務用マスターモニター込みでそれを言ってる？ >>670
どんだけオーバーサンプリングしても縦は走査線数しかないだろ
ちゃんと平面で記録する35ミリフィルムとかだったらアナログの良さは分かる デジタル化の時せめてYCbCr4:2:2を標準にして欲しかった 派手な色の服装の人とか花とかぼけぼけになる データ量の問題でしょ
解像度上げればきれいになるなんて分かりきってる。再生環境でどうにかするしかない
クロマサブサンプリングについて言うなら、
madVRとBDレコでクロマアップサンプリングの性能比較とかしてほしいな >>673
平面じゃないよ、銀化合物なんかの粒子サイズのドットだよ 静止画のくせにYUV420しか使えないWebPとかいうオワコンもあったな 誰かSkylake より昔のMacでHEVC書き出し試した人いるかな
QuickTimeから書き出しだと1080p以上のみたいだけど
Compresorが対応してきたらそれ以下のサイズでも可能になるかな?
720pの素材が大量にあるのに… MacX Video Converter ProでHEVC書き出し出来る >>679
非可逆圧縮なら大したデメリットにならないだろ SSIMいくら以上でエンコしてる？ 265でcrf=21でも0.98切るんだけどそういうもんなのかな >>686
悪いがここもスレチなんだ。x265スレへ行け
でも行く前にpsyとssimの関係について予備知識を仕入れとかないと
叩かれると思う SSIMってなんか謎だよな
俺はx264だけど、ctfを14まで下げてもSSIM0.975とかになってしまう。
映像を見てもオリジナルと差がないし、同じコマを等倍表示で左右並べて
交差法で「間違い探し」をしても違いが分かるのは画面全体でせいぜい数ドットで、
それ以外は完全一致だった。 皆にききたいけど記録用にとった映像ソース（編集用にaviにする事人もいるかも）あると思うけど
そういうのって残してる？
それともh264なりh265なりに変換したら削除しちゃってる？
結構オリジナルファイルバカにならないサイズで皆どうしてるのかと 自分の場合、公的なものとかなんかの証拠になるようなものでもないし、一定期間取っておくだけでもリソースの無駄みたいなものだから削除してる。
長期間取っておいてもほとんどの場合、一度使えばあとは編集の素材にならないことの方が多いし。 消した後に再編集したくなったりしたらどうしてる？
元のaviがないからどうしようってなるんだけどなんかうまい回避方法ないかなと aviutl + x265でエンコする際、マシン使用率確認しようとタスクマネージャーとHWMonitor起動しながらだと
時々x265に不正なパラメータが渡されましたなんてエラーがでて途中で終了しちゃうんだけどこれ既知のバグ？
そのまま繰り返して再エンコしれてばできる時もあるしタスクマネージャーとHWMonitor落とせばこのエラーが出なくなったんだけど
何が原因なんだろ うちのRyzen機でもたまになった
なんかセンサーの取りあいみたいなのが原因かなと思ってたけど
そっちもRyzen? HWInfoのバグでx265が落ちるのは考えづらい気がする >>699
うん Ryzen 1700 です
同じ人いてちょっと安心したｗ Ryzen1800X@定格でも出る
HWMonitorは起動してないので関係ないと思うぞ
タスクマネージャーはどうかな、多分ダメだろうけど試してみる SEGVだったら今でもエラーでると思うんだけどな
ちょっと今の自分のエンコ状況説明しておくと
エンコしたい動画ファイルが約500ファイル程あって、１本のmpeg-psファイルをx265でQ=21,速度midiumで変換が30分程
１０日前ぐらいから毎日毎日バッチでエンコやりはじめてエラーになるファイルは大抵がやり直してもまたエラーになるんだけど
くじけずに何度もやってるとエラーにならずエンコが完了する時があるんだ。
で CPU温度とか使用率みたくてタスクバーとHWMonitorたちあげてたんだけど
もっと正確にいうとブラウザ(IE、エッジ、chrome全部たちあげ)しながらwebサーフィンやらjanestyleも立ち上げてた。
で昨日から上であげたアプリは全部おとしてaviutlとx265だけを実行させてるけど途端にエラーがでなくなったんだ
不思議に思った >>706
更にもっと正確にいうと、ブラウザ(IE、エッジ、chrome全部たちあげ)やらjanestyleなんてアプリは一切起動せずに
タスクバーとHWMonitorたちあげてる時だけでもエラーは出てました
でも>>704さんみてるとHWmonitorは関係なさそうな・・ Ryzen1700だけどメモリの電圧上げたらいまのところ出てないよ ちなみにBIOSでCSM無効の完全UEFIにしたら問題なくなった気がするから試してみては？ 書き込みを押してからズラズラと新着が表示されて紛らわしいから書いとくけど
708と709は別人ね 結局糞メモリでメモリOCしてストレステストしてないだけじゃん
アホは定格で使ってろよ AviUtl自体が最近のWindowsやマルチコア環境についていけてないのかもしれないね Aviutlのマルチスレッド化プロジェクトって失敗に終わったんだっけ
Avisynthもロクにマルチスレッド化出来てないし、
せっかくマルチコアCPU増えてきたのにほんとエンコはオワコンになったな… AviUtlなんて内部がUnicodeじゃない時点でダメ
おまけに32bit >>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だけだった気がする >>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だな。 スレチかもしれないけど、中国製の防犯カメラでH.265に対応している製品があるけど、なんちゃってなのだろうか。
5MP/25fpsのカメラモジュールで1万円くらいからある。 >>877
で、Bフレーム有効にするとQSVでのエンコード画質は、H.265>H.264になったの？
それともとりあえず対応しました程度？ >>881-882
ググったら出てきたが。
Apple joins alliance to shrink your online videos - CNET
https://www.cnet.com/news/apple-online-video-compression-av1/ 寝言はおいとくとして、次スレに向けてスレタイやテンプレの変更をちゃんと考えないといかんな。 とりあえず次スレに向けて、スレタイ＆テンプレ変更案を書いてまとめてみたけど、どうだろうか。
Q&Aの内容はこれでいいのかとか、Daala/Thorのリンクは必要なのかとか、もろもろ意見求む。
詳細→ https://pastebin.com/quVcrCB5
スレタイ：
次世代ビデオコーデック総合スレ Part8 【HEVC/VP9/AV1等】
テンプレ
H.264/AVCの後継候補となる様々な次世代ビデオコーデックについて語るスレです。
（以下略） >>888
それ、スレ変わってるがな
別スレ扱いの内容だぞ >>889
このスレはPart3から>>1の2行目が入って、H.265だけじゃなく次世代コーデック全般のスレになってるんだよ。
過去ログか、せめて>>1-13だけでもちゃんと読んでくれ。
スレタイがこのままだと、お前さんのようにテンプレ読まずにH.265専用スレだと勘違いする人がいるし、
酷いのだと勘違いしたまま別スレを立てようとするのまでいる。（>>297-300）
だから実態にあわせてスレタイやテンプレを変えようという話。 このスレだって消化に1年くらいかかってるわけだし分ける必要性を”今は”全然感じないな
もっと動画サイトやらハードウェアやらでの採用が増えてレスが増えるようになってから分ければいいんじゃね？ H.265/HEVCにしてもAV1にしても話題もレスも今のところ大して無いんだし、
制限が続くDTV板の厳しい現状もあるし、わざわざスレ分ける必要はないわな。 統合が嫌だったらもっとHEVC関連の話題出してホラホラ 現状のままでええ スレタイを1に合わせるのはありだと思う というか、もともとこのスレで普通にAV1の話もしてたんだから、「統合」は既にされてるわけで、
「実情にあわせてスレタイを変えたほうがいいじゃないか」というだけの話なんだけどね。
「AppleがAOMediaに参加」という話を理解できなかった挙句
「AV1はスレ違い」とか勝手に言い出して暴れ続けるのはどうかと。 もうそろそろスレも終盤に近いし総合スレもH.265単独スレも建てちゃえば んじゃー次スレ立てるときにH.265単独と
次世代コーデック全般の二つ立てればいいんじゃないの 無駄にスレ分けたって両方過疎るのがオチだし、それなら現状維持の方が多分マシ。 スレタイを「次世代ビデオコーデック総合〜」にするんじゃなく
H.265/HEVC VP9 AV1 Part8
みたいにするだけなら抵抗感は少なくて済むのだろうかと、ふと思った。 惰性でスレタイは今のままが一番トラブルは少ないと思う
んでテンプレで"HEVC/VP9/AV1など新世代コーデックについて語ろう"としたら円滑に回るかと 単独スレがあるx265の話題抜きだからH.265は語ることが少ない 既に現行コーデックになったHEVCと他のカスコーデックを同列で語る意味がない >>910
【H.265/HEVC】【VP9】【AV1】 Part8 >>878
ファーウェイ子会社のハイシリコンのAVC/HEVCエンコーダが低価格帯だと有名だよ。 まぎらわしいから俺はやっぱりスレタイはこのままの次スレと
AV1やVP9の話題を扱う新スレをそれぞれ別々に立てて分けるべきだと思うわ
HEVCは一応昨年の段階で製品やOSレベルでのサポートが進んだし
今年はデバイスやアプリレベルの対応に関して話題になりそうだから ここでAV1の話とかされても困る >>918
HUAWEI Mate 10 Proのコア作ってるし、激安カメラのエンコチップによく使われてるよね。
性能は価格なりなようだけど、どうなんだろう？ >>921
MediaTekはMT〜のチップになるね。
ハイシリコンはKirinシリーズで採用されている。
調べればわかるけど、ハイシリコンはHuaweiの半導体子会社。
MTシリーズは低価格から中堅、Kirinは中堅から高スペックなあたりで搭載されている感じだろうか。 AV1を試してみようと思ってビルドしてみたんだけど、--tile-columnsに0以外を指定すると
aomenc.exeがクラッシュしてしまい、マルチスレッドエンコできなかった。
なんかバグってるのか、自分のビルドの仕方が悪いのか・・・。
コマンド（aomencがクラッシュする）
ffmpeg.exe -i 512x256.avi -pix_fmt yuv420p -f yuv4mpegpipe - | aomenc.exe --cpu-used=8 --tile-columns=1 --passes=1 -o av1.webm -
試したバージョン
v0.1.0-7551-g3ec11d1e3 (1/8頃)
v0.1.0-7588-g10fea49b3 (現在)
ちなみに--tile-columns=0（シングルスレッド動作）だと、
512x256ソースのエンコ速度が 0.03〜1.01fps（--cpu-used=0〜8） だった・・・。(i7-4702MQ) >>923
パイプじゃなくてy4mから読み込んでみるとか >>923
例え32C動作だとしても0.96〜32fpsなんだから、もう試す意味ないんじゃないか？ >>924
変わらなかった。
>>925
確かに。
というか一番聞きたかったのは「他の人はうまくマルチスレッドで動いてるの？」ということだったんだけど
それをちゃんと書いてなかったことに今気づいた。ごめん。 規格が完成したら試そうと思ってるんだけど延期に次ぐ延期でなー 12月で仕様固める言ってたのはどうなったんや
もし延期してなければ高速化はこっからが本番でしょ >>928
アップル、動画圧縮技術の開発を目指すAlliance for Open Mediaに加盟
https://japan.cnet.com/article/35112777/
AV1の仕様確定はちょい延期されたようで、上の記事によると「数週間以内」、英語Wikiにも「2018年1月」とある。
また延期されるかもしれんけど。 AV1の話は、そろそろ次世代コーデックスレ立てて、そっちでやってくれ HEVCの話をしてるとおもってたら
AV1のことだったのか 【AV1】次世代ビデオコーデック総合スレ【H.266】
テンプレは任せた >>932
まだ標準化されてないんだから「H.266」という表現は用いるべきではない。
AV1も継続して話すほどのネタは無いからわざわざスレ分けするほどではないし、
スレタイ変えるのが嫌なら現状維持でいいと思うんだが。 めんどくせーのがいるんだから隔離スレ立てて誘導すればいい 3日時間をやるから、次世代コーデック総合スレを立てて、AV1厨はとっとと出ていけ
さもないと、テンプレなしで適当にスレ立てしてAV1厨をつまみ出す！ H.265/VP9/AV1他なんでも可の新スレが建ってくれるならそれでいいわ、俺もそっち移れるし
H.265スレに残る人は残る人で自由にやってもらえばいい >>933
＞まだ標準化されてないんだから「H.266」という表現は用いるべきではない。
【2013】 H.265/HEVC 【7680x4320】
http://mevius.5ch.net/test/read.cgi/avi/1317066231/
1 名無しさん＠編集中 2011/09/27(火) 04:43:51.21 ID:HczLwb1z
圧縮率効率がH.264の2倍な次世代ビデオコーデックH.265/HEVCを語ろうぜ そんじゃ仕方ないのでとりあえず次世代コーデックスレ立てにいってみる。 立てた。すぐ落ちないよう保守しないといかんのでいくつか書き込む予定だけどよろしく。
次世代ビデオコーデック総合スレPart1 【HEVC/VP9/AV1等】
http://mevius.5ch.net/test/read.cgi/avi/1515759816/ やっと五月蝿いハエが出ていったか
今度このスレでAV1の話しやがったら、全力で潰すぅ さて、次世代コーデックスレが立ったところで、今後のこのスレについてなのだが、
現状、DTV板のスレッド数はかなり抑制されている環境のようなので、無意味なスレの乱立は好ましくないと思われる
そこで、すでに民生用途含め多くの場面で利用できる環境が整備された既存コーデックについてまとめて語る場としての「既存ビデオコーデック総合スレ」として再整備するのはどうかと思うのだが、どうだろうか？
※HEVCについてはすでに数年前よりハードウェア再生支援環境がPC、スマホ等で整ってきているので、既存ビデオコーデック総合スレの管轄と考える
ただし、AV1などの次世代コーデックとの画質やビットレートのために、次世代ビデオコーデックスレでHEVCをはじめとする既存のコーデックとの比較を行うことを妨げはしない >>950
HEVC以外の話をするなーって人が出てきて分裂したのに既存のコーデックでひとまとめにしたらまた暴れるでしょ
素直にHEVC単独スレ立てとけばいい >>951
☓HEVC以外の話をするなー
○AV1は出ていけ >>952
それが正しい
AV1は放送やAV機器で利用するようなメジャーコーデックにはならない可能性が高いから、HEVCやAVCなどとは性格が違うしね だからスレ立てたい奴が勝手に立てればいいんだよ
意味のない議論なんてするな、んなもんに正しいも糞もねーんだよ
どんなスレだろうと立てたきゃ好きに立てろよ ようするにあれか放送業界用コーデックとネット業界用コーデックの話をしたい二種類の人間がいるって感じか
次世代ビデオコーデック総合スレPart1 【HEVC/VP9/AV1等】
http://mevius.5ch.net/test/read.cgi/avi/1515759816/
> H.264/AVCの後の様々な次世代ビデオコーデック全般について語るスレです。
ということで、>>944の次世代ビデオコーデックスレは「H.264の後」を「次世代」と位置付けていて、
H.265/HEVCも含めて、VP9、AV1、FVC(わからん人はスレ見てね)など
H.264後のビデオコーデック全般について話すスレ
にしてある。
「H.265/HEVCはスレ違い」なんてアホなことは言えないようになってるので、H.265/HEVCの話をしても問題ない。
H.265/HEVCだけにこだわらず全般的な話がしたい人は次世代スレに行けばいいと思うし、
「どうしてもH.265/HEVCの話だけしかしたくない」という人はH.265/HEVCスレを続ければいいと思う。
「H.265/HEVCを次世代に入れるな」という人もいるかもしれないけど、
求められてるのはビデオコーデックの最新動向などを全般的に話すスレだと思うので、
些細な言葉の定義で無駄な議論をするつもりはない。 >>956
誰もその件について了承した覚えはないし、了承を求めたログもないわけだが ＞「H.264の後」を「次世代」と位置付けていて、
誰がこんな定義していいと言ったんだろうね？
HEVC(H.265)が登場し、放送でもすでに使われているコーデックをいまさら次世代と定義するまっとうな理由が理解できない >>957-958
正直そんなことどうでもいいよ。
元々Part3からはH.265/HEVC以外のコーデックの話もOKということでやってきたのに、
突然H.265/HEVC専用にしたいと言い出したのはそちら。
こことは別に総合スレを立てただけだから、了承とかどうでもいい。誰もが納得するスレ立てなんて無理。
次世代の定義についても>>956の最後で書いたとおりなのでどうでもいい。
「次世代」という言葉が嫌なら次スレからは「高効率」といった言葉に入れ替えてもいいかもね。
H.265/HEVCの話をどちらでするのかはスレ住人が個々に考えて決めることだから、流れにまかせればいいよ。
専用スレでやりたいという住人が多ければ、自然と専用スレに集約されるだろ。それはそれで構わない。 どうでもいいからもうコーディング何でもスレの一つに統一しろや わざわざそんな配慮しなくてもスルーすりゃいいんよ、徒労に終わるし
何やっても所構わず顔出して出て行けだの終始喚く輩だろう >>959
どうでもいいばかり連呼するような奴がスレ立てすんな >>964
俺がどうでもいいと言ってるのは(中略)のことであって、
総合スレの必要性は強く感じてるんで、スレ立ても関連情報まとめも真面目にやってあるから心配無用だよ。 >>964
気に入らないならお前がスレ立てろよ
スレ立てるのに誰かの許可なんていらねーんだよ 初めてHEVCの動画に出会ったけど重すぎて草
MPC-BEが一番軽くてVLCのナイトリービルドが次点かな？
軽い外部コーデック出てくれえ >>975
64bitだけど、何か関係あるの？
CPUがi3だからソフトウェアデコードが無理だったのよ HEVCと言っても、デコードには8/10bit、解像度、フレームレートとかも関係してくるしな。
10bitの4K60pなんて、一般的なPCではまだ厳しいのも多いだろう。
64bit版のプレーヤーを使ってLAVのソフトウェアデコードで再生が追い付かないなら
ソフトウェアデコードについては外部コーデックに期待しても無駄だと思う。
あとはHEVCのHWデコードだが、発言から察するに未対応環境なのかな？
だとしたらもう諦めるか新しいPC買えとしか。 1080pならなんとかなるi5 4460
4Kは無理だったんでHWデコードできるGPU積んだ 俺のPCはyoutubeの4Kは問題なく再生できたけどHEVCの4Kは厳しかったわ
VP9のほうが軽いのか？ 4Kの再生をするだけならHWデコードができるGPUを買うよりもApollo Lake積んだPCを買った方が安上がりかもね
CPUにHWデコーダーが載ってればCompute Cardですら4K動画を2つ同時に再生できるみたいだし
http://ascii.jp/elem/000/001/623/1623266/ >>982
記事中の動画のリンク間違えすぎだが良い収穫を得た。 HEVC/VP9は完全に世代の問題だから性能良くても古いGPUは駄目だね
逆に対応してればCeleronG3930でも8K×1、4K×4、2K×16までCPU負荷掛からず再生できる ストリーミング動画の流れによって曲がり角を迎えるMPEGについて「MPEGの父」は何を思うのか？
http://gigazine.net/n;ews/20180130-leonardo-chiariglione-mpeg-crisis/ どう見ても不要な新スレも立ってんのに一ヶ月以上埋めずに放置ってひどいな。
さすがにそろそろ落とそうぜ。 H.265/HEVC限定で話すなら
【2018】 H.265/HEVC Part8 【7680x4320】
http://mevius.5ch.net/test/read.cgi/avi/1516109573/
H.265/HEVCも含めて、AV1、VP9、FVCなども話すなら
次世代ビデオコーデック総合スレPart1 【HEVC/VP9/AV1等】
http://mevius.5ch.net/test/read.cgi/avi/1515759816/ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 391日 11時間 34分 33秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
