Ahududu Cam H.264 akışı için modern bir yol

Pi B + ve Pi kamera aldım ve şimdi kameradan ev sunucuma H.264 kodlu video akışı için en verimli (düşük CPU) ve en düşük gecikmeli yapılandırmayı bulmaya çalışıyorum.

Aşağıdakileri okudum:

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

(Tüm bağlantılarda gstreamer-1.0 kullanılır deb http://vontaene.de/raspbian-updates/ . main.)

Geçtiğimiz yıllarda bu konuda çok şey yapıldı.

Başlangıçta, biz borusuna çıktısını vardı raspividINTO gst-launch-1.0(linki 1'e bakınız).

Daha sonra (bağlantı 2) artık standart olan resmi V4L2 sürücüsü oluşturuldu ve sadece gstreamer kullanarak doğrudan bir boru olmadan veri elde etmeyi sağlar (özellikle towolf tarafından yazılan »Sat 07 Aralık 2013 15:34 bağlantıda 2):

Gönderen (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

Alıcı: gst-launch-1.0 -v udpsrc port=5000 ! gdpdepay ! rtph264depay ! avdec_h264 ! fpsdisplaysink sync=false text-overlay=false

Doğru anlarsam, her iki yol da H264 kod çözme işlemini yapmak için GPU'yu kullanır, ancak ikincisi biraz daha etkilidir çünkü ilgili işlemler arasında boru olmadığından çekirdeğe başka bir zaman geçmesi gerekmez.

Şimdi bununla ilgili bazı sorularım var.

1. İkincisi hala H264'ü kameradan verimli bir şekilde almanın en yeni yolu mu? gst-omxGstreamer boru hatlarına izin veren hakkında okudum ... video/x-raw ! omxh264enc ! .... Bu sadece kullanmaktan farklı bir şey yapıyor mu video/x-h264, yoksa daha verimli olabilir mi? Fark ne?

2. video/x-h264 ...Boru hattını kullandığımda gerçekte hangi gstreamer kodlama eklentisinin kullanıldığını nasıl öğrenebilirim ? Bu, açıkça (kod) bileşenini ( h264parseveya gibi) adlandırdığım diğer boru hattı parçalarına kıyasla, yalnızca istediğim formatı belirtiyor gibi görünüyor fpsdisplaysink.

3. Gelen linke 1'e bu cevapta Mikael Lepistö bahseder "Ben yan akış itibaren bir gereksiz filtre geçişi kaldırıldı" diye kesip yani gdppayve gdpdepay. Bunlar ne yapıyor? Neden ihtiyaç duyulur? Onları gerçekten çıkarabilir miyim?

4. Ayrıca alıcı taraf caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96"için parametreler belirterek udpsrcakışın ortasındaki akışı başlatabildiğini / devam ettirebildiğini belirtir. Bu sınırlar ne elde ediyor, neden bu özel seçimler, onlar hakkında daha fazla bilgiyi nereden okuyabilirim?

5. Soru 3 ve 4'te önerilenleri yaptığımda (ekleyerek caps, bırakarak gdppayve ekleyerek gdpdepay) video gecikmem çok daha kötü hale geliyor (ve birikiyor gibi görünüyor, gecikme zamanla artar ve birkaç dakika sonra video durur)! Neden olabilir? Orijinal komutla elde ettiğim gecikmeyi elde etmek istiyorum, ancak aynı zamanda akışa herhangi bir zamanda katılabilme özelliğine de sahibim.

6. RTSP + RTP'nin genellikle TCP ve UDP'nin bir kombinasyonunu kullandığını okudum: kontrol mesajları ve kaybolmaması gereken diğer şeyler için TCP ve gerçek video veri iletimi için UDP. Yukarıdaki kurulumlarda, bunu gerçekten mi kullanıyorum yoksa sadece UDP mi kullanıyorum? Gstreamer'ın bununla ilgilenip ilgilenmediği benim için biraz opak.

Bu sorulardan herhangi birine bile herhangi bir cevabı takdir ediyorum!

Seçenekler:

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

Düşünülmesi gereken şeyler

• gecikme [ms] (istemciden sunucudan daha fazla fps istemesini isteyip istemediğinizi)
• CPU boşta [%] (ile ölçülen top -d 10)
• CPU 1 istemcisi [%]
• RAM [MB] (RES)
• aynı kodlama ayarları
• aynı özellikler
  • ses
  • yeniden bağlanma
  • İşletim sisteminden bağımsız istemci (vlc, webrtc, vb.)

karşılaştırma:

            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 ?    ?    ?    ?    ?    ?    ?

Sadece bir tarayıcıya H264 akışı modern yolu ile UV4L : hayır gecikme, opsiyonel ses ile herhangi bir yapılandırma, isteğe bağlı çift yönlü ses / video. Sihirli GStreamer sosu yok, ancak kullanımını genişletmek mümkün.

1.) ağ üzerinden akış yapan h264es (yalnızca örnek)

sunucuda:

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

istemcide:

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

2.) ağ üzerinden mjpeg akışı (yalnızca örnek)

sunucuda:

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

istemcide:

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

tüm bunlar bir RPi Sıfır W (sunucu olarak yapılandırılmış) üzerinde bile çalışır

Bu iş parçacığı üzerinde daha fazla eylem olmadığına şaşırdım, aylardır bu sorunun cevabını takip ediyorum.

Pi Kameradan (CSI) bir Janus sunucusuna akış yaptım ve en iyi boru hattının

gst-launch-1.0 v4l2src ! video/x-h264, width=$width, height=$height, framerate=$framerate/1 ! h264parse ! rtph264pay config-interval=1 pt=96 ! udpsink sync=false host=$host port=$port

v4l2src bellek tasarruflu bmc2835-v4l2 modülünü kullanır ve donanım sıkıştırılmış h264 videoyu doğrudan çeker. Pi sıfırda, gst-lansmanı% 4 ve% 10 cpu tüketir ve 30 fps'de 1280x720 hızında yayın yapar. Ayrıca gdppay kullanmadan akışı istediğiniz zaman devam ettirebilirim. Mmal v4l2 sürücüsünü almak için rpi-update'i çalıştırdığınızdan emin olun. Pi'm de kararlılık için hız aşırttı ve aşırı voltajlı ve günlerce kesintisiz akışlar, buraya bakın

OP'nin sahip olduğu sorunların çoğunu tökezledim. En sinir bozucu sorun 5'di - gecikme zaman içinde birikiyordu ve sonunda pi'yi çökertiyordu. Çözüm sync=falseudpsink elemanıdır. Gstreamer belgelerinde eleman hakkında çok fazla bilgi yok, sadece saat senkronizasyonunu devre dışı bırakıyor, ancak çok fazla gözyaşı sonra, gecikme biriktirmeden saatlerce akış yapabileceğimi keşfettim.

Ayrıca 4. sorunla da savaştım, akış başladıktan sonra izlemeye başlayamadım veya izlemeye başlayamadım. Bunun çözümü config-intervalSPS ve PPS çerçevelerini yeniden yayınlar. config-interval=1Bunları her karede paketler kullanarak , sanırım, herhangi bir zamanda bir akış almamı sağlıyor.

Ben ffmpeg boru hattı kullanarak aynı akış oldukça yakın var:

ffmpeg -f h264 -framerate $framerate -i /dev/video0 -vcodec copy -g 60 -r $framerate -f rtp rtp://$hostname:$port

ancak akışı devam ettiremiyorum, akış sırasında bir sayfayı yeniliyorsam akış almıyorum. Bunun SPS ve PPS çerçevelerinden kaynaklandığını düşünüyorum. Eğer kimse onları ffmpeg ile nasıl paketleyeceğini bilirse, bilmek isterim.

btw Param ayarlamak için v4l2-ctl kullanıyorum, ffmpeg genişlik ve yükseklik gibi ayarları otomatik olarak tanıyor gibi görünüyor, ancak gstreamer için donanımın ürettikleriyle eşleşmesi gerekiyor

v4l2-ctl --set-fmt-video=width=$width,height=$height,pixelformat=4
v4l2-ctl --set-ctrl=rotate=$rotation
v4l2-ctl --overlay=1
v4l2-ctl -p $framerate
v4l2-ctl --set-ctrl=video_bitrate=4000000 //or whatever