TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
【ブライナ】心の闇:弐【レジスト】
【3波】アースソフトPT1/PT2/PT3 Rev.164【TS】
【4K BS/CS】TBS6812/PT4K part1【MMT/TLV】
明日から月曜だし祭も終わりかな
SATELLA1・2 サテラ1,2改造版 ４０台目
【確実】B-CASカード新改造方法判明【簡単】
【MovieWriter】Corel総合 X3s【VideoStudio】
糞環境乙】TSパケットエラー報告9【とは言わせない
Linuxでテレビ総合スレ 避難所 3
犯罪者通報キャンペーン
次世代ビデオコーデック総合スレPart4 【HEVC/VP9/AV1/VVC等】
- 1 ：2019/07/07 〜 最終レス ：2020/01/29
- H.264/AVCの後の様々なビデオコーデック全般について語るスレです。
■主な次世代ビデオコーデック
・H.265/HEVC
・VP9
・AV1 (AOMedia Video 1)
・VVC (Versatile Video Coding)
■前スレ
次世代ビデオコーデック総合スレPart3 【HEVC/VP9/AV1/VVC等】
https://mevius.2ch.sc/test/read.cgi/avi/1548833021/
次スレは>>980が宣言してから立ててください。
- 2 ：
- ■各コーデックの参考リンク
●H.265/HEVC
・https://www.itu.int/rec/T-REC-H.265
・https://www.itu.int/en/ITU-T/studygroups/2017-2020/16/Pages/video/jctvc.aspx
・https://mpeg.chiariglione.org/standards/mpeg-h/high-efficiency-video-coding
・https://hevc.hhi.fraunhofer.de/
・https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
●VP9
・https://www.webmproject.org/vp9/
・https://en.wikipedia.org/wiki/VP9
●AV1
・http://aomedia.org/
・https://aomedia.googlesource.com/aom/
・https://github.com/AOMediaCodec/av1-spec
・https://en.wikipedia.org/wiki/AV1
●VVC
・https://www.itu.int/en/ITU-T/studygroups/2017-2020/16/Pages/video/jvet.aspx
・https://mpeg.chiariglione.org/standards/mpeg-i/versatilevideo-coding
・https://jvet.hhi.fraunhofer.de/
・https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Versatile_Video_Coding
- 3 ：
- ■各ビデオコーデックの概要や状況（2019年7月上旬時点）
●H.265/HEVC
H.264/AVCの後継規格。放送やUltra HD Blu-ray等で採用が進んでいるが
３つのライセンスプールが並立するなどライセンス面での問題も抱えている。
H.265/HEVC特許暗黒時代
https://qiita.com/yohhoy/items/c2579097a507b1fbdddb
HW再生支援のサポートは進んだものの、FirefoxやChromeでの対応が進んでおらず、
ネット配信では使いづらい状況が続いている。(スマートTV向けの配信等は除く)
AppleがHLS(HTTP Live Streaming)やiOS 11やmacOS High Sierraで採用したり、
2018年3月にライセンスプールの１つであるHEVC Advanceが
コンテンツへのライセンス課金を取りやめたりといった好材料も出てきてはいる。
●VP9
Googleによって開発されたロイヤリティフリーのコーデック。
ブラウザ(Safariを除く)やHW再生支援のサポートも進み、主にYoutubeで採用されている。
- 4 ：
- ●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
https://www.youtube.com/testtube
- 5 ：
- ●VVC(Versatile Video Coding)
H.265/HEVCの後継規格。2020年10月の標準化を目指して
JVET(Joint Video Experts Team)で検討が進められている。
また、H.265/HEVCのようなライセンス問題を繰り返さないため、
MC-IF(Media Coding Industry Forum)という業界団体が立ち上がっている。
http://www.mc-if.org/
- 6 ：
- ■各ブラウザのコーデックサポート状況
https://en.wikipedia.org/wiki/HTML5_video#Browser_support
●H.265/HEVC
・https://html5test.com/compare/feature/video.codecs.mp4.h265.html
・https://caniuse.com/#feat=hevc
●VP9
・https://html5test.com/compare/feature/video.codecs.webm.vp9.html
・https://caniuse.com/#feat=webm
●AV1
・https://caniuse.com/#feat=av1
- 7 ：
- ■各社GPUでのハードウェアエンコード/デコードの参考リンク
●Intel
・https://software.intel.com/en-us/media-sdk
・https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
●NVIDIA
・https://developer.nvidia.com/nvidia-video-codec-sdk
・エンコード： https://en.wikipedia.org/wiki/Nvidia_NVENC
・デコード： https://en.wikipedia.org/wiki/Nvidia_PureVideo
●AMD
・https://github.com/GPUOpen-LibrariesAndSDKs/AMF
・エンコード： https://en.wikipedia.org/wiki/Video_Coding_Engine
・デコード： https://en.wikipedia.org/wiki/Unified_Video_Decoder
- 8 ：
- ■各社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で利用可能らしい。
https://gist.github.com/Brainiarc7/24de2edef08866c304080504877239a3
・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 ：
- ■AV1のエンコーダ/デコーダ実装の例
●エンコーダ
xiph/rav1e: The fastest and safest AV1 encoder.
https://github.com/xiph/rav1e
SVT-AV1
https://github.com/OpenVisualCloud/SVT-AV1
●デコーダ
VideoLAN / dav1d - GitLab
https://code.videolan.org/videolan/dav1d
AV1 Video Extension (Beta)
https://www.microsoft.com/ja-jp/p/av1-video-extension-beta/9mvzqvxjbq9v
- 10 ：
- ↑
テンプレここまで
変更点
・説明日付の更新（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 ：
- 即落ち仕様がどうなったかわからんのでとりあえず20まで保守
- 12 ：
- 保守
- 13 ：
- 捕手
- 14 ：
- ホシュ
- 15 ：
- ひらがなで ほしゅ って書こうとしたら「ERROR: 本文が無いように見えますよね。」って言われた・・・なんぞこれ
- 16 ：
- >>1乙
- 17 ：
- うぃうぃ
- 18 ：
- ほしゅめんどい
- 19 ：
- よしもうすぐ
- 20 ：
- 20DA!
- 21 ：
- ということであとは前スレを消費してから。
テンプレに追記すべき点で、もれてるとこなどあれば指摘をよろしく。
- 22 ：
- 乙
- 23 ：
- これが次世代のスレか…さすがすごいスレだ…俺たちは未来に辿り着いた
- 24 ：
- 前スレ>>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 ：
- パス通ってないだけじゃねーの
- 26 ：
- さすがにちょっと気になったから調べてみた
MSIインストーラー版のMercurialと
MSYS2版のMercurial
hgでx265のソースを取得してフォルダ比較ツールにかけてみたところ
一つだけファイルの改行コードが違うって言われた
これが原因かなぁ？
- 27 ：
- いよいよ我々は核心に近づいていた
これが集合知の力だ
とはいえ私にはお茶を淹れることくらいしかできないが
ﾕｯｸﾘ (´･ω･`)つ旦 ｼﾃｲｷﾀﾏｴ
- 28 ：
- 待て
それは孔明の尿だ
- 29 ：
- げぇっ関羽
- 30 ：
- >>29
それGoogle翻訳かけると「日本語→英語」なのに
「関 関」って結果になるのな(`･ω･´)
- 31 ：
- >>30
適当に言語いくつか試してみたが英語以外も「関 関」になるな、中国語と韓国語は違う結果だが
- 32 ：
- 顔文字ぐらいで使われてるんだろか
- 33 ：
- それはそうと自ビルドするよりrigayaさんのx265使ったほぐあ早いって前スレで言ったけど
xx.y4mファイルへのリンクをミスってpgoが働いてないせいだった
リンク修正したら一応はrigayaさんのよりちょびっと早くなった
- 34 ：
- Google翻訳さんには本当にお世話になっております
https://i.imgur.com/cABBeeu.png
「thunder bird」が「しりのあな」と翻訳される問題は治ったんですね
- 35 ：
- ジャニーさんは、けつのあなと言っていたのかw
- 36 ：
- SmilingWolf氏の5.5回目のAV1ベンチマーク
rav1eの異常にビットレートが膨らんでしまう不具合が修正されたみたい
Codecs performance report, 5th and a half edition
https://www.reddit.com/r/AV1/comments/cfao4x/codecs_performance_report_5th_and_a_half_edition/
720p
https://i.redd.it/ens1b6phmab31.png
https://i.redd.it/scwn58phmab31.png
https://i.redd.it/jdnazkphmab31.png
1080p
https://i.redd.it/ft71u4almab31.png
https://i.redd.it/xwpplaalmab31.png
https://i.redd.it/hosviialmab31.png
- 37 ：
- av1強いなぁ
GUI環境で簡単に使えるようになって、ハードウェア再生支援の道筋なども見えだしたら使ってみたいかも
- 38 ：
- webrtcとかで使われるvp8も比較して欲しい
- 39 ：
- 次世代画像規格JPEG XLのドラフトがJPEG委員会によって承認された模様
8月5日にはISOで投票が行われ国際標準規格となる予定
https://pbs.twimg.com/media/D5ldn28XkAYJPxP.jpg
なおJPEG XLはPikとFUIFのハイブリッドでロイヤリティフリー規格とのこと
https://github.com/google/pik
https://github.com/cloudinary/fuif
- 40 ：
- JPEG XL(Pik+FUIF)
JPEG XR
WebP
HEIF
AVIF
BPG
- 41 ：
- PikとFUIFの画質比較データ見つからない
- 42 ：
- >>41
画質比較データって主観的なやつ？
SSIMみたいな客観的な指標だとPikは低めだと思うよ
PikはGuetzliの考えを発展させて作った形式っぽいし
- 43 ：
- 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 ：
- MPEG-5 EVCもCommittee Draftになったな
個人的にはロイヤリティフリーのこっちが本命
- 45 ：
- JPEGXLって可逆圧縮のスコアはwebpと比較してどうなんだろう
- 46 ：
- やや古いけどこんな感じ（FLIF）
https://flif.info/img/comparison.png
- 47 ：
- 動画コーデックの技術を転用した画像フォーマットならギリギリこのスレの範疇でもいいと思うけどそれ以外はスレ違いな気がする
画像に関しても最新の形式について語るスレが欲しいね
- 48 ：
- 似たような技術だしここでいいんじゃないの
- 49 ：
- FLIF/FUIFは算術符号(CABACのバリアント型)つかってるから
H.264/265の親戚として扱えよう
- 50 ：
- https://i.imgur.com/7CamNBQ.jpg
- 51 ：
- >>50
グロ
- 52 ：
- アップルはいいかげんwebp対応してくれ
- 53 ：
- Zen2の登場によって、AV1コーデックを使ったエンコードの速度は向上したのかな？
- 54 ：
- 音声になるが、YouTubeのOpus音声の音質を久しぶりにヒアリングテストしてみたところ、以前より聴きやすくなっている印象がある
いつから改善したのかはしらないが、古いラジオ番組をアップしてあるような素材だとわかりやすいかも
全部ダウンロードし直す…のか？
- 55 ：
- 根拠も無しに語られても困る
もし改善されていたとしても単純にopusのバージョンが上がっただけだろう
- 56 ：
- ダウンロードし直す、とか書いてるってことは古いのはダウンロードしてあるんでしょ？
印象で語る前に、古い方と新しい方のハッシュ値なりファイルサイズなりビットレートなりを比較すればいいじゃない。
変わってるならダウンロードし直せば良いけど、変わって無かったら印象だけで全部ダウンロードしなおすとかバカみたいでしょ。
- 57 ：
- ヒアリングテスト（笑）
- 58 ：
- >>53
AV1はハードウェアエンコードがなきゃ話にならん(´･ω･｀)
- 59 ：
- YouTube、8月2日から運用の変更があったようですね
【新】YouTubeのエンコード事情
https://aioilight.space/blog/youtube-re-encode/
- 60 ：
- ・オープンソースのマルチメディアフレームワーク「FFmpeg 4.2」が公開
VideoLANの「libdav1d」ライブラリを用いた「AV1」デコードをサポート
https://forest.watch.impress.co.jp/docs/news/1200665.html
- 61 ：
- YouTubeで久しぶりにAV1動画をダウンロードしてみたが
COSTA RICA IN 4K 60fps HDR (ULTRA HD)
https://www.youtube.com/watch?v=LXb3EKWsInQ
"C:\User Program Files\youtube-dl\youtube-dl.exe" -f 401+251 "https://www.youtube.com/watch?v=LXb3EKWsInQ"
pause
で実行してAV1動画をダウンロードすると、508MBのファイル
"C:\User Program Files\youtube-dl\youtube-dl.exe" "https://www.youtube.com/watch?v=LXb3EKWsInQ"
pause
で実行してVP9動画をダウンロードすると、1.05GBのファイル
昨年テストしたときに比べ、AV1の方がかなり縮むようになっているようだ
着実に進歩しているようだね
1080pあたりまでだと、Core i5 6300U搭載のノートパソコン（dGPUなし）でもスムーズに再生できることも確認。
時代だぁ〜
- 62 ：
- AV1の問題はエンコードの方
- 63 ：
- AV1のエンコードがハードウェアでできるようになるのは、あと2〜3年後くらいかな？
そして現在のHEVC並にこなれたハードウェアとなるとさらに3年以上先か…
CPUでゴリゴリエンコードするか、
HEVCをハードウェアでエンコードするかは、動画の解像度次第かねぇ
フルHDまでならHEVCでいいとして、4KとかはAV1かVVCのどちらかにはしたいところか
- 64 ：
- https://code.videolan.org/videolan/dav1d/-/tags/0.4.0
dav1d 0.4.0 'Cheetah' リリース
ARM64での速度が最大25%向上
メモリの使用量が場合により半分以上減少
他にはSSEとARMが少し改善
- 65 ：
- そういや当初に言っていた今頃出始めてる対応ハードって何処行った？
タイミング的にnaviで対応予定だったけど無理でしたって感じで知らん顔してるんかね
- 66 ：
- >>63
4K放送や4K対応テレビが今後普及する前提で考えた場合だけれども、保存する際の解像度の問題については改めて検討すべき頃合いなのかもしれない
例えば、現行の1080i放送の場合、地上波や一般のBS放送は1440×1080iが一般化してしまったが、ビットレートも放送開始初期に比べて落とされている現状も考えると
実効的な画面解像度（実際に感じられる解像感・情報量といってもいい）は、もはや1280×720pと大差ないのではないかと思われる
さらに近年、画像のリサイズ（アップコンバート）技術が急速に改善されている現状を見ると、ますますその思いが強くなってきている
これは4K放送についても同様で、4K放送だからといってすべて4Kで保存しなればならないわけではなく、
・現行2K放送並でよい→720pあるいは1080p
・4Kの解像感をそこそこ残しつつ、保存ファイルのサイズも落としたい→1440p
・最高画質→2160p
という選択肢があってよいのだと思う
続く
- 67 ：
- panasonicのDIGAのエンコーダーが低ビットレート時でも1080iにこだわりを見せたりなどの影響もあって、長らくオリジナル解像度での保存を尊ぶ傾向にあるのだけれど、
2Kまでならば情報量的にもそれほどの差がないので意味もなく解像度を落とす必要はなかったが、4K以上がデフォルトになってくると、2160pを1440pにするだけでもかなりの情報量削減にはなるので、
HEVC以降のプログレッシブ信号ベースでの運用が前提のコーデックで保存する際は、解像度を落とすことも積極的に考えてもいいのかもしれない
※ただし、テレビやモニター側でていねいなリサイズ（アップコンバート）が行える環境であることが前提にはなるけれど
>>65
何の話？
- 68 ：
- vulkanが動画のデコードエンコードのAPIを実装する予定らしい
上手くいったらクロスプラットフォームのソフトウェアで便利に使えそうだな
- 69 ：
- フィルター処理じゃないのか…
- 70 ：
- https://www.phoronix.com/scan.php?page=news_item&px=Vulkan-Video-Decode-H1-2020
上手くいったら良さげやな。ffmpeg,gstreamerみたいのを置き換えられたら
- 71 ：
- VulkanのはVulkanドライバーさえ対応していれば、プラットホームに依存しないデコーダやエンコーダが書けるってことだね
ffmpegとかを置き換えるものと言うより、ゲーム制作者が嬉しいんじゃないかね
- 72 ：
- >>54のYouTubeの音質の件、こちらでも過去にダウンロード済みのものと比較してみたが、
過去にダウンロードした際は、音声がAAC、Vorbis、Opusの3種類のどれかであったものが、
今回ダウンロードしてみるとAACかOpusのいずれかに変更されているようで、Vorbisでいまいちだった
ものがOpusに切り替わったものなどを視聴すると確かに聴きやすくなっている印象がある
近年にアップされているものは、ほとんどOpusに統一されているようだ
- 73 ：
- APIの話だからgstreamerもあげてることだし、ffmpegで通用すると思ったけど違ったか??
ffmpegのAPIのことね。具体的にはlibavcodecとか。
- 74 ：
- アプリが単にムービーを流したいならffmpegのようなライブラリを使えば済むだろうけど、ムービーをテクスチャとして使おうとするとライブラリに依存したコードになるしプラットホームにも依存するかもしれない
それがVulkanAPIだけで完結するからシンプルになると思われる
あと高度なシェーダーを使ったフィルターが作りやすくなるのも間違いない
- 75 ：
- >>72
ダウンロード時に何もオプションをつけないでダウンロードすると音声フォーマットがダウンロードするタイミングなどでコロコロ変わるのは相変わらずのようですが、
Vorbisが消えただけマシではありますね
個人的にはオプションでbestvideo+251を指定して、ファイルフォーマットはmkvを指定するようにしてますけど
- 76 ：
- 動画圧縮コーデックをどうこうする前に、まず画質評価指標がより良くなってほしい
>>39で出てきたPIKはノイズが出やすい代わりにディティールが潰れにくいっぽい
画像ごとに得意不得意が出る感じがある
そこらへん上手くいいとこ取りできないものか
- 77 ：
- https://direct.sanwa.co.jp/ItemPage/400-MEDI023?wand=link_banner_mediaplayer
flacはハイレゾどこまで対応？24bit/192kHz？
- 78 ：
- その手の格安メディアプレーヤーって、大概10bit動画には非対応で死亡確認コースじゃなかったか？
- 79 ：
- そういやつべのwebmってVP9なんだっけ？
- 80 ：
- えっ、じゃあav1ってmp4なの
- 81 ：
- あｖ１はあｖ１
- 82 ：
- アダルトビデオ1
- 83 ：
- 大量の画像を高圧縮して転送する「SmartFileUploader」を提供開始8Kを超える超高精細画像も十分の一以下に圧縮して転送時間を大幅に短縮 | 2019年度 | ニュース | NTTテクノクロス株式会社
https://www.ntt-tx.co.jp/whatsnew/2019/190819.html
>映像向け圧縮技術のHEVCを静止画向けとして採用するだけでなく、
>静止画に特化したチューニングを行うことで、
>JPEG方式で圧縮された画像データもしくはTIFF（非圧縮データ）を
>高い画質を保ったまま約十分の一以下のファイルサイズに圧縮可能となりました。
>また、圧縮による画質低下が気になるユーザーのために
>画質を完全に復元できる可逆圧縮機能も搭載しています。
>*3：可逆圧縮
>圧縮率は低下するものの、元の画像データを完全に復元できる圧縮方式。
>HEVCは可逆圧縮に対応。
知らなんだ(´･ω･`)
- 84 ：
- そりゃ、劣化させれば幾らでも減らせるだろwww
- 85 ：
- たった1/10…
動画舐めんな
- 86 ：
- AVCはCRF0でエンコードしたら可逆圧縮になっていたけどHEVCでも同じことができるのか？
- 87 ：
- 単に量子化しないというだけ
- 88 ：
- 量子化しないデジタルなんてありえない…
- 89 ：
- CRF0じゃ圧縮どころか膨張だよな
- 90 ：
- 基本的には音声をOpus固定（251指定）でも問題ないだろうけど、稀にOpus音声が用意されていないものや、
サラウンド音声でアップされているものについては、サラウンドのみAACしか存在しないケースもあるので、
そのあたりを注意しながらの方がいいでしょうね
- 91 ：
- アンカー抜けたけれど、>>90は>>75へのレスです
- 92 ：
- >>88
デジタルが何かを理解しろ
- 93 ：
- >>86
x265にも、losslessというオプションがある
ちなみに試してみたけどx264より遅いのに縮まなくて使う意味が感じられなかった
H265の進歩した部分が可逆圧縮には役立たないものなのか、x265にまだ進歩の余地があるのか
- 94 ：
- 使う意味、という観点で見るならx264やx265より可逆圧縮コーデック使ったほうが良い。
その方が縮むし速い場合が多いから。
汎用性という意味ではH.264が優れるかもしれないが、様々な環境での汎用性を考慮する必要があるならそもそも可逆圧縮なんてデカいものでやりとりするべきでない。
- 95 ：
- 今どきそういうの気にするならdnxかproresしかないだろ
- 96 ：
- 可逆圧縮コーデックのほうが縮むの？
x264とかのほうが遅い分フレーム間予測とか使ってデータ量削減できてると思ってた
- 97 ：
- それと、dnxとかproresって可逆モードあったっけ？
- 98 ：
- >>93
HEVCのデコードに即してる形取ってるだけで、x264より可逆で縮むか云々は別な話だからな、一応出来る様になってるだけ
圧縮効率という最大のトレードオフ要素殺してるんだから複雑さ増してる分遅いし
より圧縮率が高いことで表面化し無かった副次的な記録情報の増加分があるから、相性の良いソースじゃなければ大抵デカくなるわな
- 99 ：
- 規格から逸脱しない範囲でVLCの連中が新たな手法実装すれば多少改善もあるかもだけど
同じ手法がx264にも適用出来れば、あっちの可逆圧縮性能も上がるんだよね
そもそもが可逆圧縮の為に作られたコーデックでは無いから、HEVCである事に意義がある訳じゃ無いなら、自分で好適だと思う奴使っときゃいい
- 100 ：
- 可逆圧縮の方が縮むとかそれは違う
wavファイルをgzipで圧縮しても全く縮まないどころかむしろ増える可能性がある
だけどflacとか使うと1/2〜1/3位になる
100〜のスレッドの続きを読む
/（ ﾟ )( ﾟ ）ヽ
スカパー! プレミアムをPCで視聴 23
メコスチネハーネス Part.2
★SKYLAB SKYHD SKYKIT ★28
【EDCB】EpgDataCap_Bonについて語るスレ 63
【B-CAS改造】Bｶｽｶｰﾄﾞ2038化書き換えﾂｰﾙ配布所 181
ワス
今日からPNS板になりました
■削除依頼候補■判定スレ1
カスカ 懐石・研究 80枚目
--------------------
pixiv退会した人のスレ
バイクの質問に全力で答えるスレ176
【厨房？】地獄変ドットコムってどうよ【終わり？】
【科学】縄文人、ラオス・マレーシアにルーツ？ 金沢大の研究グループがゲノム配列解読★3
キノコ板用語を勝手に使ってたに中川翔子炎上ｗｗ
間違いなくアンチ巨人の奴らが崇敬している人物
コマンドオプション
オートミールの(ﾟдﾟ)ｳﾏｰな食べ方
【メガテンD2】D×2 真・女神転生 リベレーション part593
【画像】テレビ番組に出演した松井珠理奈さんをご覧ください。
【大阪桐蔭】藤原、根尾vsインターハイ優勝者【相川、北村、塚原】
愛知の大学職場一般 パート７
ガールズラブ・百合小説スレ part41
【緊急】堀口恭司VS朝倉海、消滅の危機
【ﾎﾝｺﾏ】極貧の奥様 91【貯金ｾﾞﾛ】
【保守しないと】De 倉本寿彦 応援スレ★46【落ちるスレ】
【ファックス番号確認】千葉県庁Part38【次長新設への道】
もしアクションゲームの世界に入ってしまったら
嵐アンチスレ198
【錯覚】超能力なんて、ねーんだよ【妄想】
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
