Jetson NanoからSkyWayで送信

Jetson NanoからSkyWay経由でカメラ画像を送信できたので、その方法を備忘録として残したいと思います。

2020/06/03 追記 : Jetson Xavier NXでも確認できました。

前提条件

  • Jetson Nano Developer Kit
  • JetPack SD Card Image r32.3.1がセットアップ済み
  • Raspberry Pi Camera Module V2

パッケージを更新

お約束として、パッケージを更新しておきます。

sudo apt update
sudo apt upgrade

curlをインストール

sudo apt install curl

最新のDockerをインストール

curl -sSL https://get.docker.com/ | sh

一応 docker-compose もインストールしておきます。

sudo apt install python3-pip libffi-dev libssl-dev
sudo pip3 docker-compose

SkyWayから提供されているSkyWay WebRTC Gatewayのバイナリがarm32用なので、qemuをインストールします。

sudo apt install binfmt-support qemu qemu-user-static

ユーザーをDOCKER GROUPに入れておきます。

sudo usermod -aG docker <ユーザー名>

Dockerfileの準備

こちらのDockerfileを元にJetson Nano用に以下のように修正しました。

FROM forumi0721alpinearmhf/alpine-armhf-glibc:latest

#default 8000
ENV PORT_NUM 8000
#error/warn/debug
ENV LOG_LEVEL "error"

# Set the working directory to /skyway
WORKDIR /skyway

RUN apk add --no-cache --virtual tmpPackages ca-certificates wget && \
    wget https://github.com/skyway/skyway-webrtc-gateway/releases/download/0.2.1/gateway_linux_arm && \
    chmod +x ./gateway_linux_arm && \
    apk add libgcc && \
    apk add libuuid && \
    apk add libpthread-stubs && \
    rm /root/.wget-hsts && \
    echo [general] > ./config.toml && \
    echo api_port=$PORT_NUM >> ./config.toml && \
    echo log_level=\"$LOG_LEVEL\" >> ./config.toml && \
    apk del tmpPackages

ENV LD_LIBRARY_PATH /lib:/lib/glibc:/usr/lib

# Run rest when the container launches
ENTRYPOINT /skyway/gateway_linux_arm

Dockerイメージのビルド&起動

docker build ./ -t <タグ名>
docker run -itd --name <コンテナ名> -p 8000:8000 -p 50000-50063:50000-50063/udp <タグ名>

タグ名・コンテナ名は適当な名前を入れてください。

udpポートはこちらのサポートコミュニティの議論を参考にとりあえず64個分とってみました。

docker-composeの場合は以下の設定でいけると思います。

version: "3"
services:
  skyway:
    container_name: <コンテナ名>
    build: ./
    ports:
      - "8000:8000"
      - "50000-50063:50000-50063/udp"

nodeJSの準備

アプリをJavascript(Typescript)で書いたので、nodeJSを準備します。

使い勝手を考えてnvm経由でインストールします。

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.35.2/install.sh | bash
nvm install v12.16.1

こちらがサンプルアプリになります。

PeerIDは SSG_{Jetson Nanoのシリアルナンバー}になるので、クライアントから指定して接続してください。

時間がありましたら、iOSのサンプルアプリも紹介できたらと思います。

DeepStream ContainerでH264ハードウエアエンコーダーを使う

nvidia DeepStream SDK 3.0 のDocker ContainerにGStreamer用のH264のハードウエアエンコーダーが入っていなかったので、自前でインストールする方法の備忘録です。

前提条件

Ubuntu 18.04 x86_64
nvidiaグラフィックカード(RTX2060)
nvidiaドライバ(Driver Version: 418.56, CUDA Version: 10.1)
docker-ce
nvidia-docker
※カッコ内は自分の環境です。

ソースコードの取得

まず、ホスト側にソースコードをダウンロードしておきます。

また、コンテナ内のGStreamerのバージョンが1.8.3なので、こちらも1.8.3をチェックアウトします。

git clone git://anongit.freedesktop.org/gstreamer/gst-plugins-bad
cd gst-plugins-bad/
git checkout -b 1.8.3 1.8.3

ヘッダファイルの取得

cuda.h

/usr/local/cuda/include/cuda.hgst-plugins-bad/sys/nvenc/にコピーします。

nvEncodeAPI.h

こちらからVideo Codec SDKをダウンロードして解凍します。

include/nvEncodeAPI.hgst-plugins-bad/sys/nvenc/にコピーします。

コンテナ起動

ダウンロードしたソースコードをマウントする設定を加えて、コンテナを起動します。

nvidia-docker run -it --rm -v /home/hogehoge/gst-plugins-bad:/root/gst-plugins-bad -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=$DISPLAY -w /root nvcr.io/nvidia/deepstream:3.0-18.11

事前準備&ビルド

以下、コンテナ内でのコマンドになります。

  • /etc/apt/sources.listでdeb-srcを有効化
  • ビルドに必要なライブラリとヘッダファイルをインストール
  • ビルドに必要なライブラリのsoファイルのシンボリックリンクを作成
  • config&make
sed -i -e 's/# deb-src/deb-src/g' /etc/apt/sources.list
apt updte
apt build-dep -y gstreamer1.0-plugins-bad
ln -s /usr/local/cuda/lib64/libcudart.so.10.0.130 /usr/local/cuda/lib64/libcudart.so
ln -s /usr/lib/x86_64-linux-gnu/libnvidia-encode.so.418.56 /usr/lib/x86_64-linux-gnu/libnvidia-encode.so
cd ~/gst-plugins-bad
NVENCODE_CFLAGS="-I/root/gst-plugins-bad/sys/nvenc" ./autogen.sh --with-cuda-prefix="/usr/local/cuda"
cd sys/nvenc
make

エラーが出ずにビルドが成功すると、gst-plugins-bad/sys/nvenc/.libslibgstnvenc.soができてるはずなので、こちらを/usr/lib/x86_64-linux-gnu/gstreamer-1.0/へコピーします。

gst-inspect-1.0 nvh264enc

を実行して、情報が表示されれば成功です。

次回起動以降はDockerfileを作って、libgstnvenc.so/usr/lib/x86_64-linux-gnu/gstreamer-1.0/ADDするのがよいと思います。

とりあえず、DeepStream 4.0ではサポートされるらしいのでそれまでのつなぎとして(^^)

参考

Memcached::get(): could not decompress value in 〜というエラー

久しぶりの記事になります。
Memcachedを使っていて直面した問題で、Google先生に聞いてもなかなか答えにたどり着けなかったので備忘録として残します。

環境としてはUbuntu 16.04でPython3のpython-memcachedとCakePHP3間の通信で起きました。
pythonから書き込んだjsonをCakePHPで読もうとするとタイトルのエラーが出て、まったく読み込めないというものです
ただし、telnetでlocalhostのポート11211につないで確認してみると、python側から書き込んだjsonデータは読めるのです。

ちゃんと書き込めているので、当然PHP側を疑って、CakePHPの設定からPHPのmemcahedエクステンション等までいろいろ見てみたのですが、解決はできませんでした。
そして、原因はPython側のpython-memcahedでした。

解決のきっかけはGithubのこちらのissueでした。
Change in FLAGS set by 1.59 breaks compatibility with earlier python-memcached clients
こちらに入っていたpython-memcachedのバージョンも1.59でした。

ピコーン!
そして早速python-memcachedのバージョンを1.58に落としたところ、見事読み込むことができました。

python-memcachedで書き込んだデータをPHP側で読めない場合がありましたら、python-memcachedのバージョンを調べてみて下さい。

新SkyWayのiOS SDKをSwiftで使う

SkyWayが正式サービスとなりiOS用のSDKも更新されました。
トライアル提供時のSDKをSwiftで使うやり方と少し変わったようなので、変更点を書いておこうと思います。
トライアル時サンプルのSwift化はこちらになります。
新しいSDKでの主な変更点として、Swiftから直接使えるようになった事が大きいかなと思います。
それに伴ってBridging-Headerが必要なくなったようです。
ポイントとしては、

  • 設定-General-Embedded BinariesにSkyWay.frameworkを追加する
  • 設定-Build Settings-Build Options-Enable BitcodeをNOにする
  • SkyWayを使用するSwiftファイルに”import SkyWay”を追加する
  • 新旧SDKの差異を吸収する(addSrc:track:/removeSrc:track:/SKWPeerError.error)

新SDKでのSwift化はこちらを参照して下さい。

phpMyAdminをAWS ELBのSSL環境で使う

Ubuntu 14.04 のphpMyAdmin(4.0.10deb1)をAWS ELBのSSL環境で使った時に
Login後のURLが
https://hoge:80/phpmyadmin/index.php?token=なんちゃら〜
となってしまってエラーになります。
ポート部分の”:80″を手動で取ってリロードすればつながるのですが、直す方法がわかったので備忘録として記事にします。
(※Nginx 1.10.3 での結果です)

参考URL
https://sourceforge.net/p/phpmyadmin/bugs/4621/

phpMyAdminのインストールフォルダ(/usr/share/phpmyadmin)のlibraries/Config.class.phpを以下のように編集します。
元ファイル1298行目〜

if (! empty($url['port'])
	&& (($url['scheme'] == 'http' && $url['port'] != 80)
	|| ($url['scheme'] == 'https' && $url['port'] != 443))
) {
	$pma_absolute_uri .= ':' . $url['port'];
}

編集後

if (!empty($url['port'])) {
	if (PMA_getenv('HTTP_X_FORWARDED_PROTO') && strtolower(PMA_getenv('HTTP_X_FORWARDED_PROTO')) == 'https') {
		$url['port'] = 443;
	}
	if (($url['scheme'] == 'http' && $url['port'] != 80) || ($url['scheme'] == 'https' && $url['port'] != 443)) {
		$pma_absolute_uri .= ':' . $url['port'];
	}
}

OSX(Yosemite)のアプリブラウズで隠しファイルを表示

すぐ忘れてしまうので備忘録として。
Finderで隠しファイル・フォルダを表示する場合はツールバーの移動でいけるんですが、
アプリケーションのファイルダイアログから隠しファイル・フォルダを選択する方法をすぐ忘れてしまします。
方法は簡単で、ダイアログが開いた状態で
Command+Shift+.
を同時に押すと表示させることができます。

GAEでWordPressを動かす

自分のGAE(Google App Engine)アカウントでPHPが使えるようになったので、Wordpressを動かしてみました。
このブログの書き始めがそもそも WordPress on GAE ってことでもありますし。
(ま、その時の内容はPythonで動くWordpressもどきのweb2pyのことだったんですが、、、)

この記事の前までの状態をGAEにインストールしてみました。
それがこちらになります。(2013/11/01追記:課金止めました)

基本的にはGoogleさんのチュートリアルどおりにすればいいと思うんですが、何点か自分がハマった点を書きたいと思います。
チュートリアルはこちら。
Running WordPress – Google App Engine — Google Developers

ハマった点

  • これはGAE全体に言えることですが、反映に時間がかかることがあるので(特に起動直後など)、自分があってると思って動かない場合は少しだけ待ってみる。
  • Cloud SQLはBillingをON(有料オプション有効)にしないとCloudコンソールのメニューに出てこない。
  • Cloud SQLの有料ONはCloudコンソール側にて行う。Google Cloud Console
  • CloudコンソールのCloud SQLのメニューからSQLをImportするにはCloud Storageを有料化しなければ使えない。(gs://ではじまるのはCloud Storageのことです)
  • で、SQLのインポートはこのgs://を使ったほうがやりやすいと思う。
  • Cloud SQLのコマンドラインツールgsutil等はGoogle Cloud SDKに含まれる。
  • コマンドラインツールはシェル版・Java版それぞれでOAuth認証する必要があり、それぞれ1つしか有効にならないので、切り替える時は”gauth –revoke”でそのたびにOAuth認証を無効にする必要がある。
  • 上記理由からSQuirreLSQLを使いたい場合は最初からJava版を使ったほうがよい。

これくらいでしょうか。

まだ使いやすいとはとても言えない状況なので、いるかどうかはわかりませんが、どうしてもGAEでWordpressが使いたい人が使うという感じですw
料金的にはまだ確定したことは言えないですが、GAE側は無料のままでも行けそうで、Cloud Storageは容量使わないのでほぼ無料と仮定すると、Cloud SQLがPackageモードで$0.36/日で約$11/月ってところでしょうか。

用途にもよるでしょうが、それだったら個人的にはさくらのVPS1Gの月約1000円の方がいい感じですかね。