Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - SamElanius

Stran: [1]
1
Hardware / Re:Připojení vetšího množství USB kamer
« kdy: 11. 03. 2025, 21:31:08 »
Diky,
usbview jsem zkousel. Problematicke zarizeni spadne bud do stavu kdy je nezname (a tudiz nelze ho pouzit jako video source) nebo uplne zmizi.
USB kartu jsem pridaval, ale jak pisu. prehazuji kamery mezi radici a vse je porad stejne. Prijde mi ze uzke hrdlo muze tvorit az neco za radicem

2
Hardware / Re:Připojení vetšího množství USB kamer
« kdy: 11. 03. 2025, 21:10:08 »

Existuje jen USB2 zbernice a USB3 zbernice. Mezi nema zadnej hub neprohazuje obsah, vzdy jsou to jakoby 2 huby v jednom.
tzn. neni potreba stavet strukturu na USB3 hubech a kabelech. diky

USB2 se hodi na kamery s kompresi - kde mas napr. 1080p do 50mbit/s, a muzes pripojit par kamer, nez to zbernici saturuje. USB3 je podobne, jen v souctu je toho 5Gb/s.

myslim ze hub/radic jako takovej nesaturuju, protoze se to chova stejne i kdyz ty kamery rozlozim na 3 radice


USB2 se hodi na kamery s kompresi - kde mas napr. 1080p do 50mbit/s, a muzes pripojit par kamer, nez to zbernici saturuje. USB3 je podobne, jen v souctu je toho 5Gb/s.
- podle me to jsou s kompresi. da se nejak sledovat tok na jednotlivych radicich?

Pouzivas Win nebo Linux?
Mam tam ted dual boot. Zacinal jsem na Win, ale dostal jsem se do jedny slepy ulicky. Prisli mi dve ELP kamery co meli stejny serial ID, coz win ovladace nedaji. Linux to da pokud jsou na ruznych radicich


A pak - vice radicu je lepsi, ale musis vedet na jake pcie zbernici to visi.. a pokud je to na PCH / FCH, tak to bude zas sdilet pasmo skrze to uzke hrdlo :D

Tohle musim zjistit a sem moje znalosti (programatora) nesahaji. Da se to nejak monitorovat, pripadne jak to zjistit (u pc budu zitra), deska to je B650 Gigabyte Gaming X

dekuji

3
Hardware / Připojení vetšího množství USB kamer
« kdy: 11. 03. 2025, 19:13:11 »
Zdravim,
pracuji na streamovaci sestave pro deskove hry a podobne. Proto potrebuji mit pripojenych vetsi pocet kamer. Obraz pak zpracovavam v OBS. Zkusim popsat problem trochu obsirneji a vcetne toho co jsem zkousel.
Mam na to postaveny stolny PC s Gygabite B450 a nejakym ryzenem. Ten ma 2 usb radice a ja jeste prikoupil jednu kartu s 4 porty. K tomu pripojuji 2 grabery z HDMI, 1 webka, 3 elp kamery. Vse jsou full hd a usb2. Kdyz zacnu od zacatku a pripojim pouze klavesnici a mys a pak zacnu pripojovat jednotlive kamery tak vse vypada ok. Nicmene nekdy uz posledni kamera ma problemy s pripojeni. System ji nevidi, nebo naopak odpoji nejakou predchozi. Kdyz ale pak zacnu pripojovat dalsi periferie jako dalsi klavesnici, 3 mikrofony atd. Tak system odpojuje dalsi kamery.
Zvlastni je ze je jedno v jakem radici jsou zapojeny. Kdyz vsechny kamery nahrnu do jednoho, nebo kdyz je rozlozim do vsech 3 tak vysledek je stejny. Take se to chova naprosto stejne v linuxu i win. Meril jsem i napeti a tim to take neni (dokonce webka ma ledku pro napajeni a ledku pro "spojeni" s pc)
Videl jsem fotky kde u takove sestavy je 10+ kamer, bohuzel nemam moznost dotycneho kontaktovat.
Take vim ze lze nahradit USB IP kameramy, testoval jsem ale maji velky delay (v radu s) a kazda jiny a sesynchrovat je se zvukem neni realne.
Tim, ze prohazuji kamery/ostatni mezi jednotlivymi radici a je to beze zmeny tak si myslim ze pridani dalsi usb karty nepomuze. Take datovy tok by nemel byt problem, spis to vypada na nespecificky pocet zarizeni a hlavne se to chova dost nahodne a nedeterministicky.

Nenapadne nekoho jak toto diagnostikovat, pripadne resit? Nebo jestli navrhuji z principu spatnou architekturu?

A doplnujici otazka na fungovani USB hubu. Pokud mam kamery USB2 ktere zapojim do USB3 switche a prekrocil bych tim USB2 datovy tok, tak hub toto nedokaze zvladnout a od sebe do PC je prehodit na USB3 a vyuzit vetsi kapacitu. Chapu to spravne?

Predem dekuji

4
Vývoj / Re:SW pro náhradu kódu
« kdy: 31. 05. 2019, 22:35:14 »
Zmeny API ve vasem pripade mohou byt dvojiho typu:
1. zmena logiky - zde vam sebelepsi nastroj nepomuze. Pokud API dava neco jineho, stejne musite prepracovavat alespon castecne business a DB vrstvu.
2. zmena nazvu - pokud opravdu jde jen o kosmeticke zmeny nazvu metod/promenych na API a Vam to vyvolava chyby v business logice, pak mate spatne navrzenou aplikaci. Musite mit mezivrstvu, ktera dane api abstrahuje. Priklad: Pokud mapuji API nejakou datovou tridou, pak nelze tuto datovou tridu pouzivat v businessu, musite mit 2 tridy (byt na zacatku vyvoje jsou totozne) a premapovavat mezi nimi. Nedejboze aby jste pouzival stejnou tridu na mapovani API a jako entitu v DB.

5
Sítě / Re:Mitmproxy posílá požadavky zpět na klienta
« kdy: 22. 03. 2019, 17:50:54 »
Souhlasim. Zkusil jsem wget na stroji mimo proxy, a stejne chovani. Proste spatny vyber testovaciho vzorku, root.cz to nedela :D Velice dekuji za pomoc, tohle by me nenapadlo. V pondeli to zkusim nasadit na cilovy system.

6
Sítě / Re:Mitmproxy posílá požadavky zpět na klienta
« kdy: 22. 03. 2019, 17:03:41 »
Kód: [Vybrat]
DEBUG output created by Wget 1.18 on linux-gnu.

Reading HSTS entries from /root/.wget-hsts
URI encoding = 'ANSI_X3.4-1968'
converted 'https://seznam.cz' (ANSI_X3.4-1968) -> 'https://seznam.cz' (UTF-8)
Converted file name 'index.html' (UTF-8) -> 'index.html' (ANSI_X3.4-1968)
--2019-03-22 17:01:29--  https://seznam.cz/
Certificates loaded: 152
Resolving seznam.cz (seznam.cz)... 77.75.77.39, 77.75.77.53, 77.75.79.39, ...
Caching seznam.cz => 77.75.77.39 77.75.77.53 77.75.79.39 77.75.79.53 2a02:598:2::1053 2a02:598:a::79:39 2a02:598:a::79:53 2a02:598:2::1039
Connecting to seznam.cz (seznam.cz)|77.75.77.39|:443... connected.
Created socket 3.
Releasing 0x0000564eedfaca80 (new refcount 1).

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.18 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: seznam.cz
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 22 Mar 2019 16:01:29 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
Location: https://www.seznam.cz/

---response end---
302 Moved Temporarily
Registered socket 3 for persistent reuse.
Location: https://www.seznam.cz/ [following]
Skipping 154 bytes of body: [<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
] done.
URI content encoding = None
converted 'https://www.seznam.cz/' (ANSI_X3.4-1968) -> 'https://www.seznam.cz/' (UTF-8)
Converted file name 'index.html' (UTF-8) -> 'index.html' (ANSI_X3.4-1968)
--2019-03-22 17:01:29--  https://www.seznam.cz/
Resolving www.seznam.cz (www.seznam.cz)... 77.75.77.53, 77.75.79.39, 77.75.79.53, ...
Caching www.seznam.cz => 77.75.77.53 77.75.79.39 77.75.79.53 77.75.77.39 2a02:598:a::79:53 2a02:598:2::1039 2a02:598:2::1053 2a02:598:a::79:39
Connecting to www.seznam.cz (www.seznam.cz)|77.75.77.53|:443... connected.
Created socket 4.
Releasing 0x0000564eee35f5f0 (new refcount 1).

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.18 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: www.seznam.cz
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 22 Mar 2019 16:01:29 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
Content-Encoding: gzip

---response end---
200 OK
Disabling further reuse of socket 3.
Registered socket 4 for persistent reuse.
URI content encoding = 'UTF-8'
Length: unspecified [text/html]
Saving to: 'index.html'

7
Sítě / Re:Mitmproxy posílá požadavky zpět na klienta
« kdy: 22. 03. 2019, 15:33:32 »
I v dokumentaci je ze http i https se smeruje na jeden port a ze se nepridava zadny prepinac jestli to ma byt http/https proxy. Z toho mi plyne, ze by mel zvladat oboje ale tento zapis je trochu zavadejici.

V systemu aktualne neni vyexportovane ani HTTP_PROXY ani HTTPs_PROXY.

Na proxyserveru (tam kde je mitmproxy abych byl presnejsi) jsem udelal jen to co je popsano zde https://docs.mitmproxy.org/stable/howto-transparent/.

Nicmene dokud jsem nenaimportovat certifikat tak wget hlasil nevalidni cert. Tzn. asi to po https pujde.


8
Sítě / Re:Mitmproxy posílá požadavky zpět na klienta
« kdy: 22. 03. 2019, 14:54:03 »
Anticomp nepomohl. Pridavam vypisy z clienta i proxy:
Kód: [Vybrat]
root@xxxxx:/opt/test# wget https://seznam.cz
\--2019-03-22 14:49:21--  https://seznam.cz/
Resolving seznam.cz (seznam.cz)... 77.75.77.53, 77.75.79.39, 77.75.79.53, ...
Connecting to seznam.cz (seznam.cz)|77.75.77.53|:443... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://www.seznam.cz/ [following]
--2019-03-22 14:49:22--  https://www.seznam.cz/
Resolving www.seznam.cz (www.seznam.cz)... 77.75.79.53, 77.75.77.39, 77.75.77.53, ...
Connecting to www.seznam.cz (www.seznam.cz)|77.75.79.53|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: 'index.html.5'

index.html.5                                                    [ <=>                                                                                                                                      ]  50.45K  --.-KB/s    in 0s

2019-03-22 14:49:22 (99.7 MB/s) - 'index.html.5' saved [51663]


Kód: [Vybrat]
xxx:~ xxx$ mitmproxy --mode  transparent --showhost --anticomp
Proxy server listening at http://*:8080
10.0.10.60:55162: clientconnect
10.0.10.60:55162: GET https://seznam.cz/
               << 302 Moved Temporarily 154b
10.0.10.60:48746: clientconnect
10.0.10.60:48746: GET https://www.seznam.cz/
               << 200 OK 50.45k
10.0.10.60:55162: clientdisconnect
10.0.10.60:48746: clientdisconnect

obsah souboru (od zacatku nekolik radek):
Kód: [Vybrat]
�[s�.�>�"
e5��aH��j�II%�nQŮQo�$y�T�$���z��e�p^�Vk��5�c�Y�ټ�5� �H��u��L$�o"Q�D������H���_�}����6�n`[w�)I���L�X�ٻ]���,��
                                                                                                            ��8\��$�k�7��[����� ��.��W�[���$��h]��,��]�U �yF`�;[l�P�(ġ==$�W�Ɖ����%�kN��n�
=���YdhL_V���A-�ר�n�+ĆB�d��v!2�k�{�(>�|�Kg��n`p'C�S�sh4��E<��ѻ��`��e�9��sX�#�
�F����AD�ޮ��԰5��:�a�z�B��/Lwyt���?����ԇǔpݤxnB]���g��]�.׍�8�k�U�u-C��*S2M��[��X�c�Y ���`H�c�(��믖J�_�.�I �i`�����)�~�]/W��F� |���6>ϭ�$))�L7hɰ�J��2��v�J�u�
��˼����VA^��o����.�F�#�?�U�t`���n����BϺ]
?tQJ��t<��g^��#stc�O�r��F�_q�bh]��!�z~/g_��h�G����ӧ/ϼ�.��م�'��/�h���bK;�NOˮ�ٟ�A]�q�����}v6�|2|�e>��
                                                                                                  �y�-���)�g�Ӻ 3���
                                                                                                                   ��/ɷx��

9
Sítě / Re:Mitmproxy posílá požadavky zpět na klienta
« kdy: 22. 03. 2019, 13:23:09 »
Zdravim,
opravdu byla chyba v architekture presmerovani. Tu jsem aktualne zmenil, ale mam jiny problem.
Nyni mam na odposlouchavanem serveru nastaveny proxyserver jako vychozi branu (z dokumentace to je ten prvni pripad u transparent proxy) a mam i importovane certifikaty. A nyni:
1. udelam wget na zabezpecenou stranku
2. proxy odposlechne a prebali komunikaci - na proxy vidim obsah dotazu i odpovedi
3. wget nenahlasi problem s certifikatem - vse se tvari ok
4. ALE wget stahne rozsypany caj (mozna nejak zasifrovanou komunikaci)

jedu presne podle manualu. Zkousel jsem to na 2 verzich mitmproxy (na dvou ruznych strojich) a na obou stejne.

10
Sítě / Mitmproxy posílá požadavky zpět na klienta
« kdy: 18. 03. 2019, 11:18:59 »
Zdravim,
zkousim si pouziti mitmproxy. Infrastruktura vypada takto:
Client - odposlouchavany odesila pozadavky na http do internetu
router odklani jeho pozadavky na proxy server (rovnou smeruje na port 8080, na serveru tedy nejsou pravidla pro preposilani z 80/433 -> 8080)
proxy server - zde je nainstalovany mitmproxy a spusteny v transparentnim modu.

Problemem je to, ze proxy prijme pozadavek od klienta, ale misto toho aby udelala ten samy pozadavek na cilovou adresu, odesle udela ho na zdrojoveho klienta (ten samozrejme nema vystavenou 80 -> okamzite refuse -> proxy vrati na puvodni pozadavek 402).

Nemate predstavu kde by mohl byt problem? Dekuji

11
Vývoj / Re:PayU - Nelze vytvořit novou platbu
« kdy: 11. 04. 2014, 09:58:52 »
Ja se s PayU silene vyvztekal. Jejich dokumentace je v urcitejch mistech dost nepresna a v ukazkovym skriptu meli taky chyby. A nejhorsi je technicka podpora kde nejspis vsechny dotazy jen prekladaji do polstiny a odesilaji...

12
Server / Re:Využití domácího serveru
« kdy: 04. 04. 2014, 23:08:35 »
Ale podle toho co rika o "12 hlavnich databazich" a o tom ze vetsinu casu programuje, tak ho my lamy vubec nechapem... On chce naprogramovat DNS a DHCP servery a pak je pouzivat nebo nekomu strelit :D

Stran: [1]