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.
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.
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.
Tenhle článek ale není o stříhání reklam. Článek je o fallocate a o kolapsu dat v souboru.
Stříhání reklam je jen příklad, k čemu je to dobré, pokud mi nezáleží na přesnosti ale naopak jdu po nenáročnosti a rychlost celého procesu. A že zbyde v souboru 0.3 vteřiny reklamní znělky, nebo nějaké chvilkové drobné artefakty v MPEG streamu, to mi je fakt jedno.
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.
Občas si něco z televize stáhnu, a už jsem se setkal s tím, že na začátku a konci reklamy nebyl KF, asi aby to ztížilo její vystřižení.
Nicméně existují DVD recordéry s HD, ve kterých je možné v programu nahraném na HD reklamu označit a toto místo se při přehrávání (nebo při vypalování DVD) přeskočí (aniž by se smazalo). Umí toto i některý video přehrávač?
toho by som sa nebal, digitalne vysielanie sa dnes siri vzduchom, multicastami a inymi pochybnymi cestami, tak si nikto nedovoli strielat KF raz za niekolko sekund. treba ratat s tym, ze clovek moze zvolit niektory substream kedykolvek a nechat ho cakat trebars 20s na KF, aby sa mohol nastartovat dekoder je volovina. tusim aj samotna norma pozaduje vysielanie KF maximalne raz za pol sekundy (ale ak sa mylim, nebite ma, uz som tu normu nejaky ten piatok nevidel a bol to pekny humus).
sprtate do vykalu, ktory nesmrdi.
Já bych řekl, že MPEG TS právě je televizní signál. A keyframy se v televizi rozhodně netáhnou minutu, to byste po přepnutí programu musel minutu čekat, než se objeví obraz (je pravdou, že některé TV přijímače se této době úspěšně přibližují :) ). Běžná délka GOP je kolem 12-15 snímků, tedy půl sekundy.
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.
predpokladam, ze tato okrajova vlastnost bola do jadra zanesena kvoli podpore zahadzovania alokovanych blokov v DB systemoch, ktore nezriedka maju velkost internych struktur zarovnanu na maximalne jednotky nasobkov velkosti alokacnych blokov a tam sa takato vec teoreticky za istych okolnosti moze hodit (napr. pri preriedovani TXN logovacich suborov).
pre pana autora len odkaz: kernel to nepodporuje, pretoze to nie je jeho vec. obecna implementacia na urovni kernelu by bola rovnako junky ako je kazda jedna implementacia v userspace, pretoze proste veci funguju tak, ako funguju. polepit obsah viacerych suborov to nie je len tak. (o.i. napr. z podobneho dovodu neexistuje asi na ziadnom rozumnom systeme syscall implementujuci kopirovanie obsahu suboru).
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.