このアカウントは、notestockで公開設定になっていません。

またはハードウェアエンコーダーを待つ

ある環境で1 fpsでエンコードできるということは、その環境では1日に24分 @ 60 fps か 48分 @ 30 fps か 1時間 @ 24 fpsまでエンコードできるということなので、相当遅いけれど使い道がないことはない

今どきのCPUでハードウェア支援なしのH.264エンコードはどのくらいのスループットなんだろうか

Release v0.1.0: Made in Tokyo · xiph/rav1e · GitHub https://github.com/xiph/rav1e/releases/tag/0.1.0

> Made in Tokyo <

先程のスクリーンショットはlow_latancy=falseなので品質に妥協しないモードだと思う（現時点でlow_latancyモードがストリーミング用にしっかりチューニングかどうかは知らない）

激強レンダーファーム

いや、もらっても使い道がないな……

圧縮、使う側から見ると「前もって誰かが1回圧縮して、後で皆が伸張する」（圧縮にいくらか資源を消費してよい、伸張に消費する資源は少ないに越したことはない）と「誰かが圧縮しているそばから別の誰かが伸張する」（圧縮にも伸張にも一定以上の資源を消費できない）の間でどちらに寄せられているか、パラメーター調節でどちらにどこまで寄せられるようになっているかという感じ

算術符号の話をする流れですか？！（？る）

"Handbook of Data Compression"、面白いけれど通読するのに根気がいる

汎用可逆圧縮アルゴリズムだとなんだかんだでdeflateと比べてこれが強みというのがあるといい感じみたいなところがあった（今はLZ4、LZMA、Zstandard、HTTPだとBrotli辺りが競合になるのか）

このアカウントは、notestockで公開設定になっていません。

歴史的な経緯と、圧縮アルゴリズムが新しくなっても圧縮・伸張だけをやるツールを差し替えればいいというUnix的価値観

tar形式（の一種）は今のPOSIXにもあるけれど、tarコマンドはもうない（tarとcpioを扱えるpaxコマンドが定義されている）

アプリケーションに埋め込むとはいえ120 MB辞書だったら少しきついなと思って怯えつつリポジトリを確認してしまった

ZstandardをContent-Encodingに使う話は議論されてないわけではなくて、pre-builtな辞書を使わない場合はやれないことはない（ただしリクエストごとのAccept-Encodingを数バイト増やすことになり、Brotliがある現状でそれを正当化するだけの性能が出る必要がある）けれど、使う場合はサイドチャネル攻撃の源にならないようにやる必要があるし、Brotliのように辞書を共有する場合はfairに構築するにはどうしたらよいかという論点も当然ある

https://github.com/mozilla/standards-positions/issues/105 が参考になる

READMEとRFC 7932を読んだらLZ77とハフマン符号が基本っぽい

フラッシュペーパー、知らなかった

このアカウントは、notestockで公開設定になっていません。

占い師に良いネット活動用の名前を付けてもらう話を先日テレビで見た

毎年新生児の名前ランキングと名字の世帯数の記録を収集すれば「40代後半の男性っぽい名前」などを生成することができそう

名前の流行100年史　戦前は「清」、戦後は…｜エンタメ！｜NIKKEI STYLE https://style.nikkei.com/article/DGXBASFE2400U_U1A520C1000000/

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

本当の名簿ならこわいですけれど、人気ランキング的なものなら保険会社や新生児向けのサービスを提供している会社が毎年発表しているのでその辺り

名簿は、まあ、色々な方法で収集することで商売している人々がいるので……

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。