Rejestrator IP BCS czy KOUKAAM

Przymierzam sie do monitoringu. Docelowo do 8 kamer rozdzielczosc 1.3-2mpx.
Pod uwage biore dwa rejestratory

BCS-NVR3216 obsluguje do 16 kamer zaleznie od jakosci i ilosci klatek
- 16 kamer 1080P (1920x1080px) z prędkością 6 kl./sek.
- 16 kamer 720P (1280x720px) z prędkością 12 kl./sek.
- 16 kamer D1 (704x576px) z prędkością 25 kl./sek.
- 4 kamery 1080P (1920x1080px) z prędkością 25 kl./sek.
- 8 kamer 720P (1280x720px) z prędkością 25 kl./sek.
- 16 kamer D1 (704x576px) z prędkością 25 kl./sek.

oraz
Koukaam knr 200 do 8 kamer ip

BCS wydaje sie byc spawdzony, Koukaam ma ciekawy interfejs. Pytanie czy poradzi sobie sprawnie z taka iloscia kamer, bo na forum doczytalem ze czasem tnie. Druga kwestia to zgodnosc, kamery beda zgodne z Onvif, wiec teoretycznie powinny dzialac z Koukaam. Jaki z tych dwoch rejestratorow bardziej polecacie?

BCS obsługuje te rozdzielczości ale na papierze , knr200 do 4 można zastosować , do 8 to ryzyko. Sensowniej NUUO albo kompa, na i3 złożysz za 2 tyś. do tego linux + oprogramowanie np: exacq wersja start to 160 netto na kamere, a PRO to 450netto/kamere....

Poleasingowy Intel Core 2 Duo, HP lub Dell z legalnym Windows 7 kupisz za około 1000 zł.
Powinien spokojnie wystarczyć na te 8 kamer.

Po pierwsze musisz rozdzielić dwie rzeczy. Rejestrator BCS a kukukukam to są dwa zupełnie inne urządzenia.

Rejestrator BCS ma wyjście HDMI, na którym lokalnie możesz widzieć obraz z kamer tak jak się nagrywa, w wielu przypadkach jest to wymagane i pożądane.
Oczywiście możesz też łatwo i szybko odtwarzać obraz z kamer
Natomiast w knr200 wszystko robisz przez sieć, tzn obraz z kamer podglądasz przez sieć, odtwarzasz przez sieć itp. Czyi łątwiejszy jest napewno BCS.

Teraz strumień nagrywania, dobrze że chcesz 8 kamer, dla 8 kamer masz 32 mbit strumienia w rejestratorze BCS, czyli będzie dobrze nagrywał.
Natomiast kouukam tak jak kolega mały_smok napisał, 8 to już ryzyko.

Do BCS'a jeżeli podchodzisz, to żeby to najlepiej działało musisz kupić kamery od bcs'a, wtedy nie będzie ciąć itp.

Najlepszym rozwiązaniem komputer Ale wiadomo, czasami nie ma miejsca.

Ja też bym radził komputer, a jak szukasz oszczędności to np. jakiś niewielki desktop z Dual Corem i do tego soft - można postawić na darmowy dodawany do kamer, ale one różnie działają.
Idealnie - instalujesz Linuxa i kupujesz oprogramowanie ExacqVision. Cena to jakieś 45 USD za kamerę.

Co do Koukaama - tutaj możesz postawić te 8 kamer, jeśli chcesz uniknąć ryzyka o, którym mówią koledzy u góry - to stosujesz się do zaleceń, czyli nie przekraczaj 4 Mbitów na kanał, to spokojnie te 8 kamer uciągnie.
Osobiście Koukaama używam głownie do 1.3Mpixela, czasami dodaje 2 czy 3 kamery fullHD, ale zmniejszam im klatki tak do 8-10, działa bez zarzutu.

To co jeszcze warto powiedzieć, nie wiem jak w przypadku BCSa wygląda awaryjność, tutaj muszą wypowiedzieć się koledzy, ale w przypadku Koukaama, od początku roku, do naszego serwisu trafiły 2 sztuki (wada fabryczna w nowym modelu RACKowym), a sprzedajemy je dosłownie na taczki. W końcu czeska robota

maly_smok wrote:

BCS obsługuje te rozdzielczości ale na papierze

Zdziwił byś się.

Proponuję rejestrator Internec IP, model i7-N0716VH, do kupienia poniżej 2000 tys. Obsługuje do 16 kamer IP w rozdzielczości do 5Mpx, z odświeżaniem do 25kl/s. Ograniczeniem w tym urządzeniu jest całkowity strumień z kamer IP i wynosi 40Mbitów. Licząc ,że kamera 1,3Mpx przy 25kl./s potrzebuje ok. 4Mb/s /szt., kamera 2Mpx przy 12kl.s podobnie , możesz podłączyć do 10 takich kamer w pełnych parametrach.

Rejestrator ma wyjścia HDMI i VGA wyswietlają do rozdz. 1920x1080 i mogą pracować równocześnie i niezależnie. Wszystko można robić przez graficzne menu OSD sterowane myszką, w tym bardzo wydajne odtwarzanie z szybkim trybem x16. Generalnie obsługa tego urządzenia to rewelacja.

Oczywiście rejestrator można obsługiwać przez sieć - do dyspozycji jest 160Mb/s do połączeń klientów. Klient sieciowy na PC oferuje nowoczesny i funkcjonalny interfejs w j.polskim, klient na telefony też jest dostępny. Co ważne rejestrator obsługuje ,a kamery Internec dają 2 strumienie, więc jak masz słabe łącze Internetowe , to można podglądać w słabszej jakości/rozdzielczości, a nagrywa się w pełnej.

Co do kamer IP to rejestrator obsługuje ONVIF, PSIA a także można podłączyć kamery przez ręczne wpisanie ścieżki RTSP - w sumie rejestrator nagra dowolną kamerę IP MPEG4/H.264. Aczkolwiek pełną współpracę z wykorzystaniem wszystkich funkcji (jak. np. nagrywanie ciągłe z małą ilością klatek i przyspieszone po detekcji ruchu) uzyska się z kamerami Internec. Kamera ma być zewnętrzna to polecam 1280x960px i7-C1313D rewelacyjny obraz w nocy - najlepiej napisać do dystrybutora, podeślą nagrania. A do wewnątrz dobrym i tanim rozwiązaniem będzie 2Mpx i7-C2320 - wygląda niepozornie ale dobrze widzi i ma wymienny obiektyw.

Mam nadzieję, że pomogłem.

videocms wrote:

(...)Wszystko można robić przez graficzne menu OSD sterowane myszką (...) Generalnie obsługa tego urządzenia to rewelacja (...)
Oczywiście rejestrator można obsługiwać przez sieć (...) Klient sieciowy na PC oferuje nowoczesny i funkcjonalny interfejs (...)

Bez komentarza.

videocms wrote:

Proponuję rejestrator Internec IP, model i7-N0716VH, do kupienia poniżej 2000 tys. Obsługuje do 16 kamer IP w rozdzielczości do 5Mpx, z odświeżaniem do 25kl/s. Ograniczeniem w tym urządzeniu jest całkowity strumień z kamer IP i wynosi 40Mbitów.

40Mb/16kamer/25(kl/s)/8bitów = 0.0125 MB na 1 klatkę.
Czyli wychodzi średnio 12.5 kB na klatkę obrazu kamery 5MPix.
Ciekawe, co wtedy będzie widać?
Obsługuje, ale ma ograniczenia i niewiele pozostanie z obrazu.
Tak się klienta robi w ...

- treborsz
Oczywiście można się spierać o słowa. Świadomie napisałem 'rewelacja'. Z punktu widzenie użytkownika najważniejszy jest zawsze dostęp do nagrań. Na tym rejestratorze w dwóch kliknięciach myszką jest się w trybie odtwarzania kanału. Przejście obywa się natychmiastowo, w przeciwieństwie do wielu systemów postawionych na PC pod Windows, szczególnie na zbyt słabych PC. Odtwarza płynnie w przód i wstecz, z dużymi prędkościami, pozwala dodawać własne znaczniki, żeby później szybko dotrzeć do nagrania. Odtwarzanie w podziale również odbywa się sprawnie zasoby są dostosowane do odtwarzania do 8 kamer 2Mpx.
Archiwizacja -backup na pendriva- sprowadza się do zaznaczenie początku i końca na pasku w trakcie odtwarzania i kliknięcia ikony. Nagrania można odtwarzać na PC bez problemu, gdyż w trakcie archiwizacji dołączany jest plik playera.

A co do klienta sieciowego polecam zainstalowanie i zapoznanie się, a dopiero wtedy komentarz. Interfejs jest nowoczesny - bynajmniej nie przypomina ikon z Windowsa 3.1 , oraz funkcjonalny tzn. oferuje zestaw funkcji, dzięki którym obsługa systemu IP przez sieć jest po prostu wygodna. Dla użytkownika np. stosując grupy można jednym kliknięciem uruchomić podgląd z wielu dowolnych kamer, z różnych obiektów,a ekran automatycznie dostosuje tryb podziału. W panelu podglądu można przechodzić do trybu odtwarzania w wybranym(ch) oknach, a pozostałe mieć w podglądzie na żywo - niby nic, ale sprawdzenie co było 5 minut temu nagrane zajmuje kilka sekund.
Program bazuje na oknach, można dowolnie otwierać okna podglądu , odtwarzania , konfiguracji itp. Mając wiele monitorów podłączonych do PC, okna można rozmieścić na różnych monitorach uzyskując np. podgląd na 4 monitorach.
A dla instalatora program oferuje dostęp do konfiguracji wszystkich funkcji dla wszystkich urządzeń IP Internec.

Dodano po 13 [minuty]:

-Marek31415
A czy ja napisałem, że obsłuży 16 kamer 5Mpx 25kl.s jednocześnie? Należy to czytać jako maks.16 kamer IP, maks. rozdzielczość jaka obsługuje 5Mpx, maksymalna ilosc klatek jaka obsługuje to 25. Nadrzędnym ograniczeniem jest całkowity strumień danych z kamer IP 40Mb/s.
(tak przy okazji jaki model oferuje 5Mpx 25kl.s ?)

Pulse555 pytał o 8 kamer 2Mpx/ 1,3Mpx i taki przypadek opisałem, liczę 4Mb/s dla kamery z kompresją H.264 - dla tego przypadku rejestrator jest odpowiedni.

@videocms, zacytowane przeze mnie słowa stosuje każdy dostawca (dystrybutor, producent).
Twój wpis traktuję jako czysty chwyt marketingowy na Forum Technicznym. Tym bardziej, że był to Twój pierwszy wpis.

Przy okazji - przyznam się, że ciężko by mi było znaleźć interfejsy "nienowoczesne" ("przypominające ikony z Windowsa 3.1"). Może mi w tym pomożesz?

Kolego pulse555
Czy poza tym że obraz ma być rejestrowany ma Kolega jakieś sprecyzowane wymagania pod kątem funkcjonalności systemu ?. Zapis można od biedy zrealizować nawet na dysku sieciowym NAS - do kupienia już za kilkaset złotych, ale zarządzanie sygnałem będzie mocno "kulawe".
Czy wybrane już zostały jakieś konkretne modele kamer ?
Parametry strumieni o których piszą Koledzy na forum nie są krytyczne (przy dobrej jakości i 1080p rzeczywiście potrzeba nieco ponad 4 MBps na kamerę do zapisu), ponadto czy naprawdę istnieje potrzeba rejestracji 25 kl/s@Full HD z każdej kamery ? - ilość danych (w większości niepotrzebnych) ogromna a na to co istotne i tak zapewne braknie miejsca, przy 1080p i 25 kl/sek potrzeba na zapis z 1 kamery przez 24 h około 44 GB (8 kamer to już prawie 400 GB)

Zobacz sobie GUI AVTECHa, AVH306/312.

Jeżeli chodzi o skuteczne zmiejszenie ilości danych przy jednoczesnym zachowaniu jakości w chwilach najważniejszych, czyli wtedy 'gdy się coś dzieję' Internec ma rozwiązanie. Ustawia się nagrywanie ciągłe tzw. strumień normalny np. 1-2 kl.s/s (w 2Mpx poniżej 1Mb/s wystarczy), oprócz tego ustawia się tzw. strumień zdarzeń czyli parametry nagrywania po alarmie (np. z detekcji ruchu) na pełną jakość. Definiuje się pola detekcji i czułość. System zachowa się tak: nagranie będzie cały czas z 1-2kls./s, (czyli uniknie się sytuacji, gdy nagrywając tylko z detekcji może nie być żadnych nagrań gdy ustawiona jest zbyt mała czułość), a w sytuacjach gdy aktywował się alarm z detekcji ruchu nagrania będą płynne. 2 zalety: oszczędność dysku oraz sprawniejsze odtwarzanie, szczególnie przez klienta sieciowego (bo mniejsza ilość danych jest przesyłana, a dekodowana na PC mniejsza liczba klatek mniej obciąża CPU).

Cóż, według mojej wiedzy AVTECH nie jest zdecydowanym faworytem większości instalatorów czy użytkowników. Ale może się mylę?

Ciekawi mnie, jak się ma skuteczne zmiejszenie ilości danych przy jednoczesnym zachowaniu jakości w przypadku, gdy podgląd obrazu musi być udostępniony w trybie na żywo, i to najlepiej z dobrym odświeżaniem.
Bazując na bardzo ułomnej detekcji ruchu (źródło bardzo wielu fałszywych alarmów) w celu zmniejszenia ilości danych w przypadku zmian w treści obrazowej jest według mnie nieefektywne.
Dlaczego?

Dobrze zaimplementowane algorytmy kompresji (kodery hybrydowe z kompensacja ruchu, czyli np. H.264) w przypadku braku zmian w treści obrazowej "przesyłają", oprócz klatek bazowych (kluczowych) znikome ilości informacji: wektory ruchu (przestrzenne przesunięcie, jakie wykonuje dany blok przy zmianie obrazu) plus błędy predykcji (obliczona różnica pomiędzy odpowiednimi pikselami bloków porównywanych). Zatem praktycznie nie ma znaczenia, czy przesyłamy 25 obrazów na sekundę, czy dwa obrazy na sekundę.
W przypadku wystąpienia zmian w treści obrazowej, jeśli koder nie jest w stanie odnaleźć najbardziej podobnego bloku w obrazie odniesienia – dany blok jest i tak kodowany jest w całości. Przy transmisji VBR zwiększa się przez to automatycznie wielkość strumienia (w porównaniu do obrazu bez zmian). Nie widzę zatem powodów dla gloryfikowania oczywistego działania matematycznego (zdefiniowanego w standardzie) jako niespotykaną lub unikatową funkcję w danym rozwiązaniu.

Nie wiem czy jest obecnie faworytem AVTECH, jednak jak sięgnąć wstecz z 4-5 lata to był przełomem w analogowych DVR jeżeli chodzi o cenę / wydajność.

Zgadzam się, na żywo będzie 1-2kl.s a po detekcji płynnie. Lecz 1.nie wiemy czy ktoś będzie to cały czas oglądał u -Pulse555
2.skoro nie dzieje się nic to można zaakceptować poklatkowość, co więcej zwiększenie płynności może zwracać uwagę obserwatora.

Zgadzam się, że detekcja zmian w obrazie - zwana nieprecyzyjnie detekcją ruchu - bywa nieefektywna. Aczkolwiek nie jest to funkcja, które nie działa w ogóle. W scenach z oświetleniem dziennym przy obiektach, które na obrazie osiągają wielkość 2-4 pól siatki detekcji (siatka 22x18pól) detekcja działa bez zarzutów. Największym problemem jest zaszumiony obraz przy słabym oświetleniu - wtedy rzeczywiście nie da się ustawić optymalnie czułości algorytmu. W takim przypadku sprawdzają się tylko kamery z redukcją szumów tzw. 3D jak np. w modelu 1313D. Podsumowując - nawet jak detekcja nie będzie w 100% precyzyjna i tak uzyskamy oszczędność.

Co do algorytmu H264, proszę sobie ustawić 25kl.s, HD1080, VBR na swojej kamerze, ograniczyć z góry do tych 4Mbps i podejrzeć jaki strumień generuje dla obrazu statycznego. Z pewnością nie będzie to 1Mbps tylko znacznie więcej.
A wynika to z faktu, że nawet gdy nam się wydaje że to jest to obraz statyczny (i dla algorytmu detekcji jest statyczny), dla algorytmu kompresji zmiany w poszczególnych blokach danych występują (szumy niedoświetlonych fragmentów, krawędzie obrazu itp.)

Jeżeli poświęci się trochę czasu na prawidłową konfigurację systemu, opisana funkcja 'przyspieszenia w detekcji' ma znaczenie praktyczne. Obok wcześniej 1. i 2. jest jeszcze 3. - wyszukiwanie nagrań po alarmach, czego już -treborsz bazując 'na algorytmie' z pewnością nie uzyska.

Cóż, na temat praktycznego wykorzystania wszelkiego typu detekcji ruchu (zmiana kontrastu w treści obrazowej) lepiej, aby wypowiadali się praktycy niż handlowcy/marketingowcy. Sugestie, że detekcja ruchu może osiągać poziom bliski 100% (cytat: "nawet jak detekcja nie będzie w 100% precyzyjna i tak uzyskamy oszczędność") uważam za podświadome wprowadzanie w błąd. Nie znam prostych systemów analizy zmian kontrastu, które by było "odporne" na fałszywe alarmy: refleksy świetlne (szczególnie w nocy, dodatkowo przy scenach słabo oświetlonych), ruch w scenie nie spowodowany żadnym zdarzeniem alarmowym (szczególnie wtedy, gdy scena jest ustawiona dla obiektywu szerokokątnego), itd.

videocms wrote:

skoro nie dzieje się nic to można zaakceptować poklatkowość, co więcej zwiększenie płynności może zwracać uwagę obserwatora.

Proszę przeczytać mój poprzedni wpis. Nowoczesne i prawidłowo zaimplementowane rozwiązania nie potrzebują stosowania "trików" w celu osiągnięcia oczywistej funkcjonalności.

videocms wrote:

Co do algorytmu H264, proszę sobie ustawić 25kl.s, HD1080, VBR na swojej kamerze, ograniczyć z góry do tych 4Mbps i podejrzeć jaki strumień generuje dla obrazu statycznego. Z pewnością nie będzie to 1Mbps tylko znacznie więcej.

W przypadku algorytmu H.264 strumień danych zależy od wielu zmiennych. Obraz o większej ilości szczegółów generuje większy strumień. Mniejsza kompresja (lepsza jakość) - także większy strumień. W dobrze zaimplementowanym kodeku cała "para" idzie w obraz kluczowy kodowany wewnątrz-obrazowo.
A z drugiej strony - w przypadku sieci lokalnej strumień 4Mb/s nie ma żadnego znaczenia; w przypadku sieci rozległej (Internet) 1Mbs to w naszych warunkach przeszkoda nie do przeskoczenia w wielu aplikacjach. Dlatego w takim przypadku wiele nowoczesnych (i tu według mnie pasuje to słowo) rozwiązań bazuje na dynamicznym przełączaniu strumieni.

videocms wrote:

nawet gdy nam się wydaje że to jest to obraz statyczny (i dla algorytmu detekcji jest statyczny), dla algorytmu kompresji zmiany w poszczególnych blokach danych występują (szumy niedoświetlonych fragmentów, krawędzie obrazu itp.)

To może kilka słów o wybranych unikalnych cechach kodeka H.264 (nie oznacza to, że te cechy występują w kodekach implementowanych w "ekonomicznych rozwiązaniach):
- zawansowana predykcja międzyobrazowa z wieloma obrazami odniesienia (więcej niż jeden obraz odniesienia),
- adaptacyjny podział makrobloków na bloki o mniejszym rozmiarze podczas kodowania międzyobrazowego – siedem różnych rozmiarów bloku (16×16, 16×8, 8×16, 8×8, 8×4, 4×8 i 4×4 próbek luminancji na blok),
- wektory ruchu o dokładności 1/4 lub 1/8 odstępu próbkowania (chrominancja),
- transformata całkowitoliczbowa błędów predykcji w blokach o rozmiarze 4×4 próbki,
- ...
Ciekawe, jak sobie radzi w takim przypadku detekcja ruchu (skoro obraz dla detekcji ruchu też "jest statyczny")?

videocms wrote:

(...) wyszukiwanie nagrań po alarmach, czego już -treborsz bazując 'na algorytmie' z pewnością nie uzyska.

Co ma piernik do wiatraka? Co ma lista zdarzeń alarmowych do algorytmu kompresji? Poza tym - nie spotkałem się w ciągu ostatnich lat z systemem rejestracji, który nie posiadałby możliwości przeszukiwania archiwum według rejestru zdarzeń.

I jeszcze wracając do płynności obrazu dla obserwatora: jeśli system jest "bezobsługowy" - można sobie pozwolić na odświeżanie 1-2 obr./s. Jeśli natomiast operator chciałby "podejrzeć" obraz na żywo, nawet przez kilka minut dziennie - takie rozwiązanie jest nie do zaakceptowania przez większość moich dotychczasowych klientów.

Przytoczona funkcjonalność, która przypomnę zwiększa ilość klatek po detekcji ruchu,( ściśle detekcji zmian w obrazie) względem zapisywanej mniejszej ilości w trybie ciągłym-bez alarmu, została przeze mnie przytoczona jako sposób na zmiejszenie ilości zapisywanych danych. O dużej ilości danych pisał -Reeltime. System daje taką możliwość, a znając jej zalety i mankamenty można skorzystać lub nie.

Do treborsz -
-aluzję o handlowcach pozostawię bez komentarza
-jestem pod wrażeniem Twojej wiedzy na temat kompresji , jednakże proszę o odpowiedź jaki strumień generuje kamera, którą stosujesz w podanych w poprzednim poście warunkach. Jest to kluczowe do rozważenia czy rzeczywiście bazując tylko na właściwościach kompresji i zapisując pełną liczbę klatek cały czas, osiągniesz taką oszczędność dysku jak w przypadku dynamicznej zmiany liczby klatek (i narzuconego maksymalnego strumienia).

A jeżeli chodzi o wspomnianą transmisję przez Internet, na ten temat się nie wypowiadałem wcześniej. Obok opisywanego strumienia do zapisu, rejestrator (i kamery) mają strumień pomocniczy, który można ustawić niezależnie od nagrywania, odpowiednio do łącza.

videocms wrote:

-Marek31415
A czy ja napisałem, że obsłuży 16 kamer 5Mpx 25kl.s jednocześnie? Należy to czytać jako maks.16 kamer IP, maks. rozdzielczość jaka obsługuje 5Mpx, maksymalna ilosc klatek jaka obsługuje to 25. Nadrzędnym ograniczeniem jest całkowity strumień danych z kamer IP 40Mb/s.

Właśnie tak napisałeś, nie użyłeś słowa "jednocześnie" lecz magiczne "do".
Większość osób tak to zrozumie.
Nie wszyscy wiedzą, że termin "do" oznacza parametry faktycznie nieosiągalne.
Napisałeś, że ograniczeniem jest wielkość maksymalnego strumienia z kamer IP.
I to też nieprawda. Czy można podłączyć powyżej 16-u kamer?
Oczywiście nie, bo rejestrator jest na 16-e kamer.
A dlaczego? Bo taka jest polityka producenta.
Przy komputerach nie ma tego problemu. Podłączasz tyle kamer, ile "udźwignie" sprzęt.

videocms wrote:

Jest to kluczowe do rozważenia czy rzeczywiście bazując tylko na właściwościach kompresji i zapisując pełną liczbę klatek cały czas, osiągniesz taką oszczędność dysku jak w przypadku dynamicznej zmiany liczby klatek (i narzuconego maksymalnego strumienia).

Największą oszczędność miejsca na dysku daje zapis z dobrą detekcją ruchu i redukcją klatek.
Większość rejestratorów, z uwagi na kiepskie procesory, nie wykorzystuje tej możliwości.
Potrafią tylko zapisać strumień, który prześle im kamera.
Nie ma mowy o przekodowaniu strumienia, wyrzuceniu zbędnych klatek.
Kodek h.264 nie daje takich możliwości bez przekodowania.
Stąd próby przerzucenia analizy do kamer i jakieś pseudo-oszczędzające funkcje analizy i redukcji.

videocms wrote:

proszę o odpowiedź jaki strumień generuje kamera, którą stosujesz w podanych w poprzednim poście warunkach. Jest to kluczowe do rozważenia czy rzeczywiście bazując tylko na właściwościach kompresji i zapisując pełną liczbę klatek cały czas, osiągniesz taką oszczędność dysku jak w przypadku dynamicznej zmiany liczby klatek (i narzuconego maksymalnego strumienia).

A podałem w poprzednim poście jakieś warunki?
Właściwości kompresji są zależne od zastosowanego w danym rozwiązaniu (np. kamerze) kodeka (i jego implementacji). Magiczne słowo "h.264" nie jest rozwiązaniem samym w sobie.

Radzę Ci jednak wrócić do Twojego pierwszego wpisu i przeczytać go jeszcze raz dokładnie. Zamiast opisywać (przepisywać?) wybrane fragmenty opisujące rewelacyjne funkcje wystarczyło wstawić link dając szansę czytelnikowi do zapoznania się z tym.

-treborsz
W pierwszym poście zaproponowałem urządzenie adekwatne do wymagań użytkownika skupiając się na podstawowych opcjach.

-Marek31415
w przypadku Internec IP detekcja ruchu jest funkcją kamery IP, rejestrator 'współpracując' z kamerą jest w stanie
1. otrzymywać i przetwarzać informację o alarmie
2. dynamicznie zmieniać parametry kodowania

videocms wrote:

-Marek31415
w przypadku Internec IP detekcja ruchu jest funkcją kamery IP,

A co ja napisałem w ostatnim zdaniu?

videocms wrote:

rejestrator 'współpracując' z kamerą jest w stanie
1. otrzymywać i przetwarzać informację o alarmie
2. dynamicznie zmieniać parametry kodowania

W porównaniu z systemami opartymi na komputerze rzeczywiście niewiele.

Rzeczywiście rejestrator zapisuje strumień jaki przygotuje kamera - takie rozwiązanie jest stosowane powszechnie umożliwiając sprawną rejestrację. Dynamiczna zmiana parametrów strumienia z kamery to ulepszenie, dzięki któremu uzyskuje się funkcjonalność wspomnianej redukcji klatek, bez potrzeby 'przekodowania'.
Dlaczego 'przekodowanie' na rejestratorze PC jest lepszym rozwiązaniem, skoro wymaga większych mocy obliczeniowych i jest bardziej skomplikowane, a w konsekwencji statystycznie mniej odporne na błędy?

Cytując 'w porównaniu z systemami opartymi na komputerze ... ' rejestrator jest mały, cichy, pobiera mniej prądu, zapewnia stabilną pracę, ma wbudowane wejścia i wyjścia alarmowe (np. utratę połączenia z kamerą można przekazać przez wyjście do systemu alarmowego, powiadomienia GSM), ma wbudowaną diagnostykę dysków SMART, konfigurację i dostęp do nagrań można w pełni zabezpieczyć hasłem i użytkownik nie 'namiesza' np. formatując partycję , nie będzie służył obsłudze do korzystania z Internetu zamiast obserwacji, .. i jest tańszy uwzględniając ceny mocnego PC + licencji oprogramowania.

videocms wrote:

Dynamiczna zmiana parametrów strumienia z kamery to ulepszenie, dzięki któremu uzyskuje się funkcjonalność wspomnianej redukcji klatek, bez potrzeby 'przekodowania'.

Dobre systemy nie potrzebują stosowania redukcji klatek czy "przekodowania" (dekompresji, obróbki i ponownej kompresji).
Dzięki wsparciu dla kodeka H.264 SVC istnieje możliwość próbkowania w dół (downsample) i skalowania strumieni wideo bez dekompresji (optymalizacja sprzętu klienckiego i zmniejszenie obciążenia sieci w kierunku klienckim).
Coraz więcej producentów implementuje to rozwiązanie - jednak jak zauważyłem - wyłącznie z "wyższej" półki.

Witam.
Ja zapytam, jaki program do odtwarzania plików 264.
Ściągnąłem już kilka programów, ale nie odtworzyło mi pliku.
Jedynie co to AllConverter radzi sobie koncertując na "pospolity" format (mpg, avi ...)
ALe chodzi mi o konkretny program do odtwarzania tego rodzaju pliku. Zaznaczam, że jest to rozszerzenie *.264

Rejestrator zapisuje pod tą nazwą: ch01-2013-03-23_11-36-01_11-38-00.264

Właściwości pliku:

@UP
A z jakiego to rejestratora? Producent softu/rejestratorów zazwyczaj dostarcza "swój" player do odtwarzania i konwertowania plików z nagraniami. Więc poszukaj na jego stronie.

Skoro już odświeżyli ten temat to wrzucę jedną uwagę.
W sumie też nie miałem zaufania do Koukaama przy większej ilości kamer, dlatego poświęciłem ostatnie 3 tygodnie na testy wydajnościowe.
Bardzo fajnie spisują się te KNR-1004 i KNR-1008 - aż dziwne że takie maleństwo potrafi udźwignąć takie obciążenie.

Testowałem kamery:
4x FullHD 30fps
2x FullHD 15fps
1x 3.1 Mpixel 15fps
1x 5.0 Mpixel 15 fps

i obciążenie procesora Koukaama nie przekroczyło 80%
O testach można przeczytać tutaj:
http://cctvnerd.blogspot.com/

Tak samo z KNR-206, model do 16 kamer.
Podpiąłem 8 kamer 5.0 Mpixel, 15fps, H.264, stały bitrate na poziomie 6Mbitów/kamera. Zajętość procesora nie przekroczyła 40%.
Przy 16 kamerach FullHD, 15fps, zajętość na poziomie 60-70%

Model KNR-5016 który ma teoretycznie przepustowość 64Mbps upchnałem do poziomu 86 Mbitów i miał zajętość procesora w zakresie 89%. Trochę dużo, ale przekroczenie przepustowości prawie o 50%.

Myślę, że wydajność jest dlatego taka duża, bo nie mają lokalnego wyświetlania, więc do miejsc gdzie siedzi ochrona trzeba dać dosyć mocną jednostkę kliencką.
Ale w szkołach, sklepach, magazynach, gdzie najważniejsze są nagrania, myślę że zdały by egzamin.
Tak więc zadziwiające, ale nie są takie złe te czeskie urządzenia.

Jeśli ktoś jest zainteresowany screenami z testów zapraszam na priw, żeby tutaj bałaganu nie robić.

Informację o "konkretnym programie do odtwarzania tego rodzaju pliku" uzyskasz podając konkretny model rejestratora (być może konieczne będzie także podanie producenta).
Edit: Upss.. Niepotrzebnie zdublowałem odpowiedź (Korgoth był szybszy).

Napisałem już do działu technicznego dystrybutora firmy VIDILINE - jak będę miał program/odtwarzacz - zamieszczę go tutaj

A rejestrator to dokładnie VIDILINE DVR318

Witam,

a nie lepszym rozwiązaniem zamiast bcs nvr3216 było by kupienie jakiegoś poleasingowego dell'a ?

Otóż obecnie będę zakładał monitoring na swoim budynku

Firma zaoferowała mi właśnie ten rejestrator, lecz nie wiem czy po podłączeniu 16 kamer (docelowo) jakość będzie do czegokolwiek się nadawała.

Zaproponowali kamery:
4 kamery zewnętrzne http://www.eltrox.pl/kamera-ip-bcstip1130ir-13mpix-onvif-p-6375.html
1 kamera wewnętrzna http://www.eltrox.pl/kamera-sieciowa-ip-13-mpx-bcsdpip1130-onvif-p-6275.html
3 kamery wewnętrzne z regulowanym obiektywem http://www.eltrox.pl/kamera-ip-samsung-snb5001p-13-mpix-onvif-720p-hd-poe-p-6278.html + http://www.eltrox.pl/obiektyw-megapixelowy-2812mm-ir-f14-ai-p-4409.html

Miałbym jeszcze pytanie, czy ewentualnie kupując jakiegoś delika do każdej kamery musiałbym posiadać inny soft ? oraz co musiałbym ewentualnie zrobić, aby móc jeszcze nagrywać dźwięk ?