アカウント名:
パスワード:
HLSと言えば何か立派な難しい技術に聞こえるけど、実態は.m3u8で解像度を分けたり、数秒単位の動画にファイル分割してシークやストリーミングしやすい程度に過ぎない。HTTPのContent-Rangeでも別に構わんと思うけど、ビットレートで分けるのは便利になったりサーバー側でキャッシュしやすいとかあるかしらね。で「数秒ごとに分割された動画とかダウンロードする時めんどくさいだろ」って話だが、ffmpegで普通の動画にできる。暗号化もWidevineとか使ってないので鍵があれば当然解除可能。主要なサードパーティークライアントでは対応済みだし、自作のも問題なし。
ところでブラウザってHTTP/HTML/CSS/JSON/m3u8/WebVTTとどれもこれも独自パースが必要なテキストベース形式多いね。HTTP以外は全部XMLベースにしとけば良かったのに。
流石にそれには反対させてもらうわ。m3u8は改行区切りで縦1列のデータなんだから、どう考えてもタグいらないでしょ。マークアップは万能薬ちゃうぞ。
動画扱うんやぞ。閉じタグのサイズとか気にするか…？現在のXMLはパッケージされる時は大概圧縮されるし。SGMLので良かったんじゃないかってのは分かるけど。
実際入力支援なし手書きする際も大規模データを扱う際も無駄は多いけどね。ウェブだとgzipもない場合が多いから無視できないし。でも今時そんな気にするような話か？圧縮の有無やバイナリ形式に比べたら誤差でしょ。
XMLは複雑な表現ができる一方で専用のパーサーが必要で、パース後も取扱いが単純じゃないのが面倒なんだよな。単純なmapとlistの組み合わせでの表現に留めたJSONに負けたのは必然。メジャーなプログラミング言語で、そのままserialize/deserializeできるのは強いよ。
JSONは読み込んだ後に必要な項目がちゃんと生えているか、細かい事まで見るなら要らないものが生えていないか、をチェックする必要があってめんどう。ちまちまと手書きでチェッカーを書くのはやってられないので、JSONスキーマ的な記述様式が必要になり、…と話を進めると、結局XMLの車輪の再発明に落ち着く。
プログラミング言語で、変数定義や型の指定なんていらないぜ→…→と言ってたけど無いと辛いから型アノテーションやら入れるぜ、ってなったのと似たような、ほんと何度も何度も繰り返されるいつものパターン
まあ、XMLの、どんな問題でも絶対完璧に解決するぜと超大上段に振りかぶった感じに比べると、コンパクトで必要最小限な再発明にはなるんだけども。
わっかる～。「ジェイソン、あれ」とか手ぶりや目線といった超コンパクトなやり取りで済むこともあれば、大上段の家裁の離婚調停ですらダメ男（X MaLe）との話がまとまらなくなることもある、夫婦間の会話みたいないつものパターンでしょ。＃まったく分かってない。
でも、2021年に今更JSONがJIS化されたことは知ったぞ。JIS X 4159 vs JIS X 3061。4000シリーズは「図形、文書構造、文書交換」であって、3000シリーズは「電子計算機用プログラム言語」で、JSONはECMAScript言語(JIS X 3060)の追加扱い。JISでの番号付けを挙げずとも、そもそもJSONは、経緯的にも独立した文書とは考えられていないわけで。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
対応済み (スコア:2, 参考になる)
HLSと言えば何か立派な難しい技術に聞こえるけど、実態は.m3u8で解像度を分けたり、数秒単位の動画にファイル分割してシークやストリーミングしやすい程度に過ぎない。
HTTPのContent-Rangeでも別に構わんと思うけど、ビットレートで分けるのは便利になったりサーバー側でキャッシュしやすいとかあるかしらね。
で「数秒ごとに分割された動画とかダウンロードする時めんどくさいだろ」って話だが、ffmpegで普通の動画にできる。
暗号化もWidevineとか使ってないので鍵があれば当然解除可能。
主要なサードパーティークライアントでは対応済みだし、自作のも問題なし。
ところでブラウザってHTTP/HTML/CSS/JSON/m3u8/WebVTTとどれもこれも独自パースが必要なテキストベース形式多いね。
HTTP以外は全部XMLベースにしとけば良かったのに。
Re: (スコア:1)
流石にそれには反対させてもらうわ。m3u8は改行区切りで縦1列のデータなんだから、どう考えてもタグいらないでしょ。マークアップは万能薬ちゃうぞ。
Re: (スコア:0)
動画扱うんやぞ。閉じタグのサイズとか気にするか…？
現在のXMLはパッケージされる時は大概圧縮されるし。
SGMLので良かったんじゃないかってのは分かるけど。
実際入力支援なし手書きする際も大規模データを扱う際も無駄は多いけどね。
ウェブだとgzipもない場合が多いから無視できないし。
でも今時そんな気にするような話か？
圧縮の有無やバイナリ形式に比べたら誤差でしょ。
Re: (スコア:0)
XMLは複雑な表現ができる一方で専用のパーサーが必要で、パース後も取扱いが単純じゃないのが面倒なんだよな。
単純なmapとlistの組み合わせでの表現に留めたJSONに負けたのは必然。
メジャーなプログラミング言語で、そのままserialize/deserializeできるのは強いよ。
Re: (スコア:0)
JSONは読み込んだ後に必要な項目がちゃんと生えているか、細かい事まで見るなら要らないものが生えていないか、をチェックする必要があってめんどう。ちまちまと手書きでチェッカーを書くのはやってられないので、JSONスキーマ的な記述様式が必要になり、…と話を進めると、結局XMLの車輪の再発明に落ち着く。
プログラミング言語で、変数定義や型の指定なんていらないぜ→…→と言ってたけど無いと辛いから型アノテーションやら入れるぜ、ってなったのと似たような、ほんと何度も何度も繰り返されるいつものパターン
まあ、XMLの、どんな問題でも絶対完璧に解決するぜと超大上段に振りかぶった感じに比べると、コンパクトで必要最小限な再発明にはなるんだけども。
Re:対応済み (スコア:0)
わっかる～。「ジェイソン、あれ」とか手ぶりや目線といった超コンパクトなやり取りで済むこともあれば、大上段の家裁の離婚調停ですらダメ男（X MaLe）との話がまとまらなくなることもある、夫婦間の会話みたいないつものパターンでしょ。＃まったく分かってない。
でも、2021年に今更JSONがJIS化されたことは知ったぞ。
JIS X 4159 vs JIS X 3061。
4000シリーズは「図形、文書構造、文書交換」であって、
3000シリーズは「電子計算機用プログラム言語」で、JSONはECMAScript言語(JIS X 3060)の追加扱い。
JISでの番号付けを挙げずとも、そもそもJSONは、経緯的にも独立した文書とは考えられていないわけで。