V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Yazi je správce souborů běžící v terminálu. Napsán je v programovacím jazyce Rust. Podporuje asynchronní I/O operace. Vydán byl v nové verzi 25.12.29. Instalovat jej lze také ze Snapcraftu.
Od soboty do úterý probíhá v Hamburku konference 39C3 (Chaos Communication Congress) věnovaná také počítačové bezpečnosti nebo hardwaru. Program (jiná verze) slibuje řadu zajímavých přednášek. Streamy a záznamy budou k dispozici na media.ccc.de.
Byl představen nový Xserver Phoenix, kompletně od nuly vyvíjený v programovacím jazyce Zig. Projekt Phoenix si klade za cíl být moderní alternativou k X.Org serveru.
XLibre Xserver byl 21. prosince vydán ve verzi 25.1.0, 'winter solstice release'. Od založení tohoto forku X.Org serveru se jedná o vůbec první novou minor verzi (inkrementovalo se to druhé číslo v číselném kódu verze).
Wayback byl vydán ve verzi 0.3. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána verze 4.0.0 programovacího jazyka Ruby (Wikipedie). S Ruby Box a ZJIT. Ruby lze vyzkoušet na webové stránce TryRuby. U příležitosti 30. narozenin, první veřejná verze Ruby 0.95 byla oznámena 21. prosince 1995, proběhl redesign webových stránek.
je to takyto prikaz:
mencoder tv:// -tv driver=v4l2:input=0:norm=PAL:width=384:height=288:brightness=-10:contrast=0:saturation=0:hue=0
-vop lavcdeint -vf pp=lb -oac mp3lame -lameopts cbr:br=64:mode=3:vol=4
-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1000:vhq -o /home/michal/skuska.avi -endpos 2:0:0
No a na ostruhanie filmou pouzivam zase avidemux je super.
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)
Čili předpokládám, že se bavíme o software pro Linux. Jinak MPlayer i Avidemux mají i windowsové verze, jestli chceš nahrávat ve Windows, doporučuji programem VirtualVCR do AVI souborů, třeba kodekem XviD, nebo si stáhni ffdshow, tam jsou i ty kodeky z FFmpegu. Editovat můžeš klidně tím multiplatformním Avidemuxem nebo windowsovým VirtualDubem.
, ale myslím si, že na Živě.cz je fórum, které se pro tento dotaz hodí lépe.
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ší.
))
take totiz nechci grabovat do vice jak 20G souboru a pod....
Na vse mam skripty, mohu poslat ....
Promin ....
Ja dokazu celkem nastavit XviD, aby mi nahraval kvalitne, realtime (tedy 1 pruchod) ale s vyslednym videem se neda nic moc delat ....
))
Zato kdyz nahravas bez komprese, tak pak mas maximalni kvalitu a muzes si vysledne video prevest do mpeg2/mpeg4 dle libosti, chces-li usetrit misto, pouzijes mjpeg a pak -> mpeg2/mpeg4, to nemluvim o filtrech atd, vetsina je lepsi pouzit postprocesove .....
Jestli mam necemu verit co tu pises, posli tedy nejake skripty (pocitam ze se stale bavime ograbovani v linuxu ...:)) a ja vyzkousim....
Jinak je velmi ODVAZNE (mozna i nesmyslne) tvrdit, ze mpeg4 MUZE (nemuze neni na to staveny) byt treba stejne kvalitni jako mpeg2 DVD format .... to je preci naprosta blbost ....
Nebo mam DVD prehravat - prevadet pres Xvid ????
-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.
))
Nahravam takto:
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 ..... ???
na mail "matous podtrzitko jan tecka fialka na seznam.cz"
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.
Programy najdete na www.rpmseek.com stačí název vložit do vyhledávače a kouknout se podle přípony na balíček k vaší distribuci.
Tiskni
Sdílej: