Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 25.8.1. Přehled novinek v Changelogu.
Včera večer měl na YouTube premiéru dokumentární film Python: The Documentary | An origin story.
Společnost comma.ai po třech letech od vydání verze 0.9 vydala novou verzi 0.10 open source pokročilého asistenčního systému pro řidiče openpilot (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 4. snapshot Ubuntu 25.10 (Questing Quokka).
Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
Společnost Framework Computer představila (YouTube) nový výkonnější Framework Laptop 16. Rozhodnou se lze například pro procesor Ryzen AI 9 HX 370 a grafickou kartu NVIDIA GeForce RTX 5070.
Google oznamuje, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Tato politika bude implementována během roku 2026 ve vybraných zemích (jihovýchodní Asie, Brazílie) a od roku 2027 celosvětově.
Byla vydána nová verze 21.1.0, tj. první stabilní verze z nové řady 21.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools a Libc++.
Alyssa Anne Rosenzweig v příspěvku na svém blogu oznámila, že opustila Asahi Linux a nastoupila do Intelu. Místo Apple M1 a M2 se bude věnovat architektuře Intel Xe-HPG.
Občas není od věci vyslovit něco, za co se upaluje nebo ukamenovává. Nic není totiž tak jednoduché, aby byla pravda vždy jediná a na první pohled zřejmá.
Když jsem před pár dny psal o stavu programů v oblasti videostřihu, přišla v diskusi řeč také na řádkový proklad. Prokládané řádkování je především dílem televizní historie, nicméně ještě nějakou dobu s ním budeme muset bojovat.
K napsání tohoto textu jsem se rozhodl poté, co jsem před několika hodinami zahlédl v televizi (Prima?) reklamní spot, snad nějaký teleshopping, který měl prohozené půlsnímky. Něco takového musím samozřejmě považovat za amatérismus nejhrubšího zrna (u čerstvých záběrů "z bojiště", např. z Iráku, se to dá tolerovat - u reklamy je to ale jako pěst na oko), který v celoplošné televizi nemá co pohledávat. Nicméně se stále ukazuje, že problematika prokládaného řádkování dokáže spoustu lidí (včetně mě) pořádně potrápit.
Vznik řádkového prokladu se datuje do počátků televizního vysílání. Zatímco běžný film promítaný s frekvencí 25 snímků za sekundu lze vcelku bez problémů sledovat (vždy nějakou dobu svítí celý snímek, pak se film posune dál), na televizní obrazovce to nejde. Elektronový paprsek dopadá pouze na jediný bod a dosvit luminoforu je příliš krátký, než aby taková frekvence stačila. Obraz by příliš blikal.
Proto vzniklo prokládané řádkování - snímkový kmitočet je dvojnásobný, přitom ale není potřeba zvětšovat šířku pásma. Obraz se kreslí po půlsnímcích, nejdřív liché řádky a pak sudé nebo naopak. Pro klasickou analogovou televizi s tím není problém. Ostré hrany se sice poněkud chvějí, ale jinak není nic, co by nějak zásadně bránilo použití takové metody. To je také důvod, proč prokládané řádkování vydrželo dodnes.
Ovšem s příchodem digitální techniky nastal problém. Digitalizovaný signál se musí nějak zaznamenat, zpracovávat a posléze případně převést opět na analogový. V zásadě řešíme dvě situace: jednak odstranění řádkového prokladu, a zadruhé naopak jeho správný průchod celým řetězcem.
První situace (videozáznamy, které budou přehrávány na počítači nebo jinde, kde se nepracuje s prokládaným řádkováním) je svým způsobem jednodušší. Netrápí nás, jaké je pořadí půlsnímků, stačí "jen" uspokojivě vyřešit převod na neprokládaný obraz. Lze například zdvojnásobit snímkovou frekvenci (z půlsnímků udělat celé snímky), použít jen sudé či liché půlsnímky, smíchat půlsnímky, interpolovat nebo použít nějaký adaptivní algoritmus (aplikuje na různé části snímku vždy nejvhodnější metodu). Kdysi jsem o tom něco napsal, kdo chce, může si to přečíst.
Mnohem horší je to v případě, že i na výstupu bude prokládané video. Pak právě hrozí, že budou půlsnímky v opačném pořadí a výsledek bude otřesný (jako ve zmíněné reklamě). Zvlášť nepříjemné to je, když stříháme dohromady z několika zdrojů a každý má jiné pořadí půlsnímků.
Důležité je vědět, jaké pořadí je na vstupu a jaké má být na výstupu. Obvykle to bývá někde uvedeno (typicky pod názvem Field Dominance nebo Field Order) - setkáme se s označením Top Field First (TFF, též Upper Field First, znamená "horní pole" první, tedy nejdřív půlsnímek s lichými řádky) a Bottom Field First (BFF, též Lower Field First, "dolní pole" první, tedy nejdřív půlsnímek se sudými řádky). Ne vždy je to uvedeno, platí ovšem pravidlo, že pro DV PAL (tedy to, co leze z Mini-DV nebo D8 kamery) se používá BFF, kdežto pro "klasický" PAL (tedy normální televizní signál; často pak i to, co leze z televizní karty v počítači) naopak TFF. DVD kamery často zaznamenávají jako TFF, to aby střih současně z různých druhů kamer byl zábavnější.
Pokud pracujeme s videem pouze z jednoho zdroje (třeba jedné kamery nebo digitalizační karty), je to poměrně jednoduché. Stačí znát pořadí půlsnímků a při celém zpracování ho všude nastavovat, aby nevznikly problémy. U výstupu na pořadí obvykle nezáleží (pokud je správně deklarováno) - v opačném případě bychom ho museli opět řešit - viz níže.
Nejhorší to je, když máme buď ke střihu video s různým pořadím půlsnímků nebo když má být výstup v opačném pořadí než zdroj. Pak se musí pořadí půlsnímků otočit. Někoho by mohlo napadnout, že se prostě přehodí dvojice řádků - jenže to je hodně špatný nápad, protože tím se řádky dostanou do špatné polohy a výsledek bude vypadat divně. Musí se na to jít jinak.
Používají se v zásadě dvě metody. První z nich odstraní první řádek, čímž se první stane z druhého. Logicky nám pak jeden řádek chybí dole, což se většinou řeší zdvojením posledního řádku. Většinou to nevadí, na většině televizních obrazovek je tento řádek stejně mimo viditelnou oblast. Lze to udělat samozřejmě i obráceně, tedy odstranit poslední řádek a zdvojit první.
Pokud by byla předchozí metoda z nějakého důvodu neakceptovatelná, lze použít jinou. Ta spočívá v tom, že se půlsnímky vůči sobě posunou. To ovšem znamená, že nám na začátku a na konci zbyde vždy jeden samostatný půlsnímek, k němuž nemáme druhý do páru. Cest k řešení je více - buď se prostě zahodí, nebo se druhý půlsnímek nějak dopočítá. Časový posun je samozřejmě potřeba zohlednit i ve zvukové stopě a časovém kódu, aby nebyly oproti obrazové stopě posunuty.
Nyní zbývá už jen otázka, jak to všechno prakticky realizovat. Uvedu pár příkladů pro mencoder
. Tak nejdřív odstranění řádkového prokladu:
mencoder -vf kerndeint -o vystup.avi vstup.avi
Příklad ukazuje využití adaptivního filtru od Donalda Grafta s výchozími hodnotami. Filtr lze parametrizovat, např. změnit práh pro zapínání algoritmu (pod prahem se řádky ponechávají beze změny). Přímo v mencoderu jsou k dispozici ještě další filtry pro odstranění řádkového prokladu. Pro prohození pořadí půlsnímků lze použít toto:
mencoder -vf phase -o vystup.avi vstup.avi
Filtr lze opět v případě potřeby parametrizovat, většinou to však není třeba. Funguje na základě časového posunu půlsnímků, jedná se tedy o druhou zmíněnou metodu. Metoda první, tedy odstranění prvního řádku, zde není (pokud vím) přímo k dispozici. Lze ji ale částečně nahradit tímto:
mencoder -vf crop=720:575:0:1,scale=720:576:ilaced -o vystup.avi vstup.avi
Zmíněný příkaz odpovídá standardnímu PAL videu (720 x 576). Nejprve ořízne obraz na rozměr o 1 řádek nižší (s počátkem ve druhém řádku), pak ho zvětší na původní velikost (bez narušení řádkového prokladu). Je jasné, že zdvojený řádek dole "strašit" nebude, ale zase mírně klesne kvalita obrazu. Nevím, jak u mencoderu docílit zdvojení posledního řádku (a vyhnout se tedy zvětšování obrazu), ale s jinými programy to docílit lze.
Snad tento text aspoň trochu přispěje ke zlepšení povědomí o řádkovém prokladu a boji s jeho nástrahami. Takové klepající se videa s chybným pořadím půlsnímků opravdu nejsou ke koukání.
Tiskni
Sdílej:
Zatímco běžný film promítaný s frekvencí 25 snímků za sekundu lze vcelku bez problémů sledovatAFAIK se pleteš - každý snímek dvakrát blikne. Kdyby jenom chvíli svítil, bylo by znát blikání, když obraz zhasne a film se přesouvá na další políčko.
Před několika hodinami - nebyla to náhodou ta dvouhodinovka, ve které má vyhrazený čas regionální vysílání?To nevím. Přijímáme Primu ze 2 různých vysílačů, každý je v jiném kraji. Je možné, že to bylo zrovna regionální vysílání.
AFAIK se pleteš - každý snímek dvakrát blikne. Kdyby jenom chvíli svítil, bylo by znát blikání, když obraz zhasne a film se přesouvá na další políčko.Abych řekl pravdu, profesionální promítačky používané v kině do takové míry neznám. Ale ty amatérské, se kterými jsem se setkal (film 8 a 16 mm), svítily po celou dobu nehybnosti filmu (zhasly až pro jeho posun). Navíc jsem se teď podíval do Wikipedie, a tam píší cosi o tom, že u moderních projektorových závěrek se tato věc (dvoj- nebo i trojnásobná frekvence) skutečně vyskytuje. Je tedy otázka, s čím se člověk ve starších kinech doopravdy setkával - každopádně dívat se na to dalo docela dobře.
V tom případě by například nekompenzovaná zraková díra v místě slepé skvrny znamenala lepší zrak.Psal jsem - cituji se: "Pokud budu kvalitu zraku posuzovat podle toho, jak přesně vidí to, co skutečně vidí" Skutečně vidíš to, na co se díváš. Věci, na které se díváš, žádnou zrakovou díru nemají. Takže ještě jednou a polopatičtěji - posuzuji kvalitu zraku podle toho, jak přesně dokáže zachytit optické jevy odehrávající se ve vnějším prostředí.
platí ovšem pravidlo, že pro DV PAL (tedy to, co leze z Mini-DV nebo D8 kamery) se používá BFF, kdežto pro "klasický" PAL (tedy normální televizní signál; často pak i to, co leze z televizní karty v počítači) naopak TFF.Drobná otázka: Kterej píčus navrhoval ten DV standard? A nemá taky něco společného s glibc? :)
Pěkný blogpost.Díky
Co se stane, když výstup z DV kamery deinterlecuji pomocí TFF metody? Bude obraz nějak poškozen?Bude záležet na tom, jaký algoritmus se použije. Při smíchání půlsnímků (každý se přepočítá na celý snímek a pak se smíchají) by to nemělo vadit (ale tohle není zrovna moc dobrý algoritmus). Při interpolaci bude záležet na konkrétní implementaci (ale třeba u té od Donalda Grafta je to znatelné). Při přepočtu půlsnímků na celé snímky (se zdvojnásobením kmitočtu) to samozřejmě bude znatelné velice drasticky.
sigwaitinfo
a spol., které jsi doporučoval v jednom z minulých blogů, a funguje to skvěle. Moc díky.
Ohledně odstranění řádkového prokladu - jak dlouho to trvá (vzhledem k délce videa) a jaké jsou (subjektivně) výsledky?To záleží na algoritmu, ale je to relativně rychlá operace (řádově na úrovni reálné délky videa, spíše méně). Výsledky bývají docela slušné.
Jednou jsem se pokoušel opravit prokládané video (tj. zkoušel jsem interpolovat, aby se věci neměnily na shluk čar, když se hýbou nahoru a dolu) a kerndeint, který uvádíš, moc nepomáhal.No, abych se přiznal, osobně
kerndeint
nepoužívám, protože pro tuto činnost nepoužívám ani mencoder
. Používám VirtualDub (pod Windows, ale chodí obstojně i přes WINE), kde je plugin Smart Deinterlace od Donalda Grafta. Ten toho v novějších verzích umí trochu více a je hodně parametrizovatelný, takže se to dá docela dobře vyladit (i když většinou ponechávám výchozí nastavení).
V mencoderu můžeš také zkusit mcdeint
- podle teoretického předpokladu by měl mít nejlepší výsledky, protože analyzuje obraz, snaží se hledat vektory posunu a vypočítávat obraz podle nich. Nemám s ním žádné zkušenosti, možná je opravdu dobrý, možná ne. Každopádně ale potřebuje video předpřipravené převodem na půlsnímků na snímky (se zdvojnásobením frekvence), např. předřazením filtru tfields
. A bude výrazně pomalejší než kerndeint
.
Btw.: Zkoušel jsem použít sigwaitinfo a spol., které jsi doporučoval v jednom z minulých blogů, a funguje to skvěle. Moc díky.
V mencoderu můžeš také zkusit mcdeintJá jsem zkoušel yadiff - rychlost zpracování byla asi tak 0.6 snímku za sekundu, takže jsem to dvouhodinové video nechal na někdy, až bude lepší počítač.