Skip to content

Instantly share code, notes, and snippets.

@progre
Created March 10, 2018 15:45
Show Gist options
  • Save progre/a11c213b2b6d46e9839c4fc056471cc7 to your computer and use it in GitHub Desktop.
Save progre/a11c213b2b6d46e9839c4fc056471cc7 to your computer and use it in GitHub Desktop.
2018/3/11 配信で書きなぐった未来のピアキャスト像についての妄想
未来のピアキャスト像
いま
- P2Pネイティブクライアント (デスクトップ/Android)
- WME or OBS(rtmp)
- ネイティブプレイヤー
- したらば掲示板など
- 付随サービス類(スタンプキャストとか)
- (少数の犠牲の下)フリー
- YPのサーバー運営
- クライアント開発
未来?
- モバイルファースト
- スマホ
- モバイル(場所)
- 5G時代はモバイルでも高画質視聴できる? →時間が解決してくれるはず。
- つまりサイマルキャストは考えなくていいはず。→PCの高画質志向は限度がある・・・はず
- リスト・プレイヤー・コメントの一体化
- YPにプレイヤーとコメントサーバーがのっかるイメージ
- YPの統一
- YPが分散したまま実現する
- 他のなにか(クライアント側でがんばるとか)
- WebExtensions使えば多少無理ができる(もといNative messagingでなんでもできる) → Rustでつくるのたのしそう(妄想)
- YPの新陳代謝
- 鯖管の財布を殴り続けることになるので負担を分散できるに越したことはない
- 簡単に建てられる(建てられる、周知できる)
- 簡単につぶせる(別のYPにユーザーを流せる)
- Webアクセシビリティ?
- コミュニティが存在していることの可視化
- シェアしやすさ
- シェアを受けた人がすぐ視聴できる
- プロトコル?
- PCP
- リレー管理とデータのバケツリレー
- Web技術で置き換える?
- 3回くらい試みたけど完成させられなかった
- NATトラバーサル問題
- UPnPはIPv6だとデフォでつかえないらしい?
- UDPホールパンチングってIPv6で使えるの?
- 少なくともWebRTCの上ならブラウザが使えるように計らってくれるはず
- だからWebRTCで置き換えるべきだよっていう考えは多分僕個人のフィルターがかかってる
- つまりどういうことだってばよ
- パターンA: Webクローズドのまま進化する
- シェアを受けると自動でクライアントが落ちてきてポートが開いて視聴ができる
- チャンネル一覧もコメントもできる環境がワンクリックでできる
- WebからYPが見える必要がないので見えなくなる
- YPという概念が消えるかも
- すごいシンプルな中央サーバーが一つだけあってP2PYPする
- きっと今のピアキャストと完全な互換性がある
- パターンB: 主要技術がWeb技術に置き換わる
- rtmpがWebRTCに化けてブラウザで完結する
- YPがマストドンみたいになる
- 責任が分散するのでより強い自由(フリーダム)
- それが社会的にどういう意義があるかはしらん
- パターンC: 完全中央サーバー制に移行する
- どこぞの配信サイトよろしくな感じになるけどP2Pでがんばるのでサーバーがそんなにがんばらない
- CaveTubeだこれ
- このパターンはCaveTubeが担う領域な気がする。ローコスト運営(浮いたコストはユーザーに還元される(広告が少ないなど))で適度な自由(リバティ)
- ピアキャストの社会的意義ってなんだっけ
- しらん、って思った人、多分正しい。きっとあなたがTwitchでもYouTubeでもないここにいるのが意義。
- まあこの配信TwitchにもYouTubeにも同時配信してるんですけどねw
- もともとの「(p2p) broadcasting for everyone」はUStreamやYouTube Liveによって既に果たされている
- だから「自由である」ことが意義なんじゃないかなってきはする
- 日本だと法に外れる≒善くないのイメージ(?)が強くて意義を感じにくい
- たとえばえろいの・ぐろいの・やばいのを表現することを善とみなせるのかどうか   大学の時倫理学とってたけど教材全部処分しちゃったなあ
- 仮に「自由である」ことが意義なんだとすると他のサイトでできないことができる必要がある
- 必然的にやばいのになる
- 責任は自分でとってね
- 責任が配信者だけに行くような仕組みである必要がある
- なのでパターンCはピアキャス向きじゃないねって話
- もともとゲーム実況(俺がやるゲームをお前らが実況、略してゲーム実況)ってほぼ黒から細々とコミュニティーが形成されて今の地位があるわけで、
「自由である」ことの社会的意義ってそういうことなのかもしれない
現状との差異
- パターンA
- シェアできない
- ワンクリックでインストールできる何かが必要?インストール済みの人にはワンクリックで再生できる仕組み
- プロトコル付きリンクってOSレベルでサポートされているのではなかろうか?(peercast://ってやつ)
- アプリが分散
- Android版はわりとまとまってる つってもチャンネル一覧、本体、プレイヤーそれぞれ別にインスコしないといけない
- とにかくネイティブアプリでがんばらないといけない→わりとつらい
- プログラミング勢みるとネイティブやってる人ってやっぱり少数派なんですよね。ぼくもいまC#触ってないし。なるさんとかはゲームに振り切ってるし。
- パターンB
- rtmpをどうやってWebRTCに化かすのか
- WebRTCの未来としてWebRTCtoWebRTCが主流になるかもしれないけどまだその気配は全くない
- ぞいだーさん(よてさんだっけ?)がrtmpをwebrtc datachannelで流してmediaelementに食わせるのをやってたような?
- rtmpからH.264/AACをはぎ取るのはサーバーが多少頑張ると理論上できる。たしかコーデックに触りさえしなければ特許問題もないはず。
- 部分的に置き換えることはできるのか?
- peercast.exeは一人で全部やろうとする
- WebRTC data channel でリレーだけやる?→ブラウザの外のアプリケーションにデータを送る手段が→WebExtensions
- パターンA,B共通
- YPの負荷分散(簡単に建てられる、簡単につぶせる)
いまぼくにできること ←ゴール
もうなんかパターンBをやる理由を探してる気がする そうやって3回くらい失敗してるのでなにをすべきかちゃんとかんがえる
一体何ができるんや・・・
チャンネル一覧+チャットは作れそうではある
チャットってどうやって面倒みるんだろ?→ログ残さない前提だとP2Pすればよさそうではある。バケツの下からデータ流して全体に流れるように。
ログ残す前提だと・・・?→GoogleDocでもDropboxでもなんでもいいのでは→そもそも記録を残さない前提で設計してよさそう
P2Pチャットは未来のPeerCastが実装するとして、表面上のチャンネル一覧+チャットは実装できそうではある。
というかWeb技術のチャンネル一覧は既存実装がけっこうある
ましてやそのクライアント専用のチャットを作っても需要はないだろう
→したらばとかに書き込めるなら価値があるやんけ→PeerstPlayerがプレイヤーにチャットつけたように、チャンネル一覧にチャットをつける それなら価値になる?
→Electronアプリか、サーバーサイド+クライアントか。 →著作権厳密にとらえるとサーバーサイドでプロキシするのってアウト?ではなさそう。たぶん。
んーPWAってデスクトップ未対応なんだっけ。
PWAだとプレイヤーに送るのがつらそう。やっぱりElectronか。
プレイヤーどうしよう。インストーラーにvlc同梱するとかいう熱い運用?無理に今の環境を置き換えることを頑張る必要はないか。
チャンネル一覧+コメントビューア/ライターというピースができると
そこにプレイヤーとリレーというピースを加えるとりそうのピアキャストができる
というりそうのためのピース
Electronでどこまでできるかって考えるのやってなかったなそういえば。
あいつ生tcp扱えるのよね。
それでいてストリームのコア部分chroniumに任せられる。
だいぶ雑多になってきた。
ねむいし。
Electronが頑張るっていうパターンDが別に存在する気がする(パターンBの一歩手前の未来なのかも)
そこ熱く考えるには時間がたりん。
ぼくからは以上です。
リスナーさんなにか思うことがあればいまのうちにどうぞ。
とくになければ寝よう。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment