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.
Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.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 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Josef Průša oznámil zveřejnění kompletních CAD souborů rámů tiskáren Prusa CORE One a CORE One L. Nejsou vydány pod obecnou veřejnou licenci GNU ani Creative Commons ale pod novou licencí OCL neboli Open Community License. Ta nepovoluje prodávat kompletní tiskárny či remixy založené na těchto zdrojích.
Ř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: