1
Sítě / Re:Souběžné posílání souboru multicastem
« Poslední příspěvek od Hornik kdy Dnes v 20:42:08 »Muzete rozvest ten use case?
Co se tim snazite resit?
Co se tim snazite resit?
Poslední příspěvky
2
Software / Re:LibreOffice: jak vložit více obrázků najednou
« Poslední příspěvek od Václav Ovsik kdy Dnes v 19:39:41 »Tak mi to nedalo a zkusil jsem ten drag&drop a mě to funguje. Mám ale Debian Sid a Librewriter je z LO libreoffice-writer 24.8.3.
File dialog přes Insert / Image ale opravdu nemá multiselect.
File dialog přes Insert / Image ale opravdu nemá multiselect.
3
Sítě / Re:Souběžné posílání souboru multicastem
« Poslední příspěvek od mkudlacek kdy Dnes v 17:55:30 »Podobnym zpusobem funguje Syncthing (https://syncthing.net). Sdilis adresar mezi X zarizenimi bez centralniho bodu. Kdyz se pripojis s novym zarizenim (nebo se starym obsahem sdilenyho adresare) tak zacnes dostavat data od vsech ostatnich zarizeni zaroven.
4
Bazar / Prodám grafické karty na AI a podobně
« Poslední příspěvek od CPU kdy Dnes v 17:04:15 »Ahoj,
kolega má pár výpočetních (těžebních) karet Nvidia (něco mezi 1070 a 1080), dají se použít na hraní s AI nebo lámání hesel. Důležité je, že většina nemá výstup, což na výpočty nevadí. Za kus chce něco mezi 500 a 1000 Kč podle stavu.
Co říkal:
- Osobně v Praze, záruka týden
- Maximálně jedna karta na osobu
- Pokud by na tom chtěl někdo hrát, tak jde přesměrovat výstup v systému interně
- Lepší karty jde přeflashnout 8GB VRAM a zapnutí HDMI výstupu
Pro seriózní práci s AI to chce tak 10-20 GB VRAM, ale taková karta nebude stát pětikilo.
Kdyby někdo chtěl, kontakt předám.
kolega má pár výpočetních (těžebních) karet Nvidia (něco mezi 1070 a 1080), dají se použít na hraní s AI nebo lámání hesel. Důležité je, že většina nemá výstup, což na výpočty nevadí. Za kus chce něco mezi 500 a 1000 Kč podle stavu.
Co říkal:
- Osobně v Praze, záruka týden
- Maximálně jedna karta na osobu
- Pokud by na tom chtěl někdo hrát, tak jde přesměrovat výstup v systému interně
- Lepší karty jde přeflashnout 8GB VRAM a zapnutí HDMI výstupu
Pro seriózní práci s AI to chce tak 10-20 GB VRAM, ale taková karta nebude stát pětikilo.
Kdyby někdo chtěl, kontakt předám.
5
Software / Re:FFmpeg: jak validovat multimediální soubor?
« Poslední příspěvek od hknmtt kdy Dnes v 16:10:21 »Pokud vám ffmpeg vyhodí při následném transkódování problém, soubor vyhodíte a notifikujete uživatele.
Najskor asi tak, ako doteraz.
6
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ů.
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ů.
7
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.
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.
8
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.
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.
9
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 ;-)
10
/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
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
