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