Poslední příspěvky

1

Software / Re:FFmpeg: jak validovat multimediální soubor?

« Poslední příspěvek od Michal Šmucr kdy Dnes v 15:45:50 »

Já chápu, co je záměrem.
Ale bohužel o tom je právě celá ta debata.. Pro omezení chyb při následném zpracování nestačí jen vydetekovat typ souboru, a identifikovat streamy. Pokud to má spolehlivě validovat a pracovat s různými formáty souborů, co se od sebe zásadně liší, tak je potřeba důkladnější analýza. Ta pak logicky v závislosti na typu souboru vyžaduje nějaký čas.
A jak jsem psal, není to úplně jednoduché, opravdu nestačil jen ffmpeg, musel jsem kombinovat víc nástrojů a stejně jsem pokryl pouze část.

ffmpeg se v podstatě bez dalšího nastavení podívá jen na začátek vstupního souboru (podle -analyzeduration, resp. -probesize) a identifikují se základní parametry kontejneru a streamů, což se pak případně použije na nastavení demuxeru a dekodérů. To je celé, nemá to ambici hledat chyby ve struktuře souboru nebo datových blocích.
ffprobe pak může jít případně dál, procházet streamy (show_frames, show_packets, spočítat hashe atp.) a potencionálně nějaké evidentní věci odhalit, ale zas to bude záležet na formátu a konkrétním typu chyby - obecně bych na to moc nesázel.

Samozřejmě si můžete třeba vyhodnotit, že to nemá smysl řešit a jen reagovat na chyby při kódování.. Pokud vám ffmpeg vyhodí při následném transkódování problém, soubor vyhodíte a notifikujete uživatele. Návratové kódy nejsou 100%, ale když to třeba rozjedete s -v warning a budete parsovat stderr na výskyt určitých slov, tak můžete odchytit poměrně dost problémů.

Jak už jsem zmiňoval, tak některé zásadnější problémy dokáže docela dobře odhalit mediainfo, kterým můžete v nahradit i ten ffprobe na prvotní identifikaci. Dobře se s tím pracuje, v JSONu to vrací pole ConformanceErrors s případnými chybami.
Ale zas, jestli to zafunguje, bude záležet na typu toho problému (např. úplně chybějící kus souboru vs. pár flipnutých nebo zapadovaných bitů někdě v půlce). Můžete si jednoduše vyzkoušet, jestli vám řekne něco k té MP3ce (podle hlášky z ffmpegu mi to nepřijde jako chyba hlavičky, ale jeden nebo více poškozených rámců) a uvidíte.
Ale podobně jako ffprobe je to také nástroj primárně navržený na rychlou identifikaci vlastností souboru, ne na hloubkovou analýzu. Kterou, pokud budete chtít, tak musíte pořešit většinou dedikovaným nástrojem nebo prostě reagovat na chyby návazného transkodéru.

Zdaleka nejrobustnější je použití interních checksumů v hlavičce pro relativně rychlou externí validaci (byť s přečtením a počítáním hashe z téměř celého souboru), což odhalí i jakékoliv drobné chyby v celém řetězci, ale to je bohužel záležitost spíš bezztrátových audio formátů (BWF, FLAC, WavPack) nebo "profi" video kontejnerů (MXF s AS-07 rozšířením pro archivaci) a nedá se to využít u většiny běžných formátů.

2

Software / Re:FFmpeg: jak validovat multimediální soubor?

« Poslední příspěvek od hknmtt kdy Dnes v 14:11:13 »

Ja po uploade suboru viem ze je kompletny pretoze sledujem velkost suboru, ktoru ocakavam. Hash si robim sam ale to je irelevantne.

ffprobe mi vrati info o subore, o tom je prave to skore, a ja si kontrolujem ci nainstalovana verzia ffmpegu podporuje kodedky v audio a video trackoch a tiez aj kontajner. Takze mi ide do systemu subor ktory viem ze ffmpeg spracuje.

Problem ale nastava az pri samotnom spracovnai neskor. A mne ide o to tomu predist prave na zaciatku pri validacii suboru, nez ho poslem dalej na spracovanie. A ci ma mp4 kontajner fast start alebo nie je irelevantne. Ide o to ze ffprobe subor naparsuje a ziska metadata, to je je same o sebe prva kontrola. A ffprobe mi hovori ze subor pouziva kontajner XYZ a ma kodek ABC a DEF pre audio a video tracky. Takze viem co v subore je.

Ale z nejakeh odovodu mi potom ffmpeg hodi chybu ze data nie su validne. A o to mi ide - tomuto zabranit. Idealne ale bez nutnosti preskenovat cely subor, lebo to moze byt aj 10 giga a proste uzivatel pri nahravani nema cas cakat na nieco take.

Napriklad chyba co som pisal hore sa tyka headeru, to by hadam mal ffprobe alebo ffmpeg nejak vediet hned zachytit bez nutnosti skenovat cely kontajner.

3

Software / Re:ffmpeg - ako validovat multimedialny subor?

« Poslední příspěvek od Michal Šmucr kdy Dnes v 13:48:20 »

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/checkmate

Pokud 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.

4

Hardware / Re:Levný nevýkonný hardware na virtualizaci

« Poslední příspěvek od k3dAR kdy Dnes v 12:19:00 »

[...] Lenovo M720q Tiny [...] Chlazení je "notebookového typu" s heatpipe a radiálním ventilátorem, velmi tiché (když CPU jede naprázdno), i když ne úplně neslyšné. [...]

btw: s ovladacem nct6683 v jadre nejde fancontrol, ale s out-of-tree nct6687d ano, v idle lze snizit asi o 200rpm a pak uz je skoro neslysitelne ;-)

5

/dev/null / Re:netcup - podivne obchodne praktiky

« Poslední příspěvek od Ħαℓ₸℮ℵ ␏⫢ ⦚ kdy Dnes v 12:16:55 »

Odkud jsi na netcup narazil? Neznám ho, ale když jsem sháněl VPS, tak na lowendspirtit/lowendtalk(s) jsem narazil na takovou stránku jako "flash sales" (toto slovní spojení si zapamatujte), a mám poci,t že jsem se dostal do divných vod. Princip je, že to generuje celkem různorodé nabídky v řádu minut a musíte brát nebo nechat plavat, jednou tam je nevýhodná, pak je tam levné a pomalé, pak něco jiného, pak je tam něco s hodně ramkou, ale jedním jádrem, něco jako kolo štěstí bédy trávníčka nebo slávka boury

Dokonce už jsem si od jednoho objednával (těžko si už vzpomenu na jméno, datacentra byla v USA, NY) a dokonce se zaregistroval, platil zadáním čísla platební karty, jenže tím to haslo, dál se nic nedělo a peníze nebyly strženy

6

Software / FFmpeg: jak validovat multimediální soubor?

« Poslední příspěvek od hknmtt kdy Dnes v 11:53:08 »

Nahram na web audio/video a zbehnem ho cez ffprobe. Ak nedostanem confidence aspon 51, tak upload je neplatny.

Toto je bezny problem pri mp3, kedy perfektne validny subor nedosiahne vyssie skore proste. Neviem preco ale proste je to tak. Takze preto pouzivam take nizke skore. Tiez kontrolujem ci je tam nejaky audio/video track a nejde iba o prazdny kontajner.

Nasledne audio/video konvertujem do nejakeho nakonfigurovaneho formatu a kvality.

Problem je, ze niekedy mi ffmpeg vrati error. Napriklad naposledy:

ffmpeg error: [mp3float @ 00000000026e6f00] Header missing
[aist#0:0/mp3 @ 00000000026ce140] Error submitting packet to decoder: Invalid data found when processing input

Otazka je, ako zachytit/validovat audio/video subory pred tym, nez sa ich pokusim konvertovat? Myslel som ze ffprobe mi zaruci, ze ked vie precitat metadata, tak subor nemoze byt problem nasledne konvertovat. No ocividne to tak nie je.

Je teda nejak mozne priamo ffmpegom validovat multimedialny subor?

7

Studium a uplatnění / Re:Jak učit dětičky na základní škole?

« Poslední příspěvek od Mintaka kdy Dnes v 11:29:59 »

Ale to není argument, proč bychom se měli linuxem zabývat v "základním kurzu".

Ano, nerozumíme si, já tady neobhajuji Linux ve výuce.
Vy (několik lidí v diskuzi) si, bez znalosti kontextu uděláte nějakou představu a pak, na základě té mylné představy, argumentujete, jako byste ten kontext znali.

Když tedy:

bavíme se o výuce, o tom co a jak učit.

Pak můžeme řešit velmi podstatné otázky:

Kolik hodin výuky informatiky mají mí žáci na prvním stupni ZŠ?
Kolik hodin z toho se cíleně věnujeme Linuxu?

Chápete, jak je nesmyslné něco kritizovat, když neznáte ani tak zásadní údaje?

A nejde o to, jestli je učím o Linuxu nebo programování ve Whitespace, podstatné je, že neznáte podrobnosti a místo toho, abyste se na ně doptali, pokud vás to skutečně zajímá, tak se tu stavíte do pozice, že tomu rozumíte lépe. Nezasvítí vám červená kontrolka "teď tady chci šířit moudra, ale nic moc o tom nevím", ne, potřeba vyjádřit svůj "názor" za každou cenu, i když je totálně mimo, má navrch.

Každý, kdo do procesu vstupuje, má určeno, co bude učit, ale když to striktně určeno nemá, tak si látku nesmí vybírat, aby to hlavně bavilo jeho, ale jen a pouze podle toho, co potřebujou ty děti.

V rámci tohoto výroku se mýlíte v několika věcech.

Co se má v rámci povinného vzdělávání učit je dáno pomocí RVP (které můžete připomínkovat a podílet se na jeho sestavení). RVP si škola zpracuje do ŠVP, kam si může přidat věci dle svého zaměření, materiálních a personálních možností. ŠVP zpravidla sestavují učitelé dané školy. Na ŠVP navazují tematické plány a pak je skutečná výuka s žáky, která vám leckdy přiohne celou tu soustavu někam ještě jinam.

Na VŠ/VOŠ a některých jiných místech se jede formou akreditací vzdělávacího obsahu a vzdělávacích oborů. Moduly pro akreditace také stavují učitelé. A to je jen povinná část výuky.

Pak tu máme široký prostor v rámci zájmových kroužků.
Takže zdaleka to není vše jen podle toho, co ty děti "potřebují", ale podle mnoha dalších faktorů. To že učitele baví, to co se snaží dětem předat, nebo kudy je vede, považuji za jeden z těch hlavních faktorů. Navíc mimo úplně základního učiva ani nemáme jistotu, co skutečně budou potřebovat.

Každého jednotlivého, bez ohledu na jejich talent. Souzním s názorem učitele dílen

Rozhodně si nemyslím, že ze všech budou, nebo by měli být, ajťáci. Ale co se týče talentu, opět nesouhlasím. Pokud mám možnost rozvíjet jejich talent, rád to udělám a podpořím je v dalším směřování. Naopak, podporu talentů považuji za velmi důležitou.

Obávám se, že u prvňáčků žádná smysluplná představa, co to je operační systém, nevzniká

Opět se neshodneme, protože neznáte kontext. Stejně jako si s žáky označujeme hmotné věci kolem sebe: monitor, základní jednotka, PC myš / klávesnice, dataprojektor, flashdisk, a říkáme si k nim hlavní funkce a principy, tak si označujeme i nehmotné věci software, programy/aplikace, dokumenty,... a operační systém je prostě jeden z pojmů. Je to pojem, kterým strávíme cca 3 minuty a podané to mají tak, aby to navázalo na jejich zkušenosti. Pojmy jako Windows / Android mnozí znají. Co si z toho kdo odnese je věc druhá, ale vzhledem k tomu, že v tomto věku nasávají tisíce pojmů a významů kolem sebe, povětšinou tam něco zůstane.

Kromě klasických kroužků vedu Otevřenou dílnu.
Její navštívenka je zde: https://technicka-liga.cz/
Tak třeba na viděnou.

8

Bazar / Re:Prodám Argon EON RPi4 case

« Poslední příspěvek od malyponikvtlacence kdy Dnes v 11:26:11 »

Zlevněno na 1500.

9

Sítě / Re:Jumbo frames v kombinaci s VLAN

« Poslední příspěvek od Michal Šmucr kdy Dnes v 11:23:20 »

Ta dvoji by sla takto:

Jj. taky jsem k tomu došel, když jsem něco podobného potřeboval řešit. Konkrétní podřízený VLAN interface šel s menším MTU, ale fyz. interface se musel nastavit na 9k, aby to pak chodilo.

U mě to v ten moment bylo ještě trochu komplikované tím, že to byl server s hypervizorem a více síťovkami, jedna šla napřímo do konrétní VLANy (netagované pakety), ostatní pak šly do uplink portů na switchi (pakety s VLAN headerem k rozebrání v serveru). Do toho pak spousta interních bridge rozhraní pro virtuály (fakticky pro každou VLANu).
Nejvíc jsem se pak zasekl na tom, že jsem to nastavoval přes NetworkManager, který zarputile odmítal nastavit MTU pro fyz. interface po startu, pokud neměl žádné IP adresování (což bylo až výš na těch virt. rozhraních).
Nakonec se to povedlo, ale byl to stejně jen přechodný stav, kdy jsme přešli se všemi VLANami a infrastrukturou na jumbo framy, s tím že tam sice zůstávají nějaká koncová zařízení s MTU 1500, ale není to prakticky tak problematické.

10

Sítě / Re:Souběžné posílání souboru multicastem

« Poslední příspěvek od Michal Šmucr kdy Dnes v 11:00:07 »

Na podobnou distribuci přes UDP multicasty existuje software.. UFTP
https://uftp-multicast.sourceforge.net/
Přenosy se iniciují ze strany odesilatele pomocí uftp. Na straně příjemce pak běží instance uftpd, co přijímají ty multicasty a ukládají soubory. Ty jdou buď do finálního umístění, nebo se dá nastavit dočasný adresář během přenosu a až když je to celé, tak se to přesouvá.
Řeší to spousty dalších věcí okolo, je tam nastavitelná velikost bloku (chunku), re-transmission, volitelné AES šifrování, součástí je i proxy (pro oddělené sítě to tuneluje multicasty).
Primární důvod, proč to vzniklo, byla distribuce dat ze zařízení s limitovaným uplinkem přes sítě s velkou latencí (např. satelit), kde se už výrazně projevuje bw latency product s normálními TCP pakety, takže to používá UDP a potvrzují se celé chunky. Ale jak už tu bylo zmíněno předtím, UDP má také svá úskalí a bez správného nastavení multicastů to může udělat pěkný flood.
Také je třeba rozumně zvolit rychlost posílání tak, aby to pobrala všechna zařízení, co to mají přijímat, a nebylo tam moc opakování. Což může pro větší přenosy na rychlejších sítích vyžadovat i trochu systémového ladění přijímacích bufferů (to je typické např. na některých BSDčkách nebo Windows) a případně počítat, že tam může být i nějaký ramping na začátku přenosů.

Osobně teď v reálných projektech nemám potřebu to používat, ale před pár lety jsme si spolu s kolegou blbli v nějaké WAN síti, šlapalo to, a za určitých okolností to může být výhodné.