V tom použitém příkazu tam nikde nemáte deklarovaný bitrate, ani kvalitu u výstupního video streamu.
Navzdory nadpisu threadu to nebude HEVC bez komprese (to byste měl obří bitrate)
Také jsou tam nějaké úplně zbytečné parametry - mapování, ignore_unknown a copy_unknown se vylučují atp., experimental nepotřebujete, ale to nezpůsobuje ten problém, co řešíte.
ffmpeg má možnost určité kodeky kódovat více enkodéry. Tzn. když máte NVIDIA kartu, tak se pro HEVC (H.265) nabízí buď hevc_nvenc, nebo softwarový libx265, který funguje všude. (jsou ještě jiné alternativy jako kvazaar, svt-hevc, ale to je specifické pro konkrétní kompilaci).
Různé enkodéry jsou různě namapované na parametry řízení výst. bitrate / kvality v ffmpegu. Tzn. můžete sice použít některé parametry (např. -q:v <číslo>, -maxrate, -minrate), ale pokud tenhle konkrétní parametr není namapován, nebo enkodér není ve správném režimu, tak to nemá vůbec žádný efekt i když je uvedete.
Pak jsou tam ještě specifické parametry pro daný enkodér. Doporučuji si prohlédnout (neznamená, že je vždy dobré je nastavovat) pomocí vestavěného helpu, protože máte jistotu, že je to k té konkrétní verzi enkodéru/knihovny, co můžete použít. Např. ffmpeg -h encoder=libx265 nebo ffmpeg -h encoder=hevc_nvenc
Obecně platí, že x265 enkodér postkytuje kvalitnější výstup vzhledem k bitrate než hardwarové enkodéry (NVENC, Intel QSV, AMD AMF), ale samozřejmě výstup se kóduje déle, pokud nemáte nějaký mega stroj.
Ale ve většině případů jsou výstupy samozřejmě použitelné i s těmi hw enkodéry, jen musíte trochu přitlačit na bitrate.
U lib_x265 bych doporučil (beru standardní používání, nikoliv nějaké patologické obrazce nebo super komplikované scény, kdy se potřebujete za každou cenu trefit do co nejmenšího souboru i za cenu násobně delšího kódování třeba víceprůchodem) zůstat u CRF řízení ( vysvětlení
https://slhck.info/video/2017/02/24/crf-guide.html ).
Tzn. pro váš případ, když to zjednoduším.
ffmpeg -i vstup.mp4 -c:a copy -c:v libx265 -crf 25 vystup.mp4
Čím vyšší číslo CRF, tím menší datový tok. Není to lineární a v podstatě platí, že pro menší rozlišení např. SD PAL, potřebujete vyšší CRF např. 18, a pro vyšší rozlišení pak stačí naopak nižší CRF, např. 25-28 pro UltraHD. Dolaďte podle potřeby.
U NVENC je to trochu složitější, protože CRF, q:v ignoruje. A v podstatě jsou při jednoprůchodu použitelné dva parametry: CBR, kdy se snaží udržet okolo zadaného bitrate. QP (quantization parameter), kdy se enkodér snaží udržet relativní degradaci obrazu a může fluktuovat bitrate - což je trochu podobné zmíněnému CRF a také platí, že vyšší číslo znamená vyšší degradaci a menší bitrate.
pro CBR s NVENC stačí nastavit bitrate pro stream a většinou je to naprosto dostačující
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i vstup.mp4 -c:a copy -c:v hevc_nvenc -b:v 15M vystup.mp4
pro QP je pak potřeba přepnout režim rate control (přes parametr rc)
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i vstup.mp4 -c:a copy -c:v hevc_nvenc -rc constqp -qp 28 \
vystup.mp4
Jak tu bylo zmíněno, tak jsou tam i další paramtery, třeba pro ten rc-lookahead (načítá snímky dopředu, aby lépe rozdistribuoval bitrate) a implicitně to pak zapíná dynamické vkládání intra a b-snímků. Což může být zajímavé pro rychle se měnící videa (což není ten případ satelitních snímků) s menším bitrate.
Případně je tam i možnost použít další specifické kvantizační mechanismy nad rámec standardního rc. spatial (v rámci snímku) a temporal (mezi snímky) přes parametry spatial_aq, resp. temporal_eq. Ale zpomalí to kódování a musíte si vyzkoušet, jestli to něco udělá.
Poslední příspěvky
