アカウント名:
パスワード:
HLSと言えば何か立派な難しい技術に聞こえるけど、実態は.m3u8で解像度を分けたり、数秒単位の動画にファイル分割してシークやストリーミングしやすい程度に過ぎない。HTTPのContent-Rangeでも別に構わんと思うけど、ビットレートで分けるのは便利になったりサーバー側でキャッシュしやすいとかあるかしらね。で「数秒ごとに分割された動画とかダウンロードする時めんどくさいだろ」って話だが、ffmpegで普通の動画にできる。暗号化もWidevineとか使ってないので鍵があれば当然解除可能。主要なサードパーティークライアントでは対応済みだし、自作のも問題なし。
ところでブラウザってHTTP/HTML/CSS/JSON/m3u8/WebVTTとどれもこれも独自パースが必要なテキストベース形式多いね。HTTP以外は全部XMLベースにしとけば良かったのに。
HLSは「HTTP Live Streamingの略」って名前が示すとおり、元々はライブ配信用のプロトコルですからね。
RTMPの置き換えとして作られたもので、対抗プロトコルにはMPEG-DASHがある。Youtube は MPEG-DASH。HLSもMPEG-DASHも「ムービーを数秒単位の細切れファイル分割」し、そのメタデータ(プレイリスト)を配信する方式。HLSはプレインテキスト(単なるファイル名羅列)方式ですが、MPEG-DASHはXML。
Content-Range はファイル用意済のオンデマンド配信には使えるけど、随時データが作られていくライブ配信には使いにくい。HLS/MPEG-DASHだと、メタファイル記載の最終ファイルから再生を始めるだけ。(ライブ配信の場合、ムービーファイルの増加に合わせてメタファイルも更新されてく)
どちらも複数ビットレートでの配信をサポートしていて、同じ時間単位で区切られてるから、(高解像度のファイル10番を再生し終わったら、次は(普通なら高解像度11番再生の所を)低解像度の11番を再生する、みたいにして)映像音声が途切れること無くシームレスのビットレート切り替えができるというのもContent-Range には出来ない芸当。
>Youtube は MPEG-DASH
Apple用にHLSも吐けると思うけどひょっとしてまさか考えにくいけどAppleもMPEG-DASHサポートした?
流石にそれには反対させてもらうわ。m3u8は改行区切りで縦1列のデータなんだから、どう考えてもタグいらないでしょ。マークアップは万能薬ちゃうぞ。
無駄が多いXMLが廃れたのは相当前じゃんね。
SVGのこと忘れないで差し上げて
XMLは親子関係が複雑で再従兄弟とか出てくるツリーデータを一つのテキストファイルにまとめるには向いてる。MusicXML みたいにその世界では天下取ってるフォーマットはいくつかあるし、OOXMLみたいな使い方だと広まってなくても合理的ではある。ただ、羅列するデータをXMLで使うのは牛刀割鶏で誰も幸せになれない。というか、改行区切りはINIでもCSVでも採用されてる由緒正しい書式なんだから、適当に横文字で名前つけとけばみんな有難がってこういう無駄な議論もなくなると思うんだけどなぁ。
SVGはIEで使えるようになってからは普通に使われている
じゃなくて、#4491266がSVGを忘れているように見えるってことでしょ
しかもHTML/CSSはXMLより前。タイムマシンでも持って来いというのだろうか。ていうかXHTML/XSLの失敗を知らないのだろうか
逆に知らなければ自然な発想ではある。何せ20年くらい前は本気でそう思ってる人やプロダクトはいっぱい居たからね。
動画扱うんやぞ。閉じタグのサイズとか気にするか…?現在のXMLはパッケージされる時は大概圧縮されるし。SGMLので良かったんじゃないかってのは分かるけど。
実際入力支援なし手書きする際も大規模データを扱う際も無駄は多いけどね。ウェブだとgzipもない場合が多いから無視できないし。でも今時そんな気にするような話か?圧縮の有無やバイナリ形式に比べたら誤差でしょ。
XMLは複雑な表現ができる一方で専用のパーサーが必要で、パース後も取扱いが単純じゃないのが面倒なんだよな。単純なmapとlistの組み合わせでの表現に留めたJSONに負けたのは必然。メジャーなプログラミング言語で、そのままserialize/deserializeできるのは強いよ。
大抵の言語(ランタイム)にはXMLパーサーは実装されてるし、XML Schemaを定義さえすればそこからソースコードを生成してシリアライズもできるし、検証も変換も簡単。JSONが流行ったのはスキーマも書かないミスがあっても気づかない雑な使い方をする輩が多いだけの話でしょ。もちろんJSON Schemaを使えば似たようなことはできるけど、XMLの表現力とエコシステムと比べたらゴミ。
でもプログラマは面倒なことが嫌いで、楽に済ませたいんだ。そうでなければプログラマに向いていないとさえ言える。面倒な作業は君たちにまかせるよ。僕たちは新しい世界を作るから。
XMLとJSONを入れ替えてもきれいに成立する皮肉ですな
よほど公的な規格の場合を除いてSchemaなんか書くやついるか?
アプリ中のXMLパーサの設定するのが面倒だからテキストエディタでXMLファイルのほうのネームスペース削除するのが一番快感だよな
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は、経緯的にも独立した文書とは考えられていないわけで。
JSONは機能が少ないことこそがメリットだろ。JSONにコメントがないのは、コメントを入れたら絶対お前らコメントでろくでもないことし始めるだろという理由だし
m3u8がまさにコメントでろくでもないことしているパターンだった
世界中で兆単位の回数で使われるんだから、計算資源だけ考えても無駄はなるべく少ない方がいい。
いやURLの羅列だけでは足りなくてコメントを使ってアドホックに拡張重ねてるじゃん。
その「しやすい程度」こそが、低遅延制御、DPIでHLS特有パターンのパケット帯域を制御できる、帯域に勝手に合わせてくれる、etc…と、配信側とCDNにとって都合がいい事ばかりだと思うのだけど。DASHでないのはご愛敬。日本の外に進出したいなら、CDNの都合に合わせた連携が必須だし、ようやく重い腰を上げたか・やっとかよ・とっくに見切って株売っちゃったよ、とか散々言われて今更うんぬんカンヌン。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
対応済み (スコア:2, 参考になる)
HLSと言えば何か立派な難しい技術に聞こえるけど、実態は.m3u8で解像度を分けたり、数秒単位の動画にファイル分割してシークやストリーミングしやすい程度に過ぎない。
HTTPのContent-Rangeでも別に構わんと思うけど、ビットレートで分けるのは便利になったりサーバー側でキャッシュしやすいとかあるかしらね。
で「数秒ごとに分割された動画とかダウンロードする時めんどくさいだろ」って話だが、ffmpegで普通の動画にできる。
暗号化もWidevineとか使ってないので鍵があれば当然解除可能。
主要なサードパーティークライアントでは対応済みだし、自作のも問題なし。
ところでブラウザってHTTP/HTML/CSS/JSON/m3u8/WebVTTとどれもこれも独自パースが必要なテキストベース形式多いね。
HTTP以外は全部XMLベースにしとけば良かったのに。
Re:対応済み (スコア:4, 参考になる)
HLSは「HTTP Live Streamingの略」って名前が示すとおり、元々はライブ配信用のプロトコルですからね。
RTMPの置き換えとして作られたもので、対抗プロトコルにはMPEG-DASHがある。Youtube は MPEG-DASH。
HLSもMPEG-DASHも「ムービーを数秒単位の細切れファイル分割」し、そのメタデータ(プレイリスト)を配信する方式。
HLSはプレインテキスト(単なるファイル名羅列)方式ですが、
MPEG-DASHはXML。
Content-Range はファイル用意済のオンデマンド配信には使えるけど、
随時データが作られていくライブ配信には使いにくい。
HLS/MPEG-DASHだと、メタファイル記載の最終ファイルから再生を始めるだけ。
(ライブ配信の場合、ムービーファイルの増加に合わせてメタファイルも更新されてく)
どちらも複数ビットレートでの配信をサポートしていて、同じ時間単位で区切られてるから、
(高解像度のファイル10番を再生し終わったら、次は(普通なら高解像度11番再生の所を)低解像度の11番を再生する、みたいにして)
映像音声が途切れること無くシームレスのビットレート切り替えができる
というのもContent-Range には出来ない芸当。
Re: (スコア:0)
>Youtube は MPEG-DASH
Apple用にHLSも吐けると思うけど
ひょっとしてまさか考えにくいけどAppleもMPEG-DASHサポートした?
Re:対応済み (スコア:1)
流石にそれには反対させてもらうわ。m3u8は改行区切りで縦1列のデータなんだから、どう考えてもタグいらないでしょ。マークアップは万能薬ちゃうぞ。
Re: (スコア:0)
無駄が多いXMLが廃れたのは相当前じゃんね。
Re:対応済み (スコア:2)
SVGのこと忘れないで差し上げて
Re:対応済み (スコア:1)
XMLは親子関係が複雑で再従兄弟とか出てくるツリーデータを一つのテキストファイルにまとめるには向いてる。MusicXML みたいにその世界では天下取ってるフォーマットはいくつかあるし、OOXMLみたいな使い方だと広まってなくても合理的ではある。ただ、羅列するデータをXMLで使うのは牛刀割鶏で誰も幸せになれない。というか、改行区切りはINIでもCSVでも採用されてる由緒正しい書式なんだから、適当に横文字で名前つけとけばみんな有難がってこういう無駄な議論もなくなると思うんだけどなぁ。
Re: (スコア:0)
SVGはIEで使えるようになってからは普通に使われている
Re: (スコア:0)
じゃなくて、#4491266がSVGを忘れているように見えるってことでしょ
Re: (スコア:0)
しかもHTML/CSSはXMLより前。タイムマシンでも持って来いというのだろうか。ていうかXHTML/XSLの失敗を知らないのだろうか
Re:対応済み (スコア:1)
逆に知らなければ自然な発想ではある。
何せ20年くらい前は本気でそう思ってる人やプロダクトはいっぱい居たからね。
Re: (スコア:0)
動画扱うんやぞ。閉じタグのサイズとか気にするか…?
現在のXMLはパッケージされる時は大概圧縮されるし。
SGMLので良かったんじゃないかってのは分かるけど。
実際入力支援なし手書きする際も大規模データを扱う際も無駄は多いけどね。
ウェブだとgzipもない場合が多いから無視できないし。
でも今時そんな気にするような話か?
圧縮の有無やバイナリ形式に比べたら誤差でしょ。
Re: (スコア:0)
XMLは複雑な表現ができる一方で専用のパーサーが必要で、パース後も取扱いが単純じゃないのが面倒なんだよな。
単純なmapとlistの組み合わせでの表現に留めたJSONに負けたのは必然。
メジャーなプログラミング言語で、そのままserialize/deserializeできるのは強いよ。
Re: (スコア:0)
大抵の言語(ランタイム)にはXMLパーサーは実装されてるし、XML Schemaを定義さえすればそこからソースコードを生成してシリアライズもできるし、検証も変換も簡単。
JSONが流行ったのはスキーマも書かないミスがあっても気づかない雑な使い方をする輩が多いだけの話でしょ。
もちろんJSON Schemaを使えば似たようなことはできるけど、XMLの表現力とエコシステムと比べたらゴミ。
Re: (スコア:0)
でもプログラマは面倒なことが嫌いで、楽に済ませたいんだ。
そうでなければプログラマに向いていないとさえ言える。
面倒な作業は君たちにまかせるよ。
僕たちは新しい世界を作るから。
Re: (スコア:0)
XMLとJSONを入れ替えてもきれいに成立する皮肉ですな
Re: (スコア:0)
よほど公的な規格の場合を除いてSchemaなんか書くやついるか?
Re: (スコア:0)
アプリ中のXMLパーサの設定するのが面倒だからテキストエディタでXMLファイルのほうのネームスペース削除するのが一番快感だよな
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は、経緯的にも独立した文書とは考えられていないわけで。
Re: (スコア:0)
JSONは機能が少ないことこそがメリットだろ。JSONにコメントがないのは、コメントを入れたら絶対お前らコメントでろくでもないことし始めるだろという理由だし
Re: (スコア:0)
m3u8がまさにコメントでろくでもないことしているパターンだった
Re: (スコア:0)
世界中で兆単位の回数で使われるんだから、計算資源だけ考えても無駄はなるべく少ない方がいい。
Re: (スコア:0)
いやURLの羅列だけでは足りなくてコメントを使ってアドホックに拡張重ねてるじゃん。
Re: (スコア:0)
その「しやすい程度」こそが、低遅延制御、DPIでHLS特有パターンのパケット帯域を制御できる、帯域に勝手に合わせてくれる、etc…と、配信側とCDNにとって都合がいい事ばかりだと思うのだけど。DASHでないのはご愛敬。
日本の外に進出したいなら、CDNの都合に合わせた連携が必須だし、ようやく重い腰を上げたか・やっとかよ・とっくに見切って株売っちゃったよ、とか散々言われて今更うんぬんカンヌン。