Pokud to má fungovat obecně a pro různé typy souborů, tak se to realizuje poměrně blbě.
Párkrát jsem implementoval něco podobného, když jsem hostoval server pro výměnu a sdílení médií mezi různými týmy v rámci jednoho projektu, bohužel se to uploadovalo promocí standardního FTP a téměř odkudkoliv (mobilní sítě, satelitní internet). Byly tam nějaké automatické transkódovací cesty a potřeboval jsem zařídit, aby se odseparovaly nekompletní a případně poškozené uploady ještě než si to přebere transkodér, který byl ještě k tomu proprietární a při zpracování určitých poškozených souborů měl memory leak
, takže to bylo vcelku důležité.
U některých konkrétních formátů a kontejnerů se snadno zjistí, že nejsou celé, protože s tím od začátku počítají. Parser v podstatě tím, že chybí v souboru určitá struktura, příznak, nebo je tam reference na adresu za koncem souboru, tak snadno zjistí, že je nekompletní. Případně tam je třeba na začátku hlavička, v které je délka. Některé formáty mají i vestavěné checksumy. Takže se dá snadno zkontrolovat i jestli je soubor nejen nekompletní, ale i třeba poškozený při přenosu.
Pak jsou formáty, které tohle v podstatě neřeší a musí se buď kompletně projet a zkontrolovat jeho struktura, případně v nejhorším (časově nejnáročnějším) případě jej zdekódovat, což je ale ve většině případů pořád řádově rychlejší než komplet transkóding do jiného formátu a v případě výskytu chyby jej vyřadit. Tohle se týká primárně některých starších formátů, případně těch co jsou od v podstatě koncipované k nějakému streamování, kde se s výpadky pricipiálně počítá (např. MPEG-2 TS).
Co to navíc ještě pak komplikuje je to, že tam můžou být značné rozdíly i v rámci jednoho formátu, např. jinak se chová MP4/MOV soubor s fast-start hintem (MOOV atom na začátku a dá se "odhadnout" cílová velikost) a bez něj. Některá enkodéry a zařízení ho dají úplně na konec. Je pak nutné ošetřit více stavů.. atp.
Takže v pár bodech mé zkušenosti..
- ffprobe skóre nestačí (to je opravdu jen základní, hrubá identifikace formátu/kontejneru)
- mediainfo (resp. libmediainfo) má podle konkrétního formátu nyní (oproti době, kdy jsem výše zmíněné věci psal) řádově víc možností detekce strukt. chyb (compliance errors) a je schopné řadu variant nekompletních souborů detekovat. Tam bych začal a naintegroval buď pomocí JSON výstupů z cli toolu nebo volal tu knihovnu.
- pro spolehlivou detekci širokého spektra formátů může být pořád nutné aplikovat nějakou heuristiku. Např. já měl po úvodní identifikaci souborů víc nástrojů, až po zmíněné dekódování. Pro některé situace můžete zavolat i ffprobe -show_frames a kontrolovat chyby. Někde (mkv) by mohl stačit remux. Je potřeba mít vzorky poškozených, nekompletních souborů a ozkoušet to.
- jestli vám jde vyloženě o analýzu mpeg-audio rámců v MP3, tak bych do pipeline zařadil mpck
https://github.com/Sjord/checkmatePokud to máte pod kontrolou, tak se zamyslete nad zúžením množství vstupních formátů, kde máte ověřenou detekci, nebo vylepšením uploadu. Např.
- upravit upload frontend tak, aby rovnou spočítal do malého souboru bokem nějaký checksum, co pak snadno zkontroluje a zároveň pokud se uploaduje jako poslední, tak může fungovat jako bumper soubor, co pak triggeruje nějaký watchfolder v pipeline za tím (samozřejmě pokud to funguje jen souborově a nemáte to řešené jinak, třeba vytvořením úlohy v nějaké frontě / message brokeru).
- v projektech, co jsem řešil, se spousta věcí vyřešilo použitím hotových (komerčních) nástrojů na posílání souborů (zásilek), který má nativní klienty (appky) na všechny možné platformy, řeší integritu souborů, navazování a nepustí nekompletní zásilky dál do pipeline. Pořád je tam šance, že někdo vygeneruje špatný soubor, ale toho je řádově menší výskyt než potíží s uploadem, zvlášť z míst s nespolehlivým připojením.
5 Odpovědí
478 Zhlédnutí