Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Rozległy monitoring IP z dużą ilością kamer

basman123 07 Dec 2012 15:32 9699 56
Optex
  • #31
    Pawel2420
    Level 31  
    Marek31415 wrote:
    Serwery FTP są wolne, bo administrator może ograniczyć łącze dla użytkownika. Sam protokół nie.

    Protokoły FTP, RTSP over TCP i HTTP opierają się na TCP. Przy większej ilości danych oferują identyczną prędkość transferu. RTSP over UDP może być nieco szybszy ale w tym wypadku trudno o obiektywne porównanie.
    Sytuacja jednak diametralnie się zmienia jeśli do przesłania jest mały plik np. obrazek jpeg o wielkości 25kB. Tak jak wspomniałem wcześniej kamera za każdym razem musi się zalogować. Typowe programy do FTP obsługują to bardzo wolno. Można oczywiście zastosować specjalizowany program, który będzie działał bez opóźnień. Tu masz całkowitą rację. Jednak nie tylko szybkość działania serwera decyduje o efektywności danego protokołu. Przy małych ilościach danych istotną rolę zaczyna odgrywać czas przesyłania pakietu IP w sieci. Zwykle wynosi on od kilku mS do kilkuset mS w rozległych sieciach. W przypadku FTP i RTSP na początku urządzenia wymieniają dane kontrolne. Działa to na zasadzie pytanie-odpowiedź. Każdy krok trwa min. tyle ile dwukrotny czas przesłania pakietu IP w danej sieci. W praktyce łącznie może uzbierać się tego nawet kilka sekund. W przypadku HTTP jest prościej. Wysyłane jest jednym ciągiem POST, nagłówek HTTP i dane obrazka. Serwer odsyła potwierdzenie i koniec. Tak więc dla małych porcji danych protokół HTTP może być kilka razy szybszy niż FTP.
  • Optex
  • #32
    Marek31415
    Level 31  
    Pawel2420 wrote:
    ... Tak więc dla małych porcji danych protokół HTTP może być kilka razy szybszy niż FTP.

    I to jest rozsądna wypowiedź. Ale w tym ostatnim zdaniu lekko przesadziłeś.
    Pojedyncza klatka jpg to plik ok. 40 - 200 kB. Małe porcje danych to poniżej 8 kB. Wtedy jest szansa, że pakiet nie będzie podzielony.
    Ale faktycznie, HTTP i komenda POST jest optymalnym rozwiązaniem. Wymaga co prawda dołączenia często niemałej sekcji HEAD. Tyle tylko, że kamery jej nie obsługują. Jeszcze lepszym rozwiązaniem jest wysyłanie obrazka przez TCP bez żadnych dodatków, czystej klatki (z detekcji ruchu). Taką funkcję spotkałem w przemysłowych kamerach sortujących. Widziałem coś podobnego w Axis-ach, ale nie sprawdzałem, jak to działa.

    I jeszcze jedna uwaga do FTP. Podejrzewam, że niektórzy zakładają negocjacje przy każdej klatce w jpg. Kamery Axis np. protokołem FTP wysyłają całe grupy klatek. W jednej sesji FTP po zalogowaniu wysyłane jest wszystko, co "uzbiera się" od poprzedniej sesji FTP.
  • #33
    Pawel2420
    Level 31  
    Marek31415 wrote:
    Ale faktycznie, HTTP i komenda POST jest optymalnym rozwiązaniem. Wymaga co prawda dołączenia często niemałej sekcji HEAD.

    Przy POST nie ma sekcji HEAD. Poza właściwymi danymi wystarczy wysłać tylko kilkadziesiąt dodatkowych bajtów zwierających adres skryptu i długość pola danych. Przy obrazkach o jednakowej rozdzielczości można zrezygnować również z nagłówka JPEG mającego zwykle długość nieco ponad 500 bajtów.
    Jeśli chodzi o ten rozległy monitoring z prędkością 1 fps to HTTP to moim zdaniem wydaje się najwygodniejsze. Działa w każdej sieci, Nie trzeba nic przekierowywać. Nie są potrzebne żadne wyrafinowane programy do odbierania danych. Centrum monitoringu można oprzeć na wydzierżawionych serwerach w jakieś firmie hostingowej. W przypadku ewentualnej awarii jeden ruch ręką i cały ruch jest przekierowany na zapasowy serwer. Klient nawet tego nie zauważy.
  • #34
    Marek31415
    Level 31  
    Pawel2420 wrote:
    Przy POST nie ma sekcji HEAD. Poza właściwymi danymi wystarczy wysłać tylko kilkadziesiąt dodatkowych bajtów zwierających adres skryptu i długość pola danych. ...
    Jeśli chodzi o ten rozległy monitoring z prędkością 1 fps to HTTP to moim zdaniem wydaje się najwygodniejsze. Działa w każdej sieci, ...

    Fakt, nie HEAD lecz nagłówek. Ale tu jest mały problem, z którym być może się nie spotkałeś. Pakiet z okrojonym nagłówkiem jest przesyłany bez problemu w sieci lokalnej. W sieci rozległej, szczególnie przy dostępie bezprzewodowym (np. sieci telefonii komórkowej) ten nagłówek jest kontrolowany i jeżeli jest niezgodny ze specyfikacją, często nie jest przepuszczany. Pakiet nie dociera do odbiorcy. Do prawidłowego nagłówka sieć dołączała swoje dane i rozrastał się do niemałych rozmiarów. Spotkałem się z tym przypadkiem kilka lat temu. Może teraz to już się zmieniło. Warto sprawdzić.
    Nie zmienia to faktu, że kamery tego nie obsługują a dokładanie dodatkowych urządzeń do każdej kamery jest problematyczne. Szczególnie na Androidzie i przy dużej ilości kamer w różnych lokalizacjach.
    Muszę jeszcze sprawdzić, czy Axis nie ma tej lub podobnej funkcji.
  • #35
    Pawel2420
    Level 31  
    Marek31415 wrote:
    Ale tu jest mały problem, z którym być może się nie spotkałeś. Pakiet z okrojonym nagłówkiem jest przesyłany bez problemu w sieci lokalnej. W sieci rozległej, szczególnie przy dostępie bezprzewodowym (np. sieci telefonii komórkowej) ten nagłówek jest kontrolowany i jeżeli jest niezgodny ze specyfikacją, często nie jest przepuszczany. Pakiet nie dociera do odbiorcy. Do prawidłowego nagłówka sieć dołączała swoje dane i rozrastał się do niemałych rozmiarów. Spotkałem się z tym przypadkiem kilka lat temu. Może teraz to już się zmieniło. Warto sprawdzić.

    Myślałem, że poza mną nikt tego nie zauważył. Zaobserwowałem jeszcze wiele innych niepojących działań. Wszytko to świadczy, że operatorzy analizują on-line przesyłane dane. Ludzie myślą, że ich przeglądarka łączy się ze wskazanym serwerem. Nic bardziej błędnego. Łączy się ona z serwerem operatora a ten nawiązuje oddzielne połączenie TCP ze wskazanym serwerem. Każdy się może o tym przekonać porównują to co wysyła PC i to co dochodzi do serwera.
    Zastanawiam się czy podobna sytuacja występuje w przypadku https i np. połączenia z bankiem.
    Nigdy jednak nie spotkałem się z sytuacją aby coś nie dochodziło. Mogę sobie jednak wyobrazić przypadek kiedy serwer np. dla bezpieczeństwa sprawdza pole User-Agent w nagłówku i odrzuca zapytania nie pochodzące z konkretnego urządzenia. Jeśli operator zmodyfikuje nagłówek to serwer wszystkie zapytania odrzuci.
  • #36
    Marek31415
    Level 31  
    Pawel2420 wrote:
    Myślałem, że poza mną nikt tego nie zauważył...

    Dorzucę jeszcze jedną ciekawą informację. Dotyczy przesyłanych dodatkowych danych w strumieniu obrazu. Analizując strumienie video przesyłane przez tanią chińską kamerę zauważyłem dziwne pakiety. Po zapisaniu na dysk i otwarciu notatnikiem pojawił się tekst wyświetlany znakami chińskiego alfabetu.
    Może te kamery są tak tanie, bo są dotowane przez... i spełniają dodatkowe funkcje, nieopisane w manualu?
    Niestety, nie pamiętam, czy miałem tę kamerę u siebie, czy podpiąłem się do kamery wystawionej w Internecie, jaka to była kamera.
  • #37
    wampirek
    Level 18  
    A robiliscie kiedys monitoring po gsm tj hsdpa, lte? to sie nie wystraszcie bo wam nie pójdzie ale mam na to sposób
  • #38
    Marek31415
    Level 31  
    wampirek wrote:
    A robiliscie kiedys monitoring po gsm tj hsdpa, lte? to sie nie wystraszcie bo wam nie pójdzie ale mam na to sposób

    Tak. Bez żadnego problemu. Jeszcze na hotspotach. Też działa.
  • Optex
  • #39
    wampirek
    Level 18  
    a jakim cudem wam to działa?

    Dodano po 2 [minuty]:

    w cyfrowym polsacie i w plusie jak przekierowalem porty z dvr to cp napisal ze blokuja porty z uwagi na prawdopodobne zakłucenia które moga wystapic w sieci.
  • #40
    Pawel2420
    Level 31  
    wampirek wrote:
    a jakim cudem wam to działa?

    Jest kilka rozwiązań pozwalających obejść wymieniony problem. Jednym z nich jest kamera, która nawiązuje połączenie z serwerem. Przeczytaj to co napisałem wcześniej o protokole HTTP.
    Możesz również skorzystać z tej aplikacji na tzw. urządzenia Android TV o jakiej tu wspominałem. Małe pudełeczko np. MK808 ma naprawdę duże możliwości.
    Tu jest strona na jakiej testuję taką transmisję przez coś takiego http://gsmcamera.pl/viewer_1.html
    Teraz co prawda dane nie są przesyłane przez GSM ale mogą być. Nie są potrzebne żadne specjalne karty SIM ani przekierowania portów.
  • #41
    mail4skwarka
    Level 19  
    Pawel2420:

    Koszalin z tej kamerki :) ?
  • #43
    mail4skwarka
    Level 19  
    Toczka w toczkę Koszalinem, no może u Nas więcej śniegu :)
  • #44
    wampirek
    Level 18  
    ja rozwiazalem to uzywajac istniejeacego juz servera na obiekcie przy pomocy hamachi i mam wypuszczona alarmowka integra 128 wrl oraz rejestrator dvr.
  • #45
    basman123
    Level 23  
    Pawel2420 wrote:
    wampirek wrote:
    a jakim cudem wam to działa?

    Jest kilka rozwiązań pozwalających obejść wymieniony problem. Jednym z nich jest kamera, która nawiązuje połączenie z serwerem. Przeczytaj to co napisałem wcześniej o protokole HTTP.
    Możesz również skorzystać z tej aplikacji na tzw. urządzenia Android TV o jakiej tu wspominałem. Małe pudełeczko np. MK808 ma naprawdę duże możliwości.
    Tu jest strona na jakiej testuję taką transmisję przez coś takiego http://gsmcamera.pl/viewer_1.html
    Teraz co prawda dane nie są przesyłane przez GSM ale mogą być. Nie są potrzebne żadne specjalne karty SIM ani przekierowania portów.


    A jak Ty tam kamerkę podłączyłeś, bo bardzo fajnie to wygląda, podasz jakieś bliższe informacje ? Co to za kamera itp?
  • #46
    Pawel2420
    Level 31  
    Aplikacja nie jest jeszcze skończona. Nie ma najważniejszej opcji czyli automatycznego startu po włączeniu zasilania. Dzięki temu całość staje się bezobsługowa. Nie jest potrzebny TV i klawiatura/myszka.
    Kamera to "LifeCam Studo HD" (około 250 zł). Można też użyć tańszej "LifeCam Cinema HD". Zapewne obsługiwanych będzie również wiele innych modeli. Urządzenia na jakich sprawdzałem rozwiązanie to MK808, UG802 i MX1.
    Jak znajdę trochę czasu zrobię jakiś opis na stronie http://www.tvandroid.pl/
  • #47
    Marek31415
    Level 31  
    Marek31415 wrote:
    Nie zmienia to faktu, że kamery tego nie obsługują a dokładanie dodatkowych urządzeń do każdej kamery jest problematyczne.

    Muszę sprostować własną wypowiedź. Obsługują, HTTP i POST, nie trzeba nic dokładać. Właśnie testuję funkcję wysyłania obrazu protokołem HTTP, komendą POST. Kamera Acti 1.3MPix. Na razie nie widzę jakiś szczególnych różnic w szybkości w porównaniu z protokołem FTP. Może dlatego, że testy są w sieci lokalnej.
  • #48
    Yca
    Level 20  
    Kolego basman123, widzę że nie rozważasz jednej, zdaje się dosyć istotnej rzeczy w przypadku monitoringu tj. gwarancji ze nagrania które mają zostać zarejestrowane faktycznie takie będą. Cała masa rzeczy może wpływać na brak połączeń z urządzeniem, nie mówiąc już o ewentualnym sabotażu.
    Bez rejestracji lokalnej w każdym z punktów ja bym sie takiej realizacji nie podjął. No chyba ze nie jest to niezbędne w twoim systemie.
    Co do ilości kilkuset kamer w punkcie centralnym to potrzebujesz kilku niezłych maszyn które to obsłużą.
    Rozwiązanie z FTP moim zdaniem to bardzo na piechote, nie mówiąc o póżniejszej pracy z takimi nagraniami.
  • #49
    Marek31415
    Level 31  
    Yca wrote:
    Co do ilości kilkuset kamer w punkcie centralnym to potrzebujesz kilku niezłych maszyn które to obsłużą.

    Założenie z pierwszego postu "maksymalnie kilka minut nagrania dziennie", jeżeli nie będzie to w tym samym czasie, to nie widzę problemu. Jeden komputer powinien wystarczyć. Dobrze by było, gdyby autor tematu odniósł się do tego.
    Yca wrote:

    Rozwiązanie z FTP moim zdaniem to bardzo na piechote, nie mówiąc o póżniejszej pracy z takimi nagraniami.

    Mowa była o programie monitoringu z wbudowanym emulatorem serwera FTP.
    Spełnione są wszystkie założenia profesjonalnego monitoringu. Nie ma problemu z pracą z takimi nagraniami, zapis strumieniowy tak jak z każdej kamery.
    Dla programu jest po prostu obojętny sposób pozyskania obrazu, czy klasyczny (w tym przypadku najlepiej z powiadomieniem o ruchu z kamery w celu oszczędzenia łącza i zasobów komputera) , gdzie to jest możliwe, czy protokołem FTP (ewentualnie HTTP POST) , tam gdzie sieć nie pozwala na dostęp z zewnątrz.
  • #50
    basman123
    Level 23  
    Marek31415 wrote:
    Yca wrote:
    Co do ilości kilkuset kamer w punkcie centralnym to potrzebujesz kilku niezłych maszyn które to obsłużą.

    Założenie z pierwszego postu "maksymalnie kilka minut nagrania dziennie", jeżeli nie będzie to w tym samym czasie, to nie widzę problemu. Jeden komputer powinien wystarczyć. Dobrze by było, gdyby autor tematu odniósł się do tego.
    Yca wrote:

    Rozwiązanie z FTP moim zdaniem to bardzo na piechote, nie mówiąc o póżniejszej pracy z takimi nagraniami.

    Mowa była o programie monitoringu z wbudowanym emulatorem serwera FTP.
    Spełnione są wszystkie założenia profesjonalnego monitoringu. Nie ma problemu z pracą z takimi nagraniami, zapis strumieniowy tak jak z każdej kamery.
    Dla programu jest po prostu obojętny sposób pozyskania obrazu, czy klasyczny (w tym przypadku najlepiej z powiadomieniem o ruchu z kamery w celu oszczędzenia łącza i zasobów komputera) , gdzie to jest możliwe, czy protokołem FTP (ewentualnie HTTP POST) , tam gdzie sieć nie pozwala na dostęp z zewnątrz.


    Ostatecznie po rozmowach zaproponowane zostało oprogramowanie Luxriot w wersji Enterprise zainstalowane na 3 serwerach (mocno nadmiarowo).
    W każdym punkcie jest bardzo słabe łącze (zapewne Neostrada z uploadem 256kbps). To minus, plusem jest fakt, że wszystkie lokalizacje są połączone z centralą VPNami.

    Jeżeli chodzi o zapis lokalny to zabezpieczeniem (jako takim mają być karty pamięci zamontowane wewnątrz kamer). Minusem jest oczywiście awaryjność takiej karty, plusem oczywiście cena (nie trzeba stawiać jakiegoś NASa).
    Zapis na kartę w pełnej jakości, wysyłka do centrali 4CIF - 1fps.

    Do podglądu dwie stacje robocze (Luxriot jest w architekturze klient-serwer).

    Taka jest wstępna oferta zobaczymy co z tego wyniknie.
  • #51
    Yca
    Level 20  
    A czy Luxriot spełnia wymagania co do obsługi FTP, czy dane video są zapisywane bezpośrednio ze strumienia?
    I czy w ogóle ktoś może wskazać takie oprogramowanie do monitoringu z emulacją FTP?
  • #52
    Marek31415
    Level 31  
    Yca wrote:
    A czy Luxriot spełnia wymagania co do obsługi FTP, czy dane video są zapisywane bezpośrednio ze strumienia?

    W opisie nic na ten temat nie znalazłem. Tylko współpraca z FTP. To oczywiście nie to samo.
    Yca wrote:

    I czy w ogóle ktoś może wskazać takie oprogramowanie do monitoringu z emulacją FTP?

    Oczywiście, Selcamnet. Sprawdzone m.in. w monitoringu budów.

    Inną sprawą jest odpowiedni dobór kamery. Większość kamer wysyła nie częściej niż 1 klatkę na minutę.

    basman123 wrote:
    W każdym punkcie jest bardzo słabe łącze (zapewne Neostrada z uploadem 256kbps). To minus, plusem jest fakt, że wszystkie lokalizacje są połączone z centralą VPNami.

    To masz duży problem. VPN na słabym łączu nie nadaje się do monitoringu.
    VPN zmniejsza drastycznie przepustowość i tak już słabego łącza. Niektóre źródła podają 10-o krotne zmniejszenie przepustowości.
    basman123 wrote:

    Do podglądu dwie stacje robocze (Luxriot jest w architekturze klient-serwer).

    Czyli w sumie 5 komputerów. Jestem w szoku. Przy założeniu kilku minut z każdej kamery na dobę?
    basman123 wrote:

    Taka jest wstępna oferta zobaczymy co z tego wyniknie.

    Przy monitoringu na taką ilość kamer masz tylko jedną ofertę, od jednego dostawcy?
  • #53
    basman123
    Level 23  
    Marek31415 wrote:
    Yca wrote:
    A czy Luxriot spełnia wymagania co do obsługi FTP, czy dane video są zapisywane bezpośrednio ze strumienia?

    W opisie nic na ten temat nie znalazłem. Tylko współpraca z FTP. To oczywiście nie to samo.
    Yca wrote:

    I czy w ogóle ktoś może wskazać takie oprogramowanie do monitoringu z emulacją FTP?

    Oczywiście, Selcamnet. Sprawdzone m.in. w monitoringu budów.

    Rozumiem Panie Marku, że Pana program jest najlepszy ale niestety jest za drogi :)

    Marek31415 wrote:

    Inną sprawą jest odpowiedni dobór kamery. Większość kamer wysyła nie częściej niż 1 klatkę na minutę.


    Zaproponowana kamera Zavio D5113 ma możliwość wysyłania częściej niż 1kl/min.

    Marek31415 wrote:

    Czyli w sumie 5 komputerów. Jestem w szoku. Przy założeniu kilku minut z każdej kamery na dobę?


    A dlaczego? Jeżeli brak tych nagrań i możliwości weryfikacji działań pewnych ludzi naraża firmę na kilkuset tysięczne straty to nadal jest Pan w szoku?
    Z dwiema stacjami roboczymi osobiście się nie zgadzam, ale to jest wymóg inwestora, który za to płaci, także nie będę się spierał.

    basman123 wrote:

    Taka jest wstępna oferta zobaczymy co z tego wyniknie.

    Przy monitoringu na taką ilość kamer masz tylko jedną ofertę, od jednego dostawcy?[/quote]

    Nigdzie nie napisałem, że mam jedną ofertę. Ofert było kilka ale po rozmowach wybrane zostały te elementy.
  • #54
    jpl
    Level 34  
    basman123 wrote:
    Zaproponowana kamera Zavio D5113 ma możliwość wysyłania częściej niż 1kl/min.


    To pytanie, widziałeś tą kamere w akcji ? Ile kosztuje?Jak się sprawuje w nocy? Lub przy słabym oświetleniu? Czy smuży?

    basman123 wrote:
    Czyli w sumie 5 komputerów.


    Ile na jednym komputerze będzie nagrywało się kamer? Przy założeniu 1kl/s, wg mnie spokojnie na corei5 powinno się nagrać kolo 70 kamer na kompa.

    basman123 wrote:

    Jeżeli chodzi o zapis lokalny to zabezpieczeniem (jako takim mają być karty pamięci zamontowane wewnątrz kamer). Minusem jest oczywiście awaryjność takiej karty, plusem oczywiście cena


    Czy kamera obsługuje możliwość zapisywania na karcie .jpg/avi w przypadku utraty komunikacji z serwerem? Spytaj się o to, są kamery które pingują serwery i jak serwer się nie odezwie, to wtedy kamera zaczyna nagrywać na kartę SD, Znacząco to zwiększa żywotność takiej karty.

    Co do samej kamery, producent bardzo stara się wprowadzić użytkownika w zamieszanie - na stronie głównej nie podaje wielkości przetwornika, a czułość podaje cudowną 0,001lx (wow).
    Po wejściu w kartę katalogową przetwornik okazuje się być 1/4" (co tłumaczy slaby kąt widzenia 80 stopni przy zaj*bistym obiektywie 2,7-9), oraz czułość przetwornika na poziomie 0,1lx (czyli już nie takie wow).

    Druga sprawa sprawdziłbym czy obraz jest równomiernie ostry, czasami w tanich kamerach dają słabe obiektywy i np po rogach albo połowa obrazu jest nieostra.

    Spytaj się dostawcę o bezpłatne dostarczenie kloszy.... Niestety po pewnym czasie czyszczenia czy nawet regulacji, jak zarysujesz klosz, to światło w diodach IR będzie się odbijać w tych rysach - a na kamerze będziesz widział duuuże białe mory.

    Polecam najpierw taką kamerę wziąć na warsztat i sprawdzić jej możliwości.
  • #55
    basman123
    Level 23  
    Kamera detalicznie kosztuje 1600 PLN (przy 1MPix) to nie jest niska cena.
    Kamerę widziałem w akcji i widzi całkiem fajnie.
    Osobny strumień będzie widoczny w sieci (zapewne 1kl/s, max 4CIF) a osobno będzie zapis na karcie (najlepsza jakość). Zawsze można zlecić wymianę kart po 2 latach :)

    Kamera ma promiennik podczerwieni także z widzeniem w nocy nie powinno być tak najgorzej (regulacja momentu w którym ma się włączyć).

    Według danych producenta oprogramowania na takim serwerze na i5 działa około 150 kamer (maksymalnie do 200 oczywiście samo nagrywania, absolutnie bez żadnego podglądu)
  • #56
    jpl
    Level 34  
    basman123 wrote:
    Kamera detalicznie kosztuje 1600 PLN (przy 1MPix) to nie jest niska cena.


    Cena wysoka.... nawet b. wysoka

    basman123 wrote:
    Osobny strumień będzie widoczny w sieci (zapewne 1kl/s, max 4CIF) a osobno będzie zapis na karcie (najlepsza jakość). Zawsze można zlecić wymianę kart po 2 latach :)


    To zrób tak jak mówiłem, że kamery tylko wtedy będą nagrywać jak padnie sieć LAN lub internet.... Pozatym karty SD jak są cały czas zapisywane to nawet roku nie wytrzymają.... CZasami po pół roku padają....

    basman123 wrote:
    Kamera ma promiennik podczerwieni także z widzeniem w nocy nie powinno być tak najgorzej (regulacja momentu w którym ma się włączyć).


    Wszystko świetnie, ale nie rozumiesz o co mi chodzi, ta kamera nie ma oddzielonego klosza obiektywu od klosza diód IR. W praktyce takie rozwiązanie jest bardzo czułe na wszelkie zarysowania, (przetarcia szmatką itp, sama instalacja). Generalnie na końcu może być tak że na wielu kamerach zobaczysz w nocy białe poświaty... których niczym nie zlikwidujesz, a tylko wymiana klosza pomoże.
    Dlatego nie wierz sprzedawcy że gumka na obiektywie pomoże :) Nie pomoże.
    Przy takiej ilości kamer domagaj się kloszy.... o zgrozo nawet jest to wymagane. Znając zavio i rynek IP - za rok może zavio skończyć robić tą kamerę, za dwa lata nie będzie do niej częście kloszy itp :)
  • #57
    Marek31415
    Level 31  
    basman123 wrote:
    Rozumiem Panie Marku, że Pana program jest najlepszy ale niestety jest za drogi...

    Nie wiem, czy najlepszy i nie wiem skąd informacja, że mój.
    I nie wiem, skąd informacja, że za drogi.
    Wiem natomiast, że nie było żadnego kontaktu z producentem i pytania o cenę.
    Przy takim monitoringu zawsze cenę się negocjuje. A może jest najtańszy?
    Nie liczyłbym na darmowe oprogramowanie dołączane do kamer.
    basman123 wrote:
    Zaproponowana kamera Zavio D5113 ma możliwość wysyłania częściej niż 1kl/min.

    Zalecałbym dużą ostrożność. Dokładnie tego modelu nie znam. Niektóre kamery Zavio lubią się wieszać. Problem rozwiązuje reset programowy co 24 godziny. Nie wszystkie programy mają tę funkcję. Proponuję wziąć kamerę do testów i dokładnie sprawdzić.
    basman123 wrote:
    A dlaczego? Jeżeli brak tych nagrań i możliwości weryfikacji działań pewnych ludzi naraża firmę na kilkuset tysięczne straty to nadal jest Pan w szoku?

    Tak, nadal, zwłaszcza w związku z tym pierwszym cytatem. Przy tak rozległym monitoringu i przewidywanymi łączami w miejscu lokalizacji kamer można założyć klatkę maksymalnie co kilka sekund. A wtedy jeden porządny komputer i7 spokojne obsłuży wszystkie kamery ze sporym zapasem. Można oczywiście dołożyć drugi do zdublowania systemu. Mam wrażenie, że oferta 3-ch maszyn wynika raczej z możliwości wybranego oprogramowania.
    Przy zastosowaniu funkcji przesyłania/pobierania obrazu dopiero po wykryciu ruchu i kontrolnych klatek co np. minutę łącze i komputer będą pracować na minimalnym obciążeniu. Jest to optymalne rozwiązanie przy rozległym monitoringu i chyba jedyne sensowne.