Raspberry CamからH.26​​4をストリーミングする最新の方法

Pi B +とPiカメラを入手し、H.264でエンコードされたビデオをカメラからホームサーバーにストリーミングするための最も効率的な（低CPU）低レイテンシ構成を見つけようとしています。

私は次を読んだ：

1. http://pi.gbaman.info/?p=150

2. http://blog.tkjelectronics.dk/2013/06/how-to-stream-video-and-audio-from-a-raspberry-pi-with-no-latency/comment-page-1/#comments

3. http://www.raspberrypi.org/forums/viewtopic.php?p=464522

（すべてのリンクはからgstreamer-1.0を使用しdeb http://vontaene.de/raspbian-updates/ . mainます。）

過去数年間、この点に関して多くのことが行われてきました。

もともと、出力をにパイプする必要がありraspividましたgst-launch-1.0（リンク1を参照）。

次に（リンク2）公式V4L2ドライバーが作成されました。これは現在標準であり、gstreamerのみを使用してパイプなしで直接データを取得できます（特にtowolfの投稿を参照してください»Sat Dec 07、2013 3:34 pm link 2）：

送信者（Pi）： gst-launch-1.0 -e v4l2src do-timestamp=true ! video/x-h264,width=640,height=480,framerate=30/1 ! h264parse ! rtph264pay config-interval=1 ! gdppay ! udpsink host=192.168.178.20 port=5000

レシーバー： gst-launch-1.0 -v udpsrc port=5000 ! gdpdepay ! rtph264depay ! avdec_h264 ! fpsdisplaysink sync=false text-overlay=false

正しく理解すれば、どちらの方法でもGPUを使用してH264デコードを実行できますが、プロセス間のパイプがないため、カーネルをもう一度通過する必要がないため、後者は少し効率的です。

今、これについていくつか質問があります。

1. 後者は、カメラからH264を効率的に取得するための最新の方法ですか？について読んだことgst-omxがあります... video/x-raw ! omxh264enc ! ...。これは単にを使用するのとvideo/x-h264は違うことをしますか、それとももっと効率的でしょうか？違いは何ですか？

2. video/x-h264 ...パイプラインを使用するときに、実際に使用されているgstreamerエンコーディングプラグインを確認するにはどうすればよいですか？これは、（コード）コンポーネント（h264parseまたはなどfpsdisplaysink）を明示的に指定する他のパイプラインパーツと比較して、必要な形式を指定しているだけのようです。

3. では、リンク1に、この返信ミカエルLepistöは言及し「私が側をストリーミングから1つの不要なフィルタパスを削除し、」彼が切り出されていることを意味し、gdppayそしてgdpdepay。それらは何をしますか？なぜ必要なのですか？それらを本当に取り除くことができますか？

4. また、受信側でcaps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96"パラメータを指定するudpsrcことで、ストリームの途中でストリーミングを開始/再開できることにも言及しています。これらの上限は何を達成しますか、なぜこれらの特定の選択、それらについての詳細はどこで読むことができますか？

5. 質問3および4で提案されていること（caps、ドロップgdppay、およびを追加gdpdepay）を行うと、ビデオの待機時間がさらに悪化します（蓄積しているように見え、時間がたつにつれて待機時間が長くなり、数分後にビデオが停止します）！なぜそうなるのでしょうか？元のコマンドで取得したレイテンシを取得したいのですが、いつでもストリームに参加できる機能もあります。

6. RTSP + RTPは通常、TCPとUDPの組み合わせを使用することを読みました。制御メッセージやその他の紛失してはならないものにはTCP、実際のビデオデータ伝送にはUDPを使用します。上記の設定では、実際にそれを使用していますか、それともUDPのみを使用していますか？gstreamerがこれを処理するかどうかは、私には少し不透明です。

これらの質問のうちの1つでも答えをいただければ幸いです。

オプション：

1. raspivid -t 0 -o - | nc -k -l 1234

2. raspivid -t 0 -o - | cvlc stream:///dev/stdin --sout "#rtp{sdp=rtsp://:1234/}" :demux=h264

3. cvlc v4l2:///dev/video0 --v4l2-chroma h264 --sout '#rtp{sdp=rtsp://:8554/}'

4. raspivid -t 0 -o - | gst-launch-1.0 fdsrc ! h264parse ! rtph264pay config-interval=1 pt=96 ! gdppay ! tcpserversink host=SERVER_IP port=1234

5. gst-launch-1.0 -e v4l2src do-timestamp=true ! video/x-h264,width=640,height=480,framerate=30/1 ! h264parse ! rtph264pay config-interval=1 ! gdppay ! udpsink host=SERVER_IP port=1234

6. uv4l --driver raspicam

7. picam --alsadev hw:1,0

考慮事項

• レイテンシ[ms]（クライアントにサーバーよりも多くのfpsを要求する場合と要求しない場合）
• CPUアイドル[％]（で測定top -d 10）
• CPU 1クライアント[％]
• RAM [MB]（RES）
• 同じエンコード設定
• 同じ機能
  • オーディオ
  • 再接続
  • OSに依存しないクライアント（vlc、webrtcなど）

比較：

            1    2    3    4    5    6    7
latency     2000 5000 ?    ?    ?    ?    1300
CPU         ?    1.4  ?    ?    ?    ?    ?
CPU 1       ?    1.8  ?    ?    ?    ?    ?
RAM         ?    14   ?    ?    ?    ?    ?
encoding    ?    ?    ?    ?    ?    ?    ?
audio       n    ?    ?    ?    ?    y    ?
reconnect   y    y    ?    ?    ?    y    ?
any OS      n    y    ?    ?    ?    y    ?
latency fps ?    ?    ?    ?    ?    ?    ?

唯一のブラウザにH264をストリーミングする近代的な方法はであるUV4L：待ち時間なし、オプションのオーディオとの設定なし、オプションの双方向のオーディオ/ビデオ。魔法のGStreamerソースはありませんが、その使用法を拡張することは可能です。

1.）ネットワークを介したh264esストリーミング（サンプルのみ）

サーバー上：

raspivid -v -a 524 -a 4 -a "rpi-0 %Y-%m-%d %X" -fps 15 -n -md 2 -ih -t 0 -l -o tcp://0.0.0.0:5001

クライアント上：

mplayer -nostop-xscreensaver -nolirc -fps 15 -vo xv -vf rotate=2,screenshot -xy 1200 -demuxer h264es ffmpeg://tcp://<rpi-ip-address>:5001

2.）ネットワークを介したmjpegストリーミング（サンプルのみ）

サーバー上：

/usr/local/bin/mjpg_streamer -o output_http.so -w ./www -i input_raspicam.so -x 1920 -y 1440 -fps 3

クライアント上：

mplayer -nostop-xscreensaver -nolirc -fps 15 -vo xv -vf rotate=2,screenshot -xy 1200 -demuxer lavf http://<rpi-ip-address>:8080/?action=stream

これはすべて、RPi Zero W（サーバーとして構成）でも機能します。