DuckDuckGo AI Chat umožňuje "pokecat si" s GPT-3.5 Turbo od OpenAI nebo Claude 1.2 Instant od Anthropic. Bez vytváření účtu. Všechny chaty jsou soukromé. DuckDuckGo je neukládá ani nepoužívá k trénování modelů umělé inteligence.
VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
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: