Category: Videó

2025.09 Isarradweg, Donauradweg 01: Achensee, Tegernsee

Egy régóta tervezett és többször is kútbaesett túra végre megvalósult, ráadásul immár kettesben. Az Ausztriát Bajorországtól elválasztó Karwendel hegységből indultunk, eltekertünk a csodálatos Achen tó mellett (Achensee, Achenwald, Achenpass, Achendorf), majd némi erdei csavargás után leereszkedtünk a szintén jóképességű Tegernsee mellé, onnan egy kis bajor mezőgazdaság, majd délután elértük az Isar folyót és Wolfratshausent. Ja, a túra célja végigmenni az Isarradwegen a Dunáig, majd a Donauradwegen eljönni Győrig.
Vagy ameddig sikerül.

2025.10 – Bakonyi bringázások

Házassági évforduló. (Ne kérdezd, hanyadik.) Hosszú októberi hétvége, veszprémi/bakonyi nosztalgia… és két, combos bringatúra. Napi 100 kilométer és 1200-1400 méter szint, murvás erdei utakon. Vadul hangzik, de nem volt annyira az: a két e-bike-ot vittük el terepes túratesztre. Mondjuk az egyik majdnem belehalt.

Megvágta, meglőtte 08: Szkriptelünk

Igényes ember a nyersanyag preparálására kizárólag a Shutter Encoder felület Interpolation opcióját használja. Különösen igaz ez akkor, ha éppen most ruházott be egy meglehetősen erős GPU-ba.

Nézzük, mit is jelent ez a számok nyelvén. Próbakonverzió.
– AVC/30fpsVFR/64mbps videó átkonvertálása HEVC/50fpsCFR/40mbps videóra.
– A videó hossza 42 másodperc.
– A konverzió: 44 perc, azaz az időarány gyakorlatilag 1:60.

Ez azért eléggé lelombozó eredmény. Még akkor is, ha az általában egy napokat feldolgozó videóimban kábé 5 percnyi mobilról felvett nyersanyag van csak. Mivel 1:60 az arány, így ez 5 órányi munka. Amivel nem is lenne különösebb probléma, ha tudnám kötegelni, csak hát úgy, hogy beolvasom a Shutter Encoderbe és egyenként konvertálom át a darabokat, úgy folyamatosan ott kell ülnöm mellette. Nem tudom éjszakára ráküldeni az egészet.

Ekkor jött az ötlet. Mi van a Shutter Encoder mögött? Az ffmpeg. Ami egy parancssori program. Mi lenne, ha megkeresném a megfelelő paramétereket és akkor elég lenne éjszakára csak egy parancsfájlt elindítanom? Felvetettem az ötletet a Gemininek és határozottan csillogni kezdett a szeme. Végre egy igazán nekivaló feladat!

Ehhez képest az első szkript le sem futott. Pedig kipróbáltam először a régi ffmpeg progimmal, majd miután hibára futott, lekaptam a legújabb ffmpeg-et, de azzal is hibaüzenetet kaptam. Elküldtem a Gemininek. Komolyan, érezni lehetett a sértődöttséget a válaszában. Közölte, hogy az első ffmpeg túl régi volt, azért nem ismerte az ő paraméterét, a másik meg túl új és az meg azért. Hiába, nem könnyű a programozók élete, különösen, ha szilíciumból vannak.

Küldött egy újabbat.


@echo off
mkdir "konvertalt" 2>nul
for %%f in (*.mp4) do (
    echo Feldolgozas: %%f...
    ffmpeg -i "%%f" -vf "minterpolate=fps=50:mi_mode=mci:mc_mode=aobmc:me_mode=bidir" -c:v libx265 -crf 20 -preset fast -c:a copy "konvertalt\%%f" -y
)
pause

Ez már lefutott és az eredményvideó minősége is megfelelt. Csak éppen a 42 másodperces videóval 1 óra 44 percet molyolt. Ez 1:148-as arány, kábé 12 órán keresztül dolgozna az 5 percnyi videóval. Hát, van még tér az optimalizálásra.

Első lépés: a minterpolate szűrő és azon belül az mi_mode=mci lecserélése. Az MCI azt jelenti, hogy Motion Compensated Interpolation, Ez a legmagasabb minőségű mód, ami pixelről pixelre elemzi a mozgást a képkockák között, és megpróbálja kiszámolni, hová mozdultak el az objektumok. 4K felbontásnál ez egy matematikai rémálom a CPU-nak, mert másodpercenként 50-szer kell elvégeznie ezt a számítást 8,3 millió pixelre. Ehelyett jön be a framerate szűrő. Ez gyakorlatilag a Shutter Encoderben a Blending algoritmus az Interpolate helyett.
Illetve vedd észre, hogy azt írtam, CPU. A fenti parancs nem használta ki a GPU-t, mint lehetőséget. Ezt is belevettük.


@echo off
mkdir "konvertalt" 2>nul
for %%f in (*.mp4) do (
    echo Feldolgozas: %%f...
    ffmpeg -i "%%f" -vf "framerate=fps=50" -c:v hevc_nvenc -preset p4 -rc vbr -cq 24 -b:v 32M -pix_fmt yuv420p -color_range pc -c:a copy "konvertalt\%%f" -y
)
pause

Lefutott. Piszok gyorsan: 31 másodperc. Csak hát a minőség… az nem lett jó. Blőrözött.
(Emellett vegyük észre, hogy itt történt egy apró színhelyesség-korrekció is.)
Mondjuk úgy, hogy a nemtetszésemet fejeztem ki. Maradjon inkább az Interpolate szűrő, csak valamivel gyengébb minőségben.


@echo off
mkdir "konvertalt" 2>nul
echo --- INDUL AZ OPTIMALIZALT EJSZAKAI MUSZAK ---

for %%f in (*.mp4) do (
    echo Feldolgozas: %%f...
    :: A minterpolate itt az alap (gyorsabb) MCI modot hasznalja, ahogy a Shutter Encoder is
    ffmpeg -i "%%f" -vf "minterpolate=fps=50:mi_mode=mci" -c:v hevc_nvenc -preset p4 -rc vbr -cq 24 -b:v 32M -pix_fmt yuv420p -color_range pc -c:a copy "konvertalt\%%f" -y
)

echo --- MINDEN FAJL KESZ! ---
pause

Visszajött a minterpolate szűrő, viszont a Gemini elhagyta az “mc_mode=aobmc:me_mode=bidir” paramétereket. (Átlapolt blokk-alapú mozgáskompenzáció, illetve kétirányú becslés.)
A szkript 55 perc alatt futott le, az már közelített a Shutter Encoder eredményéhez, viszont a mozgás még mindig blőrözött.


@echo off
setlocal enabledelayedexpansion
mkdir "konvertalt" 2>nul

for %%f in (*.mp4) do (
    echo Feldolgozas: %%f
    ffmpeg -i "%%f" -vf "minterpolate=fps=50:mi_mode=mci:mc_mode=obmc" -c:v hevc_nvenc -preset p4 -rc vbr -cq 24 -b:v 32M -pix_fmt yuv420p -color_range pc -c:a copy "konvertalt\%%f" -y
)
pause

Látható, hogy visszakerült az mc_mode paraméter, csak egy kevésbé igényes kapcsolóval. Tulajdonképpen itt értük el az optimumot. A szkript 55 perc alatt futott le és a videó minősége is jó lett. Ezt már be tudtam vállalni. Igaz, 5,5 óra kellett a munka elvégzéséhez, de éjjeli munkánál 30 perc pluszmunka nem oszt, nem szoroz.

És akkor emlékezzünk vissza, hogyan vezettem fel ezt az írást a korábbiban?

És bár nem vagyok rá büszke, mert elképesztő, mit bénáztam…

Hol van a bénázás?
Most jön.

Ez itt a Shutter Encoder grafikus felülete. Bejelölgettem a fontosabb részeket, de most egyre hívnám fel a figyelmet, a bal felső sarokban lévő bekarikázásra. Látod? Az ott egy munkaasztal. A nagy szkriptelős felbuzdulásban nem vettem észre, hogy a Shutter Encoder nem úgy működik, hogy beolvas egy fájlt és azzal dolgozik, majd beolvashatom a következőt és így tovább, nem, a Shutter Encoder munkaasztalára tetszőleges mennyiségű fájlt be tudok olvasni (ctrl+klattyintás) és mindegyikkel elvégzi a kijelölt konverziót.
Bakker.
Az egész szkriptelés tök felesleges volt. Este bedobom mind az ötpercnyi mobiltelcsis videót, bekattintom a bekattintanivalókat, elindítom, reggelre kész. Gyorsan és jó minőségben.

A végére még valami. Írtam korábban, hogy Paul Pacifico, a Shutter Encoder fejlesztője mennyire tökéletesen ismeri az ffmpeg-et. Itt van a bizonyíték. A Geminivel összefogva sem bírtuk összerakni egy délután azt a paraméterlistát az ffmpeg mögé, amely a Shutter Encoder conform by interpolate funkciója mögött volt. Ahogy a Gemini fogalmazta, a pacáknak sikerült eltalálnia azt az arany egyensúlyt a futási idő és a minőség között, melyet nekünk nem.

2025.07 Júlia kerülgetése 05: Ljubljana, Kranjska Gora

Indulás után elég sokáig bolyongtunk a Postojna körüli hegyekben, jórészt murvás úton, sűrű, sötét erdőkben. Itt le is tudtuk az összes szintet, utána már sík terepen tekertünk tovább Ljubljanáig. A következő napot viszont szétbombázta az időjárás, akkora vihart jelzett a Windy, hogy inkább vonatra szálltunk, majd Jesenicéből húztuk be az utolsó 25 kilométert, mely egyébként a Millenneumi kerékpárút szlovén szakaszának az eleje is egyben.

Megvágta, meglőtte 07: VFR vs CFR

Aki figyelmesen olvasta az előző részt, észrevehetett egy nagyon fontos kitételt az ábrán. Mit is írt az Open Camera FPS választó menüje?

  • “Video frame rate (approx)”
  • Hé! Ezmiez? Most akkor 50 képkocka van egy másodpercben, vagy mennyi? 51? 57? 48? Mi ez a hanyagság?

    Úgy nevezik, hogy Variable Frame Rate (VFR). Amikor először belefutottam a fenti szoftverben, sikkantottam egyet és összeestem. Gondolj bele, mennyi küzdés, mennyi harc kell ahhoz, hogy egy 60 képkocka / másodperc videót át tudjak alakítani 50 képkocka / másodperc formátumúra, úgy, hogy az 50 kép pontosan egyenlően helyezkedjen el, hasonlóan, mint korábban a 60 volt és a képeket lehetőleg újra is generáljam, hiszen más képeknek kell lennie az egyes fázisokban a két videónál. És akkor most jön valaki és teljesen kiszámíthatatlan mennyiségű képet tesz bele egy másodpercbe? Mert a VFR-nek pont ez a lényege: attól függően, hogy milyen cselekményt vesz a kamera, ahhoz hangolja a másodpercenkénti képkockákat. Én, mint kameraman megadhatom az intervallum közepét (lsd a korábbi képen, 25 fps approx), aztán ekörül az érték körül fog ingadozni a valós fps, hosszabb felvételnél kiadva a kért átlagot. De egyébként mennyi lesz egy konkrét másodpercben? Amennyit a szoftver éppen jónak lát.
    Őrület.
    És még folytatódott. Először azt hittem, hogy csak az Open Camera ilyen gonosz. Szépen egyenként végigmentem az összes kameraszoftveren, mindegyik VFR-ben vett. Módosíthatatlanul. Megnéztem a korábbi videóknál a családtagok felvételeit. Mindegyik mobiltelcsi VFR-ben vett.
    Kész. Minden, amit az előző írásban fejtegettem, ment a levesbe. Teljesen mindegy, hogy a mobiltelcsiből ki tudom-e erőszakolni a várt 50 fps-t, ha az úgysem annyi lesz, hanem 45-55 fps között valahol. Ez úgy fog vibrálni az 50 fps CFR (Constant Frame Rate) videóban, mint az ördög segge szentivánéjkor.

    Mit lehet tenni?

    Észre kell venni, hogy nem minden esett kútba. Az első megoldás, hogy majd a mobillal veszek fel megfelelő fps-sel, az tényleg felejtős. De a második módszer, hogy valami trükkös szoftverrel ügyeskedek, az továbbra is járható. Ezek ugyanis nem csak a CFR -> CFR konverziót tudják (tehát pl. fix 60 fps-ből fix 50 fps-be), hanem a VFR -> CFR konverziót is, azaz képesek ezt a strukturálatlan szutykot kisimítani.

    Ennek fényében nézzük végig az előző írásban már említett lehetőségeket. Hogy mit is csinálnak pontosan a szoftverek?

    Csak a Vegas-t és a Shutter Encoder-t fogom tárgyalni. A Vegas-t azért, mert azzal vágok, a Shutter Encoder-t, azaz a mögötte lévő ffmpeg-et pedig azért, mert messze a világ leghatékonyabb videómaceráló szoftvere és ráadásul ingyenes.

    1. Vegas Pro 23.

    Az előző írásban bemutatott példánál még naív kezdő voltam. Fogalmam sem volt erről a judder jelenségről, nem foglalkoztam vele. Rábíztam a Vegas renderelésére. Szar lett… hát szar lett, mit tudok csinálni?
    Nos, például tanulni.
    A Vegas-ban létezik olyan, hogy resample. Ez konkrétan azt csinálja, hogy akármilyen fps-sel is rendelkezik a nyersanyag, azt különböző algoritmusokkal beletördeli abba a FR formátumba, amit a projekt paramétereinél beállítottam. Ezt be lehet állítani projekt szinten, ekkor mindegyik darabra (event) ráfut az algoritmus, illetve be tudom állítani darab szintjén is, ekkor nyilván csak arra.

    A lehetőségek
    – Frame Blend: Ha a szoftvernek le kell gyártania egy új képkockát két meglévő (A és B) közé, akkor egyszerűen egymásra vetíti őket 50-50% átlátszósággal. Az eredmény egy olyan képkocka lesz, ahol mindkét mozdulat látszik halványan. A mozgás folyamatosabbnak tűnik, de szellemképes lesz. Gyors mozgásnál (pl. egy elsuhanó bringa) olyan, mintha be lenne kapcsolva egy állandó elmosódás.
    Magyarul blőrözni fog.
    – Optical Flow: Megnézi az “A” képkockán lévő objektumokat (pl. egy labdát), megkeresi őket a “B” képkockán, és kiszámol egy mozgásvektort. Ezután létrehoz egy teljesen új “C” képkockát, ahová a pixeleket pontosan a két állapot közötti félútra rajzolja át. Ha jól működik, tűéles és folyékony lesz a mozgás. Ha a háttér bonyolult (pl. kerítés vagy lombok előtt történik a mozgás), a szoftver összezavarodik, és furcsa hullámzások jelennek meg a tárgyak körül. Olyan, mintha a valóság megolvadna egy pillanatra.

    2. Shutter Encoder

    Ebben a szoftverben a hasonló funkció neve az, hogy conform by (illesztés).

    A lehetőségek:
    – Speed: Ahogy az előző írásban is írtam, egyszerűen kimozogja a frame/secundum különbségeket, gyorsítással, vagy lassítással. VFR esetén véleményes.
    – Drop: Eldobálja a felesleges képkockákat. Piszok gyors, de nem ad jó minőséget.
    – Blending: Megegyezik a Vegas Frame Blend funkciójával.
    – Interpolation: Megegyezik a Vegas Optical Flow funkciójával.
    – Ultra slowmotion: Ez valójában az Optical Flow “szteroidos” változata. Míg a Vegasban a 30->50 fps váltásnál csak 0.66 darab új képkockát kell gyártani minden eredeti közé, az Ultra-slowmónál akár 10-20-at is. Csapágyasra hajtja a GPU-t, de extrém jól lassítható nyersanyagunk lesz.
    – Reverse: Ez kakukktojás. Ezzel a funkcióval megforgatjuk a videót, azaz gyakorlatilag megfordítjuk a képkockák sorrendjét. Ez ránézésre nem valami nagy dolog, a tömörítés miatt viszont de, brutális melót igényel.

    Mint látható, van átfedés a két program képességei között. (Frame Blending, Optical Flow.) Mikor melyiket érdemes használni? Leginkább azt kell látni, hogy ha a Vegas-ra bízzuk az fps konverziót, akkor a már így is leterhelt szoftverre pakolunk rá még egy púpot. A szerencsétlen ugyanis éppen renderel, azaz vadászgatja össze a különböző diszkeken lévő videódaraboktat, hozzájuk a hangfájlokat, húzza rájuk az átmeneteket, az effekteket és mindebből gyártja a kimeneti videót. Mi pedig ebbe a folyamatba rakjuk bele, hogy lécci-lécci röptében még kalkulálj plusz képkockákat és illeszd be a videóba, de természetesen ezekre is pakold rá a szükséges effekteket. Őrület. Kész csoda, hogy nem áll fejre a program. (Ja, nem. Fejreáll.) A Shutter Encoder ezzel szemben csak egy dologra koncentrál, az fps konverzióra. Ha megtörtént, akkor a konvertált videó csak egy sima, jól kezelhető nyersanyag lesz a Vegas számára.
    A gyakorlatban ez azt jelenti, hogy új videó esetén a Shutter Encoder alkalmazással preparálom a mobiltelcsi videóit és azok mennek a Vegasba. Ha viszont régi videókat akarok feljavítani, ahol már minden össze lett vágva, akkor a Vegas Optical Flow technikáját használom.

    És bár nem vagyok rá büszke, mert elképesztő, mit bénáztam, de leírom, mert tanulságos.
    Csak éppen nem most.

    © 2026 MiVanVelem

    Theme by Anders Norén — Up ↑