Závažná zranitelnost ohrožuje více než 100 modelů tiskáren Lexmark (pdf). Společnost Lexmark vydala bezpečnostní záplatu firmwaru. Opravovaná zranitelnost může vést ke vzdálenému spuštění libovolného kódu (CVSSv3 9.0).
Byla vydána nová major verze 2.0.0 toolkitu SQLAlchemy (Wikipedie) přinášejícího do programovacího jazyka Python podporu SQL (Structured Query Language) a ORM (Object–relational mapping). Detaily v přehledu novinek a v průvodci migrací.
Byla vydána verze 1.67.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Byla vydána nová verze 23.1 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense od této verze postavený na FreeBSD místo HardenedBSD. Kódový název OPNsense 23.1 je Quintessential Quail. Přehled novinek v příspěvku na blogu.
Sdružení CZ.NIC, správce české národní domény, zveřejnilo Domain Report 2022, ve kterém upozorňuje na zajímavá data spojená s doménou .CZ. Na konci roku 2022 bylo evidováno celkem 1 463 116 domén. Průměrně bylo měsíčně zaregistrováno 17 193 domén, přičemž nejvíce registrací proběhlo v listopadu (23 581) a nejméně pak v červenci (13 199). Na rozdíl od předchozích let byl poprvé v historii zaznamenán propad v počtu domén zabezpečených
… více »Infisical je open source nástroj s end-to-end šifrováním pro snadnou správu a synchronizaci proměnných prostředí (.env souborů) napříč vývojovým týmem, zařízeními a infrastrukturou. Zdrojové kódy jsou k dispozici na GitHubu.
Interaktivní rozšiřovatelný editor pro práci se strukturovanými binárním daty GNU poke byl vydán v nové major verzi 3.0. Přehled novinek v poznámkách k vydání.
Kosťa Šiškov v posledních několika týdnech na svém blogu vzpomínal na různé přispěvatele do projektu FFmpeg: konec forku Libav, úvod, …, shrnutí.
Byla vydána nová verze 3.7 frameworku Flutter (Wikipedie) pro vývoj mobilních, webových i desktopových aplikací a nová verze 2.19 souvisejícího programovacího jazyka Dart (Wikipedie).
Wine 8.0 bylo vydáno. Přehled novinek v poznámkách k vydání. Tato verze dokončuje přechod na Portable Executable moduly a WoW64 (volání 64bitových knihoven ze 32bitových aplikací).
Ř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: