世界を動かす技術を、日本語で。
著者はYouTubeのサンプルを再エンコードしてるって考えてもいいと思う。vp9/avc/av1 -> 非圧縮 -> これで圧縮、で、圧縮率は非圧縮ストリームに対してのものだと思う。そうじゃなかったら、READMEはもっと熱意がある感じになるはずだしね :)
そうだね、もし論文を書いてたら、.rawファイルをエンコードした方が説得力があったかもね。
イントロはH.264やその仲間たちの代替品ってことをかなり明確にしてるね。従来の動画コーデック、H.264やH.265は「気づかれない」視覚情報を捨てることで素晴らしい圧縮を実現してる。でも、完璧な再構築を保証しつつ、意味のある圧縮ができたらどうなる？このプロジェクトは、Bloomフィルタをロスレス動画圧縮メカニズムとして再利用するという、ちょっと変わったアプローチを探求してる。さらに下には、この仕組みがどうしてうまくいくかの説明があるよ：全動画フレームを圧縮するのではなく、フレームの差分にBloomフィルタ圧縮を適用するんだ。これが時間的なコヒーレンスを活かしてる。ほとんどのピクセルは連続するフレーム間であまり変わらないから、スパースな差分マトリックスができて、このアプローチに最適なんだ。もちろん、デルタフレーム圧縮は多くの動画コーデックで長い間使われてきたテーマで、H.264やH.265のようなものは、最終的なエントロピーコーディングの前にデルタフレームの情報をさらに減らすためにモーション推定のような追加技術を使ってる。だから、これをH.264や似たようなもののエントロピーコーディングの代替として見るのが一番いいかもね。
著者です。H.264がロスレスであることには完全に同意します。一般的にはロスィーですけどね。私のアイデア（まだ考え中ですが）は、フレームの差分を合理的なBloomフィルタを使って圧縮することです。以前、条件付きBloomフィルタを使うことについて投稿したことがありますが、それは合理的なkに依存していました。アイデアは、URLが悪意のある可能性が高いかどうかに基づいてkの異なる値を使うことでした。これにより、整数kと比較して同じフィルタサイズでの偽陽性率が低くなります。最近、ほぼ同じアプローチを説明した論文[https://arxiv.org/html/2502.02193v2]が投稿されているのを見ました（彼らのはもっと素敵です）。今のセットアップはちょっと雑なので、もっと厳密なテストをするつもりですが、アイデアを示すには役立つと思います。
圧縮率の計算方法はわかったけど、最悪のケース、平均、最高のケースの圧縮率の例はありますか？編集：あ、リポジトリに写真があるのを見ました。READMEに入れておくと助かるな。
ここに作者がいます。リポジトリはめちゃくちゃだけど、コードの中にはグラフを生成するためのコードもあるから、掘り下げる気があれば見てみて。もっと具体的に、ちゃんとしたテストをたくさんして進めるつもりだよ。まだまだごちゃごちゃした進行中の作業なんだ。
H.264を真のロスレスモードで動かすことも可能だけど、ほとんどやられないね。
うん、NVENCを使ってハードウェアアクセラレーションでも動かせたよ。ただ、再生はちょっと難しかった。ffplayでは動いたけど、他のはダメだった。
重要な洞察：バイナリ文字列に1の密度が低い（具体的にはp* ≈ 0.32453未満）場合、1の位置だけを効率的にエンコードできる。JPEGやMPEGがやっていることの多くは、ゼロの長い連続を作ることができるように問題を再配置することだ。DCTブロックがそのAC/DC成分の位置に対してスキャンされる方法は、多くの動画や画像圧縮技術の中で最も革新的な側面の一つかもしれない。
これが正しいとは思わない。DCTがやることは、色の表現変換とともに、細かいディテールを高い周波数に、核心的なディテールを低い周波数に変えることだよ。そこから、画像の質、つまり圧縮率は高周波数の表現を落とすだけで簡単になる。それに加えて、JPEGはハフマンテーブルを使って画像のサイズをさらに減らしてる。私の知る限り、ランを減らすために特別なことはしてないから、ゼロを並べることはあまり役に立たないよ。
同意。OPのアプローチは実際、動画圧縮にはひどいもので、典型的な動画に存在するピクセルの変化のローカリティを積極的に捨てちゃうからね。もっと優しく言うと、OPの技術は動画フレームに特有のものじゃないってことだ。どんな2つの同じ長さのビット列の差分を圧縮するのにも同じアイデアが使える。とはいえ、これがgzippingしたブロックの連結よりもこの問題に対して優れているとは思えない。なぜなら、圧縮を得るためには入力の分布（ここでは異なるビット位置のセット）が非常に予測可能である必要があるから、つまり非ランダムでなければならない。そして、ハッシュ関数を通すことでその特性が壊れちゃうんだよね（特に暗号的に強いハッシュの場合、出力がランダムと区別できないようにするのが目的だから）。
READMEがちょっと混乱するね。YouTubeの動画に言及してるけど、「ロスレス動画」ってのもあるし。これは、既存のH.264の動画（YouTubeからダウンロードしたような）をロスレスで再圧縮する話なのか、それともソースから新しい動画をロスレスで作る話なのかな？前者はJPEG XLが古いJPEGのDCTを再圧縮する能力を思い出させるけど、圧縮が良くなってもロスレスな画像にはならないよね。H.264は元々ロスレスであることもあるけど、YouTubeはそんなファイルを提供してないし。