Miniszámítógépek, SBC-k

Hello, ha van valakinek otlete, hogy helyi (Raspberryn levo) video file-t hogyan lehet WebRTC streamnek kiadni (pl, Janus, stb.) , az jo lenne. Azaz a Raspi legyen a streamer szerver.

Itt nem a Raspi kamerajat akarom streamelni, amire rengeteg leiras van, hanem egy fullHD-s (vagy kisebb) mp4 file-t.

Ha van otlet, koszonettel veszem....konkret megoldas erdekel, nem teoriak.

(ha sima Ubuntu-s -azaz nem Raspis  leiras van, azt is koszonettel veszem...)

Érdekel mindenkinek az ezen irányú tapasztalata. Pl. 4 GB-os verzióval 3-4-5-8 VM-et tudtam, amik ezt-azt vagy amazt csináltak, és azt érzékeltem, hogy. Viszont a 8 GB-ossal ellenben, míg a 2 GB-ossal ezzel szemben.

A többi értelemszerűen offtopic. (ne Pi, hanem; ne VMware hanem; ne virtulizáció, hanem; ne SBC, hanem)

A miért-re a válasz egyértelmű: mert megtehetem.

Parancssoros z80 assembler cross-compiler-t keresek. Jó lenne valami high-assembler szintű de legalábbis jó makrókezeléssel, hibareportolással. Az pedig hab lenne a tortán, ha képes lenne több parancsot is értelmezni egy sorban.

Amiket eddig próbáltam:

z80asm: hibás kódot is lefordít hibaüzenet nélkül, makrókezelése kezdetleges, akár fordítási időbe is belefagy, ha nem tetszik neki. Hibákat néha arra a fájlra jelzi, amiben van, néha arra a fájlra, amelyik include-dal használja, emiatt elég nehézkes.

crasm: nem tud bináris include-ot (legalábbis én nem találtam)

pasmo: a konstan kifejezéskiértékelése nem tud zárójelezni (a z80asm ebben elég jó), a lokális címkéket csak blokkon belül képes értelmezni, fájlon belül nem. (Ráadásul nem a . karaktert kezeli lokálisnak, mint más fordítók.)

zasm: bináris inlcude-ot ebben sem találtam. A többi tulajdonságában emiatt még nem mélyedtem el.

Eddig a pasmo a leginkább használható, de a lokális címkézése nehézkes. A perl féle objektumkezelés fájl szintű lokális címkézéssel kényelmesebb lenne. A konstans kifejezések külön nevesítése is felesleges körökre kényszerít.

Ha van ötletek, tapasztalatotok, szívesen olvasnám.

Tud-e bárki valami hasonló toolt, mint

• radeontop - nyilván AMD GPU-kra
• intel-gpu-top - nyilván Intelre
• gpustat, nvtop, nvidia-smi - Nvidia cuccokra

de működik a Raspberry pi4-ben levő Videocore VI GPU-ra és meg tudja mondani, hogy mennyi a GPU kihasználtsága?

OS: Raspberry pi OS 64 bit, Debian bullseye release (gyakorlatilag a latest ami most elérhető)

Háttér: Chromium-ból kísérletezek youtube és hasonló video streamelő oldalakról lejátszani. h264ify extension fenn van, a debug nézet ellenőrizve, hogy a video codec tényleg h.264. Lejátszás közben a

vcgencmd measure_clock h264

mutatja az órajelet, leállított lejátszásnál 0-t mutat. Ez alapján szerintem eléggé jól bizonyított, hogy hardveres h.264 lejátszás működik. VLC-vel a letöltött video lejátszása teljesen folytonos teljes képernyőn 1080p 60fps-sel is. Böngészőből viszont használhatatlanul akad. Full screenben kicsit jobb a helyzet.

Azt vettem észre, hogy a lejátszás közben a CPU igazából nincs teljesen kihasználva, a 4 magból mindre jut terhelés, de egyik sincs kimaxolva. A CPU húzva van 2GHz-re, semmit nem segített rajta. A Pi egyébként egy Flirc házban lakik, ami teljes egészében hűtőborda, remekül teszi a dolgát, minden maxra terhelve se megy 61C fölé - vagyis nem throttling a probléma. 

Megpróbáltam még a böngészős "UFO" tesztoldalon video nélkül megnézni, hogy mégis milyen sebességgel tud képet frissíteni, ez a szövegscrollozós teszt tűnt a leghasznosabbnak: https://www.testufo.com/framerates-text
Az eredmény, hogy a böngésző maximize-olt ablakban nem képes még szöveget sem 60fps-sel újrarajzolni, kb fél képernyőre kell az ablakot összehúzni, hogy a 60fps stabilan menjen. A CPU eközben nincs kimaxolva.

Az utolsó kisérlet volt a GPU overclock-olása. És valóban, ettől határozottan javul a helyzet. A doksi szerint a default 500 MHz-ről egészen 750 MHz-ig mehet. Mint kiderült ez nem hard limit, nekem egészen 830 MHz-ig sikerült húznom, mielőtt instabillá vált volna. Ennyi kellett is, hogy a szöveges scrollozása akadásmentesen vigye a 60 fps-t. Alapértelmezetten a

gpu_freq=830

paraméter mindent is 830MHz-re húz, ami nem ARM mag. Mint kiderült a h.264 engine ezt nem bírja, a video helyett csak memóriaszemetet látni.

h264_freq=750

sor hozzáadásával ezt vissza lehet venni 750MHz-re, de igazából bőven maradhatna 500 MHz-en is.

A videolejátszás böngészőben most ott tart, hogy 720p60 fullscreenben már egész folyamatosan megy, 1080p30 is, de 1080p60 továbbra is túl sok neki. Szerintem eléggé igazolt, hogy itt csakis a GPU lehet szűk keresztmetszet, viszont érdekes lenne tudni, hogy mit csinál a Chromium és valójában mekkora terhelést produkál a GPU-n. 

Sziasztok!

Tud valaki ajanlani egy olyan kis mini PC-t amibe 2x 2.5" SATA (vagy opcionalisan 2x M.2 NVME) diszket bele tudnek tenni? Olyasmire gondolnek mint a D@ll OptiPlex 7070 Micro vagy HP ED 800 G1 USDT, de nem 1x NVME + 1x SATA hanem "2x valami" kombinacioban. Ezen felul meg nem baj ha van rajta gigabites ethernet, de az gondolom mar alap :) 

Koszi, A.

Van egy ZX Spectrum 48K számítógépem, amire a programokat nem magnóról, hanem laptopról tölteném be. A laptop teljes hangerőre van állítva, de így is 5 perc kell, mire a gép annyira bemelegszik, hogy sikerül betölteni a programokat.

Vagyis hidegen, bekapcsolás után a LOAD parancs nem tudja betölteni a programokat. A Spectrum a képernyő keretét villogtatja a talált bitek függvényében, így látszik is, hogy amíg be nem melegszik a gép, a keret nem csíkozódik. Aztán idővel egyre több csík jelenik meg, később már a program fejlécét is be tudja olvasni, de töltési hibával leáll. Kb. 5 perc elteltével pedig már stabilan be tudja tölteni a programokat.

A beszerezhető információk alapján ez egy issue 3-as gép, de az alaplap elrendezése mégis inkább az issue 2 elrendezésre hasonlít. A lényeg, hogy a 7805-ös hűtőbordája a gép hátuljánál halad végig, ahogy ez az issue 3 alaplap fotó mutatja.

A célom az lenne, hogy a normális működés megtartása mellett elérjem, hogy bekapcsoláskor is rögtön be tudjak tölteni a laptopról. Ehhez meg kellene találnom, hogy melyik alkatrész lehet az, aminek így változik az értéke, és azt egy másikra kicserélni.

A kapcsolási rajz alapján én a R36, R37 vagy D13-ra tippelnék. Ezek ott vannak az EAR csatlakozó és a hűtőborda végének a közelében. A hűtőbordához legközelebb a C28 kondenzátor van - ez az issue 3 elrendezésben nincs ott, de nálam ott van -, tehát ez érezheti meg legelőször a melegedést. De - az én elég hiányos ismereteim alapján - nem szólhat bele ennyire a betöltési szintbe.

Ha valakinek van kedve, és kicsit jobban ért hozzá, szívesen venném az ötleteket, hogy melyik alkatrész okozhatja ezt a jelenséget, miért, és milyenre lenne érdemes cserélni. (Remélem, hogy ez egy ellenállás lesz, aminek hőre csökken az értéke, így egy picit kisebbre cserélve hidegen is be tudna tölteni.)

Kedves mindenki...

Nem tudom, jo helyre irom-e, ESP projekt - elektronikai komponens, forraszta stb ugyeben keresnek segitseget.
 

Van nekem egy RESOL VBUS napkollektor kontrollerem, ami nagyon jol teszi a dolgat, melegiti puffer tartalyt, csak sajnos en nem tudom integralni a Home Assistant-ba. Ennek akadalya, hogy teljesen ketbalkezes vagyok elektronikai aramkorok eloallitasabn, remeg a kezem, nem tudok forrasztani - es bar egy DHT11 et, PIR-t meg csak-csak osszedrotozok egy ESP-vel, de az alabbi cimen nehany ellenallast, IC-t is be kellene epiteni az aramkorbe.

Az ESPHome tamogatja a RESOL VBus-t es igazabol en keresnek valakit aki tudna nekem segiteni megepiteni a cimen szereplo aramkort hogy hozza tudjam kotni vegre a RESOL VBus-t a futes vezerlo ESP-mhez.

https://esphome.io/components/vbus.html

Ha nem jo helyre irok - elore is elnezest kerek, es kerem tegyetek a megfelelo helyre...

Elore is koszonom

A NOOBS utód PINN is friss listát ajánl telepítésre a felkínált rendszerekből. Rasbian, azaz RaspberryOS-ből lehet választani előző kiadást, de LibreElecből nem. Ebből pedig mindenképp a korábbi KODI18-ra épülő kellene, mert az új LibreElecben hibás a hdmi-cec. Ez nyilvánvalóan nem a Kodi19 hibája, inkább az alatta levő Linux jeosban rontottak el valamit. Nem akarom megjavítani és bőven elég a KODI18, mert úgysem tudná kihasználni a Raspberry Pi a KODI19 újdonságait. 

Hogyan lehet korábbi LibreElec imaget letölteni PINN-hez? Illetve egy kisebb SD kártyán van egy korábbi LibreElec rendszerem. Az is megoldás ha ezt át lehet másolni az új nagyobb SD kártyára, csak nem árt ha be is bootolja a PINN. 

Van bármilyen előnye, más operációs rendszert választani Raspberry Pi-re általános célokra, mint Raspberry Pi OS, régi nevén Raspbian? 

Ubuntu, Manjaro, Apertis a választék Linuxokból, illetve RiscOS. Természetesen ennél szélesebb a kínálat, Raspberry Pi imager ezeket tudja automatikus letöltéssel, kényelmi okokból elég ez a választék. 

A kérdés inkább elektronikai/fizikai jellegű mint programozás.

Arduino nano-ból csinálok "okosotthon" vezérlést (egyelőre: világítás kapcsolás illetve hőmérséklet mérés a helyiségekbe, ami alapján kapcsolja majd a fűtés köröket egy másik arduino).

A probléma, hogy a digitális lábakból nincsen sok, és bizony van ahol pl. 8 kapcsoló van... Nem akarok 8 digitális lábat ellőni csak erre, hogy maradjon még jövőbeni fejleszéseknek. Itt van egy példa arra, hogy hogyan lehet 1 analóg lábra több gombot tenni:https://www.instructables.com/How-to-Multiple-Buttons-on-1-Analog-Pin-A…

Ez tök jó... Csak én azt találtam ki, hogy jó lenne, ha lennének kombók, azaz pl. más történik, ha 2 vagy 3 kapcsolót egyszerre nyomsz meg (Pl. két adott kapcsoló lenyomása egyszerre a helyiség összes világítását lekapcsolja. Vagy a főbejárat melletti kapcsolósornál 3 kapcsoló egyszerre lenyomása a ház összes felkapcsolva maradt villanyát lekapcsolja, és hasonlók). Szóval az ellenállások értékeit úgy kellene megválasztani (mondjuk menjünk el 8 db kapcsolóig, amiből egyszerre maximum tetszőleges 3-at le lehet nyomni), hogy egyértelműen meghatározható legyen, hogy melyik 1, 2 vagy 3 kapcsoló van lenyomva.