Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
Pozor, dlouhý zápisek! Koho zajímá, jak s pomocí mencoderu kóduji nahrané filmy z televize, nechť čte dále, ale byl varován
Proč se do konverze pouštět:
Na vstupu konverze se očekává jednolitý videosoubor v MPEG-2, který již prošel odtučňovací kůrou v podobě vymazání reklam v programu dvbcut. Pro konverzi videa jsem si zvolil mencoder a jakožto pomocný nástroj Avidemux.
Jistě, Avidemux lze použít i pro samotnou konverzi, v současné verzi však stále má jistá omezení (například nelze nastavit poměr stran videa) a pro vzdálená spouštění na serveru se taky zrovna nehodí. Program tedy používám zejména pro odladění filtrů, které na záznam hodlám použít, a pro výpočet bitové šířky při požadované velikosti výsledného videa.
Poznámka: Pro výpočet bitrate je nutno znát délku videa, kterou ovšem z uloženého televizního záznamu (zejména pak u formátu MPEG-TS) můžete v přehrávači pouze odhadovat – není neobvyklé, že v tomto světě jedna sekunda ve skutečnosti znamená sekundy hned tři. Pro přesné zjištění délky pořadu je tedy dobré spolehnout se na editor, který si nad videosouborem vytvoří pomocný index.Avidemux se také hodí pro hledání snímků vhodných ke střihu v případech, kdy se rozhodnu výsledné video rozdělit do dvou či více souborů.
S ohledem na schopnosti stolního přehrávače jsem vsadil na jistotu omšelého kontejneru AVI, do kterého vkládám video ve formátu MPEG-4 a zvuk obvykle originální MPEG-1 layer 2 kódovaný se 192kb šířkou, případně překódovaný layer 3 s 96 či 128kb šířkou. Někdo může oprávněně namítnout, že kódování z MP2 do MP3 sníží kvality zvuku za cenu nepatrných pár ušetřených megabajtů, subjektivně však ve výsledku žádný rozdíl neslyším a ušetřených 50 MB na 700 MB pro video zase tak nepatrné číslo není.
Kódování zajišťuje knihovna libavcodec (neb jak říká nápověda „best quality!“), FourCC ovšem nastavuji na hodnotu DX50. Nikoho také nepochybně nepřekvapí dvouprůchodové kódování obrazu, oproti jedinému průchodu je kvalitativní nárůst jasně viditelný, zatímco více průchodů pro mne znamená akorát ztrátu času, neboť už v tom žádný posun v kvalitě nevidím.
Samotné kódování spouštím pomocí skriptu, který si podle potřeby upravuji a který vypadá přibližně takto (dlouhé řádky jsou rozděleny):
#/bin/sh # INPUT=$1 VIDEO_OPT=" -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1356: \ vmax_b_frames=2:mbd=2:v4mv:aspect=16/9:dia=2:trell:cbp:mv0: \ vlelim=-4:vcelim=7:lumi_mask=0.1:dark_mask=0.1:vpass=" MISC_OPT=" -vf crop=702:574:8:2,scale=560:448 -sws 10 -ssf cs=10 \ -ffourcc DX50 -passlogfile ${INPUT%%.mpg}.log -ss 0 -frames 93874" mencoder -oac copy -o /dev/null ${VIDEO_OPT}1 $MISC_OPT $INPUT sleep 1 mencoder -oac mp3lame -lameopts abr:br=96 \ ${VIDEO_OPT}2 $MISC_OPT $INPUT -o ${INPUT%%.mpg}.avi
Při snaze optimalizovat výslednou kvalitu videa v závislosti na bitové šířce, očekávané velikosti souboru a rozlišení obrazu je dobrým vodítkem hodnota udávající, kolik bitů se průměrně spotřebuje na jeden obrazový bod (bits per pixel). Někde jsem četl, že rozumný rozsah hodnot je 0,5–1,0 pro MPEG-2 a 0,2–0,5 pro MPEG-4. Jenomže co dělat, když originální televizní vysílání má tuto hodnotu necelých 0,3 b/px?
Několik experimentů mě přesvědčilo, že hodnota 0,2 pro MPEG-4 je hodně dobrá a 0,15 ještě uspokojivá. Pokud však chci takovýchto hodnot dosáhnout a zároveň snížit velikost videosouboru o více jak polovinu, nezbývá mi, než také zmenšovat rozlišení obrazu. V závislosti na tom, jak který nahraný pořad je pro mne cenný, zmenšuji velikost souboru na polovinu až čtvrtinu původní velikosti a zároveň snižuji výšku obrazu na (obvykle) jednu z hodnot 512, 448 a 384 (viz filtr scale
). Schválně píšu výšku, neboť obvykle je třeba ořezat černé okraje u obrazu nalevo a napravo (viz filtr crop
), čímž se šířka stává více proměnlivou. Navíc může být zobrazovaná šířka přepočítaná v závislosti na udávaném poměru stran.
Vzhledem k již zmíněné časté nevalné kvalitě vysílaného obrazu zmenšení rozlišení výsledek nijak významně nedegraduje, navíc s sebou přináší tu výhodu, že nemusím řešit odstranění prokládání (deinterlace). Základem úspěchu je však použití dobrého algoritmu pro škálování obrazu – mencoder jich prostřednictvím parametru -sws
nabízí hned jedenáct, jejichž kvalita se navzájem liší velmi výrazně. Rozdíly jsou patrné v efektu kostičkování obrazu, ostrosti hran a vyplnění jednobarevných ploch (patrné například u titulků); po otestování všech typů mi nejlepší výsledek dal typ 9 (lanczos) a 10 (přirozený bikubický spline). Rozmazanému obrazu aspoň trošku pomůže lehké doostření pomocí parametru -ssf
.
Musím se přiznat, že většině parametrů, které v mém skriptu následují za -lavcopts
, nijak zvlášť nerozumím – obecně by měly zlepšovat výslednou kvalitu obrazu a jsou opsány z nápovědy a nejrůznějších internetových útržků. Mé povědomí o nich je tedy následující:
vmax_b_frames
– nejsem nepřítelem B-snímků, pokud je obsahuje i původní vysílaný proud, proč by je nemohl mít i zkonvertovaný výsledek?mbd
, v4mv
, mv0
– úprava kódování makroblokudia
, trell
, cbp
– hledání závislostí v obrazevlelim
, vcelim
– potlačování součinitele jasové a barevné složky podle dopručenílumi_mask
, dark_mask
– maskování detailů ve světlých a tmavých částech obrazuaspect
– pokud rozlišení obrazu neodpovídá poměru stran obrazu (typické pro širokoúhlé televizní vysílání), je nutno správný poměr stran nastavit ručně; v opačném případě je vhodné použití parametru autoaspect
Ze začátku zápisu se zmiňuji o vylepšení nekvalitního obrazu s pomocí filtrů. Možná poněkud překvapivě není mou hlavní zbraní pro odstranění šumu filtr denoise3d
ani jeho vylepšená varianta hqdn3d
, ale Gaussovo rozostření unsharp
. Filtr aplikuji pouze na jasovou složku obrazu, velikost matice zadávám 3x3 a nakonec doostřuji kladným číslem okolo hodnoty 0,5 – plný zápis filtru tak vypadá následovně: unsharp=l3x3:0.5
.
V jednom případě – u filmu Stvoření světa – jsem též docenil kvality filtru MSmooth, který s animovaným záznamem umí hotové zázraky. Konverzi jsem však v tomto případě dělal v Avidemux, neboť u mencoderu jsem jej v seznamu filtrů nenašel.
Starší verze mencoderu se občas zasekly při začátku druhého průchodu s chybovou hláškou týkající se generování křivky, upgrade na rc1 toto vyřešil.
Zařízení /dev/null
je skvělé úložiště pro výstup prvního průchodu konverze.
Rozdělení videa na více částí zajistí parametry -ss
a -frames
, které udávají počáteční čas a počet snímků ke konverzi; každá část videa se tak kóduje zvlášť, vhodné hodnoty k těmto parametrům pomůže najít Avidemux.
Stejně ale asi budu muset investovat do koupě dalšího pevného disku ...
Tiskni Sdílej:
FourCC ovšem nastavuji na hodnotu DX50
proc tam nedat treba xvid? mas nejaky konkretni duvod proc zrovna fourcc DivXu5?
kódovaný se 192kb šířkou
v závislosti na bitové šířce
Jaka sirka? nejak to slovo nechapu, to o cem mluvis je totiz tzv "datovy tok" alias "bitrate".
jednu z hodnot 512, 448 a 384 ... že nemusím řešit odstranění prokládání
deinterlaci musis imho resit pokazde, pokud zdroj a) nebyl progressive a za b) resizujes na neco jineho nez "halfPAL"
nejsem nepřítelem B-snímků
nejaky duvod proc byt nepritelem B-snimku? ja osobne jsem treba jejich velkym pritelem, byt maji nevyhody plynouci z jejich definice.
jinak povidani pekne.
Nemám. Existuje nějaký důvod, proč tam dávat zrovna XVID?FourCC ovšem nastavuji na hodnotu DX50
proc tam nedat treba xvid? mas nejaky konkretni duvod proc zrovna fourcc DivXu5?
Pravda, nevhodný překlad. Někde jsem jej zahlédl a nechal jsem se zmást.kódovaný se 192kb šířkou
v závislosti na bitové šířce
Jaka sirka? nejak to slovo nechapu, to o cem mluvis je totiz tzv "datovy tok" alias "bitrate".
Subjektivně vnímám jen zmenšený obraz a obraz s odstraněným prokládáním následně zmenšený jako dva stejné výsledky, takže se tím nezabývám.jednu z hodnot 512, 448 a 384 ... že nemusím řešit odstranění prokládání
deinterlaci musis imho resit pokazde, pokud zdroj a) nebyl progressive a za b) resizujes na neco jineho nez "halfPAL"
Nevím, zdá se, že jsou tací mezi námi ...nejsem nepřítelem B-snímků
nejaky duvod proc byt nepritelem B-snimku? ja osobne jsem treba jejich velkym pritelem, byt maji nevyhody plynouci z jejich definice.
a) K televizi obyčejný levný STB (Třeba digipal 2) + PCI karta do PC. + cena + snadné zpracování dat na PC - nutnost mít zapnuté PC (spotřeba) - horší komfort obsluhy (chybí věci jako nahrávání jedním tlačítkem, timeshifting, atd) b) Koupit STB s HDD a dvěma tunery. + snadná obsluha + nízká spotřeba - cena (cca 8k+ za Sencor SHR 9116T) - nutnost data do PC nosit přes DVD-RW c) ???
Nikoho také nepochybně nepřekvapí dvouprůchodové kódování obrazu, oproti jedinému průchodu je kvalitativní nárůst jasně viditelný, zatímco více průchodů pro mne znamená akorát ztrátu času, neboť už v tom žádný posun v kvalitě nevidím.Proč by dvouprůchodové kódování mělo přinést vyšší kvalitu? Pokud jsem omezen velikostí výsledku tak samozřejmě musím volit buď konstantní průměrný bitrate (což souhlasím je neefektivní), nebo dva průchody (což zase dlouho trvá). Ale pokud mne víc než velikost výsledku zajímá jeho kvalita, proč nepoužít jednoprůchodové kódování s předem odhadnutým
vqscale
? Oč to bude horší než 2-pass?