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.