Dotaz: Pokračování problémů s kamerkou (ALi Corp. M5602 Video Camera Controller)

[Milan Uhrák]

Tak nevím, zda dotaz patří sem nebo do hardware ... no

měl jsem radost, že se mi kamerku podařilo zprovoznit, nicméně v distribuci Octopi nefunguje ( chtěl jsem ji zapojit jako kukátko na tiskárnu ... )

Octopi používá jako zprostředkovatele videokamerky prográmek mjpg-streamer. Je to konzolovka, umí nějaké kouzla s obrazem a má docela podrobný výpis toho, co zrovna dělá.

Nasucho je dá vyzkoušet

mjpg_streamer -i "input_uvc.so -d /dev/video0" -o "output_http.so -w ./www"

( např. Tak to u mně i fungovalo).

Ovšem prográmek mi sdělil

i: Using V4L2 device.: /dev/video0
 i: Desired Resolution: 640 x 480
 i: Frames Per Second.: -1
 i: Format............: JPEG
 i: TV-Norm...........: DEFAULT
 i: Could not obtain the requested pixelformat: MJPEG , driver gave us: BA81
    ... will try to handle this by checking against supported formats. 
Init v4L2 failed !! exit fatal
 i: init_VideoIn failed

Hledal jsem co to může znamenat, a co by tak asi odstranilo problém, a našel jsem dotaz, podobný mé situaci.

avafinger radil něco změnit ve zdrojáku, a znovu přeložit, což jsem zkusil, ale prográmek sděloval to samé, co přetím ( jen MJPEG se změnilo na JPEG)

i: Could not obtain the requested pixelformat: JPEG , driver gave us: BA81

Dotaz na možnosti kamerky

v4l2-ctl --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

        [0]: 'BA81' (8-bit Bayer BGBG/GRGR)
                Size: Discrete 640x480

Jaký je váš názor, je ještě nějaká šance ? podle mně je ta kamerka levný Acerský šunt, a prostě asi nebude spolupracovat. Ve VLC i QT V4L Test Unity na tomto PC funguje, ale zdá se mi, že pro ten streamer (a tudíž octopi) je nepoužitelná ..

M.

Odpovědi

[X]

https://github.com/jacksonliam/mjpg-streamer/issues/389

Osobne bych zacal s ffmpeg ve smyslu:

ffmpeg -f rawvideo -i /dev/video0 test.mpeg

[Milan Uhrák]

Ta kamerka funguje, obraz video z ní jde, ale potřebuji ji zprovoznit s octopi, který používá mjpeg-streamer (asi napevno zadrátovaná závislost) jako zprostředkovatele mezi kamerkou a jeho (octopi) web-rozhraním.

Zdá se, že formát, který leze z kamerky, nesouhlasí s formátem, který je schopen streamer ... přijmout nebo zpracovat...

Tvé řešení mi nejpíš nic neřekne, viz můj dotaz. Jak zjistím, jestli kamerka umí MJPEG nebo JPEG ?

v4l2-ctl --list-formats

nic takového asi nenašel , nevím v tomhle nejsem lumen ... a odkazovaný dotaz je na githubu jsem zadával já. Zatím bez odpovědi, ani moc odpověď nečekám, stačí se podívat do historie issues ... mnoho dotazů, odpovídá jen na to, co se mu zrovna chce a naposledy před asi rokem .. Tak moc nečekám na reakci...

[BFU]

$ apt-file search v4l2-ctl

v4l-utils: /usr/bin/v4l2-ctl

Takze

$ apt install v4l-utils

Mimochodem:

$ v4l2-ctl --help-all | grep -B 4 VIDIOC_ENUM_FMT

...

--list-formats-ext

Takze:

$ v4l2-ctl -d /dev/video0 --list-formats-ext

A jeste -D a --all switche jsou k uzitku.

[Milan Uhrák]

díky za snahu, ten v4l2-ctl mám, výpis --list-formats-ext je ... no v dotazu předtím a na odkazovaném githubu v mém "anglicky" položeném dotazu ... už to řeším jinou kamerou, zítra budou 2 nepoužívané kusy, snad některý z nich umí jpeg nebo mjpeg. Pak se uvidí , jak to celé dopadlo ...

[BFU]

No tak pokud jde o to z te kamery jenom vystipat data a debayerovat je, tak gstreamer:

$ gst-launch-1.0 v4l2src device=/dev/video0 ! queue ! bayer2rgb ! videoconvert ! jpegenc ! multifilesink location=/tmp/test%d.jpg max-files=10

Tohle bude tahat ty bayerovske framy z /dev/video0 , softwarove je to prekonvertuje do RGB, pak z toho udela jpeg a zapise to, frame po framu , to /tmp/test*jpg . Staci to nechat chvili bezet a viz obsah /tmp .

To skoro vypada, ze to muze nahradit cely ten mjpg...stuff .

Pozor, softwareove debayerovani je pomale. Nektere embedded systemy na to maji dedikovany hardware.

[Peter Golis]

Ale on chce vzdialené kukátko na 3D tlačiareň, preto streamovanie.

Nie že by to nešlo cez automatický refresh stránky so statickým obrázkom, ale to by potrebovalo vyladiť kvôli periodickým zápisom (dať ten kus webiku na RAM disk nech opakované a časté zápisy nevyvŕtajú dieru do SD karty či kam).

[BFU]

Podle toho 'mjpg_streamer -i "input_uvc.so -d /dev/video0" -o "output_http.so -w ./www"' to vypada, ze ten puvodni nastroj zapisuje obrazky do ./www .

To ten multifilesink dela taky, staci to tam nasmerovat ( viz "$ gst-inspect-1.0 multifilesink" pro vsechny mozne opce ).

Ohledne zapisu, ta gstreamerova pipeline nemusi nutne streamovat porad. Nicmene, pokud ty framy neni treba archivovat, namountovat tmpfs nekam do ./www by nebylo od veci tak jako tak, s tim souhlasim.

Nakonec, gstreamer ma RTP payloader, takze pokud by bylo libo RTP .... server (embedded hw) " ! jpegenc ! rtpjpegpay ! udpsink host=192.168.1.300 port=5000 " a client (PC s IP 192.168.1.300):

$ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,encoding-name=JPEG,payload=26 ! rtpjpegdepay ! jpegdec ! autovideosink

Jeste lepsi by bylo RTSP, ale to jsem rozchodil zatim jenom s VLC serverem, detaily viz https://wiki.videolan.org/Documentation:Streaming_HowTo/Command_Line_Examples/#RTSP_live_streaming a https://wiki.videolan.org/Documentation:Streaming_HowTo/VLM/ . Command line tool k vlc je "cvlc" .

[dustin]

Parametr -w výstupního pluginu output_http.so určuje, z jakého adresáře má mjpg_streamer číst a odesílat soubory, pokud na ně přijde přes HTTP požadavek. Vlastní stream se tam neukládá - viz stream vs. file.

[BFU]

Pak je asi na miste dotaz, jestli je vubec potreba ten mjpeg tool, nebo by to stacilo ubalit rucne pomoci treba toho gstreameru . Co je vlastne cilem, jestli jenom streamovat (on demand) video po ethernetu, pak to tim gstreamerem jde.

[dustin]

Rozhodně potřeba není, jen by se to muselo do RPi obrazu přidat. Možností je celá řada, gstreamer, ffmpeg, možná i vlc.

Hackovat konverzi z defakto raw streamu hloupé kamery do jpegu kvůli streamování v prehistorickém mjpegu mi přijde zbytečné.

[BFU]

Zrovna ten gstreamer by tam uz byt mohl.

Ohledne toho "defakto raw streamu", bayer je prostorove enkodovany, takze je potreba to nejdrive debayerovat, coz je na pomalem hardware problem, pokud to nema nejaky blok co debayerovani umi ( podle https://github.com/rasmus25/debayer-rpi to RPi zrejme nema ).

To enkodovani je stejny problem, enkodovat do JPEGu je softwarove jeste relativne OK i na pomalem hardware, s libjpeg-turbo jde pouzit i ARM32 NEON coz pomaha. I x264 ma rucne ubalene ARM32 NEON optimalizace, ale i s tema je to oproti enkodovani do JPEGu (s NEON) o dost narocnejsi. Dekodovani to same.

Takze ten JPEG docela chapu, a snahu mit sensor co udela co nejvic (debayerovani na strane sensoru s nejakym vestavenym ISP v sensoru, jako ma treba OV5640 ; nebo rovnou sensor co generuje JPEG framy) taky chapu. Bez HW en/dekoderu chapu i tu potrebu pro jednoduche kodeky.

[Peter Golis]

Pokiaľ mjpg_streamer vyžaduje na vstupe multimediálny formát Motion JPEG, tak ho musí nejako dostať. Ak kamera nevie poskytnúť MJPEG, tak je treba predradiť vrstvu ktorá zoberie stream z kamery a prekonvertuje ho na MJPEG aby sa mjpg_streamer mal čoho chytiť.

Ale na začiatok by som skúsil či to ide cez ffmpeg.

V prvom tabe spustím streaming z kamery (bez konverzie ale v obálke MpegTS):

ffmpeg -f v4l2 -re -i /dev/video0 -f mpegts udp://127.0.0.1:12345

V druhom tabe spustím prehrávanie:

ffplay -f mpegts -probesize 32 udp://127.0.0.1:12345

Ak to pôjde, tak si doladím IP, výstupný formát (x264/h265) a FPS nech to mám aj po sieti. Ale to len tak hádam, neživím sa streamovaním z kabínok.

[Milan Uhrák]

hmm .. to je magie ... děkuji a zkusím to, pak dám vědět, jak jsem dopadl ..

[Milan Uhrák]

Ještě dotaz : to jako znamená obejít octopi (teda mjpeg-streamer) a hodit to na web přímo ? Jako je to schůdná cesta, proč ne ?

[Milan Uhrák]

hm .. zase problém ... octopi nemá gui, a ffplay tudíž háže segmentation ....

no ptám se, protože jste pěkně začal .. tak ten první příkaz něco cachuje, vypadá že funguje .. mám výstup přímo hodit na síť, aby to viděl firefox ? Jaký formát použít .. ? No já vím, kabinky taky nejsou moje obílbené místo , tak tápu ...

Děkuji za popostrčení.

M

[Peter Golis]

Segmentation fault je iný týp chyby ako Could not initialize videovýstup - No available video device. Toľko k tomu pokusu.

Keď chceš, tak si tam daj webový server ngnix ktorý priamo zavolá ffmpeg s potrebnými parametrami. Nie je to tak geekovské ako využiť kamerku čo poskytuje video formát ktorý je iný ako vyžaduje tebou preferovaný streamovací program (keďŽe to vyžaduje konverziu).

Alebo to vyrieš jednoduchšie. Vytiahni z krabice s hračkami nejakú USB kameru čo poskytuje MJPEG, a budeš mať vybavené aj bez kúpy RasPI CAM.

Ohľadne FF, neviem či má ešte stále plnú podporu MPEG-1 (MJPEG/MPEG-TS). Niekde na NAS mám staré nahrávky filmíkov zo starých fotoaparátov, ale NextCloud mi niečo z toho nevedel zastreamovať (už si nespomeniem čo, nepotreboval som to zisťovať v tých kvantách súkromných dát). Viac som po tom nepátral. Ten formát je na dnešnú dobu zastaralý.

[Milan Uhrák]

Děkuji za odpověď ... Asi bude rychlejší zkusit nějakou jinou kameru ... Tu "krabici s hračkami" ale nemám, jen pár nefunkčních notebooků, no kdyžtak se porozhlídnu kolem, nebo za pár korun něco koupím... M.

[dustin]

Co např. ffmpeg místo mjpg_streamer v octoprintu?

[Milan Uhrák]

to už jsem četl dříve, ale vyžaduje to ffstreamer, a ten jsem ani pomocí apt-file nenašel. Jen zmínku, že ffstreamer byl z distribucí odstraněn, ale je možné si celý ffmpeg přeložit kompilace na Pi asi 4 hodiny ... no na mně zbytečná masařina, to už radši najdu jinou kamerku, což se taky stalo.

Ale děkuji.

[Milan Uhrák]

Příloha:

• octoprint.png (454707 bytů)

Resumé :

Tak jsem vyměnil kamerku za starou Logitech c110. v4l2-ctl říkal, že umí i jpeg i mjpeg, zkusil jsem ji a .... nic. Ani nevím, co bylo špatně, protože jsem ji znova zkusil druhý den a ... kuk :)

Jinak moc děkuji všem za pomoc, problém je vyřešen.

Co se týče toho transkódování za letu ( když má kamerka jen jiný formát než mjpeg neb jpeg, ) tak před tím dost na diskuzích varují ( sám jsem teda neměl možnost to potvrdit ), prý to nebohému Pi dost saje výkon, A tisk nemusí být zrovna kvalitní... ale nevím

Jinak hezký víkend ...

M.