« 2020年11月 | トップページ | 2021年1月 »

2020年12月

2020年12月30日 (水)

mjpg-streamerでUSBカメラをストリーミング配信してみる

Raspberry Piで自己完結型のStreamingを行ってみることにした。この世界なかなか良くわかっていないけれども、いろいろ先人の知恵を読ませていただくとmjpg-streamerが簡単そうに思えたのでそれで試すことにした。

まず、mjpg-streamerのインストールから。パッケージ化されていないとのことで、subversionからコードダウンロードする方法に倣った。

$ sudo apt-get update
$ sudo apt-get install -y subversion libjpeg-dev imagemagick
$ svn co https://svn.code.sf.net/p/mjpg-streamer/code/mjpg-streamer mjpg-streamer
$ cd mjpg-streamer
$ make

ところが、以下のエラーに遭遇。ヘッダーファイル内のstructure定義が重複しているようだ。足らないのであれば探すこともできるけれど重複は難解に思える。

pi@raspberrypi:~/mjpg-streamer $ make
gcc -D'SVN_REV="3:172"' -O2 -DLINUX -D_GNU_SOURCE -Wall -c -o utils.o utils.c
In file included from /usr/include/arm-linux-gnueabihf/sys/stat.h:446,
from utils.c:33:
/usr/include/arm-linux-gnueabihf/bits/statx.h:25:8: error: redefinition of ‘struct statx_timestamp’
struct statx_timestamp
^~~~~~~~~~~~~~~
In file included from utils.c:32:
/usr/include/linux/stat.h:56:8: note: originally defined here
struct statx_timestamp {
^~~~~~~~~~~~~~~
In file included from /usr/include/arm-linux-gnueabihf/sys/stat.h:446,
from utils.c:33:
/usr/include/arm-linux-gnueabihf/bits/statx.h:36:8: error: redefinition of ‘struct statx’
struct statx
^~~~~
In file included from utils.c:32:
/usr/include/linux/stat.h:99:8: note: originally defined here
struct statx {
^~~~~
make: *** [<ビルトイン>: utils.o] エラー 1

恐らく同様の問題に遭遇された先人も居るだろうと調べてみるとsvnからgitに切り替えることで乗り切っているようだ。確かに最近はgitだよねぇ、って思いながらtestディレクトリを作ってgitにてコードを展開。

$ sudo apt-get install -y cmake libv4l-dev libjpeg-dev imagemagick
$ mkdir ~
/test
$ cd ~
/test
$ git clone https:
//github.com/jacksonliam/mjpg-streamer.git $ cd mjpg-streamer/mjpg-streamer-experimental
$ make

このmakeは成功。以下でプロジェクトをインストール。

$ sudo make install

mjpg-start.shを mjpg-streamer-experimentalディレクトリに作成する。といっても基本的に先人の知恵をコピペしただけ。

#!/bin/sh
PORT="8090" #ポート番号
ID="user" #ID
PW="password" #パスワード
SIZE="640x360" #画面サイズ
FRAMERATE="2" #フレームレート
export LD_LIBRARY_PATH=/usr/local/lib
./mjpg_streamer \
-i "input_uvc.so -f $FRAMERATE -r $SIZE -d /dev/video0 -y -n" \
-o "output_http.so -w /usr/local/www -p $PORT -c $ID:$PW"

ドキドキしながらBrowserで localhost:8090 を実行するとエラー。

404: Not Found!
Could not open file

Could not find a fileではなくてCould not open file、、、これはディレクトリーの不整合か?
で、あらためて make installのアウトプットを見てみると以下となっている。

-- Installing: /usr/local/lib/mjpg-streamer/www/stream.html

つまり -wオプションで指定しているディレクトリは/usr/local/wwwではなくて/usr/local/share/mjpg-streamer/wwwということだ。で、スクリプトの対象ラインを以下の通り書き換えた。

-o "output_http.so -w /usr/local/share/mjpg-streamer/www -p $PORT -c $ID:$PW"

ブラウザーで確認:

localhost:8090
Streamを選択するとUSBカメラ映像が表示された。

S0011

めでたし、めでたし。

追記:

640x360よりも1280x720で見たくなるのが人情、でワークロード的にどうなるかMonitorixでみてみた(StartスクリプトのSizeを変更)。
ちょっと見ずらいので解説。

12301

メモリー状況で直近から遡ると階段状にダウンしている所があるけれども(下図)そこが640から1280に切り替えたポイント。つまり、1280にしたことで負荷が下がった訳だ。これはカメラが1280だってことに由来するのではないかと思う。640にするには変換が必要だけれど、1280だったらそのままスルーで通せるから。
12302

というこで、カメラ仕様である1280でそのまま流すのが良いってことが判明。

追記その2:

一晩走らせてみた。結果は良好。当然のことながらメモリーリークは発生していないようだし、CPU負荷も十分に小さい。これならCPU発熱も少ない。

System LoadとMemoru:17:00 に1280でストリーミング開始。
M001

CPU Utilization:
M002

Raspberry Pi Temperature:
M003

無事迎えた朝の様子。1280x760 2fps。stream_simpeple.htmlにヘッダーh1を追記したもの。

M004

これなら使えそうだ。

追記その3

Disk I/Oが発生していない。SDカードが摩耗しない。これはいい。

M005

2020年12月28日 (月)

Raspberry PiでYouTubeライブが止まる理由ーその2

Raspberry PiでYouTubeライブが停止してしまう問題の続き。
ひょっとしたらChromiumを更新すれば状況が変わるかもしれないと思い実行。

まず現状確認。78レベル。ちょっと古い。
0011

chroium関係でインストールされているモジュールを確認する。
$ sudo apt install chromiumとタイプしてからTABキーを2回押すとインストールされているモジュールが表示される。この中で怪しい感じなのはffmpegだろうか、、、、
003_20201228070801

とにかく以下を実行する。
$ sudo apt install chromium (return)

インストール完了。83レベルにアップしている。
002_20201228065701

なお、Chromiumを更新したらアプリケーション・ランチャーからChromiumが起動できなくなった。理由は不明だけれども、とりあえずランチャーにChromiumを設定しなおすことで復帰した。

005_20201228065701

で、YouTubeライブで様子見。4日目に破綻した。Chromiumは以下を表示して停止した。

006_20201228065701

ここに至るまでのMonitorixでのモニター結果。やはりメモリーリークは直っておらずずっと増加していた。起動直後に谷があるけれども、これはカメラが繋がっているUSBケーブルをひっかけてしまい、画像が送れなくなったため、止む無く再起動したため。

New005day4

結論:
Chromiumを更新してもメモリーリーク問題(って決めつけている部分もあるけれども)は解決せず。残念。

2020年12月27日 (日)

Python 3.9.1をCentOS7.7にインストールしてみた

Python環境をちゃんと作りたくてPythonをインストールした。CentOS 7.7にはDefaultでPythonがインストールされているけれども、最新のPythonにしたくて実行.

インストールに必要な情報はPython Japanのホームページにある。

Defaultでは/usr/local/binにインストールされる。

インストールが完了した状態で python と叩くと古いバージョンのPythonが立ち上がる。
古いPythonは/usr/binにあり、ここもpathが通っている。で、python シンボリックリンクが張られている。

/usr/binを見てみる。
lrwxrwxrwx. 1 root root 7 8月 14 15:12 python -> python2
lrwxrwxrwx. 1 root root 9 8月 14 15:12 python2 -> python2.7

/usr/local/binを見てみる。
lrwxrwxrwx. 1 root root 9 12月 27 17:17 python3 -> python3.9

シンボリックリンクを作り替えることにする。まず、/usr/binにあるシンボリックリンクpythonを消す。
$ rm /usr/bin/python

次に/usr/local/binにシンボリックpythonを作る。
$ sudo ln -s /usr/local/bin/python3 /usr/local/bin/python

結果は以下となる。
lrwxrwxrwx. 1 root root 22 12月 27 18:13 /usr/local/bin/python -> /usr/local/bin/python3

実際にpythonを叩いてみる。ただし、消した/usr/bin/pythonはキャッシュされたままの場合があるので、任意のディレクトリからpythonと叩くと/usr/bin/pythonを見にいってしまって、「そんなファイルないですけれど。。。」ってことになる。なので、一旦Terminalを終了してTerminalに入りなおす必要がある。
$ python
Python 3.9.1 (default, Dec 27 2020, 17:14:11)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

更新完了。

sudoしたい

今までいろんな事やってきたけれども、自分一人の環境で作業してきたので基本的にrootでログインしていたのだった。やっぱりrootで作業するのはよろしくないと思いちゃんとsudoで仕事しようと思ったわけだが、sudoerの設定でちょっとまごまごしてしまったので備忘録。

userであるpathpilotでログオンしてからsuでrootでの作業に移った。

で以下を実行。
# usermod -G wheel pathpilot
# exit 

これでuserに戻ったわけだが、以下を実行しても自分がwheelに加わったことになっていない。
$ groups
pathpilot

あれやこれや悩んで、行きついたところはログオフして再度ログオンすること。
$ groups
pathpilot wheel
やっと期待する結果になった。で、sudoも実行できたのだった。

恐らく、既にログオンしているuserのgroupは一旦ログオフしないと変更が反映されないのだろう。

2020年12月20日 (日)

networkな日々

NETGEARを購入した。目的はVLANの学習。

NETGEAR GS305Eは5ポートのコンパクトな設計だけれどもVLANやQoSをサポートしたメタルケースの立派なスイッチ。
GS305Eが備えるPort VLAN機能を使ってVLANを体験してみるのだ。

今回の学習用構成概要は以下の通り(いろいろやって結局こうなった図)。
Photo_20201220142401   

AmazonからGS305Eが届いた。
Img03784

開封すると、本体、ACアダプター、マニュアル、取り付けネジが入っている。マニュアルは至って簡単なもの。なので必要と思われるマニュアルをNETGEAR日本語マニュアルページからダウンロードすることも出来る。
Img03785

ACアダプターを接続し、ポート5にルーターからのケーブル(青ケーブル)を接続した。
Img03792

NETGEAR GS305EはDefaultでDHCPがEnableになっている。ということはGS305EがどのIPアドレスを取得したかは取得後に調べることになる。この探索にNETGEAR Insightを使う。別に検出ツールもあるけれど、今回はInsightを使ってみる。
予めスマホにNETGEAR InsightアプリをPlayストアからダウンロードしてインストールしておく。スマホのWi-FiをNETGAREをつないだルーターのWi-Fiに設定し、両者を同じネットワークに配置する。そのうえでNETGEAR Insightをスタートする。するとスマホが接続しているローカルネットワーク上でNETGEAR製品を探索する。無事GS305Eが見つかった。GS305Eの後ろ下4桁はシリアル番号の下4桁。
Img_0001_20201219074101

まずは、Network Nameとデバイス管理者パスワードを設定する画面になるので、そこでNetwork Nameをhome-01にして、デバイス管理者パスワードを設定するとセットアップが進行した。
Img_0002_20201220103101

デバイス表示をタップするとデバイスが表示される。以上でNETGEAR Insightでの作業は終了のようだ。
Img_0003_20201219074201

さてさて、これでNETGEARのIPアドレスの検出が完了した。以降は直接NETGEARをブラウザーからアクセスすることが出来る。で、早速アクセス。ディフォルトのパスワードでログインすると管理者パスワードの変更画面が出てきた。Insightでもパスワードを設定したけれどもあれは何だったんだろう。とりあえずInsightと同じパスワードを設定しておく。

Ng001

NETGEAR GS305Eの状態を取得することが出来る。
Ng002_20201220103901

さて、これからネットワークを構成していく。まずはThinkPad E580のEthernet PortをGS305Eのポート1(オレンジケーブル)に接続する。

Img03793

ケーブルを繋いだ状態。さっきまで接続状態だったWi-Fiの接続が切れている。これは特定ルーターへのパスは一つだけ、というルールのため。代わりにイーサネットでp500kへのパスが開通している。つまり、WindowsはGS305Eをとしてルーターに繋がるパスを、Wi-Fiに対して優先させたわけだ。

Networkbefore_20201220103501

この状態はRealtek - Ethernet Diagnositc Toolで確認する。これはRealtekからダウンロードできる。DHCPによってEthernet portに192.168.1.40がアサインされている。

R001   

ここからEthernet portにVLANを設定していく。今回設定するVLAN IDは5、というのもGS305EがVLAN IDを1から5までしかサポートしないから。

 R002_20201220083601

はい(Y)をクリックしてちょっと待つとVLANの設定が完了する。VLANの設定が終わると仮想ネットワークアダプターが出現した。つまり、VLANポートは仮想アダプターポートとして管理するってことだ。
R003_20201220083601

当然のことながらVLAN設定された事によってルーターとの接続は切れる。で、あたらしいネットワークセグメントを設定する。ここでは192.168.10.XとしてX=100とした。VLANを切ったからどんなセグメントでもいい(192.168.1.Xとかも)わけでない。今回の構成ではいずれのPCもルーターに接続されるネットワークセグメント(192.168.1.X)には繋がったまま。なので、仮にVLANを192.168.1.Xに設定してもトラフィックはルーター側のセグメントに流れてしまう(っていうか一瞬こセグメント設定は悩んだので備忘録でした)。
R004

仮想アダプターポートをみてみると、今設定した192.168.10.100が反映されている。なるほど、なるほど。
R005

この状態でネットワーク接続を見てみるとWi-Fi接続、つまりルーターへの接続も復活している。

Networkafter01_20201220103501

次にV530の設定に移る。まずはEthernet Adapterの増設。RealtekでそろえたかったのでRTL8111Cを購入。1300円台だけどRealtekですから。
Img03796

V530ではまず準備作業としてRealtek Diagnostic UtilityによってVLAN ID=5で仮想アダプターポートを設定し、IPアドレスを192.168.10.50を設定してからケーブルを接続することにする。で、設定の実行。

次にGS305EのポートVLAN設定を行う。これはGUIにて簡単に設定できる。VLAN設定タブを選んで「基本」を選択。基本ポートベースVLANでThinkPadを接続するポート1とV530を接続するポート3をVLANグループ5、つまりVLAN ID=5に設定して、それ以外のポートはなんでもallにする。ここでのallはVLAN ID制限をしないという意味のようだ(そう解釈した)。

Gear

 

ここまでできればケーブルを接続しても誰の迷惑にもならないはずだ。つまりThinkPadで経験したように同一ルーターに繋がるネットワークで競合は起きない。で、おもむろV530を(薄緑ケーブル)をGS305Eに接続する。
Img03797

Pingにより疎通確認実行(実はここではまってしまった。詳しくは"WindowsでPingが片方向しか通らない”を参照されたい)。無事Pingがとおり、VLAN ID=5にて独立したネットワークセグメント192.168.10.Xが2台のPC間に構成されたことになる。

でも、本当にGS305Eの他のポートはルーターのセグメントにつながってるの?との疑問を持つ人が出てくる(まぁ、自分ですけど)ので、GS305Eでallに設定したポート(今回はポート2)にYoga Tabletを接続(黒ケーブル)してルーターを通してインターネットアクセス出来るか確認した。結果はOK!! 
Img03812

これにて冒頭に掲載した構成の設定実地訓練が無事(?)完了したわけだ。

結論:

GS350EのポートVLAN機能を使って、一つのネットワークスイッチ上に独立したネットワークセグメントを構成することができた。
大規模になってくるとスイッチ間をトランクポートで接続した入り、はたまたESXiでVLANサポートするとホストマシーンからもトランクモードで接続されたりしていろいろとバリエーションが広がる。しかし基本はこれ(だろう)。今回の学習を通して、なんとなくだけれどシステム管理者やネットワーク管理者の仕事が分かったような気がする、そんな学習であった。

WindowsでPingが片方向しか通らない

ネットワーク設定をしているWindows 10 PC(PC-AとPC-B)間で、PC-AからPC-BへはPingが通るけれど、PC-BからPC-AへはPingが通らない。こんな状態になってちょっと悩んだのでメモしておく。

結論から言うとFirewall設定の問題だった。今回のネットワークはそれぞれのPCにとって2本目のネットワーク(それぞれのネットワーク異なるセグメント)で、悩んだネットワークはパブリックネットワークに分類されていた。

PC-Aのファイヤーウォール設定を見ると以下になっていた。受信の規則の中でエコー要求ICMPv4受信がパブリックネットワークで有効化されていない。そしてPingはICMPを使っている。つまりICMPv4受信を拒否しているからPingを受信しないわけだ。これによりPC-AからPC-BにPingが通る(送信はできる)がPC-BからPingを拒絶しているということだ。

Ping01

この規則を有効化する必要がある。

Ping02

有効化すると無事PC-AはPC-BからのPingを受信するようになった。
Ping03

いずれのPCもファイヤーウォール設定をしたことがなかったし、このような事象は初めてだったのでちょっと悩んだわけだ。
とは言っても無事解決して、めでたし、めでたし。

2020年12月18日 (金)

PC用スピーカー購入。

RadikoとかNHKプラスとか、PCでサウンドを再生することが増えてきた。そこでAmazonにてPC用スピーカーを購入。販売価格2990円で200円クーポンが付くので実質2790円。

購入時には評価、価格、機能で選んだのでブランド名とか確認してなかったけれど、wish sunというらしい。
Img03769

開封して、箱、本体、付属リーフレットをみてもどこにも生産国が書かれていない。ちょっと怪しい。
Img03772

電源はUSB給電。バッテリー内蔵で約8時間再生可能らしい。入力はライン、TFカード、USBに加えてBluetooth。デスクトップはライン入力に接続、スマホとはBluetoothで接続する。TFカードで再生する場合はどういうフォーマットでファイル保存したらいいんだろう?
Img03774

2台のモニターの下に配置する。高さ的に丁度ピッタリ。これは収まりがいい。
Img03779

ただ、肝心のロゴが傾いているのがご愛敬。
Img03778

Amazonでは重低音とか書かれていたけれど、そんな感じはしない。でも臨場感はしっかりと感じられる。
モードスイッチでモード切替すると現在のモードを日本語音声で教えてくれる。日本語ってことは変な国で作ったものを闇で輸入したわけではないって事。それなりに製品企画されていると判断できるので安心感がある。

ライン(AUX)入力でPCサウンドを再生すると無音状態では”シャー”といった音が乗ってくる。まあアナログだからしょうがないか。
Bluetoothは安定しているようだ。再生が途切れることはない。

全体的に「良い買い物をした」感がある。

2020年12月16日 (水)

Raspbery PiでYouTubeライブが止まる理由

YouTubeを実行しながらMonitorixでモニターしてみた。

14時間くらいでYouTubeのライブ配信が止まった。メモリがおかしい。リークしてるみたい。実際にモニターしていて、「死ぬのは時間の問題だなあ」って思えたし。
とまった時点(本当はその瞬間でYouTubeが止まったか不明)でSystem Loadは低下。しかし、増え続けたメモリーアロケーションは減らない。メモリーが掴まれたままだ。
001  002

あるところまでメモリーを使うとContext Switch数が跳ね上がった。恐らくこの影響でYouTubeライブ配信が動かなくなったんだろうと思う。その結果タイムアウトで一丁上がり。メモリー消費とContext Switchの関係は説明できないけれども、Switch多発でKernelが極端に遅くなって、、、、って感じかと。

でも、これってどうすればいいんだろう??Raspberry Pi固有の問題なんだろうか。

一旦ログオフして再ログオンしたらContext Switch多発は収まったように見えた。これはRaspberry Piのブラウザーでの確認。で、別のPCからリモートでMonitorixを見ようとしたら、初期画面は表示されたもののグラフ表示に移れなかかった。その状態でRaspberry Piブラウザーの表示も固まった。

仕方ないのでReboot。

YouTubeライブは鬼門ってこと?困ったなぁ。

追記:
試しにThinkPadで、同じUSBカメラ・マイクを使って一晩YouTubeライブをしてみた。当然の事ながらメモリーリーク症状は無し。Debianのデバイスドライバーの問題なのか、、、、

Raspberry Piの高温警報は何度で出るか

Raspberry Piは温度がある程度高くなると画面右上に温度計アイコンが表示される。一体何度で表示されるんだろうって素朴な疑問もMonitorixが解決してくれる。

Raspberry Piに負荷をかけ続けて(YouTubeでライブ配信実行)、ケースのファンを外したら温度がどんどん上昇。82度に達したところで温度計アイコン出現。
006

てなわけで、”82度あたり”が答えでした。
グラフをみてるとファンの効果がどの程度あるかもわかって、発熱対策効果を測るにはいいね。

Raspberry Piはどの程度忙しいか

YouTubeでライブ映像配信をさせてみたが、最長で48時間、短いと数時間でライブが切れた。自動で再接続しなかったところをみると結構シビアな切れ方をしたように思う。ThinkPad(Core i3)でYouTubeライブをやってみるとCPU Utilizationが60%程度になることがわかった。これはひょっとしたらRaspberry Piがいっぱいいっぱいになっているのかもしれない。で、システムモニターをしてみたくなった。

先人の知恵に学ぶと、一番手軽そうなのがMoniorixに思えた。このページの通りにインストール実行。唯一のカスタマイズ作業は/etc/monitorix/monitorix.confの変更。Raspberry Pi専用のグラフ表示をEnableにする。

<graph_enable>
 ....
   raspberrypi   = y
 ....

</graph_enable>

で、おもむろにGO!
$ service monitorix restart

私の環境ではRaspberry Piは以下のIP Address。そこをネットワーク上のPCからWebブラウザでアクセスする。
http://192.168.1.17:8080/monitorix
すると以下のOpening画面が表示される。

Monitorix

表示するGraphは選択可能。で、早速CPUの様子を見てみる。昨夜寝る前にYouTubeライブをスタートして一晩走らせた結果が表示されている。4つのコア全てがおよそ75%。これは結構大変そうだ。
Raspicpu

こうなるとCPU温度が気になる。こちらはRaspberry Pi専用のグラフで表示される。右上のグラフがそれ。60度ちょっと。今は12月で部屋はかなり涼しいけれど、結構頑張ってる。ちなみにCPUの上にはキットについてきた小さなファン(風はCPUから外に向けて流す)が取り付けてはある。
Raspitemp

この状態をどう見るかってのは判断が分かれるかもしれないけれど、いずれのコアも25%程度の余裕があるという見方もできる。まぁ、大丈夫ってことだろうか。そうするとYouTubeのライブが中断するのは別の要因?Wifiかぁ?

2020年12月 9日 (水)

Raspberry Piをリモートでアクセス

YouTube Liveの制御がカメラやマイクが繋がっているマシーン上でないと出来ないってことは、常にそのマシーンにアクセスする手段を確保しておかねばならないって事だ。でもRaspberry Piにモニターやキーボードを接続して送ってのはあり得ない。そこでつかってみたくなるのがVNC。

VNCサーバーはRaspberry Pi 4ではデフォルトでインストールされている。ただ、これはデフォルトで無効になっているので、まずはこれを有効化する必要がある。これは至って簡単で、プルダウンメニューの設定からRaspberry Piの設定を選択する。それからインターフェースタブを選んでVNCの有効ラジオボタンをセットするだけ。

Raspberry

VNCクライアントとなるPCにVNC Viewerをインストールする。TigerVNCで検索すると自分のOS用のVNC Viewerが直ぐに見つかる。ここでの落とし穴はUsernameとPassword。Raspberry Piの初期インストール時に特に設定をしてなければDefaultのpi/raspberryでOKだ。なにか設定したかもしれない人はメモを探さねばならいかも(通常のRaspberry Pi使用時には気にしないことだから)。
Vncviewer

無事Raspbery PiのDesktopが表示されれば万事OK。

Vncviewerwindows

これで監視カメラとしてのRaspberry Piは家庭内Wifiが届く範囲ならどこにでも設置できる(ただし電源コンセントだけは必要)。

2020年12月 4日 (金)

バッテリー充電器

久しぶりの出来事記録。

CB1300のバッテリーあがってしまった。購入は2年半前。GSユアサなのでこの期間で死ぬことはないだろうと、充電器を購入。
Amazonでセール特価で1970円。今同じ商品をみてみると3299円。1329円も安くなってたっとことだ。
充電するバッテリーはYTX14-BS 12Ah。

メーカー名がAnhtczyx。なんて読んだらよいかわからない中国製。評価は4つ星で、当たりはずれがある感じ。
ブランドはTOPERSUN、モデルはzyx-J30

Img03609_hdr

まずはシートを外して。
Img03612

ヒューズボックスを外すとバッテリーが現れる。
Img03613

充電の前にバッテリーのマイナス電極を外しておいた。時計など常時通電コンポーネントがあるので、何かあったときにそれへの影響を回避するため。コンセントをいれて電極をセットしたら自動的に充電が始まった。
Img03621

充電モードはMotorcyleモード。Mode Selectionボタンが触れるだけで切り替わるので要注意。スイッチの指紋のマークはそういう意味かも。
LCDが何パーセント充電できたか、電圧、電流、充電器温度を表示してくれる。
Img03616

およそ2時間ほどで充電完了。充電が完了すると自動でOFF。これはいい。
Img03626

充電後イグニッションオン。元気にセルが回ってエンジン始動。めでたし、めでたし。

2020年12月 1日 (火)

YouTubeライブ配信との付き合い方

YouTubeライブ配信はちょっと癖があるみたい。

ライブ配信はYouTube Studioダッシュボードから作成ボタンをクリックしてライブ配信ダッシュボードに移って、ライブカメラアイコンをクリックすることで開始できる(タイトルとか入力する必要あり)。

画面右上のカメラアイコンの作成ボタン:
Photo_20201201202701

とっても注意しないといけないのはライブ配信を終了することができるのはこのダッシュボードだけ(いろいろ見た範囲では)ってこと。実はこのダッシュボードは特別で、このブラウザが動いているハードウエアプラットフォームに密接に結びついている。というのも、ライブカメラを選んでライブ配信を始めようとすると以下の確認が入る。

  • カメラが繋がっているか
  • マイクが繋がっているか

試しにマイクが繋がっていない状態で配信しようとする現れるメッセージ:
Photo_20201201203101

つまり、配信はこれらのデバイスが繋がっているハードウエアプラットフォームでないと行えないわけだ。

一方、どこからでも入れるStudioダッシュボードはハードウエアプラットフォームフリーで、当然のことながら配信をしているハードウエアプラットフォームの制御など出来るわけもない。なので配信制御はできないわけだ。

問題なのは(だと思うのは)、配信している(つまりカメラやマイクが繋がっている)PCで、ライブ配信をしているダッシュボード(「ライブ配信を終了」ってボタンを持っているダッシュボード)から別のダッシュボードに移動したりすると、この配信をしているダッシュボードに戻ってこれないこと。もどってこれないと配信停止ができない。ライブ配信を終了するボタンはカメラやマイクを止めることができるはずなんだけど、そのボタンがなくなっちゃうと止めようがない。

とっても大事にしないといけないダッシュボード:
Photo_20201201202702

で、無理やり止めるにはどこからでも入ることができるダッシュボード上でライブ配信しているインスタンスを完全に削除するしかないようだ。

汎用的(?)なダッシュボードで完全に削除:
Photo_20201201180401

つまり、ライブ配信しているセッションは大切にとっておかないといけないのだ。

« 2020年11月 | トップページ | 2021年1月 »