Video stream kockázva Debianon

Multimédia

Ez nem egy pörkölt recept, éppen vaskarikából szeretnék fát készíteni! Viccnek is rossz :(
Van egy pompás IP kamera a kezemben (1920x1080 30fps), viszont a streamhez RTP vagy RTCP formában lehet hozzáférni. Nekem van egy többé-kevésbé kész Linux alapú rendszerem ami nem IP kamerára lett felépítve, egy-egy kép feldobására.
A lényeg, hogy kell valami a Linux oldalon, ami a képes "levenni" a streamet és "kikockázni" azaz egy-egy képet lerakni belőle, valami emészthető formában (jpg, png).
Úgy látom, két eszköz jöhet szóba az mplayer vagy a vlc - X NINCS és nem is lehet, csak konzol. A vlc tűnik a legígéretesebbnek.
1. Kérdőjel, vajon a Squeeze -ben lévő vlc-nox képes arra hogy leszdjen egy rtp streamet? Ha nem, szabad-e próbálkozni a VLC forrásból fordításával - nem tűnik egy egyszerű kis programnak.
2. Azt értem, hogy a vlc képes rtp streamet leszedni vagy generálni, viszont tud-e kockára szeletelni?

  • 1866 megtekintés

( zitev v | 2011. 07. 01., p – 18:51 )

"Ha nem, szabad-e próbálkozni a VLC forrásból fordításával - nem tűnik egy egyszerű kis programnak."
- én anno forrásból tettem mindig a friss vlc-t a debian stabilra, nem volt gondom vele - ha a kérdés erre vonatkozott...

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ezt még sosem próbáltam.
man apt-get

build-dep

build-dep causes apt-get to install/remove packages in an attempt to satisfy the build dependencies for a source package.

Ez most mire is jó? A "source package" a Debian source package vagy bármilyen forrás csomag? Mennyiben különbözik ez a vlc-nox bináris csomag telepítésétől? Vagy mennyiben segít ez a szerzői stabil verzió forgatásában?

* Én egy indián vagyok. Minden indián hazudik.

De most ez ugye a Debian source packet -re vonatkozik? Egy akármilyen source csomagból, hogy szedné elő a függőségeket?
Akkor viszont mi értelme a fordításnak? Más opciók? De ha más opciók, akkor más függőségek ... Kis elefánt nem látom a hasznot :(

* Én egy indián vagyok. Minden indián hazudik.

( valacska | 2011. 07. 01., p – 22:03 )

openrtsp + ffmpeg
openrtsp egyszerűen fordítható

Addig rendben lenne, ha az openrtsp, csinál egy fájlt amit az ffmpeg olvas és kockákat csinál. Viszont itt folyamatosan dől a stream.
Tudok olyat mondani az openrtsp -nek mondani, hogy ennyit csináljon, állj, ffmpeg kockáz, openrtsp újraindul ... ? Mindezt 1-3 másodperces ciklusban?

* Én egy indián vagyok. Minden indián hazudik.

( fabian-bros | 2011. 07. 02., szo – 09:15 )

mplayer -nosound -vo png -frames 1 -ss <időköz>

nem teszteltem, de valami ilyen rémlik.

---------------------------------------------------------------------------------------
Unix is simple. It just takes a genius to understand its simplicity. — Dennis Ritchie

( tovis v | 2011. 07. 02., szo – 15:05 )

Na most van gáz! A windows vlc nem tudja megnyitni a beállított porton a streamet - miért, ki tudja.
A Debian vlc-nox -ba úgy tűnik nem fordították be az rtp-t :(
(még megnézem a Debian vlc X alól), aztán valami más kerülőt kell találnom :( De hogy miért nem megy az nagy kérdés!

* Én egy indián vagyok. Minden indián hazudik.

Az biztos segítene, de ...
A nmap ezekt a portokat látja nyitva: 


Starting Nmap 4.62 ( http://nmap.org ) at 2011-07-02 15:25 CEST
Interesting ports on 172.16.3.2:
Not shown: 1707 closed ports
PORT      STATE SERVICE
21/tcp    open  ftp
23/tcp    open  telnet
111/tcp   open  rpcbind
513/tcp   open  login
514/tcp   open  shell
554/tcp   open  rtsp
5000/tcp  open  upnp
10082/tcp open  amandaidx

Nmap done: 1 IP address (1 host up) scanned in 0.210 seconds 

és a tshark, nyugalmi állapotban ilyen csomagokat lát:
  0.000000   172.16.3.2 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1 
  0.100211   172.16.3.2 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1 
  0.200494   172.16.3.2 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1 
  0.301393   172.16.3.2 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1 
  0.402150   172.16.3.2 -> 239.255.255.250 SSDP NOTIFY * HTTP/1.1  
ami a címből ítélve multicast.

Ráadásul, a teszt környezetben egy második (a netről nézve) nat mögött csücsül - nehézkes.

szerk:
Egyébként, az ftp -vel "benéztem" a fájlrendszerébe, az egész látszik, még nem próbáltam "belefirkálni" - nem kizárt hogy lehet, hiszen "firmware" -t lehet frissíteni.

szerk:
Elvileg tud rtps/multicast lenni - ha bekapcsolom, akkor az ie felület nem tud csatlakozni ...

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2011. 07. 03., v – 13:18 )

Sikerült nagyot lépni előre :D
openRTSP - csont nélkül fordul a Debian Squeeze amd64 -en.
Sikerült kapcsolatot teremteni a kamerával, egyedül a pufferen kellett állítani - mjpeg miatt (a legnagyobb felbontásnál nem tudja a h.264 -et).
Miután itt sikerült "kitalálni" a stream url -t (a kézikönyvben csak a multicasthoz van leírva), a windows vlc -t is sikerült beindítanom.
Az openRTSP framenként is tud menteni ... csak azt nem tudom ez milyen formátum, és azzal mit tudok kezdeni?

szerk:
Jó :( A frame az a streamen belüli framekre vonatkozik, azaz ha több frame jön egy streamen belül?
Mindegy, a kockázáshoz megpróbálom ffmpeg -et.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2011. 07. 03., v – 14:55 )

megoldás 1. 


#!/bin/sh
#
SLICE1_FILE=slice1.mjpeg
SHOT1_FILE=shot1.jpg
LOG_FILE=grab-err.log
#
openRTSP -u tovis tovis -vm -b 1000000 rtsp://172.16.3.2/mjpeg >$SLICE1_FILE 2>$LOG_FILE &
SLICE1_PID=$!
sleep 1
kill -HUP $SLICE1_PID
#
ffmpeg -i $SLICE1_FILE -vframes 1 -an -s 1920x1080 $SHOT1_FILE >>$LOG_FILE 2>&1

Ami még piszkálja a csőrömet, hogy ha az output fájl mpeg (szerintem ez a helyes, ezt ismeri fel a windows is) akkor nem készül snapshot :( Hiába teszem be a -i $SLICE1_FILE -vcodec mjpeg opciót, hibásnak veszi a fájlt az ffmpeg?
Mindenesetre ha a kiterhjesztés mjpeg akkor zöld :D

* Én egy indián vagyok. Minden indián hazudik.

ffmpeg [input options] -i [input file] [output options] [output file]

Hová teszed be? A -i elé vagy mögé?

De ha jól emlékszem, akkor nincs is rá szükséged, hiszen az openrtsp kimenete mjpeg, amelyből vagy ffmpeg-gel vagy egy egyszerű saját progival kiemelsz egy jpg képet. Az mjpeg-be ha belekukkantasz látnod kell a mime típust, pl.: 'multipart/x-mixed-replace; boundary=[valami]', esetleg még egy 'size' sort is. A [valami] értéke kamera specifikus, általában a vonatkozó api-ban definiálják (pl. axis esetén a http api-ban). A 'size' küldése általában a kamera beállításától függ, ki- vagy bekapcsolható. A header után azonnal jön egy jpeg kép, majd újra a mime, majd kép, ...
Megoldás lehet még, hogy az openrtsp standard kimenetét küldöd az ffmpeg bemenetére és bitstream filterrel (-bsf) néha kiemelsz egy képet a folyamból. Darabolhatsz mime alapján vagy a jpeg SOI, EOI alapján.

Hát mögé (én is csodálkoztam, de mindenütt amit láttam példa az ilyen volt).
Egyenlőre ez a megoldás megteszi, majd inkább a streamet kell használni, itt és most szimplán csak van egy kupac kész dolog, és ahhoz kellet illesztenem ezt. Majd még jobban körüljárom.

* Én egy indián vagyok. Minden indián hazudik.