W dniu 09.11.2023 o 00:22, Marcin Debowski pisze:
> To jest przeszkoda dla przeciętnego uzytkownika, ale nie dla biegłego.
> Jesli dane są na dysku to można je odczytac. W przypadku niezamknietego
> pliku nie powinno być z tym żadnego problemu.

Nie będę się przepychał, bo ja tych urządzeń nie konstruuję. Natomaist
takie różne systemy zapisu są faktem i tyle. Czemu się je stosuje, to
już nie będę dywagował.
--
(~) Robert Tomasik

do góry

W dniu 09.11.2023 o 00:58, Marcin Debowski pisze:
> Cudów nie ma, ze przy określonej kompresji nagle ma się więcej danych.

To nie tak. Powiedzmy na dysku masz zdjęcia w rozdzielczości 1920 x 1080
pikseli. Rejestrator zrzuca to do rozdzielczości 640 x 480 pikseli. Jak
sobie zgrasz film, to z niego możesz wyciągnąć zdjęcie w rozdzielczości
640 x 480 pikseli. Ale jak wyciągniesz fotkę z nośnika to dostaniesz
1920 x 1080. I czasem to pozwala na odczytanie numeru rejestracyjnego,
podczas gdy z klatki 640 x 480 nie odczytasz. No już prościej nie potrafię.

W praktyce ja to robię tak, że zgrywam filmik i go analizuję. Potem, jak
już znajdę moment, który ma znaczenie, to wracam do rejestratora i
zgrywam ten okres do obrazków. Nie każdy rejestrator na to pozwala, ale
ja ne twierdzę, że wszystkie tak robią. Po prostu warto o tym pamiętać.
U nas spotyka się rejestratory sprzed kilkunastu lat, które pracują.
--
(~) Robert Tomasik

do góry

W dniu 09.11.2023 o 01:13, J.F pisze:
>> O ile są na dysku to nie powinno z tym być problemu.
> dane gdzies są na dysku, ale jak system niepoprawnie zamknięty, to nie
> wiadomo gdzie ...

Rejestratory umieszczają na klatce dane o czasie. Jak rozsypie się
informacja o tym, która klatka z kiedy jest, to jeszcze można właśnie to
analizować programem do analizy nośników. On przy pomocy OCR buduje
bazę, a nadto przeważnie masz czas zapisania pliku - o ile zegar ktoś w
ogóle reguluje. No i da sie z czegoś takiego wyciągnąć klatkę.
--
(~) Robert Tomasik

do góry

W dniu 09.11.2023 o 00:47, Marcin Debowski pisze:
>> System operacyjny powinien miec narzędzia pozwalające na zamknięcie
>> pliku po awarii, ale oczywiscie koncówka może zniknąć, a w tym
>> przypadku moze to byc dosc istotne - zeby np zdążyło sie zapisać
>> kto wyłączył zasilanie ?
> Jest darmowe oprogramowanie odzyskujące różne funkcjonalne pliki bez
> udziału systemu plików. Szuka po nagłowkach i metadanych tych plików.

Ja do tego AUTOPSY używam.
>
>> Mozna sie tez zabezpieczyc na inne sposoby - np alokujemy miejsce
>> dla kolejnych danych w pliku, zapisujemy wszystkie systemowe dane,
>> a potem tylko wpisujemy dane video.
>> Pomysł raczej na dyski magnetyczne, bo flashe maja swoje inne narowy
>> .. szczególnie, ze w tym "twoim" pomysle jest to samo ryzyko - dane z
> Wystarczy niebuforować operacji dyskowych. Zarżnie się tak pewnie dysk,
> ale więcej ocaleje. Z tym, że jakieś bufory nadal będą, bo operacje na
> tych danej wcześniej są wykonywane.

Tylko ja na to nie mam wpływu. Mam, co mam.
>
>> wszyskich klatek będą na dysku, ale zabraknie wpisów o tych plikach.
> Tak jak to opisujesz to problem jest MZ w buforze. Na tyle się na tym
> nie znam, żeby wiedziec jak dokładnie zapisywane są na dysku dane o
> alokacji plików (co niewatpliwie zalezy tez od konkretnego systemu
> plików), ale system siłą rzeczy musi to wiedzieć już przed zapisem.
> Kwestia tylko taka, czy metadane systemu plików są zapisywane przed
> zapisem danych czy po. Zasadniczo chyba się da przed, więc pewnie się
> tak robi.
>
>> Ale mnie sie cos wydaje, ze rejestrator moze po prostu nie wyrabiac
>> z zapisem kilku/nastu filmów naraz, wiec z załozenia zapisuje sie
>> co n-tą klatkę, a wtedy kompresje "filmowe" gorzej działają, wiec
>> lepiej zapisywać "ciąg zdjęc".
> Rejestratory mają enkodery sprzętowe. Proces kompresji wideo nie odbywa
> się na dysku. Zgaduję, bo ponownie, nie jestem ekspertem, ale pewnie
> enkoder zwraca skompresowane bloki GOP (group of pictures) i dopiero one
> są zapisywane. Jest to dla dysku duzo prostsza operacja niż otwieranie i
> zamykanie pierdyliona plików na sekundę z n-różnych kanałów, gdzie
> obecnie każdy kanał miałby przetworzyć te min. 15-25 plików na sekundę.
> Dla wideo otwarte będzie tylko n-plików (w uproszczeniu) a częstotliwość
> operacji otwierania i zamykania będzie warunkowana założoną wielkością
> pliku wynikowego (np. do 2GB).
>
> Dodatkowo, dyski z DVR/NVR nie są zwykle odczytywalne w standardowy
> sposób, tzn. mimo, że wiekszość NVR/DVR działa pod Linuksem, standardowy
> Linuks tych dysków na poziomie logicznym nie widzi. Nie chciało mi się
> nigdy w to wnikać, ale najpewniej oznacza to, że albo te dyski są
> szyfrowane, albo system plików jest niestandardowy, zoptymalizowany
> własnie pod prace z cctv.

Ze szkolenia zapamiętałem, że właśnie jest tak, że jest tablica
opisująca stempel czasu oraz adres pliku oraz pliki. W praktyce, jeśli
mam wyrwany z rejestratora nośnik, to analizuję to AUTOPSY i dostaję
milion obrazków. Te obrazki układa się na osi czasu. AUTOPSY to sobie
robi pewnie na bazie metadanych. No i teraz możemy podglądać te obrazki.

Przy czym zdaję sobie sprawę, ze standardy są bardzo różne. Ale ja nie
jestem konstruktorem rejestratorów. Po prostu czasem wyciągam z nich
dane i staram się to zrobić najlepiej, jak się da.

Czasem są sekwencje filmików. System na ządanie na zewnętrzny nośnik
archiwizuje wybrany kanał jako jeden filmik albo jako jakieś odcinki.

--
(~) Robert Tomasik

do góry

On 2023-11-09, J.F <j...@p...onet.pl> wrote:
> On Wed, 08 Nov 2023 23:58:13 GMT, Marcin Debowski wrote:
>> On 2023-11-08, Robert Tomasik <r...@g...pl> wrote:
>>> Jak archiwizujesz do filmu to system po prostu wyświetla tę jedną klatkę
>>> przez godzinę. Przy czym rozdzielczość takiej klatki jest większa, niż
>>> protokół filmu avi, czy mp4 przewiduje. Jak zgrasz filmik, to z tego
>>> filmiku możesz odzyskać po prostu rozdzielczość filmiku. Ale jak masz
>>> zapisane te "ramki", to one mają większą rozdzielczość. Czasem może to
>>> mieć krytyczne znaczenie, bo pozwala na odczytanie numeru rejestracyjnego.
>>
>> Przyznam, że również pierwsze słyszę. Jak by się to miało odbywać?
>> Cudów nie ma, ze przy określonej kompresji nagle ma się więcej danych.
>
> Kamery maja teraz dosc duze rozdzielczosci, a przy filmach chce się
> mniejsze, bo za duzo danych ..

Gdzieś to trzeba składować. Zwykle chce się mieć mozliwie długi okres
monitoringu. Co z tego, że będzie dużej rozdzielczości i z perfekcyjną
jakością jak się nagra tylko parę dni? Bawiłem sie jakiś czas temu w
forografię poklatkową. Zrobiłem sobie kamery na bazie Raspberry Pi, 5MP.
Od 6 do 20 z częstotliwością 0.1kl/s, jakością na poziomie 80-90%. Z
pojedyńczej kamery dawało to 6-8GB. Ile wyjdzie dla 8-miu kanałów, całą
dobę, 25kl/s? Ca 25TB. Taki monitoring to może dla super newralgicznych
zastosowań. Nikt przy typowym czegoś takiego nie zaakceptuje. U mnie, w
2ch instalacjach jest FHD, 15kl/s, 5 kamer, 3TB dysk starcza na 2-3
miesiące zanim zacznie nadpisywać. Mozna zjechac z jakościa do 50-75%,
wtedy będzie tak z 5-10TB na dobę.

>> No chyba, że masz na myśli składanie z grubsza statycznego obrazu z
>> n-klatek. A to tak, da się wycisnąć lepszą (formalnie) rozdzielczość,
>> ale to nie będzie rozdzielczość jak to zwykle rozumiemy (że nagle z D1
>> zrobi się UHD), tylko po lini stosunek sygnału do szumu. Nb. tak
>> standardowo działają kamery co lepsiejszych smartfonów.
>
> No ale chyba własnie o to Robertowi chodzi, ze jak jest ciąg zdjęc,
> to mozna tego i poglądowy film zrobic, i dokładną klatke.
>
> Z filmu i sredniej rozdzielczosci nie zrobisz wysokiej.

Powiedzmy optymistycznie, że komuś starcza na tydzień. Mam wrażenie, że
przy tak krótkim czasie to rzadko kiedy da się nagranie zabezpieczyć.

>>> Jak rejestrator zapisuje do filmiku (są oczywiście takie), to zapisuje
>>> powiedzmy 3 minuty i to zapisuje. Jak będziesz mieć pecha i rozwali się
>>> rejestrator w ostatniej sekundzie, to Ci brakuje 3 minut - tych w sumie
>>> najważniejszych. Ale to są tańsze rozwiązania. I możesz z tego wyciągać
>>> nawet klatki - są programy zamieniające filmik w klatki.
>>
>> O ile są na dysku to nie powinno z tym być problemu.
>
> dane gdzies są na dysku, ale jak system niepoprawnie zamknięty, to nie
> wiadomo gdzie ...

Myślę, że się da, tylko to trochę więcej roboty.

--
Marcin

do góry

On 2023-11-09, Robert Tomasik <r...@g...pl> wrote:
> W dniu 09.11.2023 o 00:47, Marcin Debowski pisze:
>> Wystarczy niebuforować operacji dyskowych. Zarżnie się tak pewnie dysk,
>> ale więcej ocaleje. Z tym, że jakieś bufory nadal będą, bo operacje na
>> tych danej wcześniej są wykonywane.
>
> Tylko ja na to nie mam wpływu. Mam, co mam.

Jo, ale gadamy, ajki to musiałby być rejestrator nawsobny, aby było
lepiej niż jest.

>> Dodatkowo, dyski z DVR/NVR nie są zwykle odczytywalne w standardowy
>> sposób, tzn. mimo, że wiekszość NVR/DVR działa pod Linuksem, standardowy
>> Linuks tych dysków na poziomie logicznym nie widzi. Nie chciało mi się
>> nigdy w to wnikać, ale najpewniej oznacza to, że albo te dyski są
>> szyfrowane, albo system plików jest niestandardowy, zoptymalizowany
>> własnie pod prace z cctv.
>
> Ze szkolenia zapamiętałem, że właśnie jest tak, że jest tablica
> opisująca stempel czasu oraz adres pliku oraz pliki. W praktyce, jeśli
> mam wyrwany z rejestratora nośnik, to analizuję to AUTOPSY i dostaję
> milion obrazków. Te obrazki układa się na osi czasu. AUTOPSY to sobie
> robi pewnie na bazie metadanych. No i teraz możemy podglądać te obrazki.

Ale to przy zdjęciach rozumiem?

> Przy czym zdaję sobie sprawę, ze standardy są bardzo różne. Ale ja nie
> jestem konstruktorem rejestratorów. Po prostu czasem wyciągam z nich
> dane i staram się to zrobić najlepiej, jak się da.
>
> Czasem są sekwencje filmików. System na ządanie na zewnętrzny nośnik
> archiwizuje wybrany kanał jako jeden filmik albo jako jakieś odcinki.

Do tego to na ogół NVR/DVR potrzebne. Nb. te urządzenia są zwykle tak
fatalnie zabezpieczone, że tam chyba żadnego szyfrowania jednak nie ma.
Ale w sumie łatwo zaimplementować a sens by był.

--
Marcin

do góry

W dniu 09.11.2023 o 01:23, Marcin Debowski pisze:

>> Bzdura. Widziałeś kiedyś youtuba? Tm się taka magia dzieje, że filmik
>> gra nie wiedzac że jakby za 30 sekund samolot trafił w serwerownię to
>> nie powinien się zacząć odtwarzać 2 minuty temu:P Magia panie kulsonie!
>
> Takie coś się zdarza. Raz, mam wrażenie, że starsze wersje niektórych
> kontenerów albo i standard kodowania strumieni miały coś takiego, że
> faktycznie wystarczyło urwać plik i typowy "player" nie radził już sobie
> z takim plikiem. Sprawdzałem to kiedyś (10++ lat temu) i problem
> faktycznie był, mętnie kojarzę, ze divx'ami lub czymś na bazie h.263.
> Dwa, że zdarza się, że urządzenie, czy program, zapisuje najpierw w
> swoim wewnetrznym formacie w oddzielnych plikach dla każdego strumienia,
> a dopiero na końcu to multipleksuje. Wtedy nawet jak się plik wydaje
> poprawny to niekoniecznie jest. Z tym, że te dane tam są. Kwestia tylko
> odczytania.

I że zdarza się to raczej jak zauważyłeś w starych kodekach. Obecnie nie
jest to problemem.


--
Shrek

Czy wiesz, że "***** ***" czytane od tyłu daje "??? ?????"?
PS - i konfederację!

do góry

W dniu 08.11.2023 o 23:49, Robert Tomasik pisze:

> Jak rejestrator zapisuje do filmiku (są oczywiście takie), to zapisuje
> powiedzmy 3 minuty i to zapisuje. Jak będziesz mieć pecha i rozwali się
> rejestrator w ostatniej sekundzie, to Ci brakuje 3 minut - tych w sumie
> najważniejszych.

Nic ci nie brakuje. Znaczy brakuje odcinak między dwoma "klatkami
głównymi" czyli kilku(nastu) klatek. Tak działają na przykład kamery
samochodowe i jest dość oczywiste, że jkby miały taki feler jak piszesz
to byłby bezużyteczne. Opis standardów 254 i 256 nie jest tajny i możesz
sobie sprawdzić jak to działa.

> Teraz są jeszcze takie systemy, że zapisują w zupełnie obcym Windowsom
> formacie i rejestrator dopisuje do katalogu taki programik, co to
> pozwala na odtwarzanie tego.

No i?

> Najczęściej gdzieś na stronach producenta
> można wówczas znaleźć programik, który wyciąga z tego klatki i o dziwo w
> większej rozdzielczości, niż z filmiku.

Jak było ystawione zdjecia o wyższej rozdzielczości to wyciągnie, jak
nie to co najwyżej upskalowane (ale raczej nie robią tego profesjonalne
rejestratory bo byłoby to ingereowanie w integralność materiału).

--
Shrek

Czy wiesz, że "***** ***" czytane od tyłu daje "??? ?????"?
PS - i konfederację!

do góry

W dniu 09.11.2023 o 06:02, Marcin Debowski pisze:

> Gdzieś to trzeba składować. Zwykle chce się mieć mozliwie długi okres
> monitoringu. Co z tego, że będzie dużej rozdzielczości i z perfekcyjną
> jakością jak się nagra tylko parę dni? Bawiłem sie jakiś czas temu w
> forografię poklatkową. Zrobiłem sobie kamery na bazie Raspberry Pi, 5MP.
> Od 6 do 20 z częstotliwością 0.1kl/s, jakością na poziomie 80-90%. Z
> pojedyńczej kamery dawało to 6-8GB. Ile wyjdzie dla 8-miu kanałów, całą
> dobę, 25kl/s? Ca 25TB. Taki monitoring to może dla super newralgicznych
> zastosowań. Nikt przy typowym czegoś takiego nie zaakceptuje. U mnie, w
> 2ch instalacjach jest FHD, 15kl/s, 5 kamer, 3TB dysk starcza na 2-3
> miesiące zanim zacznie nadpisywać. Mozna zjechac z jakościa do 50-75%,
> wtedy będzie tak z 5-10TB na dobę.

Czasami jak pisałem robi się tak, że zapisujesz kilka strumieni to
różnym framerate. 25 klatek w gorszej rozdzielczości i 1 na sekunde czy
dwie w maksymalnej. Być może ktoś robertowi pojakazał i teraz ten
dorabia teorię że rejestratory nie zapisują filmów tylko zdjęcia.

>> dane gdzies są na dysku, ale jak system niepoprawnie zamknięty, to nie
>> wiadomo gdzie ...
>
> Myślę, że się da, tylko to trochę więcej roboty.

Nic więcej - dzieje się to z automatu. Przecież tak działają kamerki
samochodowe - zapisują pliki po 1-3 minut. Jakby to miało działać tak,
że przy solidnym dzwonie nie ma ostatnich 90 (czyli właśnie dzwonu) to
nie miałoby to żadnego sensu.

--
Shrek

Czy wiesz, że "***** ***" czytane od tyłu daje "??? ?????"?
PS - i konfederację!

do góry

On 2023-11-09, Robert Tomasik <r...@g...pl> wrote:
> W dniu 09.11.2023 o 00:58, Marcin Debowski pisze:
>> Cudów nie ma, ze przy określonej kompresji nagle ma się więcej danych.
>
> To nie tak. Powiedzmy na dysku masz zdjęcia w rozdzielczości 1920 x 1080
> pikseli. Rejestrator zrzuca to do rozdzielczości 640 x 480 pikseli. Jak
> sobie zgrasz film, to z niego możesz wyciągnąć zdjęcie w rozdzielczości
> 640 x 480 pikseli. Ale jak wyciągniesz fotkę z nośnika to dostaniesz
> 1920 x 1080. I czasem to pozwala na odczytanie numeru rejestracyjnego,
> podczas gdy z klatki 640 x 480 nie odczytasz. No już prościej nie potrafię.

No ale do tego potrzebne są te zdjęcia albo 2 równoległe strumienie o
2ch różnych rozdzielczościach. Takie strumienie są standardem, ale zapis
wyłącznie zdjęciami, n-kanałów z rozsądną częstotliwością, to naprawdę
trudno mi uwierzyć, że jest w powszechnym użyciu. Zwyczajnie zdjęcia
zajmują od cholery miejsca, nawet takie 2MP.

Taka klatka FHD:
https://www.smartcity.co.nz/wp-content/uploads/2021/
03/how-to-reduce-traffic-congestion-in-cities.jpg

Przy jakości na poziomie 10%, rejestracji w drugim rzędzie juz się nie
odczyta. Plik ma ca 60kb. 1 kanał, 25kl/s => 125MB na dobę. Da się
jeszcze od biedy odczytać przy 20% => 200MB/kanał. Pod 1TB przy 8
kanałach. Akcetowalna od biedy jakość jest dopiero przy 50% i jakiś
340MB na kanał. Jaki sens zapisywać to w plikach obrazków gdy nawet
h.264 da z 10-30x mniejszy plik wynikowy o lepszej jakości poszczególnych
klatek przekonwertowanych na obrazki?

--
Marcin

do góry