Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 24.05.0 editoru videa Kdenlive (Wikipedie). Ke stažení brzy také na Flathubu.
David Revoy, autor mj. komiksu Pepper&Carrot, se rozepsal o své aktuální grafické pracovní stanici: Debian 12 Bookworm, okenní systém X11, KDE Plasma 5.27, …
Wayland (Wikipedie) byl vydán ve verzi 1.23.0. Z novinek lze vypíchnout podporu OpenBSD.
Craig Loewen na blogu Microsoftu představil novinky ve Windows Subsystému pro Linux (WSL). Vypíchnout lze GUI aplikaci pro nastavování WSL nebo správu WSL z Dev Home.
V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
1. Xdtv prakticky umi jen mpeg4 kompresi a to me nezajima
2. Problemy se zvukem (prave kvuli te kompresi)
3. Kvalitnejsi obraz ma jak mplayer, tak treba transcode (gv4l)
4. Neni superstabilni (jako mencoder)
5. Neumi prevadet do DVD jako mencoder ve spojeni s transcode
5. Na vsechno mi staci 3 skripty (nahravani, prevod,autorizace+vypaleni)
můj počítač ani jedno neznáMůj počítač zná hry! Heč!
Nebo nahrávat kvalitně v plném rozlišení (768x576 nebo 720x576) a nízkou kompresí (např. MPEG-4 kodekem s kvantizací 3 - třeba těch 10-20 GB za hodinu) a až následně to překódovat.V tomto případě ale rozhodně nepoužívat mpeg4, protože je zbytečně náročný na výkon, výsledný stream je hrozně těžkopádný i pro potřeby základníoho střihu (začátky/konce/reklamy) a hlavně si nejsem jist, jestli vůbec dokáže kódovat každý půlsnímek zvlášť, což je pro nahrávání z analogových zdrojů nutnost. Tohle všechno naopak spolehlivě zvládá MJPEG nebo eventuelně huffyuv (bezeztrátový kodek).
Takže výsledné video doporučuji zakódovat právě kodekem XviD, a zvuk klasicky do MP3 CBR - s tím nebývají žádné problémy.Zvuk neraději ogg vorbis, ale zase už to nejde nacpat do AVI (je potřeba OGM nebo matroska), což může činit problémy technicky méně vyspělým uživatelům windows ;)
1. MP3 CBR jsem doporučil právě proto, že je to ta největší klasika se kterou nejsou problémy.Popravdě, nutnost doinstalovat (do windows) nějaký parser či kodek navíc nepovažuju za problém. To bysme mohli rovnou zůstat u mpeg1.
2. MPEG-4 je nahrávání naprosto v pohodě. Za prvé - můžete ho používat stejně jako MJPEG, tj. samé klíčové snímky, bez odhadu pohybu.Ale ne každý kodek to umí a je to potřeba extra nastavovat.
Tím se sníží HW náročnost a editace je stejně snadná jako u MJPEG.Sníží se určitě, ale třeba můj počítač to bohužel v 7xx x 576 stejně nestíhá, zatímco do mjpeg (picvideo) s velikou rezervou :(
Za druhé - prokládané kódování umí taky.Opět, ne každý kodek to umí a je potřeba to vědět a umět nastavit.
Za třetí - není to vždycky potřeba, protože např. většina filmů (a obecně věci točené filmovou kamerou) nemá prokládaný obrazTo hodně závisí na kvalitě toho přepisu film->video, hlavně synchronizaci. Dost často ten "šev" cestuje. Každopádně je lepší to mít nagrbovaný v půlsnímcích a pak teprv se rozhodovat co stím, než si hned na začátku ty vrátka uzavřít.
Ani u prokládaného obrazu to není nutné takhle nahrávat.Jakto, že ne ? Možná tak, při nějaké extrémní bitrate nebo bezeztrátové kompresi, která nenadělá artefakty a "neslije" mi řádky půlsnímků do sebe.
A za třetí - MJPEG kodeky v Linuxu nejsou nic moc.Aha. Tak to je ale špatný. Pak má asi mpeg4 při grabování svůj význam. BTW, co A/V synchronizace ? Ve woknech to umí kloudně jedinej program (virtualvcr) udržet, protože vypouští/přidává vzorky do zvuku, aby seděla jmenovitá framerate se zvukovou stopou (a občas se mu to taky rozjede). V linuxu se mi to nepodařilo uspokojivě pořešit vůbec :/ Upozorňuju, že řešení typu soubor s framerate 24.997 fps je mi na nic, protože výsledek musí bejt DVD nebo SVCD.
HuffYUV je pak už úplná šílenost pro labužníky, kteří vyžadují 100% kvalitu. Nároky na prostor i na rychlost harddisku (při plném rozlišení) jsou gigantické.Huffyuv je hlavně skvělej jako mezistupeň, pokud potřebuju nejdřív filtrovat a pak teprve enkodovat a nároky na prostor nejsou zase tak propastně větší než u mjpeg. Při dnešních velikostech disků....
Popravdě, nutnost doinstalovat (do windows) nějaký parser či kodek navíc nepovažuju za problém. To bysme mohli rovnou zůstat u mpeg1.Pro spoustu lidí to je nepřekonatelnmý problém (a proto zůstávají u MPEG-1). Ale já jsem myslel spíš něco jiného - např. jsem měl vždycky s OGM problémy i v MPlayeru, podle mých zkušeností prostě MPlayer OGM (a jiné formáty jako ASF atd.) podporuje velmi mizerně (problémy s převíjením, synchronizací...). A nebo s VBR v AVI jsou taky často problémy (i ve Windows). CBR MP3 funguje všude bez problémů, každý program si s tím poradí.
Ale ne každý kodek to umí a je to potřeba extra nastavovat.Ty, co jsou dostupné v Linuxu, to umí, a nastavovat kodek snad musíte v každém případě.
Sníží se určitě, ale třeba můj počítač to bohužel v 7xx x 576 stejně nestíhá, zatímco do mjpeg (picvideo) s velikou rezervou :(Ano, windowsové MJPEG kodeky jsou výborné, ale to je komerční software. Ty, co jsou v Linuxu, jsou pomalejší nebo míň kvalitní. Třeba NuppelVideo má vlastní optimalizovanou variantu MJPEG kodeku (ne standardní MJPEG, ale vlastní, upravený pro realtime zachytávání), který je na linuxové poměry dost rychlý, ale s hnusnými artefakty (vertikální pruhy v obraze). Proto preferuji XviD - naštěstí to můj stroj utáhne.
synchronizaci. Dost často ten "šev" cestuje. Každopádně je lepší to mít nagrbovaný v půlsnímcích a pak teprv se rozhodovat co stím, než si hned na začátku ty vrátka uzavřít.Možná to záleží i na TV kartě a příjmu. U mých dvou karet to vůbec žádný problém není, navíc jakékoli případné drobné "švy" u jinak neprokládaného obrazu se stejně zahladí po snížení velikosti (a i případném vyhlazení obrazu).
Jakto, že ne ? Možná tak, při nějaké extrémní bitrate nebo bezeztrátové kompresi, která nenadělá artefakty a "neslije" mi řádky půlsnímků do sebe.Při vysoké kvalitě, nízké míře komprese, to je OK. Byť to samozřejmě není ideální. Ale uznávám, že zejména pokud se použije metoda č. 1 - hnusný obraz s vysokou MPEG-4 kompresí, pak je to nutné, jinak to prokládání nadělá hroznou paseku.
BTW, co A/V synchronizace ? Ve woknech to umí kloudně jedinej program (virtualvcr) udržet, protože vypouští/přidává vzorky do zvuku, aby seděla jmenovitá framerate se zvukovou stopou (a občas se mu to taky rozjede).Avidemux synchronizuje zvuk videa nahrávaného ve speciálním formátu .nuv (původně program NuppelVideo, ale používá ho třeba i "nástupce" ffv1rec, který je součástí Avidemuxu). Bohužel dost mizerně - pouhým utnutím části zvuku nebo přidáním mezery nebo zduplikováním kousku. To zní příšerně, i když většině lidí to nevadí. Třeba nvrec to umí synchronizovat přímo při nahrávání (taky nějakou úpravou zvuku), ale taky je to dost primitivní - ale tenhle program už dlouho nesleduju. MEncoder to snad řeší vypouštěním/duplikováním video snímků. Tak si vyber - hnusný zvuk nebo trhaný obraz. Pro mě je obojí nepřijatelné. Další mořnost je zmíněná úprava framerate videa na nestanardní hodnotu. Já ale preferuji podle mě naprosto nejlepší metodu - vykašlat se na automatiku a zpracovat zvukovou stopu samostatně. Nejdřív jde o to, zjistit jak se zvuk a obraz rozcházejí. To není problém (zjistit rozdíl synchronizace mezi začátkem a koncem a vypočítat potřebné zrychení/zpomalení). Po nějaké době už získáte nějaký statistický průměr, ono se to na jednom počítači moc nemění, to je skoro konstantní číslo. No a pak jen zrychlit/zpomalit zvukovou stopu. Není-li to postupné rozcházení příliš brutální, pak jsou výsledky výborné a spolehlivé, nepoznáte rozdíl mezi originálním a upraveným zvukem U mě je to např.: sox vstup.wav vystup.wav speed 1.0006 Samozřejmě to číslo se na různém hardwaru liší.
-ovc xvid -xvidencopts fixed_quant\ =2:max_key_interval\ =1:quant_type=mpeg(Kvůli čitelnosti jsem to rozdělil na víc řádků.) A pověz mi, jaký zásadní kvalitivní rozdíl oproti FFmpeg MJPEG vidíš. To by mě opravdu zajímalo.
1. nekompresene -> prevod do mpeg2 NEBO mpeg4
2. mjpeg -> prevod do mpeg2 NEBO mpeg4
tedy ne MEZI mpeg2 a mpeg4... Jinak dik za tip vyzkousim .... A rozliseni ??? To je jedno, nebo plny PAL ???
Muj CPU je Barton na 2,5G = 3.6 P4...
1. Vysledne video je kvalitni asi jako mjpeg (mozna lepsi) ale zabira stejne jako mjpeg, tedy 1 minuta, cca 80 MB .... a zatizeni procesoru v plnem PAL 50 procent ...
2. mjpeg ma stejny obraz tedy, a stejnou velikost, ale v plnem palu je zatizeni procesoru, cca 15 procent ....
Takze k cemu ten xvid, kdyz ho stejne musim prekodovat ..... ???
Vlastně jsem si ještě uvědomil jednu věc k bodu č. 2 - to, jestli používáte MJPEG nebo MPEG-4 (ať už MJPEG-like nebo klasický) na nahrávání je v tomto ohledu irelevantní.Irelevantní to není, jde o rychlost seeku. Při mjpeg je reakce na pohyb po celém videu (tam i zpět) v editoru okamžitá. Jakýkoliv mpeg má hrozné lagy i na velmi rychlých strojích a strašně to zdržuje, obzvlášť při pohybu vzad.
Tiskni Sdílej: