Vyšla kniha Počítačové programy a autorské právo. Podle internetových stránek nakladatelství je v knize "Významný prostor věnován otevřenému a svobodnému softwaru, jeho licencím, důsledkům jejich porušení a rizikům „nakažení“ proprietárního kódu režimem open source."
Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané svým konzultačním týmem.
Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Český telekomunikační úřad vydal zprávy o vývoji cen a trhu elektronických komunikací se zaměřením na rok 2024. Jaká jsou hlavní zjištění? V roce 2024 bylo v ČR v rámci služeb přístupu k internetu v pevném místě přeneseno v průměru téměř 366 GB dat na jednu aktivní přípojku měsíčně – celkově jich tak uživateli bylo přeneseno přes 18 EB (Exabyte). Nejvyužívanějším způsobem přístupu k internetu v pevném místě zůstal v roce 2024 bezdrátový
… více »Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-10-01. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Jedná o první verzi postavenou na Debianu 13 Trixie.
Byla vydána nová verze 4.6 svobodného notačního programu MuseScore Studio (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Společnost DuckDuckGo stojící za stejnojmenným vyhledávačem věnovala 1,1 milionu dolarů (stejně jako loni) na podporu digitálních práv, online soukromí a lepšího internetového ekosystému. Rozdělila je mezi 29 organizací a projektů. Za 15 let rozdala 8 050 000 dolarů.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.17. Díky 278 přispěvatelům.
Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.
Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.
… více »ffmpeg -i video.mp4 -r 1/1 $filename%03d.pngKdyž jsem to zkoušel, tak minutovou sekvenci vyblil cca za 6 sekund 2, Pak bych vybral jeden reprezentativní keyframe, ze kterého bych pomocí výběru podle barev vybral optimální selekci, tak aby zabrala pokud možno všechny barvy titulku. A z té bych pak udělal mapu barev:
pngtopnm title_yellow.pnm | pnmcolormap all > mapa.pnmRedukcí barev se výrazně zjednoduší a zrychlí následné zpracování. 3, No a pak bych s využitím této mapy bych projel ve smyčce všechny snímky: for i in (ls *.png) ; do pngtopnm $i | pnmremap -map=mapa.pnm -missingcolor=white > ${i/png/pnm} ; done Ještě víc by se to dalo urychlit tím, že bych před ten pnmremap předřadil pnmcut, aby se zpracovávala jen ta část obrazu, kde se vyskytují titulky. Čímž by ještě víc zredukoval objem dat s nimiž by se pak měl tesseract zabývat. A k jejich zpracování bych si napsal jednoduchý skriptík, který by bral jeden po druhém a přes pnmpsnr, porovnál jestli nedošlo ke změně. Pokud jo, tak pokud by šlo o začátek titulku, tak by zavolal tesseract, a když by to byl konec, tak by zapsal výsledek s číslem počátečního a koncového keyframe do souboru s titulky.
test01.png
je výsledek po průchodu přes všechny snímky, test02.png
pouze přes dva), trochu chytřejší implementace (d(p1, p2) > t) není o nic lepší (test04.png
je výsledek po průchodu přes všechny snímky při t=10). Zvyšování thresholdu nepomáhá. Co je zvláštní, tak že i pokud threshold nastavím tak absurdně vysoko (dejme tomu na 300), že téměř všechny pixely ve scéně zůstanou netknuty, titulky to stejně částečně usekne (viz test07.png
). Napadá mě jediné logické vysvětlení, že tam dochází k nějakému nepatrnému posunu, což je věc, kterou jsem fakt nepředpokládal. Čekal bych, že titulek bude pozicovaný vždy stejně.
No ale zkoušel jsem ty framy projet od oka a žádného viditelného posunu jsem si nevšiml, tak fakt nevím. Protože pokud tam k tomu posunu nedochází, tak by to aspoň o trochu lepší výsledky produkovat mělo, ne? Pak by bylo na čase přemýšlet, jak to optimalizovat (zmenšení viewportu na relevantní část, nějaké půlení intervalu, aby to nebralo úplně všechny snímky, …). Pokud je to ale opravdu tím skákáním a neudělal jsem teď v rychlosti někde jen nějakou stupidní chybu, bylo by nutné místo jednotlivých pixelů sledovat nějaké matice sousedních pixelů atd. Natrénovat nějaký model přímo na čtení titulků by v dnešní době asi byla rozumnější cesta.
# all frames:: # mkdir all_frames_orig # cd all_frames_orig # ffmpeg -i ../Trailer_2020.orig.mp4 -vsync 0 -r 25 -f image2 %04.png # cd .. ## tohle ale muze trvat dooost dlouho (4000 asi 4 hodiny): ## vysekne jen vybrane snimky for f in $(seq 0 4752); do fn=$(printf "%04d.png" $f) ffmpeg -i ../Trailer_2020.orig.mp4 -vf "select=eq(n\,$f)" -vframes 1 $fn done ####### mkdir key_frames_orig_hms cd key_frames_orig_hms # ffprobe -select_streams v -show_frames -show_entries frame=pict_type -of csv ../Trailer_2020.orig.mp4 ffprobe -select_streams v -show_frames -of csv ../Trailer_2020.orig.mp4 > trailer_ffprobe.out cat trailer_ffprobe.out | awk -F',' '{print $5,$6,$19}' > trailer_ffprobe_types.out grep 'I' trailer_ffprobe_types.out > trailer_ffprobe_types_keys.out ## vyzaduje all_frames nebo vysekavat po jednom (viz vyse) cat trailer_ffprobe_types_keys.out | while read a b c; do zpframe=$(printf '%04d' $a); secs=$(printf '%.2f' $b); ms=$(python -c"print('{}m{:02.2f}s'.format(int($b//60),$b % 60))") convert ../all_frames_orig/$zpframe.png -quality 80 ./${zpframe}_${secs}s_${ms}.jpg; done
-noaccurate_seek
Když to čte jenom každý pětadvacátý snímek tak to zas až tak zoufale pomalé není. Nejvíc na tom zdržuje to OCR které se nakonec zavolat stějně musí. Když by se ffmpeg překompiloval s volbou --enable-libtesseract
tak se tím zpřístupní filtr ocr. Ale to moc nechápu jak to funguje.
jo :D :D ;D ;D
a furt jim tam řikám jak je jako ten linux supr jak všecko funguje aže takovej a takovej problémek by v linuxu vubec nebyl možnej i když vim žeto jako neni pravda a každou chvilku se musí v linuxu něco vopravovat :O :D :D ;D
Az na to ze na DVD jsou titulky ve vlastnich stopach ...
coz tady autor resi uplne jiny problem o oplne jine komplexite ... HardCoded SUBS :D , ale u uzivatele windows clovek neceka ze pochopi psany text a nebo vi neco o technologii na pozadi
ne, je to celkem relevantni .. chtel bych videt tn X let stary program na widle co to udela na kliknuiti ..
to jestli je autor pirat nebo ne je irelevatni, i ten kdo grabuje orig dvd a OCRkem protahuje titulky je pirat ..
Kdyby používal "neuronku", tak se neptá.Ptá, protože potřebuje trénovací data.
co tohleto hele :O :O
No to je vlastně původní důvod, proč toto celé vzniklo. Protože se mi ten videocr nepodařilo rozhýbat. Taky autor toho videocr píše, že dvacetisekundové video to čte tři minuty. To se mi zdá hodně pomalé. Teď zrovna překopávám tady ten bash skript tak, že čte za sekundu ne jeden obrázek ale dva a zjišťuju že to stačí. Žádné titulky netrvají míň jak 500ms. V té původní verzi co je navrchu v blogu se mi občas krátký titulek ztratil. Hodně se tím zvýšila přesnost časování. Bohužel s tím ale narostl počet duplikátů (asi v tom mám bug) a taky to celé trvá dvakrát dýl. Přibližně je to stejně rychlé jak přehrávání. Dám to do přílohy. Přijde mi že je to o maličko víc použitelné jak ta původní verze.
Taky autor toho videocr píše, že dvacetisekundové video to čte tři minuty.No to je fakt HODNĚ pomalé. Jak bych na to šel já jsem popsal o kousek výše.
Tiskni
Sdílej: