Díky, za shrnutí, bude trvat dýl než to strávím. u HEVC (v nastavení, kdy bitraty vychází stejně velké zhruba, čili snížit kvalitu) pozoruju horší kvalitu kde náhle něco prolítne scénou, je to kostičkované.
Zato u AVC vidím trochu banding na obloze při švenkování. (není to porovnatelné s předchozí větou)
Kóduju převážně abych zmenšil bitrate ne rozumnou míru pro traffic přes net (3-6Mbps ale i 9-15Mbps pro 4K), ale zachoval v rozumné míře kvalitu.Nechci aby 4K vypadalo jako 1080 když bude mít 4x vyšší bitrate. Zároveň na kvalitě ale tolik nebazíruju, abych paušálně nadstřelil crf, že to bude mít 10Mbps u FHD a 25 u 4K. když bud mít A aby to trochu valilo, čili tak >2x speedup. Což u HEVC je 0.4-0.8x.
A archivní kvalitu (to co vypadne ze střižny ) neřeším, objevil jsem, že to umí při top kvalitě 40Mbps HEVC a ještě je to 3x rychlejší než dosud XAVC(který jel přes 100%CPU) při 60%CPU a 80% GPU (je to od oka), tedy celkově nižší spotřebě.
Chápu, ten problém s náhlým "rozpadnutím" obrazu u QSV je právě daný tím, že to v žádném režimu s HEVC neumí adaptivně vkládat I snímky na střihy. U H.264 tohle právě zapnete zároveň s tím look-aheadem, u ostatních VBR, CBR režimů v H.264 se to dá zapnout přes parametr -adaptive_i 1. U HEVC to ignoruje, což může zapříčinit to, že na střihu nebo momentu, kde se prudce změní scéna, může rozsypat.
Jinak ještě k té bitové hloubce 8 vs 10. Strašně záleží, co máte za vstupní materiál. Nemusí jít jen o třeba 3D animace, ale například i scény ve kterých vyskytují přirozené gradienty. Zkuste si schválně zakódovat třeba tenhle můj testovací obrázek.
https://ibb.co/HCfqHNr Přestože vstupní png má jen 8 bitů, tak to prostě slušně nezakódujete bez toho, abyste použil 10 bit enkodér v jakémkoliv ze standardních ztrátových formátů (H.264, HEVC, VP9).
To je třeba důvod, proč většinou pro archiv preferuji 10bit, ve vyšším bitrate a pokud to nepodporuje hardware, tak x264 (která pořád jede velice hezky, na dnešních procesorech typ. okolo reálného času).
Je to reálný problém. Protože mnoho dekodérů není kompatibilní s 10bit kodeky, takže na to nejde úplně jednoduše přejít třeba při streamování. Pokud má někdo nasvícenou scénu tak, že z toho ten banding leze třeba na youtube, typicky nezbude nic jiného, než scénu předělat (např. dát do pozadí nějakou texturu atp.)
https://www.youtube.com/watch?v=N0gyMViIbUAKde bych se o tom QSVEnc něco dočetl, nějaký představení a tutoriál? a vůbec co je to zač,- co mi to v kódování videa umožní víc?
To jsou takové alternativní transkódovací nástroje od pána, nebo paní Rigaya
https://github.com/rigayaJe tam buď NVEnc pro NVIDIA nebo QSVEnc pro Intel.
Snaží se to maximálně využít možností pro celou HW akcelerovanou pipeline (dekóding, filtry, enkóding) na dané platformě. Pro ostatní neakcelerované formáty a filtry to používá knihovny z ffmpegu.
Pro někoho to může být zajímavé tím, že nemusí nutně znát kolikrát šílenou syntaxi toho jak tu pipeline "s hwupload, hwdownload filtry" udělat v normálním ffmpegu.
Osobně to moc nepoužívám na kódování, mám spousty věcí v ffmpegu, ale spíš na porovnávání případně rychlé zjišťování vlastností dané karty/ovladače, protože to má relativně často aktualizované rozhraní na ty knihovny a dokáže to hezky vypsat v přehledu.
A jak je na tom podpora amd rdna3 pro windows +linux cosetýče hw enkodovani ? Jake api využivá? Jak. Si vede v srovn. s nvidia a intel qsv?
Moje subjektivní hodnocení.
kvalita pro normální transkódování - ne streaming, kde je třeba preferovaná nejmenší latence)
H264 - QSV > NVENC >> AMF
HEVC - NVENC > AMF > QSV (protože to nemá ten lookahead, resp. adaptive I)
Pro streamování a trochu vyššími bitraty (stream rychlejší linkou na CDN, kde to stejně převaří na finální dist. formáty), se to může trochu srovnávat, tam bych řekl, že s povypínanými pokročilými funkcemi je QSV a NVENC víceméně srovnatelné, AMF o trochu horší (výrazně se to zlepšilo okolo posledních RDNA).
A teď ještě ty provozní vlastnosti (mám na různých místech všechny tři vendory v různých generacích).
Nejraději mám na video NVIDIA karty. Proč?
Mají sice své proprietární API (NVENC), ale jejich ovladače chodí relativně použitelně na obou systémech (bavím se o video části ne o Waylandu, ale i tam se to téměř srovnalo s AMD).
a rozběhnete to na většině jader.
NVENC knihovna nemá žádné další závislosti na Linuxu, chodí v pohodě i na systémech, kde z principu nejsou patentově zatížené kodeky (RHEL, Fedora, OpenSUSE bez dalších repo)
Je tam relativně nejmíň bugů a nedotažených věcí.
Enkodéry jsou rychlé - což se projeví v paralelním kódování (server). Např. i slabší Quadro/GF karty dovedou kódovat současně tři H.264 FullHD streamy v 50p a rychlost nepadne pod 2x realtime.
U Intelu je problém s tím, že ne všechny deklarované funkce chodí, např. ten look-ahead je potíž, kterou léta nikdo neřeší.
AMD má v podstatě dvě API (obě fungují v ffmpegu).
AMF je jejich proprietární rozhraní podobně jako NVENC. Je součástí jen jejich Windows ovladače, nebo AMDGPU-Pro na Linuxu. AMF poskytuje plnou kontrolu nad všemi vlastnostmi enkodéru.
Problém tam je v tom, že ovladač chodí jen se specifickými jádry v určitých distribucích (u ostatních se to možná povede, možná ne). I pro velmi rozšířené Ubuntu vychází typicky několik měsíců za novým releasem. Také relativně dost odstřihávají podporu starších karet (cca 5 let a šlus).
V určitých jiných ohledech je zároveň i problematičtější (3D výkon, může mít více bugů), než open source ovladač, co je přímo v jádře + v knihovnách MESA.
Ten kernel+mesa ovladač je fajn, chodí out of box pro většinu věcí. Také je to téměř nejlepší ovladač na Wayland kompozitory z hlediska kompatibility. Ale nemá proprietární AMF.
Místo toho se dá použít rozhraní VAAPI, které řeší akceleraci dekódování i kódování a používá na to MESA. Ale jsou tam dva háčky.
První je ten, že nemá všechny možnosti a parametry od HW, které nabízí proprietární AMF.
Druhý je ten, že MESA musí být zkompilovaná s podporou těch kodeků, opět kvůli potencionálním licenčním problémům v některých zemích. Některé distribuce to až tak neprožívají, jiné zase ano a pak jste odkázán na repozitáře třetích stran (s různým úspěchem), případně svá sestavení a kompilace.
Navíc má AMD na Windows, podle mě, daleko zabugovanější proprietární ovladače než NVIDIA.
Nakonec ještě ohledně kvality kódování přidám extenzivní rozbor od Tom's hardware.
Dole je obrázek s mega tabulkou.
https://www.tomshardware.com/news/amd-intel-nvidia-video-encoding-performance-quality-testedK tomu jen dvě poznámky.. Používají jednu objektivní metriku VMAF, která se nemusí vždy shodovat se subjektivní preferencí. Druhá je ta, že je to test primárně pro gamesníky na streaming, schválně povypínali některé pokročilé věci v těch enkodérech, aby snížili latenci a zároveň nesrovnávali hrušky s jablkama, pokud to jeden z testovaných hw nepodporuje.
15 Odpovědí
6412 Zhlédnutí