Uroš Popović popisuje, jak si nastavit Linux na desce jako Raspberry Pi Zero, aby je šlo používat jako USB „flešku“.
Andreas Kling oznámil, že jelikož už se nevěnuje nezávislému operačnímu systému SerenityOS, ale výhradně jeho webovému prohlížeči Ladybird, přičemž vyvíjí primárně na Linuxu, SerenityOS opustí a Ladybird bude nově samostatný projekt (nový web, repozitář na GitHubu).
Po dvou měsících vývoje byla vydána nová verze 0.13.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 73 vývojářů. Přehled novinek v poznámkách k vydání.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Ještě jsem neviděl nahrávku, kde by nebyl alespoň minimální černý nebo rozmazaný okraj,Zvlastne, ze je to bezne aj pri DVD. Na druhej strane pri vysielani rakuskeho ORF1 (aj ked som uz davno nepozeral), to byvalo cast bez ciernych pruhov.
Zdá se, že by správné bylo nejdříve nahrávku setříhat a pak až ji enkódovat, abychom nemuseli zbytečně zpracovávat nepotřebné části. Při tomto postupu jsem se ale poměrně často setkal s rozhozením synchronizace audia a videa.Na toto pouzivam stale dvbcut. Funguje super ak je zdroj mpeg2. Este som nezazil rozhodenie zvuku a obrazu. Aj ked momentalne hladam nahradu, pretoze ho vyrazili z portage a netusim ako dlho mi bude fungovat stary ebuild, pripadne kedy sa vrati.
change_rectangle
a koukat se na výsledek rovnou v reálném čase, více viz můj příspěvek do diskuze o digitalizaci VHS.
Děkuju za blog a inspiraci.
Poměr 5:4 je poměr rozměrů PAL (720x576) bez přenásobení šířky. Nudle 7xx na 3xx vypadá na americký formát 2,35:1. Na 576 řádků při poměru 16:9 připadá 1024 sloupců. Nešlo by uvést přesná čísla?Šlo, ale pro dotaz jsou nepodstatná a neměl jsem je po ruce. Kdyžtak viz parametr "quality" a celý skript tady.
Jestli máte jistotu, že to přehrávač správně roztáhne, tak by se nemuselo škálovat a stačilo by vnutit do nahrávky správný poměr, do avi souboru se to dá udělat pomocí -force-avi-aspect 16/9. Kodek lavc má zase parametr aspect. Tak můžete zkusit parametr -aspect při přehrávání mplayerem.O to se právě přesně snažím. Přepočítávání jsem z toho vyhodil úplně, ale ten poměr se tam korektně nezapisuje. Zatím jsem to nijak do hloubky nestudoval, ptal jsem se hlavně proto, jestli to už někdo nevyřešil, abych nevymýšlel kolo.
MP4Box -add soubor.mp4#video -add soubor.mp3#audio -PAR 1=16:9 vystup.mp4
(Opět poměr stran pixelu, ne obrazu.)
mkvmerge --aspect-ratio 0:16/9 -o vystup.mkv vstup.mp4
(Tady je to poměr stran obrazu, ne pixelu.)
Návod k MPlayeru překládal člověk, který neumí česky, bohužel tím zblbl hodně lidí, kteří to po něm čtou. Je to klasicky amatérské bezhlavé doslovné přepisování anglického výrazu do češtiny. Slovo enkódovat v češtině neexistuje (v žádném slovníku ÚJČ, ani v pravidlech českého pravopisu, ani v slovníku cizích slov). Předpona „en“ v anglických slovech odpovídá zhruba našemu „za“ nebo „vy“, tedy něco nějak učinit. Např. encapsulate je zapouzdřit (ne enpouzdřit), encipher je zašifrovat (ne enšifrovat), encamp je utábořit (ne entábořit), enrage je rozzlobit (ne enzlobit), no a encode je zakódovat, ne enkódovat.Tak jsem to opravil, díky za upozornění.
H.264 je běžný standard už dávno. Prakticky každý moderní stolní přehrávač videa už jej dnes podporuje (nejen proto, že je to standard Blu-ray), jeho podpora je nativně ve Windows 7 i Mac OS X, herních konzolích, video kamerách atd. Vysílá v něm i YouTube, které v H.264 nevysílá jenom pro počítače, ale i televize a mobilní zařízení. Dnes už je prostě H.264 rozšířenější a mainstreamovější než MPEG-4 Part 2, a ten rozdíl bude s každým rokem jenom narůstat.Vyjádřil jsem se trochu nepřesně. Standard to samozřejmě je, ale myslím, že ještě není moc rozšířený, zejména co se týče stolních přehrávačů. Třeba z mých známých nemá Blue-ray přehrávač nikdo. S tím, že se tento formát bude čím dál víc šířit, naprosto souhlasím. Nicméně, před časem jsem čekal, že klasická DVD nahradí nosiče s formátem MPEG-4, a zatím se tak neděje.
-vo pngTož to nevím. Ono to generuje docela rychle ty jednotlivé framy, dost zabírají a pak je ještě mazat? Když už nic, tak doporučuju aspoň -vf screenshot a klávesu S.
nejčastěji tak jsou vysílány přímé přenosy, zprávy a podobněJá měl za to, že prokládání už je součástí standardu (proto MPEG-2 a ne MPEG-1) DVB-T (a nebo aspoň u nás) a téměř každá televize už jen provádí deinterlacing.
Posledním nutným filtrem je přeškálování. Jak jsem uvedl v předchozí části, jestli chceme mít co nejvíc přenositelnou nahrávku ve formátu MPEG-4, je potřeba alespoň přenásobit šířku nahrávkyTo jsem nepochytal. Co je na 720x576 špatného?
Pro průměrnou doporučenou hodnotu CQ=0,25No, nevím. Přijde mi to zbytečně moc. Nedávno jsem se rýpal kolik by tak mohlo být sledovatelné minimum pro HD (1920x800) s MPEG-1 videem (kodek lavc) a skončil jsem na nějakých 3.5Mbps. A to šlo o trailer, takže spousta akčních scén v krátkém čase. V případě AVC (a to jsem x264 ani nijak zvlášť moc netunil – v podstatě defaultní parametry) mi nějakých 2.5Mbps přišlo pomalu jako plně transparentní. Určitě je vhodné si svoji hodnotu nějak empiricky najít a nespoléhat na předem rozhodnutá čísla. Úplně nejlepší by bylo samozřejmě nepřekódovávat to a nechat to tak jak to z karty leze.
Při druhém průchodu je dobré uložit do výsledného souboru poměr stran (parametr -force-avi-aspect)No a úplně nejlepší je nehackovat takový starý krám jako je AVI a ukládat to do něčeho normálního.
Audio je ve formátu MP3, takže většinou stačí ho jen překopírovat.
Audio je ve formátu MP2 (MPEG-1, Layer II přesněji) o 192kbps. Mám pocit, že to dokonce diktuje standard. Ale jinak souhlas. Nejlépe zkopírovat a neprznit ho chudáka ještě víc.
Nicméně až na pár vyjmenovaných maličkostí musím pochválit. Dokonce jsem se dozvěděl pár drobností, které jsem nevěděl.
Souhlasím. Jen bych doplnil, že občas v televizi běží věci, kde deinterlace není potřeba - obvykle filmy nasnímané na filmový pás, který je z principu bez řádkování a 24 fps se na 50 převede zdvojením framů a lehkým zrychlením.nejčastěji tak jsou vysílány přímé přenosy, zprávy a podobněJá měl za to, že prokládání už je součástí standardu (proto MPEG-2 a ne MPEG-1) DVB-T (a nebo aspoň u nás) a téměř každá televize už jen provádí deinterlacing.
Nejspíš to, že 720/576=1.25 a 4/3=1.33. Samozřejmě můžeme mít nečtvercové pixely (pixel aspect ratio <> 1:1). Mám ale zkušenost, že přehrávače to podporují jen u MPEG kontejneru. U oblíbeného avi (pro většinu lidí navíc avi implikuje obsah v DivX/MPEG4-ASP) to skoro žádný přehrávač nepodporuje (i když kontejner snad ano) - obraz je deformovaný na aspect ratio 1:1.25. Navíc 16:9 obsah se v MPEG-2 v DVB-T/S nebo na DVD taky přenáší v 720×576 a tam už je deformace nesnesitelná a bylo by nutné nastavovat AR ručně (u originálního MPEG2 to přehrávače umí automaticky). Nevím jak MKV, tam už je to možná lepší. Asi platí, že přeškálování je lepší se vyhnout pokud není nutné, protože přináší ztrátu kvality.Posledním nutným filtrem je přeškálování. Jak jsem uvedl v předchozí části, jestli chceme mít co nejvíc přenositelnou nahrávku ve formátu MPEG-4, je potřeba alespoň přenásobit šířku nahrávkyTo jsem nepochytal. Co je na 720x576 špatného?
Mám pocit, že co se týče klasických filmů, je takových věcí většina. Ale jak která televize.Souhlasím. Jen bych doplnil, že občas v televizi běží věci, kde deinterlace není potřeba - obvykle filmy nasnímané na filmový pás, který je z principu bez řádkování a 24 fps se na 50 převede zdvojením framů a lehkým zrychlením.nejčastěji tak jsou vysílány přímé přenosy, zprávy a podobněJá měl za to, že prokládání už je součástí standardu (proto MPEG-2 a ne MPEG-1) DVB-T (a nebo aspoň u nás) a téměř každá televize už jen provádí deinterlacing.
Tohle jsem kdysi zkoušel a nějak mi to nefungovalo, ale zase to zkusím.-vo pngTož to nevím. Ono to generuje docela rychle ty jednotlivé framy, dost zabírají a pak je ještě mazat? Když už nic, tak doporučuju aspoň -vf screenshot a klávesu S.
Jak jsem koupil, tak prodávám. Ale jak už jsem napsal, při větších rozměrech se dá jít dolů.Pro průměrnou doporučenou hodnotu CQ=0,25No, nevím. Přijde mi to zbytečně moc.
Chystám se na to, až to budu mít na čem přehrávat (myslím kromě počítače).Při druhém průchodu je dobré uložit do výsledného souboru poměr stran (parametr -force-avi-aspect)No a úplně nejlepší je nehackovat takový starý krám jako je AVI a ukládat to do něčeho normálního.
Dík za upřesnění, někde jsem to četl. A mplayer mi hlásí "MPEG layer-2, layer-3", tak nevím.Audio je ve formátu MP3, takže většinou stačí ho jen překopírovat.Audio je ve formátu MP2 (MPEG-1, Layer II přesněji) o 192kbps.
Jak jsem koupil, tak prodávámV pohodě. Prostě jen dobře mířená rada.
Ale jak už jsem napsal, při větších rozměrech se dá jít dolů.Spíš naopak.
Dík za upřesnění, někde jsem to četl. A mplayer mi hlásí "MPEG layer-2, layer-3", tak nevím.Jde o dekodér (čas od času se vyskytují i ve formě knihovny). Používá to jeden jak pro Layer-II, tak pro Layer-III.
Proč naopak? Když se komprimuje stejný obrázek ve dvakrát větším rozlišení, tak nemá čtyřikrát větší velikost, je to míň. Takže počet bitů na pixel je menší pro větší obrázky. U videa by to mělo být obdobné. JirkaAle jak už jsem napsal, při větších rozměrech se dá jít dolů.Spíš naopak.
Prakticky: Toto pravidlo zase neplatí tak úplně. A to hlavně díky blokové nátuře DCT a max. frekvenci, která se do bloku 8x8 nebo 16x16 vleze. Ano, 2× větší obrázek sice nezabere 2× nebo 4× více místa, ale také to není s tím udržováním kvantizačního koeficientu na stejných hodnotách nijak slavné a prostě musí růst pro zachování transparentnosti (a nebo aspoň stejné úrovně vjemu). A to nás tedy přivádí k otázce co je víc, zda-li menší rozlišení a vyšší kvantizační koeficient a nebo větší rozlišení a menší koeficient (logicky s rostoucím rozlišením by mělo být dáno více prostoru k projevení se energie ve vyšších frekvencích(tedy hranách kupř.) a více prostoru pro rozlití se energiím v nižších frekvencích). Psal jsem tu o tom zápisek (doporučuji začít od posledního odstavce), ale přijde mi že na důkladnou odpověď je tam tomu věnováno hodně málo místa, takže bude-li zájem, nabídnu skript, který snižuje rozlišení a přitom se snaží u obrázku zachovat podobnou velikost (nestoupne přes určitou hranici, ale volí kvantizační koeficient nejbližší nižší) a každý si může porovnat sám.
To podle me vypada jako pokus o sebevrazdu. Ukladani png za behu, cili pri 30 snimcich za sekundu? Nezkousel jsem, ale pri vyssim rozliseni nevim nevim. Jedine, ze by byla komprese skoro nulova, ale to abych pak radsi ukladal rovnou na externi terabajtovy disk.Tohle jsem kdysi zkoušel a nějak mi to nefungovalo, ale zase to zkusím.-vo pngTož to nevím. Ono to generuje docela rychle ty jednotlivé framy, dost zabírají a pak je ještě mazat? Když už nic, tak doporučuju aspoň -vf screenshot a klávesu S.
Tiskni Sdílej: