Příspěvky

1

Software / Re:NVR software pro IP kamery a kontinuální nahrávání

« kdy: 20. 03. 2025, 23:04:56 »

Tiez si myslim, ze cez FFmpeg to pojde jednoduchsie, menej narocne na HW, "skopirovat" a ukladat, ale problem je v tom, ze potrebujem, aby k tomu bol lahky pristup a aspon zakladne spravovanie pre bezneho cloveka. Z toho dovodu sa to stale snazim rozchodit v nejakom uz existujucom a ako tak prehladnom UI.

2

Software / Re:NVR software pro IP kamery a kontinuální nahrávání

« kdy: 20. 03. 2025, 22:17:02 »

Vyzera to tak, ze sa mi pod proxmoxom podarilo rozchodit integrovanu gpu. Nainstaloval som frigate lxc, nastavil zakladnu konfiguraciu, ale vychadzal som z tej, ktora tu bola postovana. Akurat som doplnil tu HWaccel, zmenil som record mode z motion na all a vypol som snapshoty. Frigate stream vyzera, ze bezi, zatazenie GPU reportuje 6% a CPU 8%, takze podla tej zataze je asi zjavne, ze nahravanie neprebieha ani v UI Frigate nevidim ziadne videa. Pravdepodobne mam chybu v konfiguracii, mozete sa na nu pozriet?

Kód: [Vybrat]

mqtt:
  enabled: false

cameras:
  cam1: # <--- this will be changed to your actual camera later
    enabled: true
    detect:
      enabled: false
    ffmpeg:
      hwaccel_args: preset-vaapi
      inputs:
        - path: rtsp://user:pass1@ip:554/Streaming/Channels/101
          roles:
            - record
    snapshots:
      enabled: false
      timestamp: false
      bounding_box: false
    record:
      enabled: true
      retain:
        days: 7
      events:
        retain:
          default: 7
          mode: all
    motion:
version: 0.14


3

Software / Re:NVR software pro IP kamery a kontinuální nahrávání

« kdy: 20. 03. 2025, 16:21:29 »

Ok tak to teda skusim tak, ze vyhodim odtial proxmox, dam tam klasicky debian a uvidim co z toho bude teda. Pozeral som ci sa neda v Proxmoxe nastavit, aby vedel vyuzivat integrovanu GPU, ale podla roznych for na to nie je univerzalny postup, zalezi to od konkretnej GPU a casto treba vela improvizovat a debugovat. Hlavny dovod preco som to povodne chcel mat pod proxmox bola jednoducha zaloha / obnova + som uvazoval, ze ak by tam ostal nejaky vykon, tak by som tam rozchodil este HA.
Inak k tym kameram: Skusal som este prenastavit motioneye podla rady z tejto temy, ale aj ked som zapol funkciu movie movie passthroug, na tej jednej kamere, tak cpu usage skocil na 50%+ a to som vypol stream ako taky a nechal iba nahravanie. Povodne som totiz predpokladal, ze stream nebudem pouzivat vobec a namiesto toho bude v realnom case pristupovat k tomu videu, ktore sa prave nahrava a v pripade potreby si ho budem moct zaroven aj prehravat. Zistil som, ze v pripade motioneye to nie je mozne pretoze v rezime passthrough vystupne video uklada do containeru mp4 a ten nie je mozne prehravat, ak video este nie je donahravane, ale v pripade mkv alebo flv by malo byt mozne prehravat video uz pocas jeho nahravania.

4

Software / Re:NVR software pro IP kamery a kontinuální nahrávání

« kdy: 20. 03. 2025, 13:43:50 »

Je důležité, aby byla využita HW accelerace na GPU, jinak to bude nesmyslně zatěžovat CPU.

No moj problem je prave to, ze v tom stroji nemam dedikovanu GPU asi som to mal explicitne napisat uz skor, ale predpokladal som, ze je to jasne z kontextu. Tak uz rozumiem, ze mas nizky CPU usage

5

Software / Re:NVR software pro IP kamery a kontinuální nahrávání

« kdy: 20. 03. 2025, 11:58:41 »

Tak podla toho co pise vecsina z Vas musim robit nejaku chybu pri konfiguraciach pretoze na Proxmox masine mam 8GB RAM a CPU:

Kód: [Vybrat]

lscpu
Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          39 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   4
  On-line CPU(s) list:    0-3
Vendor ID:                GenuineIntel
  Model name:             Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz
    CPU family:           6
    Model:                60
    Thread(s) per core:   1
    Core(s) per socket:   4
    Socket(s):            1
    Stepping:             3
    CPU(s) scaling MHz:   98%
    CPU max MHz:          3700.0000
    CPU min MHz:          800.0000
    BogoMIPS:             6584.83
    Flags:                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxs
                          r sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
                           nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2
                           ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsa
                          ve avx f16c rdrand lahf_lm abm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow flexpriority
                          ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pl
                          n pts vnmi md_clear flush_l1d
Virtualization features: 
  Virtualization:         VT-x
Caches (sum of all):     
  L1d:                    128 KiB (4 instances)
  L1i:                    128 KiB (4 instances)
  L2:                     1 MiB (4 instances)
  L3:                     6 MiB (1 instance)
NUMA:                     
  NUMA node(s):           1
  NUMA node0 CPU(s):      0-3
Vulnerabilities:         
  Gather data sampling:   Not affected
  Itlb multihit:          KVM: Mitigation: VMX disabled
  L1tf:                   Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled
  Mds:                    Mitigation; Clear CPU buffers; SMT disabled
  Meltdown:               Mitigation; PTI
  Mmio stale data:        Unknown: No mitigations
  Reg file data sampling: Not affected
  Retbleed:               Not affected
  Spec rstack overflow:   Not affected
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP disabled; RSB filling; PBRSB-eIBRS Not
                          affected; BHI Not affected
  Srbds:                  Mitigation; Microcode
  Tsx async abort:        Not affected
Vsetky jadra a celu RAM som vzdy naplno vyhradil pre dany NVR VM / LXC.
Doteraz som to vzdy testoval len s jednou kamerou Hikvision DS-2CD2685FWD-IZS (celkovo mam 4), pri plnej kvalite vstupneho streamu s rozlisenim 3840 x 2160, FPS: 25, bitrate 16 mbit/s mi frigate a motioneye reportovali tatazenie CPU 60-80% a to som nastavil len jednu kameru. Shinobi reportoval zatazenie stabilne cca 30% ale tam sa mi asi nepodarilo spustit nahravanie.

Takze dakujem za tipy, vyskusam ich a dam vediet. Ocenil by som zdielanie konfiguracie frigate, niekto tu spominal, ze vyuziva frigate cisto na dvr recordin a zataz ma velmi nizku.

PS: Viem, ze ten bitrate je mozno zbytocne vysoky, asi ho v ostrej prevadzke znizim, ale zaroven planujem kamery pouzivat na vacsi vzdialenost, preto budem potrebovat vyssi bitrate, ale asi nie az tak.

6

Software / Re:NVR software pro IP kamery a kontinuální nahrávání

« kdy: 19. 03. 2025, 21:59:39 »

Este doplnim, ze detekciu objektov vobec riesit nepotrebujem, maximalne mozno jednoduchu detekciu pohybu a ani to nie na zaklade analyzy obrazu cez NVR, ale na zaklade detekcie priamo podporovanej kamerou

7

Software / NVR software pro IP kamery a kontinuální nahrávání

« kdy: 19. 03. 2025, 21:24:23 »

Caute, potrebujem radu ohladom NVR software (idealne open source resp. free), ktory by vedel kontinualne nahravat a prehravat online stream z kamier Hikvision v slucke ale bez nutnosti transcodingu. Transcodingu sa chcem vyhnut z dovodu obmedzeneho vykonu HW. Kamery maju nativnu podporu codecov AVC/+ a HEVC/+. Testoval som viacero alternativ, ale vsetky doteraz testovane povodny stream transcodovali na svoj vlastny vystup:

- Frigate
- MotionEye
- Shinobi

Dakujem za odporucania.

8

Sítě / Re:MikroTik mDNS: nefunguje video napříč VLAN

« kdy: 23. 02. 2025, 21:11:46 »

Kód: [Vybrat]

/interface list
add name=WAN
add name="LAN PORT"
add name=LAN
/interface list member
add interface=ether1 list=WAN
add interface=fix_vlan list=LAN
add interface=host_vlan list=LAN
add interface=media_vlan list=LAN
add interface=veci_vlan list=LAN
add interface=ether2 list="LAN PORT"
add interface=base_vlan list=LAN
add interface=nowan_vlan list=LAN

9

Sítě / Re:MikroTik mDNS: nefunguje video napříč VLAN

« kdy: 23. 02. 2025, 18:45:42 »

Caute chlapy,
sorry, ze zase ozivujem tuto temu, ale asi nie je vhodne stale zakladat nove temy, ked tak nech ma moderatori upozornia a zalozim novu. Stale mam problem s tlaciarnou (tiskarnou) a myslim si, ze problem bude vo firewalle, ale neviem kde, takze sem vyprintujem cely filter.
Situacia sa v podstate dotyka styroch vlan:

- base je management vlana, ktora ma pristup do celej LAN, teda do vsetkych vlan
- fix je vlana pre bezne domace zariadenia (PC, NTB, mobily). Docasny pristup do celej LAN
- host je vlana pre navstevy
- veci je IoT vlana, v ktorej je aj tlaciaren

z fix a host vlan je tlaciaren pristupna, ale zvlastne je, ze cez pravidlo 14, ktore by malo zabezpecit pristup z host vlan nepretekaju ziadne pakety a tlaciaren je pristupna aj po vypnuti toho pravidla. Tlaciaren nie je vobec pristupna z base vlany, ktora by mala mat pristup do celej LAN - pravidlo 9, takze na zaklade toho by mala byt pristupna aj tlaciaren:

Kód: [Vybrat]

Flags: X - disabled, I - invalid; D - dynamic
 0    chain=input action=accept connection-state=established,related

 1    chain=input action=accept in-interface=fix_vlan log=no log-prefix=""

 2    chain=input action=accept protocol=udp src-address-list=LAN_ip in-interface-list=LAN dst-port=5353 log=no log-prefix=""

 3    chain=input action=drop connection-state=invalid

 4    chain=input action=jump jump-target=WAN>INPUT in-interface-list=WAN log=no log-prefix=""

 5    chain=input action=drop log=yes

 6    chain=forward action=accept connection-state=established,related log=no log-prefix=""

 7    chain=forward action=accept protocol=udp src-address-list=LAN_ip dst-address-list=dns in-interface-list=LAN dst-port=53 log=no log-prefix=""

 8    chain=forward action=accept in-interface-list=LAN out-interface-list=WAN log=no log-prefix=""

 9    chain=forward action=accept in-interface=base_vlan out-interface-list=LAN log=no log-prefix=""

10    chain=forward action=accept in-interface=fix_vlan out-interface-list=LAN log=no log-prefix=""

11    chain=forward action=accept src-address-list=Bernardo out-interface-list=LAN log=no log-prefix=""

12    chain=forward action=accept protocol=tcp src-address-list=Budky_ip in-interface=media_vlan out-interface=fix_vlan dst-port=8008-8010 log=no log-prefix=""

13    chain=forward action=accept dst-address-list=NAS in-interface=media_vlan log=no log-prefix=""

14    ;;; Tlac_Host
      chain=forward action=accept dst-address-list=tlaciaren in-interface=host_vlan log=no log-prefix=""

15    ;;; DSTNAT
      chain=forward action=accept connection-nat-state=dstnat log=no log-prefix=""

16    chain=forward action=drop connection-state=invalid

17    chain=forward action=drop src-address-list=!base_ip in-interface=base_vlan log=no log-prefix=""

18    chain=forward action=drop src-address-list=!fix_ip in-interface=fix_vlan log=no log-prefix=""

19    chain=forward action=drop src-address-list=!media_ip in-interface=media_vlan log=no log-prefix=""

20    chain=forward action=drop src-address-list=!veci_ip in-interface=veci_vlan log=no log-prefix=""

21    chain=forward action=drop src-address-list=!nowan_ip in-interface=nowan_vlan log=no log-prefix=""

22    chain=forward action=drop src-address-list=!host_ip in-interface=host_vlan log=no log-prefix=""

23    chain=forward action=drop in-interface=host_vlan out-interface=fix_vlan log=no log-prefix=""

24    chain=forward action=drop in-interface=veci_vlan out-interface=fix_vlan log=no log-prefix=""

25    chain=forward action=drop in-interface=veci_vlan out-interface=host_vlan log=no log-prefix=""

26    chain=forward action=drop in-interface=veci_vlan out-interface=media_vlan log=no log-prefix=""

27    chain=forward action=drop in-interface=host_vlan out-interface=base_vlan log=no log-prefix=""

28    chain=forward action=drop dst-address-list=bogon log=yes log-prefix="bogon"

29    chain=forward action=drop log=no log-prefix=""

30    chain=WAN>INPUT action=drop log=no log-prefix=""

10

Server / Re:Proxmox: přiřazení více VLAN jednomu LXC kontejneru

« kdy: 18. 02. 2025, 22:16:55 »

myslite uplne samostatny bridge interface pre kazdu vlanu (napr. vmbr0, vmbr10, vmbr20...) alebo len sub-interface v ramci rovnakeho bridge pre kazdu vlanu (napr. vmbr0.10, vmbr0.20...) ?

11

Server / Proxmox: přiřazení více VLAN jednomu LXC kontejneru

« kdy: 18. 02. 2025, 15:40:10 »

Ahojte, mam nainstalovany Pihole LXC container cez Proxmox helper scripts a chcel by som, aby bol pihole clenom kazdej VLANy pretoze sa mi to zda byt "cistejsie" riesenie ako povolovat komunikaciu napriec vlanami na porte 53, ale nejako sa mi nedari nastavit interface pre kazdu VLANu, tak, aby to bolo nastavene len pre ten dany container.

Proxmox host interfaces:

Kód: [Vybrat]

auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet manual
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids (mgmt id,doma id,media id,host id,iot id)         # samozrejme ze id su ciselne a bez zatvorky

auto vmbr0.(mgmt id)
iface vmbr0.(mgmt id) inet static
        address proxmox.ip.mgmt.vlan/24
        gateway gateway.ip.mgmt.vlan

V ramci konfiguracie containeru sov v proxmoxe v detaile containeru na tabe Network pridal dalsi interface (veth), v ktorom som definoval bridge - vmbr0, nastavil som vlan doma id a definoval som staticku ip adresu mimo dhcp poolu pre pihole v ramci vlany doma a este vypnem firewall. Hned ako tieto nastavenia ulozim, tak webgui pihole prestane byt pristupny - connection time out. Vzdy ked vymazem ten novo pridany network interface, tak pihole sa znova spristupni cez jeho ip v mgmt vlan.
Odvodil som z toho, ze mozno samostatny network interface pre kazdu vlanu musi mat definovany aj samostatny bridge v /etc/network/interfaces ale potom by bol Proxmox ako taky pristupny zo vsetkych vlan a to samozrejme nechcem.

12

Sítě / Re:Nastavení a ověření DoH DNS na MikroTiku

« kdy: 12. 02. 2025, 11:22:47 »

Ako to myslis "pisat vlastny"? Technitium je uz napisany (hotovy) ak je to myslene z pohladu vyvojarov, ze je to ich vlastne riesenie, tak aj PiHole je vlastne riesenie tych yvojarov alebo nieco nechapem?

13

Sítě / Re:Nastavení a ověření DoH DNS na MikroTiku

« kdy: 12. 02. 2025, 10:51:25 »

Diky za tip na image PiHole/Unbound. Zo zaujimavosti som si zbezne pozrel aktualne alternativy voci PiHole a narazil som na Technitium - www.technitium.com/dns/ , ma s nim niekto skusenosti? Co si o tom myslite?

14

Sítě / Re:Nastavení a ověření DoH DNS na MikroTiku

« kdy: 11. 02. 2025, 16:35:58 »

ano, viem, ze, aby mal pihole nejaky vyznam tak potrebuje aj Unbound. Myslel som to tak, ze ked uz mam riesit Unbound tak spolu s nim uz rovno aj pihole a je to aj s akou-takou filtraciou reklamy. Islo by len o lokalne pouzivanie cize DoT resp. DoH by v tom pripade asi nemalo ziadnu pridanu hodnotu.

15

Sítě / Re:Nastavení a ověření DoH DNS na MikroTiku

« kdy: 11. 02. 2025, 08:48:30 »

No ako sledujem tu debatu, tak sa asi vykaslem na Mikrotik DNS a rozbeham radsej pihole pod proxmox. BTW: Preco by ste preferovali DoT pred DoH?