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.