orange @[email protected]

そもそも、漢数字以外の数字の体系で、数字としての用途に限らず数字を使う(例えば単語中の文字として使う)文化圏な単独の文字コードが割り当てられた「数字 かつ 文字」って、漢数字以外にもあるんだろうか・・・？＞＜

数字 - タイ文字 - Wikipedia https://ja.m.wikipedia.org/wiki/%E3%82%BF%E3%82%A4%E6%96%87%E5%AD%97#%E6%95%B0%E5%AD%97

x音声データやの
o音声データの
(画像のってつけようとしたけど、画像では通常の手段より圧縮出来ない気がしてきてカットしたら「や」が残ってた＞＜；)

実用上は意味無さそうだけど、音声データやの非リアルタイムな受信であれば、相互にいい感じのアルゴリズムで予想して、クライアント側では予想するデータを多数投げて(上り大容量)、サーバー側では一番近いものがどれであったか応答する(下り小容量)方式で絞りこんでく方式でもそこそこ圧縮できそうな気がする＞＜

逆で、超巨大辞書をクライアント側に持たせてサーバーに応答してもらう事で仮想的に『大容量アップロード』を『大容量ダウンロード』かのように使うみたいな意味だと、圧縮の実用上たぶん無理があるし、実用化されてる方式で言うとVQ圧縮に近いものになる？＞＜；

ということはオレンジが書いてる時分割カタログ方式も一応(実用性は謎だけど)、「1バイトのリクエストで巨大なカタログから巨大なひとつのデータを選び送ってもらう」って出来るので、一応クリアしてるっぽい？＞＜；

おささんが想定してるのって「ウェブサーバーとクライアント的なやつの、クライアントからウェブサーバーへのリクエストのデータ量を最小にする」みたいな意味とオレンジは理解したけど、違うのかも？＞＜；

オレンジ方式、たぶんシーズンIDを1bitにしたら失敗するので、1バイトの応答でやるならば1シーズン辺り6bitが限界かも＞＜

例えば1分で変更x4シーズン(？)で、2bitでシーズン、残りの6bitで64のIDのカタログを提示って形にすれば、1分辺り64個提示で受け付け時間(寿命)が3分強のカタログが1バイトの応答で出来るかも＞＜

意味がよくわからないけど、ごく小容量の通信と制限なしの通信で非対称の通信で、小容量側がリクエストで大容量側が実データだとしたら、巨大なカタログを投げつけて、そのカタログにあるIDをある程度時分割で投げ返せばいいんでは感＞＜(説明難しい＞＜；)

4Kで車載実況配信とかも出来るかも？＞＜

オレンジもそう思った＞＜；

この踏み切りっぽい＞＜
https://maps.app.goo.gl/6AuwTM2wFk5ZoPzL7

"Train Slams Into Downed Single-Engine Plane On Pacoima Tracks" を YouTube で見る https://youtu.be/oyfeIdqsnaM

列車迫る線路に小型機不時着、間一髪で操縦士救出 米　写真1枚　国際ニュース：AFPBB News https://www.afpbb.com/articles/-/3384486