Na akci Made by Google 2026 (YouTube) bude oficiálně představena jedenáctá generace telefonů Pixel s novým čipem Google Tensor G6 a hodinky Pixel Watch 5.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) se spolu s partnery z dalších zemí připojil ke společnému upozornění (Joint Cybersecurity Advisory) týkajícímu se probíhající kybernetické kampaně skupiny LAUNDRY BEAR zaměřené na uživatele e-mailové platformy Zimbra Collaboration Suite (ZCS) nejméně od července 2025. NÚKIB doporučuje organizacím využívajícím Zimbra Collaboration Suite neprodleně ověřit, zda
… více »Intel vydal 42 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20260811 mikrokódů pro své procesory.
Sny o designu GNOME Shellu, článek s náhledy a videi, představuje dlouhodobou vizi týmu GNOME pro vylepšení uživatelského rozhraní GNOME Shellu. Zatímco nedávné verze přinášely spíše drobné úpravy, designéři nyní plánují zásadnější změny.
Byla vydána nová verze 10.5 sady aplikací pro SSH komunikaci OpenSSH. Přináší řadu důležitých bezpečnostních oprav, vylepšení funkcí a oprav chyb. Nově vyžaduje podporu ECC (Elliptic Curve Cryptography) v libcrypto, včetně křivky NISTP521.
Byla vydána nová verze 10.6 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. S novými obrazy pro Orange Pi 4 Pro, Orange Pi Zero 3W a Odroid M1/M1S/M2. Přehled novinek v poznámkách k vydání.
Námořní drony používané elitními jednotkami britského královského námořnictva tajně posílaly údaje do Číny. Stroje vybavené čínskými komponenty měly být využívány pro vojenské operace na Blízkém východě. Kamery na dálkově řízených průzkumných člunech K3 Scout byly vybavené součástkami, které bez vědomí britského námořnictva odesílaly informace do spojeného zařízení v Číně. Britské námořní síly využívaly flotilu námořních dronů
… více »Alza.cz nabízí herní AlzaPC s předinstalovaným Linuxem (YouTube), konkrétně s linuxovou distribucí Bazzite (Wikipedie).
Squeak (Wikipedie), open source implementace programovacího jazyka a prostředí Smalltalk, byl vydán ve verzi 6.1. Přehled novinek v poznámkách k vydání.
V Linuxu v KVM byla nalezena a v upstreamu již byla opravena kritická zranitelnost Zapscape aneb CVE-2026-64561. Root na hostovaném počítači (virtuální stroj) může obejít izolaci a získat plnou kontrolu nad hostitelským systémem (DoS útok nebo vzdálené spuštění kódu s právy roota). Na obou hlavních architekturách – Intel i AMD. Zranitelnost v Linuxu existovala 6 let (od července 2020 do července 2026).
Ř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: