Otázka:
Jaké streamovací řešení pro Picam má nejmenší zpoždění?
Antonvh
2014-02-01 22:58:13 UTC
view on stackexchange narkive permalink

Tento příspěvek ukazuje, jak streamovat pomocí VLC. Funguje to pěkně a je to jednoduché, ale dává mi to asi druhé zpoždění. Tento příspěvek používá GStreamer a má 0,3sekundové zpoždění; Chtěl bych méně.

Je možné použít k urychlení kódování grafický čip Raspberry Pi?

To zatím není možné. Zpoždění 0,3 ms je velmi dobré a nebudete se zlepšovat (nyní), protože chybí V2L. [Možná to pomůže] (http://pkula.blogspot.co.uk/2013/06/live-video-stream-from-raspberry-pi.html)
@ppumkin Myslím, že OP řekl, že zpoždění bylo 0,3 sekundy, ne milisekundy. Myslíte také V4L?
Ano, 3ms jsem přemýšlel. Ovladač Video4Linux? Nebo se tomu říká něco jiného. Víš. Nativní řidič.
@ppumkin Ahh, pak by ses mýlil. [Ovladače V4L2 byly součástí NOOBS v1.3.3] (http://raspberrypi.stackexchange.com/a/9777/8631).
V takovém případě by tedy VLC mělo pouze streamovat pakety h264 tak, jak jsou (bez dalšího překódování - nastavit ovladač V4L2 na veškerou tvrdou práci) do cíle. 0,3 sekundy je mnohem lepší než předchozí 3sekundová řešení. Nejste si jisti, jak se dostanete rychleji než za 0,3 sekundy?
http://www.linux-projects.org/modules/sections/index.php?op=viewarticle&artid=16
Tx. Brzy tyto ovladače vyzkoušíme. Také jsem našel řešení pomocí netcat. Možná to pomůže.
Tři odpovědi:
antoine
2014-12-28 20:04:52 UTC
view on stackexchange narkive permalink

S Ubuntu 14.10 a Gstreamer dosahuji latence 100 až 116 ms s 1280 x 720 při 60 Hz.

Tanky na @Antonvh, který mě staví na správnou cestu. Zde reprodukuji řešení pro druhou referenci.

Chcete-li streamovat z Pi: 

  raspivid -t 0 -b 2000000 -fps 60 -w 1280 -h 720 -o - \ | gst-launch-1.0 -e -vvv fdsrc! h264parse! rtph264pay pt = 96 konfigurační interval = 5 \! udpsink host = 10.42.0.1 port = 5001

Chcete-li jej přijmout do počítače pomocí gst-0.10 a odeslat jej na virtuální zařízení v4l2 (opravdu potřebujete v4l2loopback ): 

  gst-launch -v udpsrc port = 5001! application / x-rtp, užitečné zatížení = 96! rtph264depay \! ffdec_h264! ffmpegcolorspace! v4l2sink device = / dev / video1

Potom můžete zařízení otevřít / dev / video1 v libovolném softwaru podporujícím snímání v4l2.

Pro řešení gst-1.0 (v4l2loopback nefunguje s gst-1.0), nechám vás zobrazit příspěvek blogu Antonvh.

Antonvh
2014-04-03 12:36:18 UTC
view on stackexchange narkive permalink

Dosáhl jsem zpoždění 200 ms! Trik: poslat z Pi méně snímků, než kolik čtete na vzdálené straně, tím se zajistí, že vyrovnávací paměť zůstane prázdná.

Zde je obrázek Pořídil jsem filmování stopky. Ukazuje časový rozdíl.

Toto je recept, který používám. Nejprve na notebooku (Mac) proveďte toto: 

  nc -l 5001 | mplayer -fps 24 -cache 1024 -

poté na RPI začněte streamovat: 

  raspivid -t 999999 -w 1280 -h 720 -fps 20 - o - | nc 192.168.178.22 5001

Nezapomeňte:

  • Nejprve nainstalujte mplayer. U mě fungovala pouze metoda Homebrew. Běžné stahování bylo přerušeno.
  • Změňte výše uvedené číslo IP na číslo vašeho notebooku.
To je chytrý trik! Zajímalo by mě, jestli to funguje i pro nový ovladač UV4L
Problém tohoto řešení spočívá v tom, že přináší spoustu koktání ze strany přehrávání. Zajímalo by mě, jestli jste našli řešení.
hendry
2014-03-04 16:12:22 UTC
view on stackexchange narkive permalink

Používám tento videorecept: http://archpi.dabase.com/#sending-and-receiving-pi-camera-video-over-the-network

Vyzkoušeli jste https://github.com/thaytan/gst-rpicamsrc? To by mělo být o něco efektivnější. Tbh, nedaří se mi to zkusit.

Zpoždění 0,3 s je docela dobré.

Díky za odkazy! Myslím, že nyní mám zpoždění méně než 0,3 s, stále musím zdokumentovat řešení a přesně jej změřit. Brzy zveřejníme. Pokud moje měření prokáží, že je více než 0,3, zkusím jiný recept.
@Antonvh Jak probíhá výzkum / měření? Přináší vám tato odpověď lepší výsledky?


ⓘ
Tyto otázky a odpovědi byly automaticky přeloženy z anglického jazyka.Původní obsah je k dispozici na webu stackexchange, za který děkujeme za licenci cc by-sa 3.0, pod kterou je distribuován.
Loading...