Poslední příspěvky

21

Sítě / Re:Firewall: může server být neviditelný?

« Poslední příspěvek od Marek Staněk kdy Dnes v 11:02:56 »

Ono totiz existuji nizsi sitove vrstvy, ktere nemuzete odfiltrovat (napr. arp), pokud chcete zachovat funkcnost stroje A pro nejakou podmnozinu klientu.

Pokud chci diagnostikovat nižší vrstvy, nemusím mít náhodou pod kontrolou router vedoucí do cílového segmentu?

22

Sítě / Re:CETIN - připojení bytu

« Poslední příspěvek od Marek Staněk kdy Dnes v 10:58:35 »

Z pohledu technické životnosti jsou u sítí pod povrchem největším problémem půdní pohyby, havárie vodovodu a kanalizace a podzemní voda obecně, a samozřejmě jsou problémem zřizovací náklady. U nadzemních sítí  průjezdní výška a nutnost zřízení stožárů, jejichž postavení TAKY často koliduje s umisťovacími předpisy. Jsou tam věci jako minimální vzdálenost od vozovky, průchozí šířka chodníku, vzdálenosti od ostatních sítí, od stromů, apod. Navíc je to spojeno s poměrně velkými náklady na údržbu (viz před pár lety jak vítr v Praze na Legerce x Rumunské shodil do křižovatky ten uhnilý velký portál se značením a semafory a jen díky tomu, že se to stalo asi ve 3 ráno, to nikoho nezabilo). Na výložníky na budovách se to už asi 20 let nedává (a kde to je, tam se to ruší) hlavně kvůli odpovědnosti za údržbu a eventuální poškození budovy namáháním od výložníku; nezdá se to, ale sanovat prasklé zdi v celé ulici je ve výsledku dražší, než to rovnou uložit do země.

23

Software / Re:do HEVC komprese pomocí FFMpeg s LOOK AHEAD

« Poslední příspěvek od Michal Šmucr kdy Dnes v 10:49:16 »

Potvrdíte / vyvrátíte? Jaká je aktuální situace ohledně Hevc+lookahead @skylake @qsv.

Je rok 2024. Naposled jsem to zkoušel v 2017.
Právě jsem na to narazil (opakovaně). , Skylake. ffmpeg píše MFX session API version 2.13 a  MGX session implementation 1.31. FFMPEG mám  V nové verzi, 2024-10-02 . Nyní jsem chtěl zkusit jestli už to funguje náhodou.

 U HEVC_QSV mi to prostě kóduje bez look_ahead (píše to  RateCOntrolMethod=ICQ místo "ALA_ICQ)
Kde je zakopaný pes, proč LA_ICQ mi nejde. Je to vlastnost HEVC, quickysync, nepodpora Skylake, bug v ffmpeg?    Nebo je potřeba aktualizovat drivery grafiky a nějaký media (mfx ) runtime? Používám grafikou akcelerovaný pipeline, komplet, IA cores, jsou pod 20% a pod 5W.  GT cores berou 18W pro HEVC. (13 pro H264)

Bohužel je to pořád tak jak jsem psal a vy také potvrzujete. LA ICQ nefunguje s HEVC. Není to chyba ffmpeg, nebo nástrojů, co volají ty knihovny. Chová se to přesně, jak popisujete, pošle se nastavení rc modu - nestane se nic.

Bohužel to vypadá na neřešený bug, protože se o tom mluví na fóru Intelu zhruba od vydání Skylake (2015).

U novějších CPU tam je hlavně rozpor mezi oficiální dokumentací Intelu a realitou.
https://www.intel.com/content/www/us/en/docs/onevpl/developer-reference-media-intel-hardware/1-1/features-and-formats.html
(Třeba minimálně u nových GPU >10. gen. je LA_ICQ u HEVC explicitně uvedeno v Encode Features)

Realita je, že to nefunguje ani v FFMPEGu, Handbrake ani v QSVEnc, což je speciální dekodér, enkodér, procesor pouze pro QSV, který má pokryté asi všechny možnosti, co nabízí tak knihovna a je poměrně často aktualizovaný.
Má tam i dumpy podporovaných vlastností z různých generací hardware, včetně novějších diskrétních grafik DG2 (A380),  Linux a Windows.
https://github.com/rigaya/QSVEnc/tree/master/GPUFeatures
Všude je to LA_ICQ pro HEVC vykřížkované.

Ctěl bych shrnout otázkou:
...Kromě toho je hw kódování do HEVC 3x -6x pomalejší . Má to cenu , přecházet z AVC? Nebo mám starý HW?  jde o 8bitové 420 kodování vstupu i výstupu. 4K do 4K/1080p

Složitá otázka, záleží na spoustě věcí.
Jestli potřebujete šetřit bitrate (velikost souborů), případně jaký máte průměrný cíl pro bitrate. Jak moc vám jde o nejširší kompatibilitu (což je třeba důvod, proč HEVC nemá téměř žádná streamovací služba - stejně by to museli kódovat dvakrát), rychlost kódování, co jste zmínil atp.
AVC rozhodně pořád funguje, klidně i pro vyšší rozlišení, jen prostě není tak efektivní. Nebudu úplně zabíhat do všech technických detailů, v čem je HEVC lepší, ale v typicky mi to vycházelo okolo 25-30% úspory (těch cílových 50%, co měli tvůrci mi přijde spíš optimistické). Bavíme se o dosažení stejné pozorovatelné kvality a použití soft. enkodérů x264/x265 v HD a UltraHD.
Je tam samozřejmě také víc metrik pro porovnání - od standardizovaných (PSNR, VMAF) až po klasickou okometrickou (vezmu scénu v které je víc spatial/statických detailu, zároveň nějaký významnější pohyb a budu s bitratem iterovat dolů až na hranici nějakých viditelných artefaktů. Můžu si porovnat plynulost pohybů, texturu těch detailů, plynulost bar. přechodů, hrany - čemuž např. pomáhají in-loop filtry).

Ten cílový bitrate hraje roli v tom, že rozdíl mezi kodeky se snižuje s jeho velikostí. Pokud budete chtít dělat menší soubory, např. okolo 5Mbit v HD, tak tam bude vyšší rozdíl než např. u 14Mbit.
Pro posouzení by pak hrál roli samozřejmě také účel. Jestliže to mám na nějaké svoje věci, které si archivuji s relativně vysokou kvalitou a nevadí mi třeba vyšší bitrate (který bude ale pořád řádově menší než u I frame kodeků - DNxHR, ProRes, AVC Intra), když z toho budu chtít cokoliv jiného, prostě to překóduji.
Nebo jak píše třeba tazatel, jde víceméně o nějakou "normalizaci" už jednou komprimovaných videí z různých zdrojů do stejného kodeku, který je pak kompatibilní se všemi mými zařízeními.

Takže suma sumárum, pokud by tam nebyl s AVC žádný reálný problém, používal bych ho dál, nerušilo by mi to klidné spaní. Jen bych případně přitlačil na bitrate, pokud by mi šlo o kvalitu.
Klidně bych pro důležité kódování (např. mnou natočené věci) použil i 10bitů a softwarový AVC kodek, pokud to nepodporuje můj hardware. Bude to na kódování pořád rychlejší než HEVC a má to smysl, pokud se chcete vyhnout bandingu (skokům v barevných přechodech) i když je vstupní video 8bitů.

24

Sítě / Re:Vodafone chce výměnu modemu pro dual-stack

« Poslední příspěvek od Ivo2003 kdy Dnes v 09:42:46 »

. Což je dost rozdíl oproti jiným ISP, kde se platí i za tu dynamickou veřejnou IPv4 (PODA, Nej.cz a další), případně ji nemají vůbec (T-Mobile v kabelové síti Vodafone) a pevnou obvykle nabízí za příplatek jenom firmám.

U Pody je dokoupená veřejná  IP samozřejmě  statická, i když  je přiřazena DHCP serverem. Klient si ji může do wan rozhraní  nastavit i na pevno.

25

Sítě / Re:ISC DHCP přiděluje duplicitní adresy

« Poslední příspěvek od Václav Ovsik kdy Dnes v 09:38:53 »

Co je v souboru /var/lib/dhcp/dhcpd.leases ? Není s tím souborem něco?  BTW existuje utilitka dhcp-lease-list, která obsah vypíše...

26

Server / Mapování uživatelů v PostgreSQL

« Poslední příspěvek od Marcel Tomaškovič kdy Dnes v 09:23:58 »

Zdravim,
Postgres 16.4
RH 9

Potrebuji v posgresql nastavit user mapping na domain account. Cilem je aby se domenovy ucet mohl pripojit na DB.
pg_ident.conf:
pepa  pepa@nasedomena.local     pepa

pg_hba.conf:
host    all             all             all               gss include_realm=1 krb_realm=NASEDOMENA.LOCAL map="pepa"

Log:
[2024-09-30 14:39:06 CEST pepa authentication postgres 192.168.221.77]FATAL:  GSSAPI authentication failed for user "pepa"
[2024-09-30 14:39:06 CEST pepa authentication postgres 192.168.221.77]DETAIL:  Connection matched file "/opt/identity-profile-db/data/pg_hba.conf" line 120: "host    all             all             0.0.0.0/0               gss include_realm=1 krb_realm=NASEDOMENA.LOCAL"

Muzete mi prosim poradit, kde delam chybu?
Dik.

27

Server / Re:Pořízení domácího serveru na Proxmox

« Poslední příspěvek od R233 223 kdy Dnes v 07:21:04 »

Doma pouzivam HA cluster z 3x Lenovo M920q tiny na proxmoxu...
IDLE spotreba se da kolem 50W, 10GBe v PCIe a Ceph.

Cele to stalo kolem 10k, pouzity HW z ebay.
Bezzasahove vydrzi uplny vypadek jednoho node, zasahove dvou, ve standardni situaci je tak load ballancing, funguje ziva migrace...

28

Sítě / Re:ISC DHCP přiděluje duplicitní adresy

« Poslední příspěvek od zapik1 kdy Dnes v 06:37:24 »

V pokusu o konfiguraci trvalého přidělení adres jsem se ukázal jako trubka - nechal jsem tam samozřejmě blbou fixed adress, to mám opraveno.
Po té se sezmořejmě ESP posunulo na 225. To je OK.

Ale stále mi vrtá hlavou to, že  DHCP server si dovolil přidělit totožnou adresu v době, kdy jsem tam fixed záznamy neměl.

Díky

29

Sítě / ISC DHCP přiděluje duplicitní adresy

« Poslední příspěvek od zapik1 kdy Dnes v 06:17:09 »

Zdravím,
objevil se mi tu takový nešvar  - zjistil jsem že dvě zařízení (televize Samsung a ESP8266) mají stejné adresy.  ESP8266 běží trvale, televize občas několikrát za den. V okamžiku, kdy jsem televizi poprvé zapnul tak to ESP bylo zrovna vypnuté, takže telka si zřejmě lízla jeho adresu a snaží se ji používat. Její rozhraní jak tak neslutečně ořezané a pitomé, že se nedá z něho zjistit ani jakou má adresu natož cokoliv - ale absolutně nic - nastavit.
Teď fakta:
Záznam z logu ISC DHCP serveru:

2024-10-03T21:24:30.325095+02:00 debian dhcpd[1403]: DHCPOFFER on 192.168.1.224 to b0:e4:5c:02:b9:d0 (Samsung) via br0
2024-10-03T21:24:30.325909+02:00 debian dhcpd[1403]: DHCPREQUEST for 192.168.1.224 (192.168.1.10) from b0:e4:5c:02:b9:d0 (Samsung) via br0
2024-10-03T21:24:30.338182+02:00 debian dhcpd[1403]: DHCPACK on 192.168.1.224 to b0:e4:5c:02:b9:d0 (Samsung) via br0
2024-10-03T21:24:30.339490+02:00 debian named[1027]: client @0x7f2280857168 127.0.0.1#40855/key rndc-key: updating zone 'zapadlo.test/IN': adding an RR at 'Samsung.zapadlo.test' A 192.168.1.224
2024-10-03T21:24:30.349630+02:00 debian dhcpd[1403]: Added new forward map from Samsung.zapadlo.test. to 192.168.1.224
2024-10-03T21:46:59.529207+02:00 debian dhcpd[1403]: DHCPOFFER on 192.168.1.224 to b4:e6:2d:36:d9:06 via br0
2024-10-03T21:46:59.554231+02:00 debian dhcpd[1403]: DHCPREQUEST for 192.168.1.224 (192.168.1.10) from b4:e6:2d:36:d9:06 via br0
2024-10-03T21:46:59.554473+02:00 debian dhcpd[1403]: DHCPACK on 192.168.1.224 to b4:e6:2d:36:d9:06 via br0
2024-10-03T21:46:59.557596+02:00 debian named[1027]: client @0x7f2280857168 127.0.0.1#40855/key rndc-key: updating zone 'zapadlo.test/IN': adding an RR at 'ESP_36D906.zapadlo.test' A 192.168.1.224

První si požádal o adresu Samsung, mac adresa  b0:e4:5c:02:b9:d0 (přičemž ESP v tu chvíli byl zapnutý), za cca 20 minut obnovoval adresu ESP mac b4:e6:2d:36:d9:06 a ISC DHCP server jim oboum bez uzardění tu proklatou 192.168.1.224 prostě potvrdil.

Teď ráno vidím v logu (Samsung je od večera vypnutý):

2024-10-04T05:45:31.592302+02:00 debian dhcpd[1403]: DHCPREQUEST for 192.168.1.224 from b4:e6:2d:36:d9:06 via br0
2024-10-04T05:45:31.593019+02:00 debian dhcpd[1403]: DHCPACK on 192.168.1.224 to b4:e6:2d:36:d9:06 via br0
2024-10-04T05:45:31.605339+02:00 debian named[1027]: client @0x7f2280857168 127.0.0.1#40855/key rndc-key: updating zone 'zapadlo.test/IN': adding an RR at 'ESP_36D906.zapadlo.test' A 192.168.1.224
2024-10-04T05:45:31.605379+02:00 debian dhcpd[1403]: Added new forward map from ESP_36D906.zapadlo.test. to 192.168.1.224

Tj ESP si žádá o adresu, ale ve výpisu dhcp-lease-list ji vůbec nevidím.
V konfigurace DHCP serveru mám:

default-lease-time 86400;                                                                                                                                            
max-lease-time 17800;                                                                                                                                                

Takže by měl držet minimálně 1den jako obsazenou.
Pokusil jsem se situaci vyřešit záznamy "natvrdo", ale nic se nezměnilo, jako by to DHCP server úplně ignoroval:

host Samsung {                                                                                                                                                       
  hardware ethernet b0:e4:5c:02:b9:d0;                                                                                                                               
  fixed-address 192.168.1.224;                                                                                                                                       
    ddns-hostname "Samsung";                                                                                                                                         
}                                                                                                                                                                    
#teplomer babicka                                                                                                                                                    
host  ESP_36D906 {                                                                                                                                                   
  hardware ethernet b4:e6:2d:36:d9:06;                                                                                                                               
  fixed-address 192.168.1.224;                                                                                                                                       
    ddns-hostname "ESP_36D906";                                                                                                                                      
}    

   

Co jsem nepochopil a je úplně blbě? ISC server ve stávající konfigurci na tom serveru provozuji takto minimálně 10 let a zatím vždy v poho (nebo jsem si podobného chování nevšiml).
Jen doplním, že ESP má firmware generovaný ESPhome bez zásahu do konfigurace síťového nastavení.
Co přehlížím?
Díky                                                                                                                                                           

30

Hardware / Re:Kvalitní kamera pro minipočítač

« Poslední příspěvek od Hynek Beran kdy Dnes v 02:20:30 »

Kvalitní kamera pro minipočítač je podle mě oxymorón.

Tak přes CSI můžete připojit jakoukoli kameru. I kvalitní.

To neni pravda. Muzete zachytavat jen RAW data, bez pouziti ISP kterym RPi disponuje.

ISP na RPi je uzavreny subsystem, s blobem, bez moznosti konfigurace. Proto existuji jen 2-3 podporovane kamerky - a co vic - i tyhle moduly maji autorizacni cip se SHA, aby neslo vyrobit to same ale levneji. Proste malinova zumpa se vsim vsudy.

Tohle: https://auvidea.eu/b101-hdmi-to-csi-2-bridge-15-pin-fpc/ jsem před pár lety normálně používal. Navíc tazatel neomezuje minipocitace na rpi, na jetson nano funguje treba lecos. A uz jenom oficiálních kamer je víc, než 2-3 (5-6) :-)