GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.
Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.
Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.
Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.
MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.
Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
Byla vydána nová verze 19 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Řešení dotazu:
Ty na tom C2D děláš encoding videa? Nebo ti stačí jen hw akcelerace při přehrávání?Jednou jsem to zkusil, takže nedělám -:). Jedná se mi o to, jestli by tomu nová grafická karta výrazně pomohla.
Zdar Max
Video si zpravidla pouštím na televizi přes Odroid C2 s Kodi, který zvládá Full HD bez problémů.
JirkaEnkódování videa je sice na CPU pomalejší než na grafice, ale výstup z hardwarového enkodéru GPU je sračka.Máš k tomu nějaký odkaz kde by bylo vidět jaký je rozdíl ve výstupu z CPU vs. GPU?
OP se ptal na reenkódování videopořadů/záznamů a tam má smysl to dělat s vyšší kvalitou.V tom prípade má smolu keďže každé reenkódovanie do stratového formátu spôsobí stratu kvality. A to bez ohľadu na to, či sa použije AI akou sa chvália napr. moderné televízory pri upscalingu.
TL;DR enkódování na GPU je konkurent pro enkódování na CPU ve scénářích typu "špatně ale rychle".Aj reenkódovanie na GPU má prednastavené profily ktoré sa líšia rýchlosťou a výslednou kvalitou. TL;DR Nech si OP vyberie čo mu vyhovuje, a na čo mu stíha sieť, CPU alebo GPU. Reenkódovanie z HEVC do X264 má asi len za účelom podpory starých prehrávačov, kde o kvalitu moc nejde. Podpora AV9 bola v Androide pred vyše 10 rokmi, takže mu ten výsledok asi nikto nebude pozerať na 8K telke. Kedy tam bola pridaná podpora HEVC/H265, o tom radšej pomlčím.
OP se ptal na reenkódování videopořadů/záznamů a tam má smysl to dělat s vyšší kvalitou.V tom prípade má smolu keďže každé reenkódovanie do stratového formátu spôsobí stratu kvality.
Ano, ale lidi to podstupujou. někdy to není tak zlý - je to sice pravda, ale je třeba být pragmatik. Někdy je "má to nevýhodu = blééé nikdy to nebudu dělat, bez výjimky" mentální zkrat.
Jinak jsem chtěl zmínit, ale pak zapomněl, že by možná stálo za to se podívat, kolik mají videa k archivaci v originálním formátu. Televize dneska vysílá v HEVC a bitrate asi nebude až tak vysoký. V takových podmínkách je zisk uspořeného místa vzhledem k potenciální degradaci o dost menší, než když se dřív přeenkódovávaly místem plýtvající DVD v MPEG-2u do H.264. Nemám úplně představu kolik mbps dává české TV vysílání jednomu HD kanálu, ale možná by stálo za to jenom prostě muxovat dumpnutý stream bez dekomprimace/rekomprese a koupit na to HDD místo grafiky.
:~/Videos$ ffmpeg -hide_banner -y -vaapi_device /dev/dri/renderD128 -i FIREPLACE\ \(10\ HOURS\)\ Ultra\ HD\ 4K\ -\ Relaxing\ Fire\ Burning\ Video\ \&\ Crackling\ Fireplace\ Sounds\ kt4Z2AA5Kj0.f315.webm -vf 'format=nv12,hwupload' -c:v vp9_vaapi -global_quality 31 -bf 1 -bsf:v vp9_raw_reorder,vp9_superframe M-vp9_qsv.mkv
Input #0, matroska,webm, from 'FIREPLACE (10 HOURS) Ultra HD 4K - Relaxing Fire Burning Video & Crackling Fireplace Sounds kt4Z2AA5Kj0.f315.webm':
Metadata:
encoder : google/video-file
Duration: 10:00:30.02, start: 0.000000, bitrate: 65 kb/s
Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709), 3840x2160, SAR 1:1 DAR 16:9, 50 fps, 50 tbr, 1k tbn (default)
Stream mapping:
Stream #0:0 -> #0:0 (vp9 (native) -> vp9 (vp9_vaapi))
Press [q] to stop, [?] for help
Output #0, matroska, to 'M-vp9_qsv.mkv':
Metadata:
encoder : Lavf59.27.100
Stream #0:0(eng): Video: vp9 (Profile 0) (VP90 / 0x30395056), vaapi(tv, bt709, progressive), 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 50 fps, 1k tbn (default)
Metadata:
encoder : Lavc59.37.100 vp9_vaapi
[matroska,webm @ 0x557ff48cdc40] File ended prematurely8.52 bitrate=1990.0kbits/s speed=0.872x
frame= 4449 fps= 44 q=-0.0 Lsize= 22641kB time=00:01:28.96 bitrate=2084.9kbits/s speed=0.872x
video:22610kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.139688%
Že sa v defaulte CPU kodeky nepoužívajú na realtime remastering a GPU enkodéry používajú na realtime remastering neznamená že GPU remastering na GPU je menej kvalitný.
"The speed requirement for all platforms was 60 fps."Pouze byla tvůrci testovací metodiky nastavena minimální požadovaná hranice výkonu. Řada z těch 51 videí v testovacím balíku pravděpodobně byla jiného framerate než 60p.
"Some of the participants could not reach speed requirement, but we decided to publish all results anyway to show the current landscape. 50 FullHD video sequences were used.!"Do výsledků pro představu zařadili i ty co tohoto výkonu nedosáhly. Při remasteringu Audio CD v celém procesu nového zpracování původního materiálu pro vznik nového masteru se žádný (re)encoding nemusí vyskytovat (na AudioCD se používá LinearPCM 2x 44,1kHz x 16bit).
kvalite remasteringu cez GPUremasteringu? :D
TL;DR enkódování na GPU je konkurent pro enkódování na CPU ve scénářích typu "špatně ale rychle".Nerozumím video editingu a encodingu natolik, abych mohl něco z toho co jsi napsal rozporovat. Je to pro mne moc odborné. Když se zeptám úplně hloupě, tak ty srovnáváš: SW CPU encoding vs. HW GPU encoding? Mám to chápat tak, že HW GPU encoding je závislý na HW a ovladači HW (respektive ovladači GPU) a ten má určité limity oproti SW CPU encodingu, který limity nemá? Teda jediným limitem jsou možnosti které poskytuje daný video editovací software, který se o encoding stará (DaVinci a podobné softy)? Pokud to tak chápu správně, tak pak se nabízí otázka: Umí dnešní video editovací (encodovací) SW (jako DaVinci atd.) použít GPU pro softwarové (nikoliv hardwarové) encodování? Pokud ano, tak by přece neměl být kvalitativní rozdíl mezi softwarovým encodování na CPU vs. GPU.
preset nebo co dělá quality-controlled variable bit rate crf) a v HW grafické karty, je to značně ořezané, primárně proto, že některé komplexnější volby se špatně paralelizují. Stačí si to zkusit na CPU. Pokud máš dost jader tak rychle zjistíš, že rozhození na více jader (tak od 8 nahoru) pro kvalitnější kódování nepřináší to zvýšení rychlosti, které by člověk očekával. A GPU to jede v desítkách a stovkách jader, tam musí volit jen ty algoritmy, které si nezavazí.
ffmpeg -filter=scale... to škálování se potom z nějakého důvodu počítalo na CPU.
Tiskni
Sdílej: