2017/07/27 google様の輻輳制御TCP BBRを一部のサーバで試させて頂くなど
(high12,31,32,tokyo102,212,214,216,217-219,221,222,501,503-506,osaka101)
2017/05/22 テスト的にマストドンのテスト
livetubeのドメイン内にありますがlivetube本体とアカウントは連動せずセッションの行き来もなく、どちらかにアカウントがあるかログインしているかは相互に影響しません。
これはlivetubeのアカウントをそのまま使えるようにすることを考えた場合、マストドン側のユーザ名は多バイト文字を使うことを想定しておらず、それができるように書き換えるとおそらく別のサーバやツールとのやり取りに問題があるだろうと思われるのがこれをしない理由のうちのひとつです。
認証の連動は元々マストドン側でできるのでそれはやってもいいのですが。
livetube本体側でマストドンのハッシュタグ#ltを拾うようになっています。
タグを指定できるかオフにできるかあるいはタグの指定でなくてもいいような気もしますがとりあえず現時点ではこのタグで決め打ちでテスト的な。
また別のインスタンス上のツイートでも一人以上のフォローがある場合、またはその関係にある場合の更に別のユーザのツイートのブーストでも仕様的には拾うはずですがこの辺は全くテストしていません。
このインスタンスはぱっと見でできる速く動作するような構成上のチューンはしてあって、割と速く動作するはず、なので普通に快適なマストドンとして使うこともできるはず、包括的なテストや比較のベンチマーク等は全くしてないですが。
また現時点ではやってないですが今後livetube本体側にたくさんあるCPUをスパイク時用に使えるようにするので大きなAPI使用を伴う用途や人力のいわゆるバルス的な使い方もおそらく大丈夫。
マストドンはユーザやツイートのIDが連番の整数による番号でかつそれが普通にプロトコルやURLで外に出ます。なので誰でもサーバ上の全ユーザのリストを得ることができ、スクリプトによるボットフォロー・ボットスパミング、または目的が綺麗とは限らないデータのクロールも誰でも特に遮るものがなく行えます。この点御注意下さい。(APIの回数制限はマストドン側でもデフォルトでかかります。)
よく知られているように例えばtwitterとかだとこれらは容易にはできないようになっています。この辺パッチするのは全然できると思いますが、とりあえず現時点では見た感じそのような感じのようです。
マストドンは別の多くのサーバのタイムラインを実質的にコピーするサーバを持つことも仕様的には問題なくできてそれは不毛なことなのか有益なことなのか、少なくとも作ってる人的には意図通りなのか。
このインスタンスは本家のmasterをあまりタイムラグなく追従しています、本家側のmasterのコミットで何かバグった場合(普通にあります)、普通に巻き込まれます。
ステージングしたバージョンの選べる並列動作とかも実現しえるとは思いますが現時点ではとりあえず面倒なので。
画像や動画の添付について、アップロードしたものは他のインスタンスのフォローやブーストによって他のインスタンスにコピーされ、他のインスタンスが使っているオブジェクトストレージかCDNまたはその両方にコピーが作られる場合があります。
これは当然発信元をロンダリングして露出しやすいということにもなります。フォローする別のインスタンスのアカウントは自分で作ったものかもしれないしその判別はできず、またCDNには通常アクセスの制限がないか非常に緩いです。
マストドン側のアカウントにはメールアドレスが必要です、livetube側からはメールアドレス収集の動機はないので10分メールとかでも特に制限はなくアカウントを作れます。ただその場合はアカウント作成後もアドレス自体は憶えておく必要があります、マストドン側のログインはデフォルトでメールアドレスによるもののみです、これはマストドン側の仕様です。
このようなメールアドレスがログインIDになるやり方の場合、gmailを使っている場合は１つのアドレスで制限なく複数のIDを持つことができます。namae@gmail.comの場合、namae+hoge1@gmail.com, namae+hoge2@gmail.com・・・のような感じ、これはマストドンでも無制限に可能です。
現時点ではテスト的なテストといった感じですがそういったものが好きな方はぜひ試してみていただけると幸甚です。
2017/05/22 PCのChromeでFlashで動画を見る場合にFlashの起動をブロックされる場合がある
→Chrome上部のアドレスの横の鍵をクリック、"Flash"→"このサイトでは常に許可(Always allow on this site)"で常に起動できるようになります。
後程度のサーバでもFlashを使わずに再生できるように入れ替えます。
2017/05/22 かなり前からPCのIEで全く見れなくなっている
→IEの設定でTLS1.2を有効、で今でも見れるはず
2017/05/22 Flashで接続しないと見れない動画が稀にある
→画がAVCで音がmp3の組み合わせになっているとそうなります、livetubeでは非Flashにする場合画がAVCのときは音はAACであると決め打ちになっている部分がありそうなります
2017/05/22 後程近いうちにlivetubeのコメントに書かれるリンクは全てrel=nofollowになります。
これは人間がコメントを読み書きする場合には全く影響せず、何らかのアプリや外部サイトまたは検索ボットがコメントを読み取る場合は影響する場合があります。
これはかなり前からユーザが書き込める部分について検索エンジン様的にはそうなってるべきとのことだったのですが今更的に対応します。Facebook様やTwitter様もその他のサイト様もそれに従っているとのことで。
余談になりますがこれはその検索エンジン様側からコメント側ではなく我々のようなコメントのホスト側へのメッセージなわけで。
そもそも前からlivetubeのコメントでリンクを書かれると被リンク側ではGoogleのコンソールに無価値なリンクが張られてると警告が出るということはそもそもGoogleボットがそのリンクを読んだ段階でそのリンクがサーチランクのスコア的な意味で無価値であると別にnofollowのマークアップに頼るまでもなく認識しているわけで。
これは要はコメントのホスト側に、サーチランクの算出価値的には君等ホスト側のやり方が無価値と言わずとも明らかに黙示的に言っているわけで。まあ別にいいのですが。
他サイト様のリンクは確かにそうなっているようで、かつyoutube様のコメント上のリンクにそうなっているものは見当たらないのでつまりそういうことで。いいのですが。
2016/09/16 ブラウザで見る場合のFlashを使わない動画再生テスト中です
現時点ではs-tokyo218,223で動画を開始、発信側がrtmpで開始、AVCでエンコードしている、見る側がそのサーバで動画を開いた場合のみ使われます。Chrome, Firefox, Safari, Edgeで動作確認。テストしながら今後順次対応拡大します
サーバ間のミラー、鏡、自サーバ、録画については現時点では対応しておらず後程、これらについてはやれることのセマンティクスは同じままやり方を変えるかも、後程。
現時点ではブラウザの動画へのキャッシュ消去をサイト側からはせずブラウザのデフォルトの動作に任せます、特にChromeはデフォルトで今見ているタブに空いてるメモリを全振りするので見た目のメモリ消費が大きくなる場合があります、後程対応。
現時点では動画のUIをサイト側からは何も作らず、ブラウザのデフォルトの動作に任せます、後程対応。
現時点では致命的でない問題は全放置する素朴な簡易対応なので、問題があれば後程対応、何かあれば言ってください。
動画の起動時間とラグについては今後チューンされますがPCでChromeでAVCをデコードする場合現時点でもどちらもFlashを上回っているはず、Flashのネイティブプロトコルで接続するよりもHTTP/2で動画をロードするほうが現時点でも速く、ラグが小さくなっているはず。
動画再生の能力が見る端末とブラウザの組み合せによって変わります、再生できない組み合せが生じる場合があります
-> Google-Chromeの場合ブラウザ内の動画の再生はどの端末にいても内蔵しているffmpegで多くの処理が行われます、MS-EdgeとApple-Safariの場合OSで用意されている動画再生の仕組みを使うようになっており、Firefoxの場合各OSの再生の仕組みが使える場合にそれぞれのそれを使います、
これによって再生の能力の差が生じます、特にmacまたはiPhoneでOSの動画再生する場合(つまりそれらでSafariかFirefoxで見ている場合)、全てのAVCの動画をデコードできるわけではないようです、一方Chromeでは動画再生に若干の負荷とバッテリ消費が増える場合がある代わりに一度再生できた場合どの端末でも共通して再生できることが期待できます、また現時点では多くの場合ChromeはAVCを再生できます、またWindowsでもAVCは全て再生できているように見えます
またFlashでデコードできることに制約されなくなるためこの場合の動画のエンコード方式の追加/削除するかもです、特にHEVCとVPX、これについては後程。
他何かあれば言ってください。
2016/06/17 iPhone,iOS8だと見れない -> 直りました
2016/06/10 AndroidまたはiPhoneでコメントできない -> ">_"<-こうなってるところを押してください
2016/05/15 動画左下<<>>のアイコンについて->HTTP/2で通知します->
超簡易説明->
HTTP/2だけで完結する通知とかバックグラウンドで何か起動できる仕組みを使います、こういうもの->
※,
※
これについては固まりきった仕様のものではなくまた何かを通知した場合それがどう扱われるかはそれを何で表示しているかに依って変わります
GoogleChromeだと現行の全リリースチャンネルで使えるはず、ボタンを常に押せなくなっている場合ブラウザのサイトのアドレスを表示している部分の鍵マークで"通知"を"許可"に
Firefoxでも現行の全リリースで出来るはず、Edgeでも出来るようになるようですが今のビルドではできないようです
Androidではブラウザを開いていなくても通知欄に出るはず
MacでChromeの場合ブラウザを開いた際に開いていなかった時の通知もまとめて表示、OSの通知欄にはでないもののChrome最新で"chrome://flags/#enable-native-notifications"でテスト的にそれもできるようです
Windows10のOSの通知欄に貯まるようには現時点ではできないようです
このやり方は現時点では多くの未完成部分と仕様の変更があります、それでも良い方は使ってください
アカウント単位だけでなくタグでまたは条件で起動または配信側から任意のタイミングにできるようにとかは今は未定
この通知は着信側はLivetube側でのアカウントとのひも付けは必要なくログインしていなくてもできます
2016/04/30 録画の失敗頻発、録画が機能してない->録画がa-tokyo3Xになる場合かなりマシなはず、他のも後程。録画のサーバを選ぶのは今はできないです、動画開始時点であいてそうなところが使われます
2016/04/29 動画左下<<>>のアイコンのところは
httpsでページをロードしている場合のみ押せます、配信側から文言を入れて送ることは今はできないです、その他の詳細は後程に
2016/04/25 brotli使うと稀に壊れる件修正
2016/04/22 どのホストからもアカウントの画像指定できるように再度なっています。 機械判定は小さい画像だとかなりおかしい場合もあるようです、何か変えるかも
2016/04/22 稀にpaypalで★付くのが遅延する場合がある問題修正、paypalのセキュリティアップデートにも対応
2016/04/22 コメント書けない場合がある -> Livetubeではコメントに4バイト文字(絵文字とかです)を書けないです、変えるかも
2016/04/12 アカウントに画像指定できない場合がある ->
https://z.livetube.cc/でログインするとテスト的に再度出来るようになっています。ただしその場合サーバ側ボットで指定された画像に何が写っているかGoogleVisionその他の方法でチェックされる場合があり、画像またはアカウントに何らかの自動処理がされる場合があります。誤判定されていたらメールとかで言うか普通の人間のモデレータに解除してもらってください。後程他のサーバでもできるようにします
2016/02/28 nginxからpushできない -> s-osaka101でできるようになっています、他のは後程
2015/08/20 動画送信のやり方についてはwiki.livetube.ccの内容は古くなっているため、wikiではなくトップページ(このページ)の一番下の説明を参考にして下さい
2015/08/27 ★付きで重い場合high11も使ってください、やり方: ログインして以下のどれかから開始してください,
[high31],
[high32],
[high11]2015/08/30 自分以外のアカウントに★をつけたい -> できるようにしました、各アカウントのページで"このユーザへのスポンサー"でできます
2015/09/02 ★付きの場合high11ではなく代わりにhigh12を使ってください、11は停止
[high12]
AndroidなどでGoogleのPlayStoreが使える場合
GoCoder (このアプリの場合、画面キャプチャーをそのままでは送信できないです)
やり方:
Server info
-> Host -> Server -> [使うサーバ名](s-tokyo223.livetube.ccとか), Port -> [1935]
-> Application -> [live](実際は何でもいい), Stream Name -> [myStream](実際は何でもいい)
-> Publisher Name -> [ログイン名], Password -> [パスワード]
(Applicationの部分の入力はlivetube.ccでは現時点では使わないので現時点では空欄でなければ何でもだいじょうぶです。)
現時点ではhigh26,s-tokyo223,301のみ接続可能です。
OpenBroadcasterSoftware
やり方1:Livetube.ccにログインしてトップページ(このページ)左上"サーバ"で"外部接続RTMP"、OpenBroadcaster側で"Settings" -> "Broadcast Settings"
Mode -> [Live Stream]
Streaming Service -> [Custom]
FMS URL -> [(Livetube.cc側で表示されたFMS URL)]
Play Path/Stream Key (if any) -> [(Livetube.cc側で表示されたStream)]
RTMPの認証またはストリームキーを使うやり方:(TBD)
Wowza GoCoder (このアプリの場合、画面キャプチャーをそのままでは送信できないです)
やり方:
Server info
-> Host -> Server -> [使うサーバ名](s-tokyo223.livetube.ccとか), Port -> [554]
-> Application -> [live](実際は何でもいい), Stream Name -> [myStream](実際は何でもいい)
-> Publisher Name -> [ログイン名], Password -> [パスワード]
Options
-> Video Settings -> Transport -> [TCP]
現時点ではhigh26,s-tokyo223,301のみ接続可能です。
iPhone/iPadのWowzaからの場合、ログイン名に日本語などの多バイト文字を使っている場合発信できないです(ログイン名"hoge"は大丈夫で、"ほげ"はだめ)、これはアプリ側の障害です。別の手段でできるようにするかも。
現時点では接続が切れた場合に再接続すると前のにつながらず新しい発信になってしまうかも。
Adobe FlashMediaEncoder(このアプリの場合、画面キャプチャーをそのままでは送信できないです)
(TBD)
OpenBroadcasterSoftware
やり方1:Livetube.ccにログインしてトップページ(このページ)左上"サーバ"で"外部接続RTMP"、OpenBroadcaster側で"設定" -> "配信"
配信種別 -> [カスタムストリーミングサーバ]
URL -> [(Livetube.cc側で表示されたFMS URL)]
ストリームキー -> [(Livetube.cc側で表示されたStream)]
"OK" -> "配信開始"。この操作は動画を新たに開始する毎に繰り返す必要があります。
RTMPの認証またはストリームキーを使うやり方:(TBD)
ffmpeg
やり方:Livetube.ccにログインしてトップページ(このページ)左上"サーバ"で"外部接続RTMP"、
"ffmpeg [何か入力( -i 〜とか)] -f flv [表示されたrtmpのURL]"
新しいユーザを作る 
Livetube.cc.msi(90.6M 
インストールやり方[Windows版]
Intel Livetubecc_intel.dmg