Názory k článku Mazání dat uprostřed souboru

Přijde mi to dost neohrabané, hlavně implementace v programech (jestli vůbec bude), nebude nijak triviální právě k vůli nutnosti zarovnání na bloky.

Smysl by mělo označní místa pro smazání až k místu pokračování a svázání souboru, byť by to vedlo k fragmentaci.

Při editaci videa přece není keyframe zakódovaný do zarovnaného bloku a zvuk k danému místu se může nacházet samostatně opět se zarovnáním do jiného bloku.
Pokud bych smazal 10MB videa s reklamou o délce 5-ti minut a 5 a půl minuty zvuku, tak to bude minimálně kravit.

Nechápu tak užitečnost tohoto řešení.

Proc resis video a zvuk kdyz od toho jsou tam synchronizacni znacky? Jak delat splicing si precti na mpeg.org.
Proc resite odmazavani od prostredka kdyz muzu:
- strihat standartni strihaci soupiskou a pak z ni udelat novy sestrihany soubor. Mam dva soubory a zalohu puvodniho kdyby se neco popo... Strih se resi minimalne mezi dvema medii kvuli vykonu original a strih. U MPEG streamu stejne kvuli kompresi nemuzete strihat presne ale idealne na splice pointech.
- abych treba usetril misto muzu pouzit filesystem ktery deduplikuje na blocich a nebo soft ktery umi prolinkovavat obsahy souboru mezi sebou na urovni bloku. Kdyby to bylo naimplementovane v nejakem strihacim softu to by se to pracovalo. Hruby strih by byl tak velice rychly.

Zminil bych ze hromada softu ignoruje synchronizacni znacky a struktury a ani neumi spravne pracovat s vadnymi pakety transport streamu( pro softwarove sampony je s podivem ze tam jsou prirozene chyby ). Proto o nich a jejich vyznamu(stejne jako chyceni GOPu nebo okamziku pro splice) malokdo vi.

Běžně se video už při záznamu rozděluje na 1G soubory, takže se pracuje jen s nimi.

Nerekl bych ze bezne. Je to kvuli FAT limitaci a pro ruzne nablble uzivatele aby nemuseli premyslet. Tohle mi uz nedelal ani dreambox(tam bylo imho volitelne rezani 1/2/4/8gb). Kamera to taky triska do souboru - na exFAT klidne 18GB jen to svihne.

Obecnejsi operace by byly operace "split" a join:
split: dodam offset souboru, a jmeno noveho souboru
join: dodam dve jmena souboru, to druhe jmeno se smaze, v tom prvnim souboru mam concatenovany obsah
Vyse zminena operace by umela ten strih, stejnym zpusobem jako to podivne volani fallocate, a jeste neco navic. Jak to naimplementovat na stare FATce vim, ale zda by to nejak slo delat pres jadro, to netusim.

Moje motivace vychazi z toho, ze jsem resil trochu jiny problem: na disk jsem zapsal 3 velike soubory (celkem 1GB) a pak jsem je chtel concatenovat (destruktivne, jeste s malym souborem na zacatku, jakoze hlavickou). A nevim o nicem, co by mi ty soubory spojilo (klidne jen pokud budou mit zarovnanou velikost na 4k), aniz bych musel data z fs vytahnout ven a zase je tam ulozit. (V podstate slo o offline vyrobeni indexu, ktery pri prutokovem indexovani mel "2 kurzory", ten 3. soubor byly puvodni data. Ale pro dalsi praci s tim indexem bylo potreba mit ho jako jeden soubor. A cim rychleji to bylo hotove, tim lepe, delalo se to pravidelne.)

P.S.: dnes uz bych asi umel atomicke switchnuti na adresari (pomoci symlinku), ale stejne by mne to konkatenovani zajimalo.

Výše zmíněné operace nelze provést a to proto, že nelze jen tak daty šoupnout v rámci sektorů. Fallocate pracuje na úrovni celých sektorů.

Spojování souborů je stejný problém, data v druhém a třetím souboru by se musela šoupnout.

Vždyť tam píšu, že mi nevadí, že podmínkou bude, že velikost souboru bude zarovnaná na velikost bloku (psal jsem explicitně 4k).

Každá editace videa, která neumí pracovat s jednotlivými snímky, je špatná. Granularita 192512 je v tomto kontextu masakr.

Chceme docílit vystřihnutí reklam, tak prostě najdu dva přibližně podobné snímky před a po reklamě a snímky mezi nimi smažu. Fallocate mi na toto nijak nepomůže a nevím co je na tom zase nepochopitelného.

A ako to robis? Ja si napriklad Openshote najdem zaciatky a konce reklam (hh:mm:ss.ff) a nasledne to podhodim mkvmergu, kde to spojim vsetko okrem reklam do noveho suboru. Ak je vsetko ok, tak povodny subor zmazem. Stream zachytavam ako .mkv z tvheadendu. Obcas vsak nastava proble, ze mkvmerge strihne inde ako chcem (bezne priblizne 30 sekund, ale pre vsetky pozicie je to rovnaky posun) a celkom to stve. Idealne by bolo, keby som si mohol vyzualne nast snimky, v ktorych chcem strihat a hned to spojit bez reenkodovania.

Jenže jde o to, že ten soubor bude prostě načatej.
Videosoubor není jen o tom, že smažeš nějaké bloky a vše je OK.
Vezmi si třeba takovou Matrošku MKV a H.264 kodek.... myslíš, že můžeš ze souboru "vyříznou" tady kousek a tady kousek bez toho, aniž by nastal nějaký problém?

Řekl bych, že celé to je o tom, že se bude jednat o dost specifické využití, jestli to vůbec někdy někdo k něčemu využije.

Povrchni mini clanek kvuli jedne okrajove vlastnosti jadra a jeste jen castecne podporovane ? Kandidat pro zpravicku, tohle je mizerie …

Btw. krome problemu se zarovnanim data versus velikost bloku filesystemu snizuje pouzitelnost obsluha zachovani konzistence formatu ulozenych dat, kterou vidim jako daleko obvyklejsi nez binarni stream.

Pozor s tim kopirovanim obsahu souboru. Jsou tu volani sendfile a splice, protoze uz nekdo zjistil, ze nema smysl pri kopirovani (ze souboru do sockety a podobne) tahat ty data do userlandu.

Nektere implementace filesystemu podporuji sdileni casti souboru (treba spolu s copy-on-write)(i kdyz je to treba jen po blocich), a mam za to, ze maji nejakou utilitu, ktera to na namountovanem fs umi vyuzit (takze musi nejak jadru vysvetlit, ze nebo co tam delaj, i kdyz treba pres nejake ioctl).

Nicmene to co by se libilo mne by bylo, tady mas soubor: rozrizni ho na dva na tomhle offsetu (zarovnanem treba na bloky), nebo naopak: tady mas dva soubory, nastav tomu prvnimu velikost na offset + delka druheho (pokud je kratsi) a presun obsah druheho na ten offset. Volitelne pak data v prvnim, ktere jsou od offsetu dal posun o delku druheho (zase offset i delka musi byt zarovnana na bloky).

U vetsiny filesystemu by to byla jen nejaka rychla manipulace s tabulkou bloku nebo extentu. Jedina potiz je v tom, ze vyuziti techto funkci je docela minoritni, ja bych asi jejich zacleneni neobhajil. Stejne tak mi prekvapuje, ze v clanku zminena feature se dostala do kernelu jako obecne volani. Spis bych pochopil, kdyby to bylo nejake FS-specificke ioctl, ti co tu funkcionalitu potrebuji, si nainstaluji fs, ktery to podporuje. Zda se, ze hralo roli to, ze je to vlastne jen pridani jednoho flagu.