WebRTCサーバー Janusを試してみる

ちょっとしたことで監視カメラを作りたくなったので、WebRTCサーバーのJanusを試してみることにしました。今の所録画は考えておらず、逆に必要な時だけ映像を受信できる形に持っていきたいのです。

 

本来映像のストリーミングは、RTMPなりをnginxとnginx-rtmp-moduleで受けてHLS配信するのがお手軽簡単かと思います。ただし、Webサーバーを自宅に配置するとポートを開ける必要がありますし、かといってクラウド上に置くとRTMPのデータを四六時中受ける必要があるためお金がかかるという理解です。

 

ここで映像をエンコードRTMPで配信する部分を必要に応じてオンオフできると節約になるんじゃないかと思いました。ついでに触ったことのないWebRTCに興味があったので試してみようと思い立ったわけです。聞いたところによるとラグも少ないみたいですし。

 

もしかしたらオンオフ制御はそのままでHLS配信になるかもしれませんが…。

 

WebRTCは下記の記事を参考にしました。

 

qiita.com

 

仕事で WebRTC · GitHub

 

 

Janusについて、試してみた手順はおおむねこちらの通りです。

 

www.mikan-tech.net

 

www.mikan-tech.net

 

これらの記事にもあるように。libniceやlibrtsp、libwebsocketsはaptでインストールできるものとは相性がよくありませんでした。

 

また最近?のブラウザはWebRTCを使うのにhttps接続が必須になるようです。記事中にもあるように自己署名証明書を用意して使うようにしました。

 

これでJanusのStreamサンプルが動作し、Raspberry Pi カメラモジュールの映像を受信することができています。次回から、WebSocketで配信(ffmpegかGstream)をオンオフできるようにしたいと思います。

調べ物のメモ (x86について)

x86なPCがどんな風に動いてきたのか、興味が湧いたので整理がてらメモを残すことにしました。

 

ja.wikipedia.org

 

ja.wikipedia.org

 

とりあえずは8080、8086からでしょうか。本来なら4004、4040からなんでしょうが、今の流れの根幹として8080ということで。x86アセンブラはこの辺のレベルで解説しているサイトが多いイメージ。

 

ja.wikipedia.org

 

ja.wikipedia.org

 

今現役のx86の根幹がこの辺り。リアルモードとプロテクトモードが実装されたのは80286。リアルモードは8086互換でアドレス幅は16bit。DOSとかがこのモードで動く。プロテクトモードが使われたのはWindows 3.0かららしい。

 

PCを触り始めた頃はMS-DOS 3.3系かWindows 3.1だったなぁ…。

 

x86のCPUはリアルモードで起動し、後にプロテクトモードに切り替える。

ELECOM NSR-MSシリーズのNASからデータをサルベージしてみた記録

すごく久しぶりにブログで記録を取りたいなと思ったネタが上がってきました。一言で申しますと、先人の知恵は素晴らしい!!

 

ネタとしては掲題の通り、ELECOM製のNASNSR-MSシリーズのHDDからデータサルベージを行いました。(下記リンクは製品の一例です)

 

www.elecom.co.jp

 

症状としては本体の基板が故障して起動しなくなってしまったようです。HDDからは異音はせずPCからデバイスとして認識したためハード的には無事と判断。そのためHDDからデータサルベージを試してみることにしました。ちなみにファームウェアにバグがあるのか設定が悪かったのかバックアップが正しく動作していなかったようで…。

 

先に試したのはRAID 1で構成していたHDDアレイのうち1台を単純にマウントしてみること。手持ちの古いUSB-SATA変換ケーブルを使ったところ、fdiskでパーティション情報が表示されませんでした。持ち込んできた方いわくそんなはずはないとのことで、裸族を使って確認したところいくつかのパーティションが見つかりました。一番大きいサイズのパーティションが実際にデータが格納されていることろのようです。

 

パーティションがわかればこっちのもの、と思ったものの、EXT4で認識されているにも関わらず"EXT4-fs :bad block size 65536"とエラーが表示されてマウント失敗。その他LVMやxfsを疑ったりググって出てきたツール類を試すもすべてダメ。

 

ここで自分の知っている範疇を超えてきたのでネット上でどなたか解決しているかを確認してみました。型番やメーカーではかからないのですが、先に確認したエラーメッセージで調べるとYahoo!知恵袋のある質問を見つけることができました。数日かかって解決されたようで24ぐらいまで伸びています。

 

detail.chiebukuro.yahoo.co.jp

 

最終的には23、24を見れば概ね解決方法が書いています。少し記事を追いにくいのと、別のNASやHDDが故障した場合に役に立ちそうなのでこちらで纏める事にしました。

 

手順としてはソフトウェアRAID機能の管理ツールmdadmを使ってミラーしているHDDを1台でマウントします。マウントするのはディスクそのものでもいいですが、アクセス中の故障が怖い場合はあらかじめddコマンドなどでイメージファイル化しておきましょう。ちなみにこのNAS。ディスクに書き込んでいるエンディアンx86なPCと違うのかなと思ってddコマンドで変換しながらイメージ化してもダメなようです。確か東芝のHDDレコーダーがこの方式を採用してましたね。

 

HDDを接続時に自動でディスクアレイを構成していることがあるので現在の状況を確認します。パーティションがsda2の場合でディスクアレイが構築されている場合は下記のような表示になります。

 

$ cat /proc/mdstat
(一部抜粋)
md125 : active (auto-read-only) raid1 sdb2[2] sda2[0] 953153536 blocks super 1.2 [2/2] [UU]

 

ディスクアレイの解除はすべての/dev/md?デバイスをStopする方法で対応しました。

 

# mdadm --stop /dev/md124
(/dev/md?があるだけ)

 

/dev/md0としてディスク1台だけでソフトウェアRAIDアレイを作成します。その後にfsckファイルシステムをチェック。

 

# mdadm --verbose --assemble /dev/md0 /dev/sda2 --force
# mdadm /dev/md0 --grow --raid-devices=1 --force
# fsck.ext4 -fy /dev/md0

 

あとはサルベージ先を用意します(サルベージ先デバイスは/dev/sdb1)。

 

# mkfs.ext4 /dev/sdb1
# mkdir /salvage
# mount -t ext4 /dev/sdb1 /salvage
# chmod 755 /salvage
# cd /salvage

 

ここでRAIDのディスク(/dev/md0)をext4でマウントしようとすると、最初に見たエラーが出るだけなので、debugfsなるツールを使用します。これでマウントせずにデバイスやディスクイメージからデータを吸い取れるようです。rdumpの引数で、/dev/md0のディレクトリdataの内容をサルベージ先ディスクのカレントディレクトリにコピーします。

 

# debugfs -R "rdump /data ." -c /dev/md0

 

サルベージが完了したらsshやsftpなどを使うなりでWindows機にコピーするか、Linuxから移行先のNASに接続してコピーしてやってください。これで作業は完了です。無事にデータをサルベージすることができました。

 

今回はこの知恵袋に大変助けられました。ext4に見えてるけどマウントできないってのはディスクのパーティション、フォーマット構成をちゃんと理解して解析すれば普通に対応できたのかもしれません。が、今回はdebugfsなるツールが大活躍でした。USB-SATA変換ケーブルも相性というか読める読めないが出てくるんですね…早めに買い換えないといけません。

LibreOffice SDKを触ってみる

あるソフトウェアでかき集めたデータを、ODS形式なりXlsx形式なりで出力したくなったのでLibreOffice SDKを触ってみることにしました。

 

今回はもとのソフトウェアが主にライブラリの都合でC#で実装しています。LibreOffice SDKJavaから扱うのが一番よさそうですが引き続きC#で実装することにしました。

 

コンポーネントコンテキスト、サービスマネージャ、コンポーネントローダの取得など具体的な事とはネットで探すと出てきます。一例がこちら。

 

nekochango5.hateblo.jp

 

ここではハマった事をメモしたいと思います。用語用法や理解の不足は本職でプログラム組んでいるわけではないのでご容赦ください。

 

SDKLibreOffice本体の場所を環境変数で設定する必要があります。SDKのリファレンスにもあるように環境変数などビルド環境を設定するBatファイルが用意されていますが、こちらはコマンドライン上でビルドする場合に使うようです。手動で設定する変数も記載されていますが、どうにもうまく動きません(ビルドは通るが実行すると例外が投げられる)。

色々調べてみた結果、コード中で環境変数を書き換える方法が見つかりました。下記を参考にしたところ動き出すようになっています。

 

stackoverflow.com

 

  • 新規作成する場合はloadComponentFromURLの引数に作成したいファイル名ではなく"private:factory/***"を指定する。(****はドキュメントタイプ)

OpenOffice側のWikiに載っている事ではあるんですが、しばらくハマってました。実行するとURLが無効と例外が投げられます。一覧はなぜかなでしこのサポートから見つけました…。

 

nadesi.com

 

  • 保存形式はPropertyValueでFilterNameとして指定する

ネットで見つけたサンプルコートが、すでにあるファイルを編集する物ばかりで、新規作成したデータを保存する方法がわからずハマっていました。普通に保存するとODS形式なんですね…当たり前ですが。PropertyValue.NameにFilterNameを、PropertyValue.Valueにはuno.Anyクラスのオブジェクトとして形式を指定します。

 

www.okapiproject.com

yorozuyanet.hatenablog.com

 

その他のフィルター名はLibreOfficeのフォーラムに添付されてたであろうファイルソースコートリポジトリからフィルター名を知ることができました。OpenOfficeWikiにも一覧がありましたが、こちらはLibreOfficeに比べて対応形式が少ないようです。

 

Bootstrapで立ち上げたLibreOfficeプロセスは本体のソフトウェアが終了しても残るようです。終了時にプロセスを探してKillが必要みたいです。プロセス名は"soffice.exe"と"soffice.bin"が居るようで、今の所binの方を指定しています…が、こちらはもう少し調べたほうがいいかもしれません。

 

hima365.cocolog-nifty.com

 

  • ファイルの保存はcom.sun.star.frame.XStorableインターフェースのstoreメソッドを使う

これもSDKのリファレンスやサンプルコードを見ると書いてあるんですが、コンポーネントローダをXComponentLoaderとしてインスタンス生成しているのでstore系メソッドがありません。XStorableインターフェースにキャスト(C#とかこの場合でもキャストって言うのだろうか…)してstore系メソッドを呼ぶようです。また、この状態ではファイルが開いたままのようで、閉じる場合はXCloseableインターフェイスにキャストしてcloseメソッドを呼ぶ必要があるようです。

新規作成したデータはURLに紐付いてないと保存できないので保存処理前にすでに紐付いているか、変更があるかなど確認が必要のようです。

 

nekochango5.hateblo.jp

 

ネット上のサンプルを上記に注意して変更を加え、ファイルの作成とExcelで開けることを確認しました。今後は具体的にデータ入力やテンプレートの使用、PDFへのエクスポートを試してみたいと思います。

 

次はこのあたりのサイトを参考にする予定。

 

calibreblo.blogspot.com

librebasic.momiji-mac.com

hermione.s41.xrea.com

hermione.s41.xrea.com

GSX-S125買いました

スズキの原付二種バイク、GSX-S125を迎え入れたお話です。

 

実は今年6月に自動車学校に入校しまして、小型限定ながらも自動二輪の免許を取得しておりました。小型限定の解除はまた追々…。

 

なぜ免許をとってバイクも買ったか。某3輪乗り車載主に影響されたとかのもあります。もともと学生時代に50cc乗りだったというのもあります。近所を移動するのに2輪だと楽そうだなと思ったのもあります。色々理由はありますが、面白そうだったからと言うのが一番ではないでしょうか(力説。楽しければいいんです。

 

50ccから125ccへの乗り換えで400ccを体験していない前提で一通り感じたことを少々。

 

低回転数でトルクが細いと言われがちらしいですが、個人的には気になりません。発進時のエンストも初回ぐらいですし、ちょっと急な坂道での発進も今の所大丈夫。

まだ300km程度の絶賛慣らし運転中ですが、6速ギアのおかげで5000rpm縛りでもさほど困りません。坂道では積極的にギアを落としましょう。たまに6,7000rpm以上回さなきゃいけない場面もありますが、これぐらいの時の音が好きです。

ヘッドライト、真正面はそれなりに明るく照らしてくれます。が、広がりは今ひとつ。カーブの先が見えづらいので、街頭のない夜間は極力速度を落としましょう。

 

総じて遊びから日常の足として活躍してくれそうな印象です。ノーマルの状態では積載ナニソレの状態なのでキャリアを追加しています。何をカスタムしたのかはまた次の機会で。

Raspberry PiにAlpine Linux入れてデスクトップ環境を構築した…い (3)

まさかの前回の続きです。続くとは思わなかった…。  

nitteru.hatenablog.com

色々と試行錯誤を重ねていたら、前回できなかった自動ログインができるようになりました。どうも設定が不足していたようで、lxdmのタイムアウトの設定を追加することで無事に自動ログインできるようになりました。タイムアウトは5秒以上が推奨されていたので下限値の5を設定しました。xfce4のせいかと思って一時OpenBoxを入れてみたんですが結果同じで、lxdmの設定で触れそうな所を、と探していた結果たどり着いた次第です。

timeout=5

/etc/lxdm/lxdm.conf

これでキオスク的な使い方もできそうですね。Raspberry Piの場合、GUIが不要な用途が多そうなのでGUI版の他にCUI版もSDカードの中身をまるごとバックアップして後々の環境構築が簡単になるようにしました。展開してコピーするだけは楽でいいですね。

ここでついでの確認事項としてRaspberry PiのGPIOやSPI、UARTの動作を確認してみました。確認には以前別のディストリ上で動かしていた自作のpythonスクリプトを動かしています。使用したライブラリはRPi.GPIOやpySerial、py-spidevなどです。これらモジュールのpipでのインストール時にいくつか開発環境が必要になります。メモが少しあやふやですが、確か下記3点ぐらいだったと思います。またarmv7版では問題なかったものの、aarch64版ではライブラリがうまく動きませんでした。むりに64bit OSでなくても大きく問題はないと思いますが、これからに期待ですかね。

# apk addlinux-headers alpine-sdk python3-dev

ここまできたら最後に残っているのが永続ストレージ (persistent storage)の扱い。

lbuはデフォルトで/etc直下の管理をしているらしいです(/homeも?)。ではなぜ/etcのみで永続化ができるかというと、詳しい仕様はぱっと見つけられませんでした。公式ドキュメントやソースコードを追ったりはまだできていませんが。とりあえず今できる範囲で調べてみた結果がこちら。

  • インストールしたパッケージは/dev/mmcblk0p1/cacheに保管されている(デフォルト設定時)
  • /etc/apk/worldにインストールしたパッケージ名が記録されている
  • /usrを永続化した後にapk add (パッケージ名)してlbu ci -dする前にリブートすると/usrには残っているが、/etc下の設定は無くなっている
    • /etc/apk/worldにも記録されていない
  • /usr下にインストールされたファイルを消してパッケージ名を/etc/apk/worldに追記し再起動するとインストールされている(キャッシュが残っている場合)

ということで、想像したブートプロセスのイメージがこんな感じ。順番の前後はかなりありそうですが。

  1. ブートローダカーネルの起動
  2. rootfsをtmpfs上に展開
  3. 基本のパッケージをインストール
  4. tar.gzにまとめてあったlbu (/etc)の変更分をオーバーレイで反映 (tmpfs)
  5. /etc/apk/worldにリスト化されているパッケージをインストール

下記サイトでもあるように、この辺りの動作はログに残っているそうです。というか確認を忘れました。後日覗いてい見ます。

unix.stackexchange.com

ここいらの想像が正しいとして、今までの設定だと/usrと/etc以外は永続化されないので例えば/var下にデータを保存するようなソフトは別途lbuの管理下に置く必要がありそうです。もしくは別にUSBメモリなどストレージをマウントしてそちらに逃がす手もありそうですね。

永続ストレージを作ったあとにlbu ci -dを実行しないように、というのも/etc/apk/worldに記録されてしまうとRAM上に展開されるからと考えられます。いや、そう書いてはあるんですが。逆に反映しないと/etc下のファイルがごっそり消えてしまう。lbuの管理対象設定いかんではその他のディレクトリに保存されているデータも永続化されないということで、パッケージのインストールには思ったより工夫が必要そうな感じです。

ある意味当たり前ですが、/etc/apk/worldにインストールされているという記録が残っている場合はapk delで永続ストレージにインストールしたパッケージも消すことができます。逆にlbu ci -dせずに/usrにだけ残っている場合は消すことができません(同パッケージを再度インストールし、すぐにアンインストールで消すことはできました)。

最後に気になるRAMの使用状況。freeコマンドで表示される-/+ buffers/cacheのFreeはCUI版で890MB、GUI版で730MBほどでした。他の情報はメモを消してしまったので機会があればまた今度。とりあえず思ったより使える印象です。

ここにきてようやく、Alpine Linuxの動きがなんとなく見えてきました。シャットダウン処理無しに電源を切られても壊れにくいという利点を生かして、diskless化していない環境で動かしていたものを移行してみたいと思います。

Raspberry PiにAlpine Linux入れてデスクトップ環境を構築した…い (2)

前回のつづきです。

前回はCUIでログインできるところまでできたので、この上にWindow環境を構築してみます。今回の参考文献はこちら。

wiki.alpinelinux.org

wiki.alpinelinux.org

とりあえず公式の手順に則り、まずはxorg用のパッケージをインストールし、その後必要なパッケージをインストールしていきます。dbus自動起動するように設定した後、xfce4をインストールしました。

# setup-xorg-base 
# ​apk add xf86-video-fbdev xf86-video-vesa xf86-input-mouse xf86-input-keyboard dbus ​set​xkbmap kbd  
# rc-update ​​add dbus
# apk add xfce4

ここでstartxを叩いてもいいらしいのですが、今回使用しているのがRaspberry Pi3のためOpenGL関係もインストールします。ビデオメモリの割当容量が設定できるので今回は32Mを割り振りました。

(/media/mmcblk0p1/config.txtに下記を追加)
dtoverlay=vc4-kms-v3d
gpu_mem=32

/media/mmcblk0p1/config.txt

該当ファイルがあるパーティションは永続ストレージを作る際に書き込みできるよう再マウントされているものとします。

# apk add mesa-dri-vc4

これで準備完了、としたいところですがこの手順ではウィンドウマネージャ (xfce4)はインストールされますがディスプレイマネージャ (今回はlxdm)がインストールされておらずデスクトップ環境には足りません。足りないものを追加でインストールしました。

# apk add lxdm faenza-icon-theme mesa-egl xf86-input-evdev libinput
# rc-update add lxdm

上記の例ではlxdm以外もインストールしています。アイコンパックはいいとして、mesa-egl以下3つはデスクトップ環境を立ち上げた際にXorg.0.logやlxdm.logに読み込みエラーとして記録されていたものです。

最後にもう2点、必要な設定を行います。この設定のまま再起動するとウィンドウマネージャが立ち上がった時点からXorg.0.logに下記メッセージが大量に出力されます。これを抑制するためにPageFlipモードをいうものを無効化する必要があるようです。このための設定が1点目です。

(EE) modeset(0): Failed to get GBM bo for flip to new front.
(EE) modeset(0): present flip failed

無効化の方法は下記設定内容を記述したファイルを作成します。

Section "Device"
  Identifier "DisplayLink"
  Driver "modesetting"
  Option "PageFlip" "false"
EndSection

/usr/share/X11/xorg.conf.d/20-displaylink.conf

2点目は、デフォルトセッションをxfce4に変更します。

(下記設定を追記)
session=/usr/bin/startxfce4

/usr/lxdm/lxdm.conf

ここでlbu ci -dで変更を反映し、再起動します。するとGUIのログイン画面が表示される、はず。動作はやはりというかもっさりな感じがしますし、メモリ使用量も500~600MB近くまで上がりました。

記事タイトルがデスクトップ環境を構築し「たい」にも関わらず、うまく構築できています。今回引っかかたのは実はここから。キオスク端末のごとく自動ログインさせたいという要件が残っていました。自動ログインの設定自体は簡単です。デフォルトセッションを設定したファイルに下記内容を追記して再起動するだけです(設定反映を忘れずに)。

(下記を追記)
autologin=root

/usr/lxdm/lxdm.conf

この設定を有効化したまま再起動すると…ログイン画面が表示されません。lxdm.logやXorg.0.logにもそれらしきエラー(EE)の記述もなし。不思議なことにCUIでログインしてstartxfce4もしくはrcコマンドを実行すると何事もなかったかのようにログインが完了した状態で起動します。大きく違うのはデスクトップ環境起動時にすでにユーザー(ここではroot)でログインしていたか否か、だと思います。となると認証関係でしょうか…。この一点のために行き詰まってしまいました。

このままこの問題を追うか、arch Linuxなど別の軽量Linuxに乗り換えるか。どうしたものかなぁと言うことでこれまでの作業内容をブログに残しました。