RTSP(H264/H265) to MP4の超低遅延ブラウザ再生(配信)

はてブ数 2021/02/22プログラム::TCP/IP

カメラ等で使われるRTSPストリームはブラウザとすこぶる相性が悪く、以前はFlashを使って親戚のRTMPが再生されたりしていましたが、もはや過去のお話。

最近は、分割した MPEG4 ファイルを連続再生する HLS や MPEG-DASH が主流です。しかし、すべてを数秒に分割する仕組みのため通信効率が悪くなってしまいますし、どうやっても遅延の問題が避けられません。

かと言って WebRTC はP2P用に設計されていて、ブラウザ間ビデオチャットには向いていますが、配信等の目的に使うことは難しく、そもそもUDPが使えない環境では動作もしません。

そこで超低遅延(1秒未満)のストリーミング再生(配信)システムを構築しました。

更新履歴

  • 2022/09/05 WebCodecs正式版に対応。
  • 2021/04/29 H.265/HEVCに対応。
  • 2021/04/21 エラー内容をHTML上で表示するよう変更。
  • 2021/02/22 初版。

デモ

デモを設置しています

rtsp:// で始まるURLを入力すると、RTSPをリアルタイムで変換を確認できます。残念ながら適当なフリーのRTSPソースがないため、各自ご用意ください(192.168.x.xxのアドレスで試す人が多いようですが、当然接続できません。グローバルIPを持ったRTSPサーバを指定してお試しください)。

  • Chrome および Firefox が推奨です。
  • 対応しているのは「H.264/avc1」か「H.265/hvc1(HEVC)」ストリームのみです。
  • デモはセキュリティのため以下の制限を加えています。
    • RTSPパスワード認証は使用不可に設定しています。
    • RTSP接続ポートは 554 のみに制限されています。
    • 再生時間は60秒に制限されています。
  • 「WebSocket Server Down」と言われた場合は、変換サーバの起動忘れなので、コメント or ご連絡ください。
  • デモですので、常識の範囲内でご利用ください*1

*1 : 外部から利用する等はやめてください。ログは取っていますので発見次第対処します。

仕組み

rtsp_to_mp4.png

RTSPサーバに接続して、リアルタイムでmp4に変換しています。コンテナ(フォーマット)を変換していますが再圧縮しているわけではないので高速に動作します。ffmpegを使っても同様のことが可能ですが、ffmpegでは変換過程で数秒程度の遅延が発生します。

ffmpeg -rtsp_transport tcp -i rtsp://<ip_address>/path -c:v copy -an -movflags empty_moov+omit_tfhd_offset+frag_keyframe+default_base_moof -f mp4 pipe:1

mp4に変換されたデータを WebSocket 経由でブラウザに送信し、受け取ったデータを JavaScript で MediaSource に入力し、VIDEOタグで表示しています。

let sourceBuffer;
const ms  = new MediaSource();
ms.addEventListener('sourceopen', function(evt){
	sourceBuffer= ms.addSourceBuffer('video/mp4; codecs=avc1.64001E');
});

const VIDEO = document.getElementById('video');
VIDEO.src   = window.URL.createObjectURL(ms);

const ws = new WebSocket('ws://example.com/');
ws.binaryType = "arraybuffer";

ws.onmessage = function(evt) {
	sourceBuffer.appendBuffer( evt.data );
}

実際はもう少し複雑ですが、フロントエンド(JavaScript)では難しいことはしていません。デモページ内のソースに、スクリプトが全部書かれていますので、興味のある方はご覧ください。

変換サーバは?

今のところ非公開です。興味のある方はメール等でご連絡ください。ライセンス等する予定です。

まとめ

  • 映像が目的だったため、今のところオーディオには非対応です。
  • H264の圧縮も伸張もしていないので、H264がらみの特許問題は起きないはずです。
  • Windows Media ServerやReal Serverがそうだったように、将来的にはRTSPが廃れるか、ブラウザがRTSPやRTSPライクな何かをサポートして状況は変化するように思います。

参考文献

  • html5_rtsp_player
    • WebSocket経由でRTSPサーバにアクセスし、JavaScript側でRTSP通信をしながらmp4を再構成しています。原理的には似ていますが、サーバ/クライアントでの処理分担が異なります。サーバはNode.jsで書かれていますが、30行程度のスクリプトでサーバを自作することも可能でした。
  • v4l2rtspserver
    • V4L2を使用した、RTSPサーバ。H264で出力をするためには、カメラがH264エンコーダーを内蔵しているか、V4L2対応のH264ハードウェアエンコーダーが必要。
  • fmp4streamer
    • V4L2(H264)なソースから、ブラウザで再生可能なH264ストリームを生成するソフト。やってることは一緒。ただ作り込みが甘いのか、試した限りだとリアルタイム性がいまいち。多少書き換えれば改善するかもしれもい。

メモ

Video4Linuxとffmpegを使用して、カメラからリアルタイムH265を吐き出す方法。

ffmpeg -f video4linux2 -i /dev/video0 -s 640x360 -c libx265 -pix_fmt yuv420p -fflags nobuffer -tune zerolatency -f rawvideo

これをそのままWebSocketで送信できれば、上記デモと全く同じ仕組みで、ブラウザ上にリアルタイムカメラ画像を取得可能。

2020/10/04(日)Huawei nova lite に Android 10(LineageOS 17.1)を入れる

前提条件

  • Oreo以降にアップデート済
  • ブートローダーアンロック済

カスタムカーネルを導入している場合は、作業前に必ずストックROMカーネルに戻しましょう。*1

*1 : いろんなROMを試しても起動せず、数時間ハマったらしい……

導入手順

概ねLineageOS 17.1の記事に書いてあるとおりです。

  1. OS本体とパッチをダウンロードします
  2. Honer P9 lite用のTWRPを焼く(相変わらずP8 Lite用はイマイチ
    fastboot flash recovery_ramdisk twrp-3.4.0-0-prague.img
    
  3. zipを解凍して出てくるOS本体を焼きます。
    fastboot flash system system.img
    
  4. リカバリを起動します。
  5. Wipe → Advance → System → Change File System → Resize File System
  6. cache等を wipe(消去)します(Wipeデフォルト)。
  7. 必要に応じてWipeから Format Data します。消去するとアプリ等の情報はすべて消えます。*2
  8. https://opengapps.org/ から ARM64 10.0 の nano か pico を落とし、TWRPからUSB(MTP)で接続するなどしてSD等に転送します。
  9. 転送した gapps を焼きます。
  10. los_patches_prague.zipを焼きます。
  11. 再起動します。

*2 : 消去したほうが確実ですが、しなくてもきちんと動作することもあります。

その他

関連記事

2020/10/01(木)Sambaでファイルコピーに失敗し 0x80070032 エラーになる

Windows10からファイルをコピーしていると「予期しないエラーのため、ファイルをコピーできません」「エラー 0x80070032: この要求はサポートされていません」と表示される問題。

エラーの状況

  • コピー元: Windows 10
  • コピー先
    • Samba Version 4.9.5 on Linux
    • Filesystem NILFS2

この状況で大量のファイルをコピーしていると、一部のファイルやフォルダでエラーが発生します。

samba_0x80070032.png

ログの調査

  • Windows 7では起きていなかった。
  • Samba側のファイルシステムがext4だと起きない。

「log level=10」に設定して、ログを確認しみました。

set_ea_dos_attribute: Cannot set attribute EA on file AU.txt: Error = サポートされていない操作です
open_file_ntcreate: FILE_OPEN requested for file AU.txt and file doesn't exist.

ファイルの作成に失敗しているような感じです。

原因

Sambaは「store dos attributes = yes」のときに、DOS attributeと呼ばれるファイル属性を維持したままファイルを保存しようとします。

DOS attributeとは、Windows登場前の大昔に存在したファイル属性で、古くは「R,S,H,A」の4種類がありました。Windows時代になって不要となったものだと思っていたのですが、知らない間に拡張され続けていたようです……。

Windows では attrib コマンドによってファイル属性(DOS attribute)を確認または変更できます。*1

samba_attrib.png

このうち、比較的最近拡張された「X, P, U」属性があると、NILFSはこれらの属性値に対応していないためコピーに失敗します。

*1 : エクスプローラーのファイルのプロパティからでも確認できますが、その場合、なぜかX属性は表示されません。

解決策

smb.confに以下を設定します。

	store dos attributes = no

この設定のデフォルトは元々 no だったのですが、Samba 4.9(2018年9月)以降で yes に変更されています。

ext4等のファイルシステムは対応済のようですが、NILFSのようなメジャーではないファイルシステムを使用しているとこの問題に当たるかと思いますので、記録として残しておきます。

雑感

SambaはNTFSのファイルアクセス権限(NT ACL)等、ファイル属性をなるべく維持するように作られていて、ファイルシステム側もそれに対応できるよう拡張されてきた歴史があります。user_xattrでググると色々出てきます。

Linuxのシステム構造の中に、NTのアクセス権限やDOSのファイル属性が残るというのも不思議な感じですが、それが災いしてしまった事件でした。

どれだけ検索しても(海外含め)同じ不具合踏んでる人がいないので苦労しました……。

2020/07/05(日)NILFS使用時にLinux Kernelエラーが起こる問題の解決策

最近の新しいLinux KernelでNILFS(NILFS2)を使用すると、最初の書き込み時に

BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8

となるエラーの解決方法(対処療法)。

NILFSとは

ログ構造化ファイルシステムと言われる、ファイルを変更するたびに常にスナップショットを自動的に保存できるLinux標準サポートのファイルシステムです。

/home 以下などをNILFSにしておくと、間違えてファイルを書き換えたときや、間違えてファイルを削除したときに、1時間前や1週間前の状態に遡ってファイルを復元することができます。

間違ってファイルを削除(上書き)してまうこと、ファイルを直接変更してしまってから元に戻したいことは誰しもあると思いますが、NILFSならいつでも元に戻せるため人為的にミスにとても強く重宝しています。

新しいカーネルで動作不安定に

このNILFSですが、最近の(ここ1年ぐらいの)カーネルで動作不安定になる不具合があります。Debian 10.4をインストールした際にこの問題に当たってしまいました……。

調べるとカーネルのファイルキャッシュに対するちょっとした変更(パッチ)が原因となっているようです。解決策はLinux系のMLにありました(そしておそらく投稿者の記事)。

要約すると「NILFSをマウントする前に、ダミー書き込みをすれば良い」とのことです。

簡単な解決策

/etc/fstab では自動マウントせずに(noautoオプションをつける)、rc.localでマウントするように変更します。

dd if=/dev/sda6 of=/dev/sda6 count=1
mount /home

/dev/sda6 やマウント場所は該当のパーティション等に合わせてください。ddコマンドで512バイトほどダミー書き込みをしてからマウントします。たったこれだけで問題は解決します。

やや複雑な解決策

rc.local でマウントする方法では、NILFSパティーション以下にDBデータ等サービスで使用するデータを置く場合や/varがNILFSパーティションだった場合に問題があります。rc.local のタイミングでマウントするのでは遅すぎるからです。

ですので、理想としてはfstabでマウントする直前にダミー書き込みを実行したいのです。

Debian系のsystemd環境では以下のような設定ファイルを置くことで、fstab実行直前にダミー書き込みを実現できます。

# /etc/systemd/system/nilfs2-dummy-write.service
[Unit]
Description=NILFS2 dummy write
DefaultDependencies=no
After=local-fs-pre.target
Before=local-fs.target

[Service]
ExecStart=/bin/dd if=/dev/sda6 of=/dev/sda6 count=1
Type=oneshot

[Install]
WantedBy=sysinit.target

ファイル作成後、サービスとして認識されたか確認します。

# systemctl list-unit-files --type=service | grep dummy
nilfs2-dummy-write.service             disabled

認識されているようなら、サービスを有効にします。

# systemctl enable nilfs2-dummy-write
# systemctl list-unit-files --type=service | grep dummy
nilfs2-dummy-write.service             enabled

参考文献

まとめ

  • NILFS/NILFS2はとても便利なのに利用者が少ない。
  • パッチが出てるので、近々修正されるとは思う。
  • systemdの勉強になった。