次世代ビデオコーデッ ..
2:名無しさん＠編集中
19/07/07 01:26:41.65 fC6IN7rQ0.net
■各コーデックの参考リンク
●H.265/HEVC
・URLﾘﾝｸ(www.itu.int)
・URLﾘﾝｸ(www.itu.int)
・URLﾘﾝｸ(mpeg.chiariglione.org)
・URLﾘﾝｸ(hevc.hhi.fraunhofer.de)
・URLﾘﾝｸ(en.wikipedia.org)
●VP9
・URLﾘﾝｸ(www.webmproject.org)
・URLﾘﾝｸ(en.wikipedia.org)
●AV1
・URLﾘﾝｸ(aomedia.org)
・URLﾘﾝｸ(aomedia.googlesource.com)
・URLﾘﾝｸ(github.com)
・URLﾘﾝｸ(en.wikipedia.org)
●VVC
・URLﾘﾝｸ(www.itu.int)
・URLﾘﾝｸ(mpeg.chiariglione.org)
・URLﾘﾝｸ(jvet.hhi.fraunhofer.de)
・URLﾘﾝｸ(en.wikipedia.org)
3:名無しさん＠編集中
19/07/07 01:28:15.47 fC6IN7rQ0.net
■各ビデオコーデックの概要や状況（2019年7月上旬時点）
●H.265/HEVC
H.264/AVCの後継規格。放送やUltra HD Blu-ray等で採用が進んでいるが
３つのライセンスプールが並立するなどライセンス面での問題も抱えている。
H.265/HEVC特許暗黒時代
URLﾘﾝｸ(qiita.com)
HW再生支援のサポートは進んだものの、FirefoxやChromeでの対応が進んでおらず、
ネット配信では使いづらい状況が続いている。(スマートTV向けの配信等は除く)
AppleがHLS(HTTP Live Streaming)やiOS 11やmacOS High Sierraで採用したり、
2018年3月にライセンスプールの１つであるHEVC Advanceが
コンテンツへのライセンス課金を取りやめたりといった好材料も出てきてはいる。
●VP9
Googleによって開発されたロイヤリティフリーのコーデック。
ブラウザ(Safariを除く)やHW再生支援のサポートも進み、主にYoutubeで採用されている。
4:名無しさん＠編集中
19/07/07 01:33:27.53 fC6IN7rQ0.net
●AV1(AOMedia Video 1)
Amazon、Cisco、Google、Intel、Microsoft、Mozilla、Netflix等が中心となって立ち上げた
Alliance for Open Mediaによって開発されたロイヤリティフリーのコーデック。
VP10、Daala、Thorの技術を受け継いでいる。
2018年3月末にリリースされたが、v1.0.0の仕様確定は2018年6月末にずれこんだ。
HW再生支援のサポート等も含めた本格的な普及は2020年頃になる見込み。
コンテンツ配信/ハードウェア/ブラウザ系などの主要企業がサポートを表明しており、
ネット配信を中心として広く普及することが期待されている。
YoutubeやVimeoでは既に一部の動画をAV1でも提供し始めており、
Chrome74/Firefox67で高速デコーダdav1dが採用されるなど、ブラウザの対応も進みつつある。
YouTube TestTube
URLﾘﾝｸ(www.youtube.com)
5:名無しさん＠編集中
19/07/07 01:34:06.73 fC6IN7rQ0.net
●VVC(Versatile Video Coding)
H.265/HEVCの後継規格。2020年10月の標準化を目指して
JVET(Joint Video Experts Team)で検討が進められている。
また、H.265/HEVCのようなライセンス問題を繰り返さないため、
MC-IF(Media Coding Industry Forum)という業界団体が立ち上がっている。
URLﾘﾝｸ(www.mc-if.org)
6:名無しさん＠編集中
19/07/07 01:34:41.67 fC6IN7rQ0.net
■各ブラウザのコーデックサポート状況
URLﾘﾝｸ(en.wikipedia.org)
●H.265/HEVC
・URLﾘﾝｸ(html5test.com)
・URLﾘﾝｸ(caniuse.com)
●VP9
・URLﾘﾝｸ(html5test.com)
・URLﾘﾝｸ(caniuse.com)
●AV1
・URLﾘﾝｸ(caniuse.com)
7:名無しさん＠編集中
19/07/07 01:35:26.19 fC6IN7rQ0.net
■各社GPUでのハードウェアエンコード/デコードの参考リンク
●Intel
・URLﾘﾝｸ(software.intel.com)
・URLﾘﾝｸ(en.wikipedia.org)
●NVIDIA
・URLﾘﾝｸ(developer.nvidia.com)
・エンコード： URLﾘﾝｸ(en.wikipedia.org)
・デコード： URLﾘﾝｸ(en.wikipedia.org)
●AMD
・URLﾘﾝｸ(github.com)
・エンコード： URLﾘﾝｸ(en.wikipedia.org)
・デコード： URLﾘﾝｸ(en.wikipedia.org)
8:名無しさん＠編集中
19/07/07 01:36:01.80 fC6IN7rQ0.net
■各社GPUのHWエンコーダでのH.265/HEVCおよびVP9のサポート状況(2019年7月上旬時点)
●Intel QSV (Kaby Lake/Coffee Lake＋Intel Media SDK 2018 R2)
〇HEVC
mainおよびmain10。Bフレーム使用可。
〇VP9
・LinuxでVA-APIを使えばKaby Lakeで利用可能らしい。
URLﾘﾝｸ(gist.github.com)
・Intel Media SDK for Windows 2018 R1で、Cannon Lake向けの
プレビュー機能としてVP9エンコーダ関連のAPIが追加されたので
Cannon LakeからはWindowsでも使えるようになるかもしれない。
●Nvidia NVEnc (Turing＋NVIDIA Video Codec SDK 9.0)
〇HEVC
mainおよびmain10。TuringでBフレームに対応。
〇VP9
未対応
●AMD VCE (Polaris＋AMF 1.4.9)
〇HEVC
mainのみ。main10は不可。Bフレーム使用不可。
〇VP9
未対応
9:名無しさん＠編集中
19/07/07 01:36:51.15 fC6IN7rQ0.net
■AV1のエンコーダ/デコーダ実装の例
●エンコーダ
xiph/rav1e: The fastest and safest AV1 encoder.
URLﾘﾝｸ(github.com)
SVT-AV1
URLﾘﾝｸ(github.com)
●デコーダ
VideoLAN / dav1d - GitLab
URLﾘﾝｸ(code.videolan.org)
AV1 Video Extension (Beta)
URLﾘﾝｸ(www.microsoft.com)
10:名無しさん＠編集中
19/07/07 01:37:46.02 fC6IN7rQ0.net
↑
テンプレここまで
変更点
・説明日付の更新（2019年1月下旬時点→2019年7月上旬時点）
・AV1の状況に以下を追記
・YoutubeやVimeoでの一部採用
・TestTubeのURL
・Chrome74/Firefox67でのdav1d採用
・NVIDIA Video Codec SDK 8.2 → 9.0
・AV1のエンコーダ実装にSVT-AV1を追記。
・AV1のデコーダ実装にAV1 Video Extensionを追記。
11:名無しさん＠編集中
19/07/07 01:39:40.70 fC6IN7rQ0.net
即落ち仕様がどうなったかわからんのでとりあえず20まで保守
12:名無しさん＠編集中
19/07/07 01:40:20.02 fC6IN7rQ0.net
保守
13:名無しさん＠編集中
19/07/07 01:41:23.39 fC6IN7rQ0.net
捕手
14:名無しさん＠編集中
19/07/07 01:42:10.12 fC6IN7rQ0.net
ホシュ
15:名無しさん＠編集中
19/07/07 01:44:00.00 fC6IN7rQ0.net
ひらがなで ほしゅ って書こうとしたら「ERROR: 本文が無いように見えますよね。」って言われた・・・なんぞこれ
16:名無しさん＠編集中
19/07/07 01:44:04.30 65Sqxffm0.net
>>1乙
17:名無しさん＠編集中
19/07/07 01:44:40.09 fC6IN7rQ0.net
うぃうぃ
18:名無しさん＠編集中
19/07/07 01:45:25.39 fC6IN7rQ0.net
ほしゅめんどい
19:名無しさん＠編集中
19/07/07 01:46:08.88 fC6IN7rQ0.net
よしもうすぐ
20:名無しさん＠編集中
19/07/07 01:47:01.67 fC6IN7rQ0.net
20DA!
21:名無しさん＠編集中
19/07/07 01:48:18.24 fC6IN7rQ0.net
ということであとは前スレを消費してから。
テンプレに追記すべき点で、もれてるとこなどあれば指摘をよろしく。
22:名無しさん＠編集中
19/07/07 07:30:22.45 r8+yb6Ye00707.net
乙
23:名無しさん＠編集中
19/07/10 22:42:31.94 o0iQCttz0.net
これが次世代のスレか…さすがすごいスレだ…俺たちは未来に辿り着いた
24:名無しさん＠編集中
19/07/11 20:30:33.70 ZFX/ggO20.net
前スレ>>996
> 今試したら"Mercurial 5.0.2 Inno Setup installer - x64 Windows"だとそのエラーが出た
> MSI installerの方は大丈夫みたいなのでそっちで試してみて
本当だ
MSIインストーラー版のMercurialインストールしたら問題無くビルドできた
Mercurialって単にhg.exe使うためだけに導入してるんだよね？
EXEインストール版はNGでMSIインストール版はokとか完全に訳分からん
ちなみにhg.exeはMSYS2のパッケージにもあったりする
（mercurialって名前のパッケージ）
これ使ってもビルドに失敗してたからまとめると、
・MSYS2版Mercurial： NG
・EXEインストーラー版Mercurial： NG
・MSIインストーラー版Mercurial： OK
こんな感じ。
プログラムのビルドって奥が深い・・・
25:名無しさん＠編集中
19/07/12 15:09:01.99 /hNujOpha.net
パス通ってないだけじゃねーの
26:名無しさん＠編集中
19/07/12 21:56:07.70 JpXl0zFk0.net
さすがにちょっと気になったから調べてみた
MSIインストーラー版のMercurialと
MSYS2版のMercurial
hgでx265のソースを取得してフォルダ比較ツールにかけてみたところ
一つだけファイルの改行コードが違うって言われた
これが原因かなぁ？
27:名無しさん＠編集中
19/07/12 22:48:30.49 L/6jGeEK0.net
いよいよ我々は核心に近づいていた
これが集合知の力だ
とはいえ私にはお茶を淹れることくらいしかできないが
ﾕｯｸﾘ (´･ω･`)つ旦 ｼﾃｲｷﾀﾏｴ
28:名無しさん＠編集中
19/07/13 09:03:34.43 VKV/zQo4M.net
待て
それは孔明の尿だ
29:名無しさん＠編集中
19/07/13 11:03:08.44 TK7oUvnC0.net
げぇっ関羽
30:名無しさん＠編集中
19/07/16 03:22:47.75 0+ZAoJNm0.net
>>29
それGoogle翻訳かけると「日本語→英語」なのに
「関 関」って結果になるのな(`･ω･´)
31:名無しさん＠編集中
19/07/17 17:10:01.07 yhiZbi+C0.net
>>30
適当に言語いくつか試してみたが英語以外も「関 関」になるな、中国語と韓国語は違う結果だが
32:名無しさん＠編集中
19/07/17 18:04:00.12 SUbigZro0.net
顔文字ぐらいで使われてるんだろか
33:名無しさん＠編集中
19/07/17 18:11:18.87 SUbigZro0.net
それはそうと自ビルドするよりrigayaさんのx265使ったほぐあ早いって前スレで言ったけど
xx.y4mファイルへのリンクをミスってpgoが働いてないせいだった
リンク修正したら一応はrigayaさんのよりちょびっと早くなった
34:名無しさん＠編集中
19/07/17 18:49:36.04 PmpY5KRw0.net
Google翻訳さんには本当にお世話になっております
URLﾘﾝｸ(i.imgur.com)
「thunder bird」が「しりのあな」と翻訳される問題は治ったんですね
35:名無しさん＠編集中
19/07/17 19:34:18.08 g5wY7l6HM.net
ジャニーさんは、けつのあなと言っていたのかw
36:名無しさん＠編集中
19/07/20 22:22:34.73 gEwSvH020.net
SmilingWolf氏の5.5回目のAV1ベンチマーク
rav1eの異常にビットレートが膨らんでしまう不具合が修正されたみたい
Codecs performance report, 5th and a half edition
URLﾘﾝｸ(www.reddit.com)
720p
URLﾘﾝｸ(i.redd.it)
URLﾘﾝｸ(i.redd.it)
URLﾘﾝｸ(i.redd.it)
1080p
URLﾘﾝｸ(i.redd.it)
URLﾘﾝｸ(i.redd.it)
URLﾘﾝｸ(i.redd.it)
37:名無しさん＠編集中
19/07/21 11:45:21.80 84sTw9Ib0VOTE.net
av1強いなぁ
GUI環境で簡単に使えるようになって、ハードウェア再生支援の道筋なども見えだしたら使ってみたいかも
38:名無しさん＠編集中
19/07/21 23:32:09.07 VnB96Q8s0.net
webrtcとかで使われるvp8も比較して欲しい
39:名無しさん＠編集中
19/07/21 23:51:42.53 iZWyachfM.net
次世代画像規格JPEG XLのドラフトがJPEG委員会によって承認された模様
8月5日にはISOで投票が行われ国際標準規格となる予定
URLﾘﾝｸ(pbs.twimg.com)
なおJPEG XLはPikとFUIFのハイブリッドでロイヤリティフリー規格とのこと
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
40:名無しさん＠編集中
19/07/22 12:27:08.92 8YChxtVk0.net
JPEG XL(Pik+FUIF)
JPEG XR
WebP
HEIF
AVIF
BPG
41:名無しさん＠編集中
19/07/24 23:26:20.85 hFf34753M.net
PikとFUIFの画質比較データ見つからない
42:名無しさん＠編集中
19/07/24 23:34:40.65 wQTByBuI0.net
>>41
画質比較データって主観的なやつ？
SSIMみたいな客観的な指標だとPikは低めだと思うよ
PikはGuetzliの考えを発展させて作った形式っぽいし
43:名無しさん＠編集中
19/07/25 22:59:07.23 e2RI74Ca0.net
VVCがDraft 6でCommittee Draftになった
Geneva（2019年 3 月）
Gothenburg（2019年 7 月）CD
Geneva（2019年10月）
Brussels（2020年 1 月）DIS
Alpbach（2020年 4 月 ）
Geneva（2020年 6 - 7 月 ）FDIS
Rennes （2020年10月）IS
こうなりそう
44:名無しさん＠編集中
19/07/26 00:20:49.57 nc7x27VLMFOX.net
MPEG-5 EVCもCommittee Draftになったな
個人的にはロイヤリティフリーのこっちが本命
45:名無しさん＠編集中
19/07/28 03:58:40.04 9iJnoKJaH.net
JPEGXLって可逆圧縮のスコアはwebpと比較してどうなんだろう
46:名無しさん＠編集中
19/07/28 07:19:15.83 lkYE+4CqM.net
やや古いけどこんな感じ（FLIF）
URLﾘﾝｸ(flif.info)
47:名無しさん＠編集中
19/07/28 09:55:29.67 xHIt3gHu0.net
動画コーデックの技術を転用した画像フォーマットならギリギリこのスレの範疇でもいいと思うけどそれ以外はスレ違いな気がする
画像に関しても最新の形式について語るスレが欲しいね
48:名無しさん＠編集中
19/07/28 19:14:14.85 28mA7dgPa.net
似たような技術だしここでいいんじゃないの
49:名無しさん＠編集中
19/07/29 09:52:17.73 F1mM7/3cM.net
FLIF/FUIFは算術符号(CABACのバリアント型)つかってるから
H.264/265の親戚として扱えよう
50:名無しさん＠編集中
19/07/29 22:36:59.79 cpGRb6hGdNIKU.net
URLﾘﾝｸ(i.imgur.com)
51:名無しさん＠編集中
19/07/31 10:33:13.29 3/gcN9DL0.net
>>50
グロ
52:名無しさん＠編集中
19/07/31 13:50:53.75 802kroBLH.net
アップルはいいかげんwebp対応してくれ
53:名無しさん＠編集中
19/08/02 18:29:53.60 +saCRnxjM.net
Zen2の登場によって、AV1コーデックを使ったエンコードの速度は向上したのかな？
54:名無しさん＠編集中
19/08/03 18:58:03.91 c/cs9dN50.net
音声になるが、YouTubeのOpus音声の音質を久しぶりにヒアリングテストしてみたところ、以前より聴きやすくなっている印象がある
いつから改善したのかはしらないが、古いラジオ番組をアップしてあるような素材だとわかりやすいかも
全部ダウンロードし直す…のか？
55:名無しさん＠編集中
19/08/04 16:40:50.13 tHRSoFKqa.net
根拠も無しに語られても困る
もし改善されていたとしても単純にopusのバージョンが上がっただけだろう
56:名無しさん＠編集中
19/08/04 18:01:36.47 N+mb771A0.net
ダウンロードし直す、とか書いてるってことは古いのはダウンロードしてあるんでしょ？
印象で語る前に、古い方と新しい方のハッシュ値なりファイルサイズなりビットレートなりを比較すればいいじゃない。
変わってるならダウンロードし直せば良いけど、変わって無かったら印象だけで全部ダウンロードしなおすとかバカみたいでしょ。
57:名無しさん＠編集中
19/08/04 19:26:21.69 v55UDMSD0.net
ヒアリングテスト（笑）
58:名無しさん＠編集中
19/08/05 20:29:29.09 qxysZLtX0.net
>>53
AV1はハードウェアエンコードがなきゃ話にならん(´･ω･｀)
59:名無しさん＠編集中
19/08/08 01:39:30.98 IGW5D2keM.net
YouTube、8月2日から運用の変更があったようですね
【新】YouTubeのエンコード事情
URLﾘﾝｸ(aioilight.space)
60:名無しさん＠編集中
19/08/09 02:08:01.22 d+86vZCpM.net
・オープンソースのマルチメディアフレームワーク「FFmpeg 4.2」が公開
VideoLANの「libdav1d」ライブラリを用いた「AV1」デコードをサポート
URLﾘﾝｸ(forest.watch.impress.co.jp)
61:名無しさん＠編集中
19/08/12 17:08:45.23 mmQFU/0S0.net
YouTubeで久しぶりにAV1動画をダウンロードしてみたが
COSTA RICA IN 4K 60fps HDR (ULTRA HD)
URLﾘﾝｸ(www.youtube.com)
"C:\User Program Files\youtube-dl\youtube-dl.exe" -f 401+251 "URLﾘﾝｸ(www.youtube.com)
pause
で実行してAV1動画をダウンロードすると、508MBのファイル
"C:\User Program Files\youtube-dl\youtube-dl.exe" "URLﾘﾝｸ(www.youtube.com)
pause
で実行してVP9動画をダウンロードすると、1.05GBのファイル
昨年テストしたときに比べ、AV1の方がかなり縮むようになっているようだ
着実に進歩しているようだね
1080pあたりまでだと、Core i5 6300U搭載のノートパソコン（dGPUなし）でもスムーズに再生できることも確認。
時代だぁ〜
62:名無しさん＠編集中
19/08/12 17:21:42.05 7ePuU0kg0.net
AV1の問題はエンコードの方
63:名無しさん＠編集中
19/08/12 19:23:23.10 8sqKJlkNM.net
AV1のエンコードがハードウェアでできるようになるのは、あと2〜3年後くらいかな？
そして現在のHEVC並にこなれたハードウェアとなるとさらに3年以上先か…
CPUでゴリゴリエンコードするか、
HEVCをハードウェアでエンコードするかは、動画の解像度次第かねぇ
フルHDまでならHEVCでいいとして、4KとかはAV1かVVCのどちらかにはしたいところか
64:名無しさん＠編集中
19/08/13 13:39:36.12 X9e6fDDv0.net
URLﾘﾝｸ(code.videolan.org)
dav1d 0.4.0 'Cheetah' リリース
ARM64での速度が最大25%向上
メモリの使用量が場合により半分以上減少
他にはSSEとARMが少し改善
65:名無しさん＠編集中
19/08/13 14:09:19.71 4dt2JaJE0.net
そういや当初に言っていた今頃出始めてる対応ハードって何処行った？
タイミング的にnaviで対応予定だったけど無理でしたって感じで知らん顔してるんかね
66:名無しさん＠編集中
19/08/13 14:33:54.98 4ADFBC5P0.net
>>63
4K放送や4K対応テレビが今後普及する前提で考えた場合だけれども、保存する際の解像度の問題については改めて検討すべき頃合いなのかもしれない
例えば、現行の1080i放送の場合、地上波や一般のBS放送は1440×1080iが一般化してしまったが、ビットレートも放送開始初期に比べて落とされている現状も考えると
実効的な画面解像度（実際に感じられる解像感・情報量といってもいい）は、もはや1280×720pと大差ないのではないかと思われる
さらに近年、画像のリサイズ（アップコンバート）技術が急速に改善されている現状を見ると、ますますその思いが強くなってきている
これは4K放送についても同様で、4K放送だからといってすべて4Kで保存しなればならないわけではなく、
・現行2K放送並でよい→720pあるいは1080p
・4Kの解像感をそこそこ残しつつ、保存ファイルのサイズも落としたい→1440p
・最高画質→2160p
という選択肢があってよいのだと思う
続く
67:名無しさん＠編集中
19/08/13 14:34:44.04 4ADFBC5P0.net
panasonicのDIGAのエンコーダーが低ビットレート時でも1080iにこだわりを見せたりなどの影響もあって、長らくオリジナル解像度での保存を尊ぶ傾向にあるのだけれど、
2Kまでならば情報量的にもそれほどの差がないので意味もなく解像度を落とす必要はなかったが、4K以上がデフォルトになってくると、2160pを1440pにするだけでもかなりの情報量削減にはなるので、
HEVC以降のプログレッシブ信号ベースでの運用が前提のコーデックで保存する際は、解像度を落とすことも積極的に考えてもいいのかもしれない
※ただし、テレビやモニター側でていねいなリサイズ（アップコンバート）が行える環境であることが前提にはなるけれど
>>65
何の話？
68:名無しさん＠編集中
19/08/14 02:23:14.47 VwM4qTBta.net
vulkanが動画のデコードエンコードのAPIを実装する予定らしい
上手くいったらクロスプラットフォームのソフトウェアで便利に使えそうだな
69:名無しさん＠編集中
19/08/14 03:16:11.20 FLRqMk1C0.net
フィルター処理じゃないのか…
70:名無しさん＠編集中
19/08/14 12:31:22.19 SJQI5nNw0.net
URLﾘﾝｸ(www.phoronix.com)
上手くいったら良さげやな。ffmpeg,gstreamerみたいのを置き換えられたら
71:名無しさん＠編集中
19/08/14 12:51:45.23 eNrjw1O6a.net
VulkanのはVulkanドライバーさえ対応していれば、プラットホームに依存しないデコーダやエンコーダが書けるってことだね
ffmpegとかを置き換えるものと言うより、ゲーム制作者が嬉しいんじゃないかね
72:名無しさん＠編集中
19/08/14 14:45:29.66 dZLZB5tm0.net
>>54のYouTubeの音質の件、こちらでも過去にダウンロード済みのものと比較してみたが、
過去にダウンロードした際は、音声がAAC、Vorbis、Opusの3種類のどれかであったものが、
今回ダウンロードしてみるとAACかOpusのいずれかに変更されているようで、Vorbisでいまいちだった
ものがOpusに切り替わったものなどを視聴すると確かに聴きやすくなっている印象がある
近年にアップされているものは、ほとんどOpusに統一されているようだ
73:名無しさん＠編集中
19/08/14 20:01:26.15 LWa6MI3r0.net
APIの話だからgstreamerもあげてることだし、ffmpegで通用すると思ったけど違ったか??
ffmpegのAPIのことね。具体的にはlibavcodecとか。
74:名無しさん＠編集中
19/08/14 22:44:34.67 yoDIwIFna.net
アプリが単にムービーを流したいならffmpegのようなライブラリを使えば済むだろうけど、ムービーをテクスチャとして使おうとするとライブラリに依存したコードになるしプラットホームにも依存するかもしれない
それがVulkanAPIだけで完結するからシンプルになると思われる
あと高度なシェーダーを使ったフィルターが作りやすくなるのも間違いない
75:名無しさん＠編集中
19/08/16 17:58:21.06 jicCtSO7M.net
>>72
ダウンロード時に何もオプションをつけないでダウンロードすると音声フォーマットがダウンロードするタイミングなどでコロコロ変わるのは相変わらずのようですが、
Vorbisが消えただけマシではありますね
個人的にはオプションでbestvideo+251を指定して、ファイルフォーマットはmkvを指定するようにしてますけど
76:名無しさん＠編集中
19/08/18 12:49:23.45 cO0Qf1bi0.net
動画圧縮コーデックをどうこうする前に、まず画質評価指標がより良くなってほしい
>>39で出てきたPIKはノイズが出やすい代わりにディティールが潰れにくいっぽい
画像ごとに得意不得意が出る感じがある
そこらへん上手くいいとこ取りできないものか
77:名無しさん＠編集中
19/08/18 17:35:25.65 LdR+7gmIx.net
URLﾘﾝｸ(direct.sanwa.co.jp)
flacはハイレゾどこまで対応？24bit/192kHz？
78:名無しさん＠編集中
19/08/18 17:49:45.07 PEghx+7SM.net
その手の格安メディアプレーヤーって、大概10bit動画には非対応で死亡確認コースじゃなかったか？
79:名無しさん＠編集中
19/08/19 02:05:21.83 4S/U7ig2H.net
そういやつべのwebmってVP9なんだっけ？
80:名無しさん＠編集中
19/08/19 02:33:44.68 4b1Me/CA0.net
えっ、じゃあav1ってmp4なの
81:名無しさん＠編集中
19/08/19 20:55:19.19 JK8Y9ZB30.net
あｖ１はあｖ１
82:名無しさん＠編集中
19/08/20 01:50:23.97 cdnzmgW00.net
アダルトビデオ1
83:名無しさん＠編集中
19/08/20 03:09:14.85 PEZrxnil0.net
大量の画像を高圧縮して転送する「SmartFileUploader」を提供開始8Kを超える超高精細画像も十分の一以下に圧縮して転送時間を大幅に短縮 | 2019年度 | ニュース | NTTテクノクロス株式会社
URLﾘﾝｸ(www.ntt-tx.co.jp)
>映像向け圧縮技術のHEVCを静止画向けとして採用するだけでなく、
>静止画に特化したチューニングを行うことで、
>JPEG方式で圧縮された画像データもしくはTIFF（非圧縮データ）を
>高い画質を保ったまま約十分の一以下のファイルサイズに圧縮可能となりました。
>また、圧縮による画質低下が気になるユーザーのために
>画質を完全に復元できる可逆圧縮機能も搭載しています。
>*3：可逆圧縮
>圧縮率は低下するものの、元の画像データを完全に復元できる圧縮方式。
>HEVCは可逆圧縮に対応。
知らなんだ(´･ω･`)
84:名無しさん＠編集中
19/08/20 04:01:50.14 7hIrGa7t0.net
そりゃ、劣化させれば幾らでも減らせるだろwww
85:名無しさん＠編集中
19/08/20 12:39:11.05 6lCoRCZ7M.net
たった1/10…
動画舐めんな
86:名無しさん＠編集中
19/08/20 12:59:16.53 v7OJ/STYa.net
AVCはCRF0でエンコードしたら可逆圧縮になっていたけどHEVCでも同じことができるのか？
87:名無しさん＠編集中
19/08/20 14:12:31.37 DYfr1yw00.net
単に量子化しないというだけ
88:名無しさん＠編集中
19/08/20 14:22:04.76 6lCoRCZ7M.net
量子化しないデジタルなんてありえない…
89:名無しさん＠編集中
19/08/20 15:04:41.88 q89UwEJOd.net
CRF0じゃ圧縮どころか膨張だよな
90:名無しさん＠編集中
19/08/20 17:39:51.96 3/KCQegv0.net
基本的には音声をOpus固定（251指定）でも問題ないだろうけど、稀にOpus音声が用意されていないものや、
サラウンド音声でアップされているものについては、サラウンドのみAACしか存在しないケースもあるので、
そのあたりを注意しながらの方がいいでしょうね
91:名無しさん＠編集中
19/08/20 17:41:01.91 3/KCQegv0.net
アンカー抜けたけれど、>>90は>>75へのレスです
92:名無しさん＠編集中
19/08/20 19:56:07.44 DYfr1yw00.net
>>88
デジタルが何かを理解しろ
93:名無しさん＠編集中
19/08/20 20:41:14.90 VxbJJzdAM.net
>>86
x265にも、losslessというオプションがある
ちなみに試してみたけどx264より遅いのに縮まなくて使う意味が感じられなかった
H265の進歩した部分が可逆圧縮には役立たないものなのか、x265にまだ進歩の余地があるのか
94:名無しさん＠編集中
19/08/20 21:35:17.40 EKUDJSd00.net
使う意味、という観点で見るならx264やx265より可逆圧縮コーデック使ったほうが良い。
その方が縮むし速い場合が多いから。
汎用性という意味ではH.264が優れるかもしれないが、様々な環境での汎用性を考慮する必要があるならそもそも可逆圧縮なんてデカいものでやりとりするべきでない。
95:名無しさん＠編集中
19/08/20 21:40:45.98 FZqj56ck0.net
今どきそういうの気にするならdnxかproresしかないだろ
96:名無しさん＠編集中
19/08/20 22:15:58.71 JMkUQ9DLM.net
可逆圧縮コーデックのほうが縮むの？
x264とかのほうが遅い分フレーム間予測とか使ってデータ量削減できてると思ってた
97:名無しさん＠編集中
19/08/20 22:16:26.68 JMkUQ9DLM.net
それと、dnxとかproresって可逆モードあったっけ？
98:名無しさん＠編集中
19/08/20 22:49:05.64 DYfr1yw00.net
>>93
HEVCのデコードに即してる形取ってるだけで、x264より可逆で縮むか云々は別な話だからな、一応出来る様になってるだけ
圧縮効率という最大のトレードオフ要素殺してるんだから複雑さ増してる分遅いし
より圧縮率が高いことで表面化し無かった副次的な記録情報の増加分があるから、相性の良いソースじゃなければ大抵デカくなるわな
99:名無しさん＠編集中
19/08/20 22:53:24.00 DYfr1yw00.net
規格から逸脱しない範囲でVLCの連中が新たな手法実装すれば多少改善もあるかもだけど
同じ手法がx264にも適用出来れば、あっちの可逆圧縮性能も上がるんだよね
そもそもが可逆圧縮の為に作られたコーデックでは無いから、HEVCである事に意義がある訳じゃ無いなら、自分で好適だと思う奴使っときゃいい
100:名無しさん＠編集中
19/08/20 23:04:03.96 gq/e33Xca.net
可逆圧縮の方が縮むとかそれは違う
wavファイルをgzipで圧縮しても全く縮まないどころかむしろ増える可能性がある
だけどflacとか使うと1/2〜1/3位になる
101:名無しさん＠編集中
19/08/20 23:27:16.22 6vBpZqsfa.net
>>100
flacて可逆圧縮じゃないの
>>94の言いたいのは可逆圧縮コーデックとして開発されたもの使うほうが汎用圧縮コーデックのロスレスモード使うより速いし縮むよって事かと
102:名無しさん＠編集中
19/08/20 23:50:22.24 gq/e33Xca.net
>>101
言い方間違えた
汎用可逆圧縮の方が縮むってのは違うと言いたかった
103:名無しさん＠編集中
19/08/21 04:33:54.83 cjzJfxG80.net
>>97
可逆とかそういうのを理解してないけど大丈夫か？
劣化の極めて無い状態で残すのが必要ならdnxかprores
104:名無しさん＠編集中
19/08/21 04:54:16.61 tOy9rTTvM.net
>>103
イミフ
なんでロスレス圧縮の話してんのに、
劣化が極めて少ないとかそんな話が出てくんの？
105:名無しさん＠編集中
19/08/21 05:00:11.41 cjzJfxG80.net
>>104
逆に俺からすれば後々の事考えて残す、というのにavcやhevc使うのが謎
黙ってdnxなproresだろ
106:名無しさん＠編集中
19/08/21 05:04:53.08 tOy9rTTvM.net
>>105
何度も言うけどロスレス圧縮の話してるので……
必要ならいくらでもdnxなりproresに変換すりゃーいいじゃん
ビットレートの無駄とか編集向きじゃないって話ならもちろんわかるけどね
ロスレス圧縮なんて効率考えればアホだもん
107:名無しさん＠編集中
19/08/21 05:07:55.00 cjzJfxG80.net
>>106
まさにそういう話だし、逆にあとの編集考えるわけでもないならフルhdでhevcに3mbpsも当てれば十分じゃね
108:名無しさん＠編集中
19/08/21 05:08:56.72 tOy9rTTvM.net
>>107
だからなんでロスレス圧縮の話してんのにそーなるわけ？
109:名無しさん＠編集中
19/08/21 05:12:03.19 cjzJfxG80.net
逆に後々カラコレやコンポジットしないならロスレス要らんだろ
ロスレスは高画質になるわけではないし中間コーデックも同じ。
ただ見た目で同じ、ではコンポジットやカラコレで粗が出るからわざわざ中間コーデック使うわけ。
カラコレしたらよくわかるよ
110:名無しさん＠編集中
19/08/21 05:16:49.14 tOy9rTTvM.net
イミフ
後々編集するにしてもロスレス圧縮で残しといて画質的なデメリットは無いだろう
それが効率的かはおいておいて
111:名無しさん＠編集中
19/08/21 05:22:55.42 cjzJfxG80.net
>>110
それはやったことないからだね
まぁロスレスなんて一番使いみちがないし必要もない
hrやxqで全部残しておけるくらいストレージ用意するのも大変だが
実写だとbmやredのrawとかもあるけどそれはまた用途も意味も違うしな
112:名無しさん＠編集中
19/08/21 05:25:31.82 tOy9rTTvM.net
>>111
ゲームの録画（FHD）だけどロスレス圧縮で残してるよ
月数TB程度増えるけど今なら非現実的な容量じゃないしね
4Kは計算量的にもビットレート的にもまだ非現実的だと思うわ
113:名無しさん＠編集中
19/08/21 05:26:30.25 xCmM3Fi0d.net
>>110
>>103 (ﾜｯﾁｮｲWW 2b02-O81Y)は、
TVMWスレを荒らしてるHDR君だから
何を言っても話が通じないよ。
編集用非可逆圧縮コーデックのProresが
極めて劣化が無いなんて無学な事を
言っているのは笑えるな。
114:名無しさん＠編集中
19/08/21 05:45:21.28 FXgj8qd70.net
多分ビジュアルロスレスか何かと勘違いしてんでしょう
見た目同じ、とか言ってんのが頓珍漢すぎて会話になってないｗ
115:名無しさん＠編集中
19/08/21 06:12:51.36 cjzJfxG80.net
>>112
あとあとの編集やカラコレしないならフルhd hevc 3Mbpsでよくない？
116:名無しさん＠編集中
19/08/21 06:39:33.85 tOy9rTTvM.net
>>115
3Mbpsとかなめてんのか？
エフェクトとかボロボロになるわ
それに、何度も言うが、ロスレス圧縮の話をしている
117:名無しさん＠編集中
19/08/21 07:12:16.94 cjzJfxG80.net
>>116
見るだけならhevcなら問題ないね
後々のコンポジットや、特にカラコレ考えるならhrでもxqでも選べばいい
hevcに執着する理由がまったくない
118:名無しさん＠編集中
19/08/21 08:02:22.77 HoNOnQ0E0.net
>>117
視力悪いの？
119:
19/08/21 12:09:27.34 2kJijKPg0.net
>>98
可逆圧縮のほうが単純だから早いよ
x265のドキュメントに書いてある
URLﾘﾝｸ(x265.readthedocs.io)
120:名無しさん＠編集中
19/08/21 12:23:10.60 oDME6Gk/0.net
>>118
視力よりもやばいの見えるでしょ。NG入れて触っちゃダメ。
121:名無しさん＠編集中
19/08/21 15:21:46.62 j1U6iFbT0.net
>>119
>>86, 93の流れで安価打ってるのに、何故不可逆との話が出てくる？
122:名無しさん＠編集中
19/08/21 20:10:23.28 2ixso+Qmd.net
>>118
>>113
このスレも荒らされるから触らないように
キチガイだから
123:名無しさん＠編集中
19/08/22 12:38:39.38 EBTWibwR0.net
NetflixのAV1サンプルが新しくなってる。
URLﾘﾝｸ(download.opencontent.netflix.com)
124:名無しさん＠編集中
19/08/22 13:28:26.04 WyebYonRM.net
>>123
めちゃくちゃたくさんファイルがあるが、一番容量のデカい1.3GBのやつでいいのか？
125:名無しさん＠編集中
19/08/22 15:18:02.41 EBTWibwR0.net
>>124
ファイルの説明 m49919_ISOBMFF sequences for experiments on movie fragments.docx をダウンロード。
ContentId>_<CPLId>_<FileId>_<Bitrate>_<FrameRate>_<Encrypted>.mp4
ContentId is either:
C for Chimera (23.976 fps, 24min50s),
CL for Cosmos Laundromat, 24fps, 12 min 10s).
M for Meridian (11 min 59s)
CPLId (Codec, Profile, Level):
V1: avc-baseline-L30
V2: avc-high-L22
V3: avc-high-L40
V4: av1-main-L30
V5: hevc-main10-L31
V6: hevc-main10-L50
A1: heaac
A2: xheaac
126:名無しさん＠編集中
19/08/22 16:38:14.73 WyebYonRM.net
>>125
それぞれのコーデックごとに、*.mp4と*_enc.mp4の2種類が存在するようだけど、
手元の環境で再生できたのは*.mp4のほうのみだな
127:名無しさん＠編集中
19/08/22 18:39:12.44 xeP6DVE+d.net
encはencryptedだから再生できないんじゃね
128:名無しさん＠編集中
19/08/22 19:36:35.96 nw1M1b6T0.net
URLﾘﾝｸ(aomedia.googlesource.com)
URLﾘﾝｸ(aomedia.googlesource.com)
libaomのメモリ消費量が半減した
CPUを使い切るための複数同時エンコードが前よりやりやすくなるね
129:名無しさん＠編集中
19/08/24 17:12:45.91 WaJlI4EOr.net
↓のは全部見たんだけど60fpsの8Kってどっかに無い?
AV1 4K & 8K
URLﾘﾝｸ(www.youtube.com)
130:名無しさん＠編集中
19/08/24 22:19:32.30 xhG44jcL0.net
Mile High Video 2019 議事録
URLﾘﾝｸ(mile-high.video)
131:名無しさん＠編集中
19/08/25 17:58:16.51 tVAvKjED0.net
HEVCにPCMとかの高音質コーデック合わせられるコンテナって
QuickTime以外ありませんか?
132:名無しさん＠編集中
19/08/25 18:01:10.45 RliOBm9iM.net
最強のコンテナ、MKVをお忘れか？
133:名無しさん＠編集中
19/08/25 19:44:52.41 Nxkfd1ny0.net
mkvだね
134:名無しさん＠編集中
19/08/25 20:54:06.78 b9UDHjbY0.net
そもそもmp4コンテナにPCM入れられない訳でも無いんだが
十分なメタデータ付与されているコンテナでそれぞれのストリームの再生に問題出るならデコード側の問題だし
135:名無しさん＠編集中
19/08/25 23:22:01.35 tVAvKjED0.net
mkvですか(`･ω･´)調べて試してみます
持ってるソフトはmp4にPCMは全部ダメだったから
規格的に出来ないもんなのかと思ってました(´･ω･`)
136:名無しさん＠編集中
19/08/25 23:25:46.65 kIzkxnc5d.net
>>131
MPEG-TSもPCMを格納できるね。
137:名無しさん＠編集中
19/08/26 01:39:21.47 T9PY5x+w0.net
ALACに可逆圧縮してmp4に入れるとか
138:名無しさん＠編集中
19/08/26 02:15:24.35 hA6XhzvL0.net
手持ちのツールで旨く扱えもしない音声がPCMな動画ソース何処から持ってきたんだっていう
まぁ次は適切なスレで質問した方がいい
139:名無しさん＠編集中
19/08/26 03:37:20.43 /de9g6W90.net
>>138
怪しいデータではないよ(´･ω･`)
mp4にHEVC/PCM入れられるツールおせーてょ(`･ω･´)macだと嬉しい
140:名無しさん＠編集中
19/08/26 03:40:40.96 k9cPtlCg0.net
mac板で聞けよクズ
141:名無しさん＠編集中
19/08/26 03:43:09.25 JMKQqM+Va.net
ffmpegで無理なんか？
142:名無しさん＠編集中
19/08/26 11:07:08.54 N1cmqcrD0.net
みんな優しいな。スレ違いでけって終わりなのに
143:名無しさん＠編集中
19/08/26 16:15:06.69 dG40foxQ0.net
コンテナの問題で気になったことがあるのだが、映像と音声を分離・結合するMuxerについてだが、
昔はMP4BOXが主流で、その後L-SMASH remuxerとかが出たりしたかと思うのだが、今現在主流のMuxerってなんだろう？
AvidemuxかMKVToolNixあたりなのだろうか？
144:名無しさん＠編集中
19/08/26 16:35:00.74 S5Hr71Zj0.net
MKVとは用途が違うけどMP4ならL-SMASH一択
145:名無しさん＠編集中
19/08/26 18:01:17.35 eT/HzLEn0.net
>>136
業務用だとSMPTE302MでMPEG2TSにLPCM入れてるな
146:名無しさん＠編集中
19/08/26 18:36:42.09 dG40foxQ0.net
>>144
それは何か特別な理由があってとか？
147:名無しさん＠編集中
19/08/26 18:43:31.30 I993fB830.net
L-SMASHはAV1扱えないからこのスレ的にはNG
148:名無しさん＠編集中
19/08/26 18:50:10.52 dG40foxQ0.net
>>147
そういえばAV1を扱えるMuxerって考えてなかった
何があるんだろう？
149:名無しさん＠編集中
19/08/26 20:44:20.33 wS4GJtW1M.net
一番いろんな方式のファイルを扱えるのはFFMPEGなわけで、AV1とか最新の方式も含めてならばFFMPEGで結合や分離をすればいいのでは？
CUIで毎回ファイル名書き換えてやるのも面倒だろうけど
あるいはFFMPEGをGUIで操作できるソフトウェアを併用するか
150:名無しさん＠編集中
19/08/27 22:27:58.05 QlJxxwlhM.net
>>143
>>148
MKVToolnixは昨年10月にリリースされた28.0.0からAV1対応してる。
URLﾘﾝｸ(www.bunkus.org)
mp4boxが含まれてるGPACは6月にリリースされた0.8.0でAV1対応した。
URLﾘﾝｸ(github.com)
151:名無しさん＠編集中
19/08/27 23:54:06.49 Spcja+p/0.net
>>146
1 追加コマンドなしで規格に準拠したMP4を作れるところ
2 バイナリの入手が簡単（MP4boxはインストーラーを実行する必要がある）
パッと思いつくのはこれ
152:名無しさん＠編集中
19/08/28 00:14:14.66 ExV+KHPsM.net
>>150
2つとも対応してるんだね
>>151
逆に言うと、他のソフトウェアは規格に準拠していないの？
昔だけでなくて今もならば大問題なんじゃないの、それ？
153:名無しさん＠編集中
19/08/28 02:08:56.86 aiuLfL2ia.net
x264(265)guiExが吐くmp4とかMIMEタイプおかしいしな
昔の規格との互換性を重視してるらしいがmp4的には異常
まぁ何にせよffmpegでよくね
154:名無しさん＠編集中
19/08/28 10:23:11.32 e4HIMk6y0.net
>>152
今は知らないが、必ずしも規格に準拠したものがデファクトスタンダードになってるとは限らないから
実用面で困ることはない（muken氏曰く規格違反の動画でも互換性で困ったことはない）
>>153
具体的には?
155:名無しさん＠編集中
19/08/28 12:54:03.99 KRUpFWo1M.net
>>153-154
mp4は細かいところで何やら問題があるのかな？
とりあえずmkvなら問題ないならmkvにしといたほうが無難か？
156:名無しさん＠編集中
19/08/28 13:13:32.87 e4HIMk6y0.net
いうほど問題はないと思うが
mkvで困らないのならmkvでいいんじゃないの
コンテナ形式で困っても、ばらしてMP4に再muxするだけだし
157:名無しさん＠編集中
19/08/28 21:57:18.62 pQRyBuin0.net
画像圧縮ツール「Optimage for Mac」がAV1を実験的にサポートし、JPEG/SVG圧縮やコマンドラインツールなどを改善。 | AAPL Ch.
URLﾘﾝｸ(applech2.com)
158:名無しさん＠編集中
19/08/29 07:42:11.46 bmB43TVgH.net
>>157
avif吐けるってこと？
159:名無しさん＠編集中
19/08/29 11:55:29.86 bhxDS7yE0.net
君が記事読んでそう思うならそうなんじゃない？
160:名無しさん＠編集中
19/09/01 08:12:19.35 by6k6rOL0.net
Intel、中華codecもやるっぽい。
OpenVisualCloud/SVT-AVS3
URLﾘﾝｸ(github.com)
良記事があった。
新一代视频编码标准：VVC、AVS3 ※Google翻訳 新世代のビデオコーディング標準：VVC、AVS3
URLﾘﾝｸ(mp.weixin.qq.com)
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
1585日前に更新/166 KB
担当:undef