- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- SSD kibeszélő
- Kormányok / autós szimulátorok topicja
- VR topik (Oculus Rift, stb.)
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Amazon Fire TV stick/box
- Milyen asztali médialejátszót?
- LG C3: egy középkategóriás OLED tévé tesztje
- Milyen TV-t vegyek?
- Publikálta a Microsoft az MS-DOS 4.0 forráskódját
Hirdetés
-
Bemutatta a DisplayHDR 1.2-t a VESA
ph Bővülnek és változnak a követelmények, illetve a hitelesítési teszt is fejlődik.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Egyre nagyobb a hatása a választásokra az AI-generálta képeknek
it Az OpenAI ezért külön eszközt hoz létre, hogy azonosítsa a DALL-E 3 által létrehozott képeket.
Új hozzászólás Aktív témák
-
válasz Smktrooper #31775 üzenetére
Feleslegesen messzire megyünk vissza. Aktuális összefoglaló:
TCP-vel mind a 9 kamera képe hibátlan. Az egyetlen gond, hogy így 4db X típusú kamera rendszeresen reboot-ol, csak 5db Y típusú stabil (így valószínű, hogy a TCP-s reboot-olás az X típusú kamerák eredendő hibája -> ezért erőltetném [az egyébként alapértelmezett] UDP-t, bár persze lehet, hogy a TCP-s reboot gond is megszűnne, ha eltűnne a másik probléma, ami az UDP-t is érinti...).
UDP-vel soha sehol nincs reboot és egyszerre 1db (tetszőleges) X típusú kamera rögzíthető az Y-októl függetlenül, de egyszerre kettőnél több már használhatatlan.
A problémás 4 kameránál semmi sem változott, mikor ott helyben switch-et cseréltem alattuk, vagy mikor kivittem oda egy laptop-ot is, és bekötöttem közvetlenül abba a switch-be, amibe a kamerák is kötnek és azzal is próbáltam rögzíteni (sőt, a szerveren Gentoo Linux, a laptop Windows 10 van).
A kinti laptop és itthoni gépek közt ~10MB/s-el tudtam file-okat mozgatni. Zavartalan 100Mbps-el kommunikált a kinti switch-en át a laptop és az SXT olyankor is, mikor a kettő közül valamelyik épp rögzíteni próbálta a kamerákat, akár TCP-vel, akár UDP-vel.
Mikor épp mind a 4 kamera vissza volt véve 0.2MB/s-re, gyakorlatilag meg sem látszott a fájlmásolási sebességen, ami előtte durván 9-11 közt, aztán 9-10 közt hullámzott.Szóval bárhogy próbálom körbejárni, csak a 4db Y típusú kamera okoz zavart, és azok csakis egymás működésében. Nem fullad le tőlük teljesen sem az egész switch, amibe bekötnek, sem más eszközök, amik ebbe a switch-be kötnek be, egymást viszont megölik (1fejenként ~4Mbps is sok lesz nekik).
Mondjuk egy kifelé 8 vagy 9 portos switch odabent lehet pl. két darab 5+1 portos lapka, és talán ilyenkor az egyik ág lehal úgy, hogy a másik lapka felé is csak 10Mbps megy tovább, a másik ág viszont a többi porton 100Mbsp marad..? Viszont ha egy 10Mbps eszköz lefullaszt egy egész ágat, akkor a második ágat is ugyan úgy le kéne fullasztania a két lapka közti 10Mbps vonalnak, szóval... (Persze ha nem egyforma lapkák... de két különböző típusú switch-el is ez van...)
Ping-elni is próbáltam már a kamerákat 1472 byet-os csomagokkal, letiltott tördeléssel. Nem igazán lehet észrevenni, hogy épp megy-e rögzítés róluk egy szálon, vagy sem.
..................
Most valami olyan szálon próbálok előbbre jutni, hogy az ffmpeg és vlc vajon nem csak a saját, de az OS UDP stack buffer beállításait is átkonfigurálják-e, és volt-e esetleg olyan alaposan és ügyes valaki, hogy pontosan egy átlagos 1080p30 stream-re legyen elég, többre ne.
De próbáltam UDP-t használni azokkal a kamerákkal, amik nem reboot-olnak TCP-vel és mióta alaposan átrágtam a WiFi beállításokat, azóta mehet velük az UDP (tehát egyszerre 5db Y típusúval is jó az UDP, de ha ezeket leállítom, akkor sem jó 4db X típusúval). Szóval ez megint nem látszik vezetni sehová.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest