Azt hittem, ez egyszerű lesz 
. Hiszen a Chromecast, Miracast 10+ éves dolog, minden is ismeri. Meg hát van csomó Github projekt erre, régen mindenki csinált ilyet, csak akkor még nem volt TV-m. Van itthon Raspberry (hármas), meg x86-os minigép is, ami jó lehet erre, miért ne.
Az alapötlet onnan jött, hogy az x86-os tabletemen hülyén működik az USB C, vagy kontaktos, vagy a Dell idióta vezérlőt tett bele (amúgy mindkettő ), de C-s dokkal nem ment a képátvitel, meg C-HDMI cuccal sem. Na, de minek ehhez kábel, hát biztos simán megoldható. Aha... (És ne kelljen hozzá venni semmit, az is fontos volt.)
Ötletelés
Nagyon amúgy nem mélyedtem el abban, hogy mik az alapjai ennek. Egyszerű, egy kattintós cucc volt a cél, amivel akkor már telefonok, PC-k is tükrözhetőek a TV-re. Kismillió Github projekt van ilyesmire...
Ja, mind 10 éves, be se fejezték, csak régi Pi OS-en megy, a Chromecast protokollt kb. soha nem fejtették vissza rendesen, egyéb protokollokat meg ha valaki megcsinált, az is olyan, hogy vagy saját, vagy nem ismeri semmi.
- Lazycast : Ez lett végül a befutó, meg lehetett oldani friss Pi OS-re is (amúgy Bullseye Debian az utolsó, amihez ajánlja a készítő), bár a PC-s kapcsolat eléggé köhög, de telefonnal megy szépen
- Miraclecast : Ehhez minden tudott csatlakozni, de kép, az sehogyan nem volt
- Berryshare : El se indult semmin 
- Picast (ebből kettő van, valamennyire működött az egyik)
- WebRTC - ami jó megoldás lenne - : overkill, azaz nem teljesen, de nem jutottam vele semmire, több macera lenne rendesen beüzemelni, gstreamer plugineket kellene hozzá fordítani, de az pont nem fért el egy 8GB-os kártyán
Aztán jött az, hogy legyen Lazy, és mellette valami más megoldással a PC-k. Hiszen a Lazycast egyik lehetősége is a VLC-s lejátszás. A mezei VLC képes egy Pi-n fullHD streamet élvezhetően lejátszani (újabb Pi OS_eken már csak konzolon), szerencsére van h264 dekóder a prociban. A hálózat viszont érdekes, wifi kapcsolat nem elég neki, kábelen kell lennie. (Lesz erről még meglepetés )
Kliensoldalon az Android telefonokban van Miracast/Chromecast kliens, iPhone-nál ne is álmodj ilyet, csak az Apple-s cuccukkal megy, Linuxon Gnome-network-displays, Windowson van beépített kliens. Ahogy azt Móricka elképzelte.
Megvalósítás - Miracast, telefonokhoz
A Lazycast fordítása teljesen jól megoldható a leírás alapján Bullseye Debian alapú dolgokra (kipróbálva, tényleg működik, csak nem akartam outdated OS-t). Igazából, nem is kell ténylegesen fordítani, mert egy csomó bash és Python script a lényege, megcsinálod, működik, a player meg a control részeket fordítja, meg a Pi userlandet. Trixie-n (Bookworm- és újabbakra, azaz 12 és 13-as Debianra) már érdekesebb. Leklónozni a Git projekt, a d2.py -ban átírni a player-t 0-ra (0 a VLC, az 1 és a 2 fordulna le fordítás közben, ezek sokkal kisebb erőforrás-igényűek), a newmice.py -ban pedig a concurrent=1 -et. Így megy az infrastruktúra mód is (MICE, MiraCast over Infrastructure, ezt szereti elvileg a Windows is), meg az all.sh -t is futtatja, ami a telefonos p2p wifi kapcsolathoz kell.
A leírásban a Pi userland kódját nem tudom, mennyire lényeges, de én leforgattam. Le is fordult, meglepő módon. Valószínűleg lényeges, hogy 32 bites Pi OS volt alatta, mert 64 bitessel valahogy konzolon se játszotta jól a fullHD mintavideót HTTP-ről a Pi. Első körben GUI-n álltam neki, de aztán áttoltam konzolos bootra, miután azon is minden működött. (Amúgy az egész cucc elég kókánynak tűnik, Python+shell script, mikor mi volt éppen a készítő érdeklődése gondolom, stb. És a többi ilyen projekt is hasonló szint, Python mindenhol, azt' csodálkozunk, hogy lassú. Rendesen megírt üzenetek sehol.) Mindenképpen fel kell mellé tenni az Avahi csomagokat (avahi-utils), amiket a leírásban javasol, ha MICE-t is akarunk, azaz Windows, vagy Gnome-network-displays kapcsolatot is. Nyilván egy VLC is kelleni fog, az lesz a megjelenítő. (Igen, sima Linux konzolon, ablakkezelő nélkül is megy.)
Szóval amúgy forgatás előtt ez fog kelleni :sudo apt install vlc mc avahi-utils libx11-dev libasound2-dev libavformat-dev libavcodec-dev python3-evdev cmake
Viszont ennyivel nem fog működni, nem fog p2p eszközt találni.
Amennyire rájöttem, az egész úgy működik, hogy normál TCP hálón hirdeti magát (mDNS/Avahi), és ha valaki kapcsolódni akar, akkor az Wi-Fi direct (p2p) kapcsolaton történik egy WPS PIN-el (ezt amúgy az all.sh-ban kell átírni, ha sajátot akarsz). A Debian Bookworm (12) után azonban ennek szigorodott a kezelése, és a wpa_supplicant (ami a wifit kezeli) már nem hoz létre p2p eszközöket. Vissza kell rugdosni abba az állapotba, amikor még hozott
(Jelentős AI segítség volt amúgy végig, mert ennyiféle hibára megoldást túrni még így is rengeteg idő volt, meg hát az AI pont erre való, olyan infók kutatására, amiket kézzel nagyon nehéz megtalálni, és megvizsgálni, hogy az a te bajodra jó-e.)
Wpa_supplicant konfig :sudo vi /etc/wpa_supplicant/wpa_supplicant.conf
(vagy nano vagy mcedit vagy akármi 
)
Bele (ezek között a device-type ha minden igaz, Pi specifikus, a name viszont jobb, ha azonos a hostnévvel) :ctrl_interface=DIR=/run/wpa_supplicantupdate_config=1device_name=raspberrypidevice_type=1-0050F204-1p2p_go_intent=7p2p_listen_reg_class=81p2p_listen_channel=1p2p_oper_reg_class=81p2p_oper_channel=1
Kiütni a wpa_supplicant service-t :sudo systemctl stop wpa_supplicantsudo systemctl mask wpa_supplicantsudo systemctl mask wpa_supplicant@.service
Létrehozni egy saját wpa_supplicant service-t az eredeti helyett :sudo nano /etc/systemd/system/wpa_supplicant-p2p.service
A file-ba :[Unit]Description=Classic wpa_supplicant for P2P (Miracast)After=network.targetWants=network.target[Service]Type=simpleExecStart=/usr/sbin/wpa_supplicant \ -i wlan0 \ -D nl80211 \ -c /etc/wpa_supplicant/wpa_supplicant.conf \ -u -s -O /run/wpa_supplicant -g /run/wpa_supplicant/globalRestart=always[Install]WantedBy=multi-user.target
Engedélyezni a saját service-t :sudo systemctl daemon-reloadsudo systemctl enable wpa_supplicant-p2psudo systemctl start wpa_supplicant-p2p
Networkmanagertől elvenni a fifit :sudo vi /etc/NetworkManager/conf.d/unmanage-wlan0.conf
[keyfile]unmanaged-devices=interface-name:wlan0
Networkmanager restart :sudo systemctl restart NetworkManager
Innentől kezdve egy reboot után lennie kell a /run/wpa_supplicant könyvtárban valaminek (p2p eszköznek se árt), a wpa_cli interface parancs kimenetében is.
És működnie kell a ~/lazycast könyvtárban a ./mice.sh -nak, ami ha jól indul, akkor a p2p eszközök neveit, és sok OK feliratot ad. Utána valahol egy "Display is ready" is lesz, és elkezdi írogatni a WPS PIN kódját a p2p hálónak.
Én a céges Samsung telefonommal tudtam tesztelni, az azon beépített Smartview tükrözés simán működik, megtalálja a raspberrypi nevű eszközt, bekéri a PIN-t, csatlakozik, indul a VLC, és van kép. A régebbi Android cuccaim nem működnek így, mert leválasztott háló van a régebbi eszközöknek, és arról a hálóról a normál hálózat nem is érhető el. A *cast protokolloknak meg muszáj, hogy az eszközök egy hálózaton legyenek. (A régi eszközeim meg a WPA3 normál wifikre úgysem tudnak csatlakozni, mint sokadik indok. Viszont a Samsung A5 2017 Lineage-s tartalék telefonról egyszer ment, nem tudom, hogyan )
Linux kliensek és natúr streamek
Ezeken létezik a teljesen kulturált Gnome-network-displays csomag, amivel vezeték nélküli kijelzőket lehet kezelni. A Debianban levő wpa_supplicant esetén itt is valószínűleg a p2p mód szigorításába futottam bele, de MICE-n tud csatlakozni (p2p-n csak a csatlakozás kezdeményezéséig jut, elvileg a Group Ownershipen akad el, de annak az állítgatásával sem lesz jobb). Mondjuk sok köszönet abban sincs, a kép szép, de videó esetén 10mp-enként megáll, szétesik. Prezentációt tartani mondjuk megfelel. Igazi *cast vevővel biztos jó lenne.
Más megoldás kellett. Elkezdtem VLC-vel szórakozni, itt derült ki, hogy amúgy ez konzolon lazán viszi a fullHD streamet. És a VLC tud hálózati folyamot is lejátszani, meg küldeni is. Akár az asztalt is tudja felvenni...
Tehát a legbutább RTP fogadó konzolra :cvlc -f --network-caching=1000 rtp://@:5004
(ha GUI-n vagy, akkor nem cvlc, hanem sima, és akkor van felület is - a cvlc a VLC parancssoros felületre kitalált része)
És tesztelni lehet ezzel, mint stream feladó :vlc tesztvideo.avi --sout '#transcode{vcodec=h264,vb=6000,scale=1}:rtp{dst=vevő.eszköz.ip.címe,port=5004,mux=ts}' :no-sout-all
Kell képet adnia a vevő eszközön. Tkp. ha a vevő oldal fut, akkor akármi, ami oda küld streamet, meg fog tudni jeleníteni képet, mert ha nincs stream, nem áll le a vevő Ez a része kényelmes.
UDP stream :
Küldő : vlc tesztvideo.avi --sout="#std{access=udp,mux=ts,dst=vevő.eszköz.ip.címe:5004}"
Fogadó : cvlc -f -network-caching=1000 udp://@:5004
VLC grafikus felületen ugye ez úgy néz ki, hogy File, kiválasztani a forrást (film, felvevőeszköz...), Lejátszás gomb mellet kinyitni a kis menüt, Közvetítés, nextnextfinish, azaz azért célnak hozzá kell adni egy UDP célt (és ott a fogadó címét), és Műsor. (Nem kell feltétlen átkódolni, ha működik anélkül, akkor az eredeti adatfolyamot fogja továbbítani, ami csak jó.)
Videóhoz ugye az UDP alapú átvitel elvileg megfelel, mert annak nem gond, ha kiesnek csomagok, nem foglalkozik visszaigazolással se, mint a TCP. Ha szép képet akarunk ezzel a MPEG-TS konténerformátumú izével , akkor viszont elég jó bitrate kell, amit meg a Pi nem szeret. Rendszeresen villog, szétesik még az állókép is a csomagvesztés miatt, ha fulHD-t jó minőségben kap UDP streamben. Lehet trükközni UDP buffer emelésével, de nem lesz igazán jó.
Viszont, a mezei VLC csak X Window esetén jó Linuxon teljes képernyőt tükrözni (Meg Windowson is megfelel.). A mostanában szokásos Wayland alapú GUI-kon (KHMM Gnome ) nem fér hozzá az ablakokhoz, és az asztalhoz sem. (Amúgy filmet átvinni teljesen jó, még RTP vagy UDP módszerrel is, ez nem para.)
A megoldás az OBS Studio lett, mert az van Linuxra, és hozzáfér a Wayland képernyőihez. Ebben vagy UDP streamet tudtam összerakni, ami úgy 15-16Mbit/s körül már jól néz ki , vagy RTSP-t, ami egy sokkal jobb dolog, szép és stabil képpel, kevesebb sávszélből. Meredek, hogy ehhez egy streamer szoftver kell, de ha ágyúval kell lőni a verébre, akkor azzal .
Az UDP streamhez :
Settings-Output-Recording (mi más), Type : Custom, FFmpeg Output : Outout to URL, File path udp://vevő.gép.ip.címe:port , Container format : mpegts , Bitrate ízlés szerint, keyframe ízlés szerint (nekem 250-500 között vált be), Video encoder libx264, esetleg a video encoder settings tune=zerolatency.
Ezzel a fenti VLC-s UDP vevő szépen megy.
A RTSP stream sokkal érdekesebb. Ehhez kell az obs-rtspserver plugin, ami csomagból települ, bár nekem még kellett kézzel mókolni (a csomagból a .so file -t a /home/user/.config/obs-studio/plugins/obs-rtspserver/bin/64bit könyvtárba másolni). Nyilván a RTSP szerver nem kimeneti opció lesz, hanem a Tools menüben fog megjelenni.
Ez sem egy űrtechnika. Portot átírtam 8554-re, mert magától az 554-et akarja. A Start Output gombra indul a móka. (Nekem rosszak a gombfeliratok, mert a fordítást nem másoltam a helyére, gondolom )
A fogadó pedig : vlc rtsp://küldő.gép.ip.címe:8554/live . (Vagy cvlc, konzolról.) Viszont ez nem olyan kényelmes, mint az UDP-s cucc, a streamnek léteznie kell, amikor a fogadó elindul. Illetve ha megáll a kép, vagy csak hang van, esetleg össze-vissza esik-kel az átvitel, akkor az OBS Studio újraindítása is jól jön (meg vevő oldalon megnézni, hogy van-e beragadt VLC példány )
Az OBS-ben simán megosztható ablak, teljes képernyő, stb. Ez a része nagyon kényelmes. A RTSP-t a Pi még egész jól viszi, néha van egy-egy csuklás, azaz akadás, vagy foltok a képen, de nekem tök nézhető. Illetve szép a képe, nem blokkosodik.
Windows
Nem ismerem a Windowsra létező asztal-streamelő dolgokat, de biztos van sok. Windowsom viszont nincs Azaz van virtuális, de az nem hajlandó semmilyen vezeték nélküli kijelzőköz sem csatlakozni, mert finnyáskodik, hogy nincs neki wifi. (Ha odaadom neki a PCIE kártyát a host gépből, akkor meg nem telepíti fel a drivert 
. Ennek semmi nem elég jó. ) OBS Studio létezik erre is, meg VLC is, és a VLC screen:// MRL-je is működik, ezt kipróbáltam, UDP-n simán át lehet tolni az asztalt. RTSP-hez sügér voltam.
Elvileg a Lazycast MICE módja pont Windowshoz való, de nem igazán volt mivel tesztelni; a céges laptop egyszer hajlandó volt csatlakozni, de nem erőltetem, mert az ugye céges; a kötelező VPN miatt az is csoda, hogy egyszer megtalálta a fogadót.
Kényelem
Már amennyire ez az. Tehát letettem a Pi-re scriptet az UDP és RTSP vevőkre, így ssh raspberrypi "sh vlc_rtsp_sajatgepem.sh" -val indul a RTSP vétel, ha már megnyomtam az OBS-ben a startot. UDP ugyanígy.
És ez megy együtt a Lazycast-tel, és mivel a Pi autologinos konzolra, így azt is csak a .bashrc -be szórtam be, azaz a végérecd /home/user/lazycastps aux | grep "mice.sh" | grep -v grep && echo MICE already running || ./mice.shcd ~
Szóval ha már fut a MICE, akkor nem indítja el megint. Így a Pi bootolásakor elindul a MICE, csatlakozhatnak a telefonok, Windows, Gnome-network-displays, és ha laptopról küldenék a TV-re teljes képernyős videót, akkor ssh-n indulhat a VLC, a MICE fut tovább a háttérben.
Mondjuk az egész VLC-s RTSP/UDP/akámilyen stream fogadóban az az egy jó, hogy az viszont egy normális hálózaton bármin elmegy, akármilyen gép befogható rá, amire van VLC. És az ugye a legtöbb oprendszerre létezik 
Hálózat
Nem akarnék külön kábelt ehhez a TV-ig. Nincs messze a normál hálós switchtől, de minek? Az itthoni hálón 2 VLAN van, egyik a normál háló, másik a régi, nem WPA3 képes, nem frissíthető eszközöknek. A Pi és az x86-os mingépem is csak WPA2 képes, és a Miracastnak, de a streamnek is jobb, ha egy hálón vannak a gépek. (Mondjuk a leválasztott háló teljesen elérhető a normálról, csak fordítva nem, de ettől még a tükrözés nem működik )
Azért kipróbáltam, mit tud a WPA2-es wifire felhúzva a Pi és a napi használós laptop is, az azt kiszolgáló router kb. 20mp akadozó stream után újraindult (Ez egy TP-Link 1043v1-en megy most, az utolsó Openwrt-vel, ami létezik rá.)
Az az érdekes, hogy amikor p2p/Wi-fi directen át kapcsolódik a Pi-re valami, akkor semmi gond, telefonról is a stream kb. hibátlan (csak elég alacsony bitrátájú).
Megnéztem olyan eszközzel is, ami tudott ugyanazon a hálón lenni, mint a gépem, és wifin elég akadozó volt minden (450 és 700mbit/s-es két háló van). Szóval, érdemesebb a kábel.
Az is fura, hogy a RTSP stream telefonos lejátszása (jóhogy kipróbáltam ) pl. nem volt jó, pedig maga a telefon wifin tanúsított sebessége megfelelő.
Végszó
Teljesen bosszantó, hogy erre 2026-ban nincs egy olyan DIY megoldás, hogy feltelepíted (a fogadó és a küldő oldalon is) és működik (főleg, hogy láthatólag a hardver oldala a legkisebb gond). A fentiek ugyanis 3 hétnyi túrás és próbálgatás eredménye. (Jó, közben megjavult ez-az, telefon, ilyesmi, de azok csak egy-egy délutánt jelentettek. ) És így is egy tákolmány az egész.
A legértelmesebb alternatíva a WebRTC lett volna, ahhoz a Gstreamerhez külön plugin kell (meg azt leforgatni) - OK, megcsinálom majd - de kb. az lenne a normális menete, hogy egy signaling szervert telepítsek...? (Janust?) Lenne mire, de tényleg egy olyan szerver kellene, amin videokonferenciázni lehet? (OK, a WebRTC-hez egy signaling szerver kell, ami a kapcsolat kiépítéséért felel, nem a streamért, de ez is overkill egy kijelzőtükrözéshez...)
A végén a Pi-ből lett a fogadóeszköz, idle 0,3A fogyasztással, lejátszás közben 0,35-0,47 között. Ez azért kemény 1,5-2,5W Egy 8GB-os kártyán bőven elfér az egész OS (igazából ha 4GB foglalt belőle).
Olvasni is sok, nemhogy megcsinálni 