• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    FROORaspberry Pi - miniaturní počítač za 35$
    SPM
    SPM --- ---
    FATBOZZ: na tom mplayeru jsem si to hlídal, aby to běželo bez cache, takže spíš to posílala fakt tak blbě kamera :-/ onvif player vyzkouším, dík
    FATBOZZ
    FATBOZZ --- ---
    SPM: Zkus nejaky onvif player jestli to neni lepsi nez pres vlc, https://ubunlog.com/en/onvifviewer-cameras-network-onvif-protocol/
    A s tim zpozdenim ... koukni jestli si nekde nedela 10s buffer pak by to zpozdeni sedelo
    SPM
    SPM --- ---
    FATBOZZ: Má, jenže právě ten stream, co z toho přes RTSP dostanu, je +- 10 sekund zpožděnej... A asi je to fakt kamerou, protože ikdyž to otevřu ve VLC na ntb, tak to mám zpožděné úplně stejně. (Což relativně vadí, pač na to kouká ostraha a pak třeba prskají, že na ně troubí nebo zvoní auto u závory, které oni ještě nevidí). Jsou to jinak kamery od Mobotixu, různé druhy, namátkou jedna, na které jsem zkoušel i nějaké pokusy, je Mobotix M16.
    FATBOZZ
    FATBOZZ --- ---
    SPM: Nema ta kamera nejaky rtsp/ovif ? I nejaka stara axis srajda to uměla. Cinsky kamerky za 500 tim taky disponujou tak bych se divil ze nejaka svetoznama znacka tohle neumi.
    Posli typ, kouknem do datasheetu :D
    SPM
    SPM --- ---
    RAINBOF: Tohle vypadá asi v pohodě... Nebo takhle, evidentně na každý puštěný mplayer mi běží dva procesy. Z toho ten jeden běží pořád od zapnutí (a tam v /proc/.../fd vidím 7 odkazů a jsou pořád stejné). Druhý proces běží jenom chviličku a hned chcípne, počítám, že ten proces prostě stáhne obrázek, skončí a znova.

    Jinak swapiness je na standardních 60... což asi ideální není, na druhou stranu pořád to naběhně v OK stavu a vyžere to paměť až při hodinách běhu :-)

    Nic, jdu si vyrobit ten stream, to se mi líbí nejvíc už kvůli tomu, že pak na ty kamery půjde koukat i z jiných míst, aniž bych umlátil tu kameru (kupte si drahou kameru... a pak si to stejně zbastlete sami... :-) )
    RAINBOF
    RAINBOF --- ---
    SPM: me napadla jedna vec, mrkni do /proc/id procesu/fd zda se ti tam nezvetsuje pocet odkazu.
    SPM
    SPM --- ---
    SUK: To je zajímavej nápad. Vnuklo mi to jednu myšlenku. Jak jsem zkoušel, tak to přehrávání obrázků umí vyloadovat i ten můj notebook, když těch kamer otevřu X... Takže to schválně zkusím, protože tímhle bych si mohl to stahování obrázků vyrobit na nějakém lepším hardwaru, kde mám i slušný CPU a do maliny stahovat už jenom video stream, který bude akcelerovaný. (A alespoň uvidíme, jestli se mi ten memory leak objeví někde jinde :-D )
    SUK
    SUK --- ---
    SPM: co takhle mplayerem prehravat stream، ktery bude tvorit ffmpeg z tech stahovanych obrazku?
    SPM
    SPM --- ---
    Díky všem, jdu se tím postupně nějak prokousat, jestli se mi u něčeho z toho zadaří něco najít. Samotné googlení na mplayer nepřineslo nic zajímavého. (Zatím jsem jako quickfix přepsal ten script tak, že to pouští mplayer v cyklu a cron to jednou za hodinu killne... což je prasárna hrozná, ale přijde mi to v tuhle chvíli lepší, než aby ty lopaty z toho natvrdo tahaly napájecí kabel).
    RAINBOF
    RAINBOF --- ---
    Hele, mrkni na nastaveni swapu, swapiness hodnoty a oom_adj.
    Zrat by ti mohla grafika.
    DURDIN
    DURDIN --- ---
    SPM: napadá mě, že si to mplayer ukládá do nějaké cache, zkus se kouknout na nastavení (-cache/-cache-min). A ještě můžeš zkusit místo mplayeru mpv.
    RUSTU
    RUSTU --- ---
    SPM: Chytat takhle leaky v cizim softwaru a jeste na maline asi nebude snadny. Muzes zkusit testovaci run s valgrindem, jestli se ti ho podari na RPi rozbehat.
    MA747
    MA747 --- ---
    SPM: jen výstřel od boku: hledal bych okolo libjpeg
    SPM
    SPM --- ---
    SPM: jo, zapomněl jsem dodat, že když jsem s nima přehrával ten videostream, tak to tohle nedělalo. Běželo to klidně několik týdnů v kuse, bez problémů. Paměť to začalo žrát až při tom přehrávání jpg obrázku.
    SPM
    SPM --- ---
    Mám takový divoký problém... který asi ani není úplně do tohohle audítka, ale nevím kam s ním jinam :-) Mám na RPi4 postavený zobrazovač kamer. Tedy televize namontovaná někde u stropu, RPi na tom přehrává 9 kusů kamer, je to bezobslužné. Bohužel se ukazuje, že kamery jsou úplně dementní (jenom dopředu dodávám, že to není žádný čínský šmuk, ale je to prosím pěkně pekelně drahá značková kamera) a neumějí posílat žádný videostream. Teda umí, ale všechny videostreamy, co jsem zkoušel, mají asi tak 10 sekund zpoždění a obsluze se to úplně nelíbí (zpoždění na tom streamu mám, ikdyž to pustím z normálního železa). V rámci debuggingu, kdy se tam kolegové furt snaží prosadit nějaký windowsí sráč, protože s originálním klientem to funguje úplně bez problémů, jsem začal pátrat, jak funguje originální klient a/nebo webxicht té kamery, kde ten obraz se chová taky normálně. Mno, tak při otevření v chromu to přehrávání funguje tak, že chrome periodicky stahuje jpg obrázek s aktuálním pohledem a ten zobrazuje. Pokud je tam nastaveno 20fps, tak ho prostě stahuje 20x za sekundu... Ani se pak nedivím, že kameře už nezbývá výkon na to, aby posílala třeba video...

    No nic, rozhodl jsem se adaptovat na tohle debilní přehrávání a přesvědčovat mplayer, aby taky stahoval obrázky. Až jsem dospěl k tomuhle příkazu, který funguje docela hezky:

    player -msglevel all=-1 -loop 0 -fps 1 -idle -fixed-vo -mf type=jpg -x 640 -y 360 -zoom -geometry 0:0 http://ip_kamery/obrazek.jpg

    Problém je, že asi tak druhý den nějaká kamera "spadne"... Když se mi konečně povedlo jim zakázat to natvrdo restartovat, abych zjistil, co s tím je, tak spadnutí vypadá tak, že mplayer zabije OOM killer, protože na malině dojde paměť. A bohužel pohled do topu ukazuje, že za a) mplayery žerou hrozně CPU (ale nevím, možná je to normální, když takhle blbě stahuju obrázky na kalkulačce... to bych tomu prominul, stíhat to jinak stíhá), ale taky že za b) žerou fakt hodně paměti a časem boptnají... Takže ta 2GB verze je asi po 24 hodinách out of memory, u té 4GB se to tak rychle nestane, ale o pár dní později ji to dostihne také.

    No a teď ještě ta divnější věc: pustil jsem si schválně jednu kameru na notebooku, stejně. A tam mi ten mplayer prostě neboptná, paměť nežere skoro žádnou. Schválne přikládám screeny z aktuální maliny (ráno rebootnuto, takže takhle to vypadá po ~ 8 hodinách běhu... před restartem byly už 2 mplayery zabité OOM killerem a paměť se "swapem" plná) a z notebooku, kde mi to běželo asi 3 hodiny. Abych nekecal, tak na notebooku jsem zapomněl ten parametr -msglevel all=-1 (bez něj se na RPi, jak je to puštěné z ~/.xsession, ten výpis mplayeru ukládal do syslogu a za chvíli tomu došlo místo na kartě); nicméně pustil jsem to teď chvíli z něj a prostě v topu to pořád bere +- stejně, nevypadá, že by to rostlo...

    Čímž mi nějak dochází nápady, proč mi to na RPi žere paměť a na normálnim PC ne... Někdo nějakej nápad? :-)

    TR1
    TR1 --- ---
    TR1
    TR1 --- ---
    NYRLEM:
    Ja mel to stesti, se ty UUgeary jsou skladem. Me spis slo o to, ze majitel firmy se fakt snazi a slogan "reklamace vyresime do tri pracovnich dnu" nejsou jenom prazdna slova, jak to mnohdy vidime jinde. Bohuzel spousta HW je nedostatkove zbozi a s tim asi majitel uz mnoc neudela.
    NYRLEM
    NYRLEM --- ---
    TR1: ja cekam na rpi400 co nebootuje z karty uz mesic..
    TR1
    TR1 --- ---
    Musim pochvalit rpishop.cz. Ve stredu zjisten vadny UUgear, elektronicky vyplnena reklamace a na ctvrtek objednan svoz. Dnes je utery a novy UUgerar prave pristal na stole. Kez by vetsina veci sla tak rychle a hladce.

    Jeste pridam tohle, pokud to nekoho minulo:
    Nadupaný malinový server. Malá deska obsahuje šest Raspberry Pi a pojme stejný počet SSD – Živě.cz
    https://www.zive.cz/clanky/nadupany-malinovy-server-mala-deska-obsahuje-sest-raspberry-pi-a-pojme-stejny-pocet-ssd/sc-3-a-218002/default.aspx
    RAINBOF
    RAINBOF --- ---
    TOOMIX: ted aby to bylo bezne dostupny a nemuselo se to obednavat pri mesicku z nejakeho special eshopu mimo EU
    Kliknutím sem můžete změnit nastavení reklam