W dniu 08.11.2023 o 15:33, Robert Tomasik pisze:

>> Żadne programowo robienie z klatek. Po prostu jest standard jak ma
>> wyglądać plik wideo i tak zapisuje.

> Ale dopiero przy zgrywaniu, a i to, jeśli to robisz celowo. Podejrzyj
> sobie dysk rejestratora z Linuksa i nie zawracaj gitary.

Zabawne, że o tym piszesz;) A co jeśli właśnie to robię służbowo?

>>> Mało kto wie, że z rejestratora można wyciągnąć obraz z o wiele
>>> większą rozdzielczością, niż się zabezpiecza filmiki.
>> NIeprawda. Nie da się wyciągnąć filmu z większą rozdzielczością niż
>> był zabepieczony. Można potem upskalować.
>
> Przeczytaj moje zdanie, ale ze zrozumieniem. Przemyśl, czy pisałem
> cokolwiek o wyciąganiu filmu z większą rozdzielczością. Przy czym są
> różne rejestratory. Samochodowe przykładowo przeważnie filmiki
> faktycznie zapisują.

I lunuksowe DVRy również:P

> Nie mam interesu tłumaczyć Ci jak to działa

Naprawdę nie musisz mi tłumaczyć:P

> pewno przekręcisz i będziesz komentował wymyśloną przez siebie bzdurę.

Przecież komentuję właśnie bzdurę ale wymyśloną przez ciebie:P

--
Shrek

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

do góry

W dniu 08.11.2023 o 22:28, Shrek pisze:

>>> Żadne programowo robienie z klatek. Po prostu jest standard jak ma
>>> wyglądać plik wideo i tak zapisuje.
>> Ale dopiero przy zgrywaniu, a i to, jeśli to robisz celowo. Podejrzyj
>> sobie dysk rejestratora z Linuksa i nie zawracaj gitary.
> Zabawne, że o tym piszesz;) A co jeśli właśnie to robię służbowo?

Cóż. Zawsze mnie wkurzają ludzie, którzy używają argumentu, że lepiej
wiedzą, bo się na tym znają. To z reguły świadczy o tym, że nie mają
zielonego pojęcia ani nawet argumentów za swoim poglądem. Przeważnie są
na takim poziomie, ze jeszcze nie wiedzą, czego nie wiedzą.
--
(~) Robert Tomasik

do góry

W dniu 08.11.2023 o 21:30, J.F 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 ?

Nie bierzesz pod uwagę tego, że tego systemu operacyjnego po awarii może
po prostu już nie być. Jak zapisujesz klatkę co 1/30 sekundy, to ta na
1/30 wcześniej jest. W praktyce w wypadku dobrze zaprojektowanego
monitoringu to spore ograniczenie objętości. Jak masz kamerę gdzieś w
pustym pomieszczeniu, to system nie zapisuje kolejnej klatki, dokąd suma
kontrolna obrazu się zgadza. Jak się zmieni, to zapisze.

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.

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.

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. 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.
--
(~) Robert Tomasik

do góry

On 2023-11-08, Robert Tomasik <r...@g...pl> wrote:
> W dniu 08.11.2023 o 01:48, Marcin Debowski pisze:
>>>> Przy czym sama idea jest MZ mocno takase i trochę watpie czy jest nadal
>>>> powszechnie stosowana.
>>> Zaletą tej idei jest to, że jeśli przerwiesz nagranie, to masz ostatnią
>>> klatkę. Jak nagrywasz filmiki, to nie masz ostatniego.
>> Masz, bo ramka I jest zawsze przed P i B.
>
> Jeśli przerwiesz w wyniku katastrofy zapisywanie filmiku, to potem się
> go nie da odczytać, bo plik nie jest zamknięty. Może jest jakiś sposób
> obejścia tego, ale w każdym razie z pierwszego taki problem się rodzi. I
> dlatego właśnie wymyślono ten zapis klatek. Tak przynajmniej na
> szkoleniu wyjaśniał to facet.

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.

Problem jest, ale gdzieindziej - operacje na dysku są prawie zawsze
buforowane, a to odbywa się w pamieci ulotnej. Jesli system nie zdąrzy
zrzucić z bufora na dysk, to ta czeście przepada. Z tym, że dotyczy to
tak samo zdjęć jak i filmu. Mozna co prawda argumentować, że przy
zdjęciach przepadnie mniej, bo kompresja dużo niższa, ale ma na to wpływ
sporo różnych czynników i nie wydaje mi się, aby ta róznica, o ile w
ogóle występuje*, miała wieksze znaczenie praktyczne.

*) operacje otwierania i zamykania plików są powtarzające się, więc
pewnie intensywnie buforowane. Mozna sobie wyobrazić sytuacje, gdzie
przy zdjęciach straci się więcej, bo jest ich tam o rząd większosci
więcej.

--
Marcin

do góry

On Wed, 8 Nov 2023 23:49:09 +0100, Robert Tomasik wrote:
> W dniu 08.11.2023 o 21:30, J.F 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 👂
>
> Nie bierzesz pod uwagę tego, że tego systemu operacyjnego po awarii może
> po prostu już nie być.

Ale dane są. A i system nie powinien sie uszkodzic, choc to róznie
bywa.

> Jak zapisujesz klatkę co 1/30 sekundy, to ta na 1/30 wcześniej jest.

Dane są. Zamknięcie pliku to jeszcze paru zapisów wymaga
w katalogach itp. Na magnetycznym dysku nie problem, na SSD juz dosć
spory.

> W praktyce w wypadku dobrze zaprojektowanego
> monitoringu to spore ograniczenie objętości. Jak masz kamerę gdzieś w
> pustym pomieszczeniu, to system nie zapisuje kolejnej klatki, dokąd suma
> kontrolna obrazu się zgadza. Jak się zmieni, to zapisze.

Szumy są. Na pewno sie zmieni. Trzeba czyms mniej czulym porónywac.

No ale kompresja "filmowa" tez wtedy mało miejsca może zużyć.

> 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ść.

To mozna tez mniej ambitną kompresję filmową użyć, wyjdzie na to samo
:-)

> Czasem moĹźe to
> mieć krytyczne znaczenie, bo pozwala na odczytanie numeru rejestracyjnego.
>
> 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

Dane na dysku są, odszukanie może być problemm.

> najwaĹźniejszych.

Z tym, ze niekoniecznie ta awaria ma związek z jakims atakiem ..

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

Bo tam akurat wielkich wymagań do systemu plików nie ma, a inne
systemy mogą być lepsze .

> pozwala na odtwarzanie tego. 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.

J.

do góry

On 2023-11-08, J.F <j...@p...onet.pl> wrote:
> On Wed, 8 Nov 2023 15:36:09 +0100, Robert Tomasik wrote:
>> W dniu 08.11.2023 o 01:48, Marcin Debowski pisze:
>>>>> Przy czym sama idea jest MZ mocno takase i trochę watpie czy jest nadal
>>>>> powszechnie stosowana.
>>>> Zaletą tej idei jest to, że jeśli przerwiesz nagranie, to masz ostatnią
>>>> klatkę. Jak nagrywasz filmiki, to nie masz ostatniego.
>>> Masz, bo ramka I jest zawsze przed P i B.
>>
>> Jeśli przerwiesz w wyniku katastrofy zapisywanie filmiku, to potem się
>> go nie da odczytać, bo plik nie jest zamknięty. Może jest jakiś sposób
>> obejścia tego, ale w każdym razie z pierwszego taki problem się rodzi. I
>> dlatego właśnie wymyślono ten zapis klatek. Tak przynajmniej na
>> szkoleniu wyjaśniał to facet.
>
> 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.

> 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.

> 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.

--
Marcin

do góry

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.

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.

> 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.

> 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. 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.

Jestem przekonany, że to nie jest większa rozdzielczość a wspomniana
redukcja szumów/zniekształceń.

--
Marcin

do góry

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 ..

> 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.

>> 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 ...

J.

do góry

On 2023-11-08, Shrek <...@w...pl> wrote:
> W dniu 08.11.2023 o 15:36, Robert Tomasik pisze:
>
>> Jeśli przerwiesz w wyniku katastrofy zapisywanie filmiku, to potem się
>> go nie da odczytać, bo plik nie jest zamknięty. Może jest jakiś sposób
>> obejścia tego, ale w każdym razie z pierwszego taki problem się rodzi. I
>> dlatego właśnie wymyślono ten zapis klatek. Tak przynajmniej na
>> szkoleniu wyjaśniał to facet.
>
> 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.

--
Marcin

do góry

On Wed, 08 Nov 2023 23:47:13 GMT, Marcin Debowski wrote:
> On 2023-11-08, J.F <j...@p...onet.pl> wrote:
>> On Wed, 8 Nov 2023 15:36:09 +0100, Robert Tomasik wrote:
>>> W dniu 08.11.2023 o 01:48, Marcin Debowski pisze:
>>>>>> Przy czym sama idea jest MZ mocno takase i trochę watpie czy jest nadal
>>>>>> powszechnie stosowana.
>>>>> Zaletą tej idei jest to, że jeśli przerwiesz nagranie, to masz ostatnią
>>>>> klatkę. Jak nagrywasz filmiki, to nie masz ostatniego.
>>>> Masz, bo ramka I jest zawsze przed P i B.
>>>
>>> Jeśli przerwiesz w wyniku katastrofy zapisywanie filmiku, to potem się
>>> go nie da odczytać, bo plik nie jest zamknięty. Może jest jakiś sposób
>>> obejścia tego, ale w każdym razie z pierwszego taki problem się rodzi. I
>>> dlatego właśnie wymyślono ten zapis klatek. Tak przynajmniej na
>>> szkoleniu wyjaśniał to facet.
>>
>> 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.

I wychodzi mu to lepiej lub gorzej.

>> 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.
>
>> 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

W FAT wiedziałem, w Unixie wiedziałem.

> plików), ale system siłą rzeczy musi to wiedzieć już przed zapisem.

Ale nie musi tego od razu zapisywac.
Praktycznie co blok (kilka sektorów), trzeba zapisywac kilka bajtów
do FAT czy innej tablicy, wypadałoby zmodyfikować długośc pliku - wiec
nic dziwnego, ze sie to odsuwa, szczegolnie ze zaraz będzie zmienione.
Ale prawdziwy problem jest na dyskach SSD/Flash.

W magnetycznym z kolei głowice się urwą :-)


> 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.

IMO - niewielka z tego zaleta. Chyba, ze wiesz, ze kolejne dane będą w
kolejnych sektorach.

>> 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ę.

Ale niektóre monitoringi to mialy np 4 klatki/s na kanał.

> 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.

Moze byc mocno niestandardowy i dopasowany do zadania.

J.

do góry