新しいものを表示

良い時間なので、これ再掲しときますね!

i'm lovin' it

今日の

いうてあんまり力は入ってないんですが、イベントやってます。

このタイプのイベントは、PROでフルコンする方向でやるのがストレスなくていい!

ということで、コンディション良いときに初めて3曲フルコンできたやつを。パーフェクトコンボって出るんですねー。その続きでアンコール曲(イベント曲)もフルコンしたよ!

……調子にのってMASTERとかやると惨敗するけどね!!

Mastodon v3.2.0からの流れは、ざっとこういう風になっています。

mainというのが、文字通りメインです。

開発成果はここに積み上がっていき、特定のタイミングでバージョン番号を付与して(タグを切って)リリースされます。

stable-x.xというのは安定版が枝分かれしたもので、mainとは切り離して管理され、そこからリリースされることがあります。

これは、まだ最新版をリリースできるタイミングではない時に、とはいえこの修正適用したバージョン出さないとマズいな、という場合に、必要なものをmainから逆輸入(バックポート)するために作られる枝(ブランチ)です。

枝分かれしたものからmainの新しいバージョンに対しては、連続性がないので、直接アップデートできません。

何も改造してないのであれば、単にmainブランチに切り替えてしまえばいいのですが、

ここに自分なりの修正を加えていた場合は、それを元のブランチに移植する必要がでてきます。

mainとstable-x.xを別々に管理し、両方に同じ修正を適用しておくのが吉です。

スレッドを表示

たとえば、ATMで特定の操作をすると無限にお金が引き出せる方法が発見されたとして、

これをいきなり公表しちゃうと、犯罪と被害が多発するじゃないですか。

こういうのは、決して口外せず、こっそり問題を修正すべき立場の人に伝え、ただちに全てのATMに対策を実施し、修正が行き渡った状態になってから問題を公表します。

Mastodonの場合は、Githubみると、セキュリティのタブがあって、保証対象となるバージョンと、連絡先が書いてあります。ここに速やかに連絡してください。
github.com/mastodon/mastodon/s

----

こういう問題がありましたって公表する時には、できるだけアップデート自体が行き渡っている状態に。理想的にはすべて行き渡った状態にしたい。

一方で『セキュリティアップデートだから、とりあえずあてて! 説明はあとで!』っていうからには、他の問題が起きないことを保証しないといけない。

そのためには、修正部分を最小限にしないといけない。今回のアプデはそういうヤツです。(なお、次が本番です)
github.com/mastodon/mastodon/r
v3.3.0用もあります。

んー、なんかMisskey v12.103.1のビルドだめだな? 戻すか……。

マンゴーラッシーに氷が入っているの図(郡部なので都会ではないですね)

ここまで書いたのでついでに。

動画配信者は、RTMPで動画をFediMovieインスタンスに配送します。動画のストリーミング配送プロトコルですね。

インスタンス側ではffmpegがこの受信側を担っており、HLSにトランスコードして、先程のような小間切れのTSファイルとその一覧のm3u8ファイルを吐き出しています。

ブラウザでこれを受け取って再生するコンポーネントがVideo.jsで、HLSによるストリーミング再生を実現しています。

スレッドを表示

このあいだのP2Pの実例。

いま、S.H.さんがやってるHALOのキャンペーン攻略のライブ動画配信を、
fedimovie.com/w/hcYWdEstnw3aPD

4視聴者が閲覧していて、2人がP2P(WebTorrent)に参加しています。

不参加の2人は、インスタンスから77MBを直接受け取っています。

参加している1人(私)は、添付画像のように、インスタンスから43MB、ピアから33MBというような割合で受け取っています。

また、他のピアに向けて36MBのデータを受け渡しています。

もう一人のピアの内訳はわかりませんが、概ね逆算できるハズです。

このように、たった2人のピアの参加ですら、インスタンスにかかる負荷を軽減する効果があります。

なお、通常の動画はオブジェクトストレージに移動し、そちらからデータを流していますが、ライブの場合はインスタンスのストレージから直接配送します。

小間切れの.tsファイルがあって、その一覧を.m3u8で渡してます。4秒ずつで、1分ちょっと保持してる感じかな。この小間切れを、インスタンスかピアから受け取っているわけです。

スレッドを表示

正しい組み合わせを線でつなごう

補足でちょっと画像つけとくね。

P2Pに参加する(ピアになる)かどうかは、自分の設定と、あと再生する時に画面下部に確認がでます。

ユーザーに断りなく行わないようになっています。

少しでもリスクを減らしたい場合や、帯域に余裕がない(転送量課金対象になっているなど)場合は参加しない方が良いです。

他方、参加することで再生が安定する場合もあるわけです。

何をしているのか理解した上で、活用してください。

スレッドを表示

PeerTubeはファイル容量の大きい動画をホストするサービスということもあり、連合によって投稿を配送する際も、動画そのものを複製しません。

自身のコンテンツを管理しやすいプラットフォームです。

ここでは、動画を投稿したサーバをオリジンインスタンスと呼びます。

他のサーバの動画を再生する場合は、オリジンインスタンスの持っている動画データを直接参照します。

ただ、そのままだと人気のある動画をホストした場合に、みんなのアクセスが集中し、オリジンインスタンスに非常に高い負荷がかかります。

そこで、P2Pとミラーリングで負荷分散する仕組みがあります。

P2Pは、動画を同時視聴しているユーザー同士でデータをシェアしあうことで、オリジンインスタンスの負荷を軽くする仕組みです。

ブラウザ同士で通信しあう時にお互いのIPが割れるということがあるため、自分のブラウザをデータ提供に参加させるかどうかは任意です。

WebTorrentによって、WebRTCで動画データ(フラグメント)を融通しあいます。

参加しているブラウザはピアと呼ばれます。

の動画のシェアについて

動画のURLを投稿に貼ると、リンクになります。

Mastodonでは、Mastodonのプレビューカードという仕組みと、WebのoEmbedという仕組みの組みあわせで、埋め込みプレイヤーが表示されます。

ただし、埋め込みプレイヤーが表示されるのは、投稿を認識してから1〜2分経ったあととなります。

これは、たとえば私の1,525人のフォロワーに配送された際、それぞれの所属サーバで動画に対して埋め込みプレイヤーの取得処理がほぼ同時に発生してしまうため、わざと遅延処理をランダムに入れて、処理を分散させていることによるものです。

もうひとつ、動画のURLを検索欄に入力すると、動画そのものが投稿の一つとしてみえます。

これは動画投稿そのものであるため、これにお気に入りすると、動画の高評価がカウントアップされます!

また、既存のコメントがリプライとしてぶら下がっていて、Mastodon側からリプライでコメントを追加することができます。

この、投稿として動画を認識するのが、ActivityPub対応している動画サービスの醍醐味といえます。

のアカウントとチャンネルについて。

添付のスクリーンショットをみてください。

まず、のえる@FediMovie、noellabo3というのが、私のアカウントになります。

下の二つ『のえるチャンネル』と『のえる@デレステCh』が、私のチャンネルになります。

チャンネルをMastodonやMisskeyからフォローすると、そのチャンネルの新着動画が配送されてくるようになります。

アカウントではなく、チャンネル単位でフォローするのが基本です。

なお、FediMovieなどPeerTubeで登録できるのはチャンネルのみです。

各チャンネルのページにアカウント名と、アカウント名のコピーボタンがあります。ここを押すと、noellabo_ch@fedimovie.comという文字列がコピーされます。

これを、MastodonやMisskeyの検索欄に入力するとアカウントが出てくるので、ここからフォローすることができます。

添付画像はFedibirdのもので、チャンネルはグループとして認識されています。一般のMastodonでは普通のアカウントのように見えます。

基本はカッターナイフであるが、まあこういうのにも便利よね、というヤツ

ウチの子(ノイズキャンセリングついてるワイヤレスBluetoothイヤホン)

室内の雑音を打ち消してくれるので、無音のままつけてても便利である。

古いものを表示
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。