アカウント名:
パスワード:
ピクセルサイズ重視かフレームレート重視かで最適な圧縮アルゴリズムが違うってオチはないのか。情報劣化無しという前提だと逆転は無いだろうけど、60fpsだとフレーム間相関が強いから補間データは相対的に少なくなりそうな気がする。
興味本位で x264 で変換してみた（入力はフリー素材で、4k fps のボーダーの動画 [yitechnology.jp]）
入力）258MB 59.94fps 3840x2160 １）23.8MB 59.94fps 1280x720 ２）73.8MB 29.97fps 1920x1080 ３）132MB 29.97fps 3840x2160 グレースケール化
パラメータ次第でいくらでも変わるので参考も参考だけど、H264 では fps 高い方が圧縮は効きそうな感じ３については、グレースケールにしただけなので 256 色に最適化すれば違う結果になると思うが……やり方がわからない
# なお本題では圧縮を考えないものであるのは百も承知で、ただの遊び心です
何も考えずにデフォルト設定で使うのが「圧縮などは考えないものとする」の意図に沿っている気もしますね。（無圧縮でなく）
何も考えずにスマホで写真撮ったら HDR対応 の .heic になっている時代だし。
動画の色空間はYUV系が普通だろうから、問題文の「16,777,216色(24bit)」ってのは何ともチグハグな印象。
っYUV444
YUV の MPEG の場合 [wikipedia.org] を参照。色深度を増やして「16,777,216色(24bit)」になるの？
MPEG用の整数演算は以下の方法で行う。RGBの値域は0〜255の8ビット。YCbCrに基づいているが、8ビット整数に変換する際、Yの値域として16〜235、UやVの値域としては16〜240を使用する。Yの値域の中心は128になっていない。また、値域として0〜255を使ってないことから証明できるように、RGB → YUV → RGBの変換を行うと、元の色に戻らない場合がある。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
ナマ？ (スコア:0)
ピクセルサイズ重視かフレームレート重視かで最適な圧縮アルゴリズムが違うってオチはないのか。
情報劣化無しという前提だと逆転は無いだろうけど、60fpsだとフレーム間相関が強いから補間データは相対的に少なくなりそうな気がする。
Re:ナマ？ (スコア:1)
興味本位で x264 で変換してみた（入力はフリー素材で、4k fps のボーダーの動画 [yitechnology.jp]）
入力）258MB 59.94fps 3840x2160
１）23.8MB 59.94fps 1280x720
２）73.8MB 29.97fps 1920x1080
３）132MB 29.97fps 3840x2160 グレースケール化
パラメータ次第でいくらでも変わるので参考も参考だけど、H264 では fps 高い方が圧縮は効きそうな感じ
３については、グレースケールにしただけなので 256 色に最適化すれば違う結果になると思うが……やり方がわからない
# なお本題では圧縮を考えないものであるのは百も承知で、ただの遊び心です
Re: (スコア:0)
何も考えずにデフォルト設定で使うのが「圧縮などは考えないものとする」の意図に沿っている気もしますね。（無圧縮でなく）
何も考えずにスマホで写真撮ったら HDR対応 の .heic になっている時代だし。
動画の色空間はYUV系が普通だろうから、問題文の「16,777,216色(24bit)」ってのは何ともチグハグな印象。
Re: (スコア:0)
っYUV444
Re: (スコア:0)
YUV の MPEG の場合 [wikipedia.org] を参照。色深度を増やして「16,777,216色(24bit)」になるの？