RPI5

Debian GNU/Linux

RPI5, Raspberry Pi OS (64-bit) Release date: May 13th 2025 Debian version: 12 (bookworm)

1. A tápfeszültség kikapcsolása utáni bekapcsoláskor nincs hang. A jobb felső sarokban a hangerőszabályzó sem jelenik meg. Ha ezután a kezelői felületen vagy a rajta található nyomógombbal újraindítom, akkor megjön a hang.

2. A https://sign-el-soft.hu/tv.html oldalon található programmal használom. Ez az X11 könyvtárt használja. A rajzolási műveletek mint pl. az XDrawLine nagyon lassú (kb. százszor lassabb). Át kellett dolgozni azokat a részeit, ahol sok a rajzolás (pl. hang jelalak görbék). A wayland állítólag azért készült, hogy gyorsabb felületet biztosítson, akkor miért lett ennyivel lassabb?

  • 2629 megtekintés

( dlaszlo | 2025. 07. 11., p – 13:20 )

Szerkesztve: 2025. 07. 11., p – 13:22

A tápfeszültség kikapcsolása utáni bekapcsoláskor nincs hang. A jobb felső sarokban a hangerőszabályzó sem jelenik meg.

Ehhez így nehéz hozzászólni, de ilyenkor én mindig dmesg-gel és journalctl-lel nézem meg az üzeneteket, és lehet látni, ha valami nem tud elindulni, vagy leállni.

A journalctl-lel az a jó, hogy megmondhatod akár azt is, hogy melyik bootolásra vagy kiváncsi, ki lehet vele listázni, hogy mikből választhatsz, stb...

Nem érdemes csak a "hang"-ra szűrni pl (snd, vagy hasonló), hanem először lapozd át az összes üzenetet.

Szerintem lesz ott valami log üzenet, hibaüzenet, vagy bármi..

A hang probléma egy egyedi használat következménye:
Egy túlfesz védett hosszabbítóba van bedugva az asztali PC a monitor az RPI5 és mások. A PC és az RPI5 egy KVM switch-en keresztül osztozik a monitoron egéren és billentyűzeten. Csak akkor jelentkezik a probléma, ha a hosszabbító kapcsolóját kapcsolom ki, majd be. Ha az RPI5 közvetlenül csatlakozik a monitorra, akkor nincs semmi probléma.
Tud-e valaki olyan megoldást, ami a hang rendszert újra indítja anélkül, hogy az RPI5 reboot-olna?

Nagy Gábor   https://sign-el-soft.hu

"PC és az RPI5 egy KVM switch-en keresztül osztozik a monitoron egéren és billentyűzeten"

Nem lényegtelen szempont, amikor a hdmi hangról van szó. Lehet, hogy dvi módban jön fel valamiért a kvm switchen át a kimenet? 
A mostani rendszeren is van valami üzemód lekérő parancs, tool?

A régebbi rendszeren config fájlban simán meg lehetett adni kézzel, hogy milyen hdmi módban legyen és akár azt is, hogy mindig úgy viselkedjen, mintha rá lenne kapcsolódva a monitorra. A mostani rendszeren valsz bonyolultabb ez.

A hosszabbítónak lehet csak annyi a szerepe, hogy azt bekapcsolva más sorrendben élednek fel az eszközök, mint amikor egyenként kapcsold be őket. És lehet nem áll készen még valamelyik, amikor a pi nézi mi van a portjára kötve, ezért butább módot választ.

Ez valami hasonló, nem? https://forums.raspberrypi.com/viewtopic.php?t=363503

Meg itt lehet érdemes körbenézni: https://www.raspberrypi.com/documentation/computers/config_txt.html#vid…

+ itt legacy video options részt nézd meg még: https://www.raspberrypi.com/documentation/computers/legacy_config_txt.h…

A config.txt-ben lehet még megadni hdmi-vel kapcsolatos beállításokat, pl hdmi_force_hotplug, hdmi_group, hdmi_mode, hdmi_drive

 

Érdemes lehet megnézni őket, ahogy @azbest is írta. Én a yocto-val szívtam rengeteget a hdmi-vel RPI-n. Kiderült, hogy egy rossz kábel is okozta a furcsaságokat (ha minden kötél szakad, akkor érdemes erre is gondolni). :)

( Ritter | 2025. 07. 11., p – 16:11 )

A Raspberry Pi OS most már alapból Wayland-et használ, és X11 alkalmazásokat Xwayland kompatibilitási rétegen keresztül futtat.

Az XDrawLine és hasonlók software rendering-gel kerülhetnek megvalósításra, ha az OpenGL-ES/DRM backend nem támogatja őket vagy ha az Xwayland nem gyorsított.

Wayland nem támogatja közvetlen X11 hardware-gyorsítást, csak a "kompatibilitási Xwayland" rétegen keresztül, ami nagy mértékben szoftveres lehet a Raspberry Pi5-ön, ha a megfelelő driverek nincsenek betöltve.

lsmod | grep vc4
glxinfo | grep "OpenGL renderer"

Ha szoftveres renderelést "llvmpipe" látsz, az probléma. 

Szerintem próbálj visszatérni xorg-hoz. 

sudo raspi-config -> Advanced Options -> Wayland / X11 -> válaszd az X11-et.

Sajnos egyre több probléma van a RPi-vel. Nemcsak drága lett de problémás is. Még ma is a RPi3-at tartom az utolsó vállalható Raspberry-nek. 
 

Az rpi3 óta a teljesítmény a fogyasztással egyenes arányban nőt, szerintem sincs érdemi fejlődés. Egy ideje nem vagyok naprakész a témában.

Van már sata?
Még mindig választani kell, hogy x265 vagy x264 -et akarok gpu-ból dekódolni ?  

Nincs natív SATA. De USB 3.0 és PCIe 2.0 x1 van, így már használhatsz gyors SATA-t adapterrel. Mivel a RPi 5 egy darab PCIe 2.0 x1 FPC csatlakozón keresztül létezik, amihez lehet NVMe vagy SATA adaptert csatlakoztatni. 
PINEberry Pi HatDrive! vagy Geekworm X1001  Ezek SATA vagy NVMe M.2 SSD-t támogatnak.

Ami a sebességet illeti PCIe 2.0 x1 elméleti maximuma kb. 500 MB/s, gyakorlatban 300–400 MB/s.

B. megoldás, hogy USB 3.0 porton keresztül is csatlakoztatható SATA, de ott is csak USB-SATA bridge van, nem natív vezérlés.

 

Az RPi 5-ben a VideoCore VII GPU található, amely hardveresen támogatja a H.264 és H.265 (HEVC) dekódolást.

A hardveres dekódolás most már v4l2-m2m interfészen keresztül történik. Az ffmpeg és gstreamer támogatja. De GPU-korlát miatt nem tudsz egyszerre H.264 és H.265 streamet dekódolni hardveresen.
Konkrétan

Egyik ablakban H.264 megy GPU-val.

Másik ablakban H.265 már szoftveresen vagy az előző leállítása után megy GPU-val. 

És ezt úgy reklámozta a Raspberry, hogy már desktop használatra alkalmas a RPi 5. Hát nekem más fogalmaim vannak erről. 

A legtöbb médialejátszó (KODI, VLC, mplayer, ffmpeg) általában beállítható úgy, hogy preferálja a hardveres dekódolást, de formátumváltáskor fallback van szoftveresre, ami CPU-t zabál. Playlist lejátszásánál ez simán előfordulhat. 

A korretség kedvéért annyit meg kell jegyeznem, hogy a Pi5 CPU-ja (Cortex-A76, 4 mag) elég erős akár 1080p x265 szoftveres dekódolásra is, de 4K már necces.

A Pi5 pont h. nem tud már hardveres h264-t, szoftverből dekódol.

És eléggé megterheli, főleg egy h265-höz képest.

https://hup.hu/node/186361

 

Pi5: 4Kp60 HEVC hardware DEcode

Other CODECs run in software

H264 1080p24 DEcode ~10–20% of CPU

H264 1080p60 DEcode ~50–60% of CPU

H264 1080p30 ENcode (from ISP) ~30–40% CPU (ahol az ISP = Image Signal Processor)

Igazad van. A RPi4 volt ami hardveresen támogatta a h.264-et és h.265-öt is. 

Illetve nem múlt idő a RPi4, mert még ma is kapható. Ha a videolejátszás fontos az Orange vagy Banana Pi jobb választás. De a megemelkedett árak miatt szerintem videózásra is inkább Intel n100 jobb mindegyiknél. 

+1

En 2 eve vettem 3 x mini PC-t darabja £229 (azota van sokkal olcsobban is) memoriat es ssd-ket en raktam bele mert volt itthon boven. De a PI sem sokkal olcsobb mert a 16 gigas PI5 is  £114.90 es ez csak a board ehhez vegyel PSU, hutot, hazat,  sd kartya, micro hdmi kabel es arban mar kozel vagy a mini PC-hez nade a teljesitmeny eg es fold. Ja a mini PC darabja 20 wattot eszik atlagban.

Amugy ha mindenkepp SBC kell akkor a https://radxa.com/ meg viszonylag nagyobb gyartok kozul van

Intel N100, N150 procis vagy hasonló minipécé. 4 efficient core, 32GB ddr4 vagy ddr5-tel még több memória modullal is megy, bár intel hivatalosan 16GB támogatást mond, 1 slotban.

100-150 dolcsi közt kapni sokszor, sokféle változatban. Van olyan integrált, kompakt változat is, ami kb akkora mint egy raspberry pi. Csak persze ez házban van, tápegység jár hozzá. De van router változat  is, amikor 2.5G lanokat tesznek rá 2-6 db közt. Csak 9 pcie sávja van, így ha sok a slot / lan, akkor lehet 1-2 sávot kap csak egy nvme ssd slot.

200-300 dolcsi körültől meg már ryzen procisokból r5 5825U,  r5 6600H vagy akár r7 6850H procis is van.

Ha kellenek a csak RPi kompatibilis kiegészítők, mint HuskyLens vagy PiRotator vagy érzékelőkészletek meg a többi millió RPi GPIO-ra csatlakozó kiegészítők, akkor a PC nem lesz kompatibilis alternatíva. Banana Pi és Orange Pi alternatíva lehet, viszont kicsi közösség áll mögöttük, ezért ha elég a Raspberry Pi 3 akkor azt tartom még ma is a legjobb alternatívának. Nem kell aktív hűtés hozzá, az áramfelvétele is kisebb. Az volt az utolsó jól sikerült Raspberry. 
De egyébként a ha ilyen GPIO-ra csatlakozó kiegészítők kompatibilitása nem köti a kezed ma már Intel N100 jobb választás szerintem. Valamivel többet fogyaszt, de még elfogadható határon belül. Rengeteg OS között válogathatsz, hozza a PC kompatibilitás minden előnyét. 

A NYÁK-on van egy RP2040-es mikrovezérlő is, ugyanolyan, mint amit a Raspberry Pi Pico-ra is tettek. Ennek a mikrovezérlőnek a portlábai vannak kivezetve a GPIO tüskesorra. Az RP2040 USB-n vagy UART-on keresztül érhető el az Intel N'00-as CPU felől, vagyis teljesen máshogy tudod kezelni a GPIO lábait, mint egy Raspberry Pi esetében, így kompatibilitásról csak hardveres értelemben lehet beszélni, szoftveresen bele kell nyúlni a dolgokba rendesen.

https://docs.radxa.com/en/x/x4/software/c_sdk_examples?type=GPIO

Ahhoz, hogy használhasd az RP2040-et, előszö bele kell töltened egy firmware-t:

https://docs.radxa.com/en/x/x4/software/flash

Igen, ez még olcsóbb is, mint az RPi5, és teljesítményben oda-vissza veri (cache, CPU, GPU, memsávszél), ráadásul mivel x86-os platform, szabvány GPU driver, szabvány disztrók viszik, nem kell spécit tölteni mindenből, aki nagyon mazohista, még teljes értékű Windowst is tehet rá, akár 11-est is.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Köszönöm. Az X11-re át tudok váltani a raspi-config segítségével, de mivel a programot már korábban módosítottam, nem biztos, hogy azt fogom használni. Az X11-hez tartozó ablakkezelő ugyanis kevésbé szimpatikus.
Azzal, hogy egy egyenes rajzolásához hardver gyorsításra lenne szükség, vitatkoznék. Én úgy oldottam meg a wayland/x11lib problémát, hogy a program azon részeit, ahol sok egyenest rajzol átdolgoztam. (pl.: https://sign-el-soft.hu/reklam.html itt kb ötször annyi egyenest rajzol, mint ahány képpont széles az ablak) Mostantól C-ben írt programrész húzza az egyeneseket egy bitmapben, és azt utána egy lépésben átadja az X11-nek, ami továbbadja a wayland felé. Kb 100-szor gyorsabb mint az Xlib/XDrawline a wayland alatt!!! Az XDrawline a wayland nélkül persze mindig jól működött.

A https://hup.hu/comment/3203276 szálon hivatkozott link ezt írja:

"The only problem, the ONLY problem is the forced deprecation of X11 BEFORE Wayland is ready."

Nagy Gábor   https://sign-el-soft.hu

"Sajnos egyre több probléma van a RPi-vel. Nemcsak drága lett de problémás is. Még ma is a RPi3-at tartom az utolsó vállalható Raspberry-nek. "

Nem értem, hogy miért nem jó szerintetek az RPI5. Nekem ez az első RPI, de szerintem jó.

Mi nem vállalható belőle?

Azt írják, háromszor gyorsabb mint az elődje. A teljesítményére példa, hogy a DUNA HD-ről felvett videókból egyszerre ötöt is képes lejátszani öt külön ablakban akadás nélkül kb 90% terhelésen.

A fogyasztása DVB tunerrel együtt felvétel közben kevesebb mint 3W.

Az ára házzal táppal, hűtővel, SD kártyával, mikro HDMI kábellel, ... komplett csomag házhoz szállítva 40 eFt.

https://www.aliexpress.com/item/1005007895053258.html
https://www.aliexpress.com/item/1005008062096550.html

Nagy Gábor   https://sign-el-soft.hu

gondolom a duna hd itt a h265-ös mindigtv adás. H264 vagy vc9, av1 vagy más online elterjedt codec-cel valsz nem ilyen rózsás, mert idióta módon kihagyták a dekódoló modukt hozzájuk. 

Amúgy biztosan megvan az a cél feladat, amihez most is jó. Például lehet rögzítős settopbox-ot építeni. Meg legózni vele.

Inkább a relatív környezetben nézném a jóságát. Már desktopnak nyomja az alapítvány, miközben ahhoz nem nőtt annyit a teljesítménye, bár sokat javult. De közben az x86 vonalon rengeteg alternatíva jelent meg hasonló áron. És azokkal sok kompromisszum nincs meg, ami pivel az arm és video dekódolás kapcsán, buszok, portok kapcsán megvan. A fogyasztásban lehet picit vezet, de az is relatív, vissza lehet lassítani akár egy n100 családbéli minirendszert is úgy, hogy hasonló fogyasztása legyen pláne, hogy az hw gyorsítással tud dekódolni modern video codeceket és még transzkódolni is. És abból is van nagyon pici méretű.

A Duna HD h264, amit szoftveresen lejátszik akár ötöt egy időben. Ez a processzor képességét mutatja. (A h265-öt tudná hardveresen, de szerintem csak egyet.)

Ha lehet, mondj konkrét adatokat, hogy szerinted mit lehet venni, ami jobb és olcsóbb!

Nagy Gábor   https://sign-el-soft.hu

Korábban ezt írtad:

A teljesítményére példa, hogy a DUNA HD-ről felvett videókból egyszerre ötöt is képes lejátszani öt külön ablakban akadás nélkül kb 90% terhelésen.

Az DVB-T adásnak a kódolása H.264. Amikor ezt felveszed, a kódolás marad ugyanaz a felvett anyagban is?

Korábban már írtak pont itt jobb alternatívát

Bár csak kicsit olcsóbb, de olcsóbb és sokkal jobb, mint a Raspberry Pi5. 

Ha pedig IoT-hez kell mert Arduino nem elég a feladatra, akkor pedig Raspberry Pi3, amihez elég a passzív hűtő (szerintem egy aktív hűtést követelő eszköz szuboptimális IoT-ra).

A Raspberry Pi5 fogyasztása csak idle állapotban 3 Watt. Teljes terhelés alatt 12 Watt is lehet, egyébként átlagban 7 és 9 Watt közötti. DVB-T kártyával ha csak a TS-t kapszulázod valahova, az szinte idle. De ha valamit közepesen komolyabb feladatot végeztetnél vele máris megugrana 3 Watt-ról a fogyasztása. Egyébként pedig erre a feladatra is elég egy Raspberry Pi3 is. 

A 3B+ tényleg elég jó IoT központnak is, nálam is az van. Jófajta microSD kártya kell bele. Egyedül a memória aggaszt, ezért nézegetem a Pi4-eket is valami passzív bordaházzal. Nekem HA alatt elmegy most 700MByte, de ki tudja, később mennyi kell.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

A linkeden X4 4GB: HUF27,879.57 + Shipping: HUF5,538.19 ez több mint 33 eFT (csak a kártya).
RPI5 4GB csak a kártya 30 eFt-ért is található. (Free shipping)

Szintén a linkeden egy hozzászólás ezt írja:

"It's a good product. During boot-up, it consumes about 20w of power temporarily, and when idle, with windows installed, it seems to draw about 5-10w. If there are additional components, it would likely consume a bit more power. The seller advised connecting a power supply of 30w or more. I'm satisfied with it, except for the slightly high ssd temperature due to heatsink limitations when a poe hat is installed."

Nagy Gábor   https://sign-el-soft.hu

A Radxa hivatalos oldalán volt ez az Aliexpress eladó. Valószínűleg találnék free shippingeset is hasonló áron. 

Abban igazad van, hogy valamivel több az n100 fogyasztása mint a RPi5. De cserébe van hardveres (gpu) támogatás decode szinte minden érdemben használt video codechez. Ebbe a holnap standardjának tekinthető AV1 is beletartozik. Enkódolásnál pedig h.264, h.265 és vp9 mind gpu támogatott n100-on. 

Mivel x86, illetve amd64 arch lényegében minden linux disztibúció, windows, *bsd működik rajta. TrueNAS például nagyon jó lenne RPi-n, de arm-en nem érhető el. 

Kevés olyan feladatot tudok elképzelni amire RPi3 már kevés, és a RPi5 jobb választás lenne mint az intel n100 

N100, N95 N97, N150 proci változtos minipécékból rengetegféle van. 100-160 dolcsi közt is, attól függően milyen felszereltséggel. 

És ott az árban benne a ház, táp, van amelyiknél a ram és ssd is.

Firebat T8 plus, N100, forrasztott 16GB ddr5, 512GB m.2 sata ssd-vel én 140 dolcsiért vettem, de most is látni 160 - kuponért. Péládul https://www.aliexpress.com/item/1005008478736308.html
3 hdmi, 2 lan, 1 m.2 wifi slot kártyával és 1 m.2 2242 slot ssd-nek. Ennek az alaplapja területre kb a pi méretét foglalja. A raxda mivel pi-t utánoz nem ideális. Biosban állítható a fogyasztás.

Ha vannak mardék alkatrészek, akkor ddr4 és ddr5 sodimmes változatban is vannak mások, barbone. 
https://www.aliexpress.com/item/1005005776132222.html

8/256 egyszerűbb fajta, bővíthető 112 dolcsi minusz kupon, ha van https://www.aliexpress.com/item/1005008341711971.html

De van ami kifejezetten router jellegű, több, akár 4 db 2.5G lannal. Régebben 160 dolcsiért vettem olyan barbonet, aminek 1kg súlyú nagy bordás háza van, 4 db intel 226v lanja, egy ddr5 sodimm slotja, 1 m.2 wifi slotja, 1 2280 m.2 nvme slotja, 1 miniPcie slotja és egy sata portja is van. Valami gpio is van rajta, de nem mentem utána, hogy kideríthető-e hogyan kell programozni.

Tudsz forrást mutatni arra, hol mesélték az 5 HD h264 lejátszást? Csak kíváncsi vagyok, ha fórumos beszélgetés, akkor mikről volt még szó ott.

Mikor teszteltem úgy emlékszem a Pi4 röhögve dekódolta az av1-et is 1080p60-ban full szoftveresen dav1d-dal. Overclock nélkül.

A baj akkor van, amikor meg is akarod jeleníteni amit dekódolt :) Ablakban jó, ha 30fps-sel megy 1080p-ben. Illetve - ha a szart is kitaposom a videocore-ból, kb over_voltage=6, gpu_clock=850 - na akkor "majdnem" megvan a 60fps. Ebből a szempontból a h264 hardveres gyorsítása semmit nem segít, azzal is pont ugyanennyit tud. Egy fullscreen böngészőablakban fehér alapon fekete szöveg scrollozása (elhanyagolható cpu használattal) is csak videocore overclock-kal tudja akadásmentesen a 60fps-t.

A Pi5 állítólag jobb ebből a szempontból, de a lényeg hogy nem a hardveres videodekóder hiánya a fő baj.

Régóta vágyok én, az androidok mezonkincsére már!

Talán már valamivel jobb lehet az újabb, talán részben gyorsított grafikus felülettel. Valamennyire kíváncsi vagyok rá, de annyira nem, hogy csak ezért vegyek egyet :D Kicsit így is túltoltam már a minipécéket és most meg régi szerver vasakat.

De videókat nézni régebben/gyengébb pikkel kifejezetten célszoftverrel ment csak jól. Kodi natív opengl-es módban. Olyan set-top-boxosan használva.

Igen az omxplayer tudott valami trükkös fullscreen módot, ez volt az egyetlen, amivel nekem simán ment a videolejátszás, de ez valahogy időközben kikopott. Már nem emlékszem, hogy a 32->64 bites OS váltásnál, vagy az X11->Wayland váltás miatt veszett el.

Régóta vágyok én, az androidok mezonkincsére már!

Részben a szabványos video api használata miatt. Másrészt a régi pi-ken a video dekódoló modul sajátja volt ez az omxezés. A pi4-en meg ilyen felemás, a régi codeceket az omx vitte és a régi modul dekódolta, az újat meg már szabványos apin egy másik hw modul talán. Persze újabb os-sel lehet egységesítették. Azt hiszem pi4-en még lehet benne van hardver az mpeg2 és vc-1 dekódolásához, de nem árultak már licenszet hozzá. (tudom, hogy azt mondják nincs benne, de valsz hazudnak, nincs engedélyezve a használata). Aztán idővel kikopott mind. Az 5nél meg ugye eleve nincs is meg a régi hw modul és codec támogatás.

Az omxplayer repora ránéztem: https://github.com/popcornmix/omxplayer és tényleg jól emlékeztem, a 64 bites kernelre már nem portolták a régi OMX API-t, ott kopott ki: "uses openmax which has been deprecated for a long time & isn't supported with 64-bit kernels"

Asszem ebben a kommentben van leírva a lényeg: https://github.com/RPi-Distro/vlc/issues/47#issuecomment-2260091421

"as it stands the passthroughs to create a video layer that is directly rendered by the HVS don't exist" - szóval úgy tűnik, hogy volt valami direkt út a video codec és a hardveres scaler között, de az ezt használó API-k hiányoznak... ez sajnos sokmindent megmagyaráz. Bár azt írrják, hogy fullscreen-re talán megy... meg kéne néznem újra, hátha javult mióta utoljára próbáltam.

"tudom, hogy azt mondják nincs benne, de valsz hazudnak, nincs engedélyezve a használata" - ezt szerintem csak kb die shot alapos elemzésével lehetne kideríteni. Viszont eddig csak a Pi5 SoC-ről találtam die shotot (https://siliconpr0n.org/map/broadcom/bcm2712-c0/), és az sincs annotálva.

Régóta vágyok én, az androidok mezonkincsére már!

A pi5-nél még az egész régi dekódoló modult kihagyták valsz, a pi4-nél csak azért gondolom, hogy benne volt, csak letiltva, mert nem hiszem, hogy csak azért másikat terveztek volna.

Jaja omx simán felülcsapta a képernyő tartalmát, akár karakteres konzolon, akár valami grafikus felületen :D Nem tudom a kodi mennyire omx alapú volt, mert az fölé tudott tenni feliratokat, gui elemeket is.

Az érdekes kérdés itt az, hogy a teljes képernyő felülcsapás valójában minek a limitációja volt. Az omx API-t kiszolgáló (fkms talán így hívták?) drivernek, vagy maga a hardver scalerből hiányoznak feature-ök, ahhoz hogy ablakozott üzemmódban használható legyen. Sajnos erről megint nem túl sok derül ki, hivatalos doksit nem adtak ki, ami reverse engineering projektek voltak (erről tudok: https://github.com/hermanhermitage/videocoreiv) azok a video scaler-ig nem jutottak...

Régóta vágyok én, az androidok mezonkincsére már!

A konzolos használatnál meg lehetett adni, hogy a képernyő milyen területére tegye ki. Az kellhet a drivernek, hogy mik a koordináták és esetleg a kulcsszín, hogy mit szabad felülcsapni. Ez nem tűnik bonyolultnak. Azt nem tudom, hogy támogatja-e a menet közbeni pozíció és méretváltoztatást. Ja és X11 alatt is működött ez, a konzolos indítás, azt is felülcsapta. Nem tudom a moddolt vlc változat, amit csináltak hozzá, az hogyan csinálta, lehet abban csak a dekódolás gyorsítás rész volt, a kirajzolás már nem.

Úgy látom egy magyar srác csinált hozzá gui-s keretet
https://www.youtube.com/watch?v=BHiql-hjbXY

Arra tippelnék, hogy a kodi nem így használta, hanem opengl textúra is bejátszott, oda tehette át a képet, mert ott emlékem szerint átmenetes árnyékolást is raktak rá, de lehet az is omx apis volt, úgy emlékszem a logokra. 

Régi windows (95-98 környéke) tájáról van tapasztaltom még videolejátszás, de még inkább tv tuner kártya használatából. Ott is úgy ment, hogy overlay színkód és koordináta alapján tette ki, kb nulla cpu beavatkozással dma átvitellel a mozgóképet. Lassú gépen kicsit laggolt a GUIn az ablak rakosgatásakor a követés, így picit késve követte a kép a területet. És persze lehetett azzal szórakozni, hogy paintet az ablak fölé tettünk, amibe belerajzoltunk kulcsszínnel és ott átlátszott a paint ablakában a videó :D

A procis rajzolós átvitelhez kevés volt a cpu és talán a grafikus kártya io mennyisége is, arra váltva csak bélyegkép mérettel ment folyamatosan. 

Durva, hogy pont nekem is eszembejutott amit írtál a win95-98 környéki video overlay megoldásokról. Anno - mikor először bejöttek a hardveres MJPEG capture kártyák - sokmindenkinek építettem videovágó gépet (persze a többségnek "budget" IDE merevlemezzel, SCSI-t 1-2 ember vagy cég volt hajlandó megfizetni, pedig akkoriban az eléggé kellett a framedrop nélküli capture-höz).

Igen, a chroma key (jellemzően #ff00ff hupilila színű) overlay maszkolás miatt random átlátszóvá váló GUI elemek megvoltak. :) Meg a bugos videokártya driverek, amik chroma key helyett már bitmaszkot használtak, és maszk plane-en néha memóriaszemetet hagytak. Pl a kinyitott start menu helye sokszor utólag is ottmaradt a videoképen átlátszatlan téglalapként. Úgy kellett keresni, hogy a képernyő melyik részén maradt átlátszó terület. Meg a laggoló overlay update, ha mozgattad az ablakokat, kb 10-20 frame késéssel update-elte a videó helyét a képernyőn... 

Nekem pont az jutott eszembe (abból a kevés infóból, ami a Videocore HW scaleréről a regiszter listából kiderül: https://github.com/raspberrypi/linux/blob/rpi-6.12.y/drivers/gpu/drm/vc4/vc4_regs.h), hogy pontosan ilyen oldschool scaler engine lehet benne, mint anno az S3 Trio64 és kortársaiban először megjelent. Téglalap x0,y0 - x1,y1 koordinátáig és egy szimpla bitmaszk, hogy melyik pixelen ne takarja le a videó az alatta levő framebuffert. Esetleg alpha channel, hogy lehessen antialiasolt OSD elemeket kirajzolni (látok olyan regisztert aminek a nevében benne van, gondolom támogatott). Ha jól értelmezem, itt 3db ilyen engine van.

Egy compositing window managerbe (vagy wayland compositorba) élvezet lehet belehackelni a támogatást erre. Teljesen keresztülhúzza az egész architektúrát, hogy az ablakok takarási Z sorrendben renderelése után, mindenen felül jön a video plane (3 db, gondolom fix takarási prioritással) és utólag kell kitalálni, hogy melyik hol legyen átlátszó, hogy úgy nézzen ki, mintha a (félig-takart) ablakban lenne. Ehhez sokkal jobban illeszkedik az opengl-es, textúrázásos videókezelés, csak ehhez szerintem már nem elég kraftos a Pi4-ben levő videocore.

Régóta vágyok én, az androidok mezonkincsére már!

A Kodi 19-es (Matrix) verziójától kezdődően a fejlesztők eltávolították a proprietary OMX és MMAL hardveres dekódoló interfészek támogatását, és áttértek a V4L2/GBM stackre. Ez a Raspberry RPi4 és RPi5 esetében is az alapértelmezett. A V4L2 api-t használja a hardveres dekódoláshoz, míg a GBM felelős a hatékony képernyőre renderelésért. Ez lehetővé teszi, hogy a Kodi kihasználja a RPi4 és 5 hardveres dekódolási képességeit.

Szerintem Raspberry-ken a Kodi-t LibreELEC vagy OSMC rendszereken érdemes futtatni. Ezek kifejezetten a Kodi futtatására optimalizált, könnyűsúlyú Linux disztribúciók. Ezek a rendszerek közvetlenül a V4L2-t használják, és minimalizálják a rendszererőforrások használatát, így a Kodi gyors és gördülékeny marad. A LibreELEC például egyszerű telepítést kínál, és a RPi 4/5 esetében támogatja a 4K HDR tartalmakat 8/10/12 bites kimenettel. Ezt az OSMC is tudja, továbbá egy light-os debian van alatta, amire apt-vel fel lehet tenni további debianos csomagokat és debianként is működik. Ezért kicsit több erőforrást igényel mint a jeos rendszerű LibreELEC, de videózásnál ebből semmit nem lehet érzékelni. 

Ez gondolom az újabb kernelből jött a verzióváltásokkal, mert a régiben volt meg a kernel + zárt blob csomag, ami a régi módszert kezelte. 

Emlékszem volt átmeneti időszak anno, amikor még nem volt kész minden és vagy 1-2 évig jobban ment a pi3-ig bezárólag a lejátszás támogatás, mint az újabbakon. Az nem lepne meg, ha közben el is vesztettek volna képességeket. A régi pi-ken a régi megoldás például támogatott 3d dvd lejátszást is, bár valamelyik változatnál kicsit trükkösen átalakítva.

A régi pi-kre valsz jobb a régi verziót feltenni, bár addon telepítés lehet már azoknál nem működik. Sokat nőtt az újabb rendszerek gépigénye, amihez már kevés a pi1 és a 4 magos 2-3asok is megizzadhatnak, ram szűkös lehet.

Anno sokat használtam, de már régóta kész androidtv/firetv eszközöket használok az előfizetések miatt.

( carlcolt | 2025. 07. 16., sze – 15:12 )

Szerkesztve: 2025. 07. 16., sze – 15:14

Ide legkevesbe off a kerdes:

Van-e olyan ValamiPi (ARM64 SoC elerheto aron), ami azert egy Intel Iris / Intel ARC 140 integralt GPU-t elver, vagy legalabb utoler GPU performance-ban?