Page 2 of 1213

Már megint Komoot

Megint anyázni fogom a fent nevezett programot, mégpedig azért, mert végre-valahára belefejlesztették azt a képeséget, melyet ezer éve őrjöngve követeltek a Komoot felhasználók.
Elismerem, ez így elég furán hangzik, de meg tudom magyarázni.

A gpx fájlformátum egy meglehetősen rugalmas formátum.
– Képes arra, hogy nem csak egy track adatait tartalmazza, hanem többét is.
– Képes arra, hogy kérésre egy track-en belül összeköti a pontokat, és így útvonalat tárol.
– Képes arra, hogy kérésre nem köti össze a track-en belül a pontokat, így egy waypoint gyűjteményt tárol, mely nem alkot útvonalat.

A Komoot ezt a rugalmasságot telibe ignorálta. Nála a gpx-ben csak útvonal lehetett, waypoint nem. Értelemszerűen hiába volt tele a Komoot saját térképe névvel jelzett POI-kkal, meg úgynevezett kiemelt (highlight) pontokkal, ezek nem kerültek ki a gpx fájlba, azaz nem látszódtak a túragps-en. És ez fordítva is igaz volt, hiába gyártottam le egy külső alkalmazással a waypoint-okat tartalmazó gpx fájlt, a Komoot ezt útvonalként tudta csak beolvasni, azaz szorgalmasan összekötözgette a pontokat. Egyenes vonalakkal.
Fogalmam sincs, mi rejlett a koncepció mögött, mindenesetre elég rendes öntökönrúgás volt egy ilyen képességet kihasználatlanul hagyni.

Tavaly év vége felé erős kalapálás, reszelgetés hallatszott a Komoot háza tájáról és ennek eredménye is lett. A leglátványosabb változás a külsőt érintette, teljesen újratervezték a megjelenést. Ebbe nem akarok belemenni, mindenesetre hajlamos lennék gyűjtést indítani, hogy a designer csapatot küldjék már el egy UX tanfolyamra. Bosszantó, frusztráló hibák sorban, olyanok, melyek nem a tökéletlen megvalósítás miatt lettek bénák, hanem szándékosan lettek ilyenre tervezve.

De nem ez a lényeg. Hanem az, hogy végre elkezdték kihasználni a gpx fájl képességeit. Illetve még ennél is nagyobb változás történt: megjelentek az alkalmazáson belül a felokosított waypoint-ok. Óriási, józan ésszel felfoghatatlan nagy meló rejlett emögött. Több tízmillió waypoint-ot bővítettek fel a rendszerben. Mindegyiket névvel, gpx koordinátákkal, tipusjelző ikonnal, kiegészítő információval, fényképeket rendeltek hozzájuk, a legtöbb waypont cimkéjére ki lett vezetve a Streetview alkalmazás, azaz közvetlenül is meg lehet tekinteni, hogyan néz ki a pont. És nem csak az ismert látványosságokból lett waypoint, hanem szinte mindenből: az lett a közkút, a pad, a piknikasztal, de az lett az e-bike töltőállomásokból is.

Jogos lehet a kérdés, hogy ha ez ennyire jól sikerült, akkor mi a bajom?

Az, hogy – minden jó szándék ellenére – kvázi használhatatlan lett ez az egész a túlzott merevség miatt.
– Azt értem, hogy a térképen lévő waypoint nevét nem lehet megváltoztatni, de amikor kijelöltem, azaz jeleztem azt a szándékomat, hogy ezt a pontot szeretném majd kirakni a gpx fájlba, ott már lehetne neki egyedi nevet adni, melyet az én track-emen belül fog viselni. Nekem van egy kikristályosodott névkonvencióm, ez alapján tudok gyorsan kavarni a pontok között. Itt nem lehet.
– A waypoint koordinátája csak akkor kerül ki a gpx fájlba, ha az útvonalon fekszik. Nem kell túl sokat agyalni azon, hogy ez miért nem életszerű. Például nézzük a kempinget. Kikerestem, hol fogunk aludni, de a kemping weboldalán azt írják, hogy főszezonban előfordulhat, hogy nem lesz helyünk. Ilyenkor azt csinálom, hogy olyan húsz kilométeres körzetben kikeresem az összes kemping koordinátáját és felveszem ezeket (feltételes) waypoint-nak. A Komoot-ban ilyet nem lehet csinálni, csak úgy, ha útvonalat tervezek minden kempingbe. Ez persze minden más olyan pontra is vonatkozik, amely nincs pont rajta az útvonalon, és ilyenkor tud igazán dühítő lenni egy térképalkalmazás. Például azt mondja, hogy nem tudok bemenni egy parkolóba, csak jó egy kilométernyi kerülővel, miközben a valóságban csak át kellene tolnom a bringát egy normál szélességű járdán. Emiatt kénytelen vagyok lenyelni, hogy egy kerülő kamuútvonal került a track-be, és ha nem figyelek, azon fogok menni. Vagy nem kerül bele a waypoint a gpx fájlba. (Igen, tudom, hogy van szabad rajzolás is, de aki csinált már ilyet, tudja, hogy mennyire szét tud esni egy ilyentől az útvonal.) Ugyanilyen feltételes waypoint lehet egy közeli várrom, vagy akármilyen célpont, ahová úgy tervezem, hogy ha lesz időm, felmegyek, ha nem, akkor nem. A Komoot-nál vagy fixen odatervezem az utat, vagy nem kerül ki gpx fájlba a pont.
– Továbbra is csak saját waypoint-okat ismer. Ha beolvasok egy waypoint-okkal teli gpx fájlt, azt útvonalnak olvassa be.
– Én magam nem tudok waypoint-ot definiálni. Nyilván nem akarok olyat, amely bekerül a Komoot zárt rendszerébe, de olyat mindenképpen szeretnék, amelyik rá tud kerülni az éppen tervezett track-re és a végén ki is megy a gpx fájlba. Ez, nem győzöm hangsúlyozni, alapkövetelmény, minden útvonaltervező alkalmazásnál. Az élet ugyanis tele van változásokkal: itt bolt volt, megszűnt. Ott meg nyílt egy hamburgeres. Ilyesmikbe már most is belefutottam, pedig még csak pár hónap telt el az átalakítás óta. A Komoot boltot jelez ott, ahol nincs. A Google Maps meg mutatja, hogy ott van egy bolt, csak hát ahhoz meg nincs waypoint. Én meg nem tudok sajátot létrehozni. Hogy ne is beszéljünk arról, hogy mi van, ha fel akarom venni a csak a helyiek által ismert Biri néne borospincéjét is a track-re.

Szóval, pozitív, hogy felfedezték a gpx fájformátum rugalmasságát és beleépítették a rendszerükbe. Óriási és feltétlenül megsüvegelendő dolog az elképesztő mennyiségű waypoint adattáblájának feltöltése, illetve a waypoint-ok exportálása a track gpx fájljába. De azzal, hogy a rendszert megtartották szigorúan zártnak és merevnek, rákényszerítettek, hogy továbbra is külső alkalmazást használjak a waypoint-ok kezelésére. És ha már úgyis külső alkalmazást használok, akkor nem akarok két helyen adminisztrálni, így az a frusztráló helyzet áll elő, hogy első lépésben a Komoot által gyártott gpx fájból kigyakom a waypoint-okat. Igen azokat, melyek létezéséért annyit koptattam a számat és annyira, de annyira elvártam a Komoot-tól, hogy nőjön már fel. Aztán egy másik gpx fájlba felviszem a saját waypoint-jaimat és a túragps-en már ebből a kettőből áll össze az a térkép, amelyen az útvonal is rendben van, meg a pontok is. Azaz minden ugyanúgy megy, mint régen, azzal a különbséggel, hogy most bejött egy plusz meló, a Komoot gpx fájljából törölnöm kell a waypoint track-et, melyet immár mindenképpen beletesz, akár akarom, akár nem.

Szóval, ezen a waypoint kezelésen kellene még egy kicsit törpölni. Első körben azt tudnám javasolni, hogy a waypoint alapból ugyan lehet térképobjektum, de amint kijelölöm, onnantól már egy másolatpéldánynak kellene keletkeznie és az már track-objektum lenne, mely az éppen szerkesztett track-nek lesz a – módosítható(!) – része. Az újonnan létrehozott egyedi waypoint-ok, hasonlóképpen a beolvasott waypoint-ok is, meg már helyből track-objektumok lennének. És persze az egyénileg létrehozott track-objektum waypoint-oknak már nem kellene kötelezően az útvonalon lenniük, mert miért is kellene?

[Update1]
Így jár az, aki nem publikálja egyből az írásait. Ez itt konkrétan már több hónapja figyel kifelé az admin felületből és várja, hogy publikus legyen. Csak éppen közbejött egy csomó minden.
Aztán a Komoot meg lépett. Elkezdték azt, amit az írás végén hiányoltam. Létre lehet hozni saját waypoint objektumot, mely nem a térképhez kötődik, hanem az aktuális track-hez. Úgy is tudom létrehozni, hogy rákattintok az útvonalra. Ez megint egy előrelépés, innentől fel tudom venni az útvonalamba Biri néne borospincéjét is.
Mi a baj?
Hát az, hogy az útvonalra tudom felvenni. Ha például be akarok jelölni egy, az útvonalamtól 500 méterre lévő pontot, mondjuk egy boltot, ahová nem biztos, hogy bemegyek, mert majd eldöntöm a helyszínen, akkor a jelenlegi megoldással mindenképpen oda kell terveznem az útvonalat. Ha a célpont környékén tíz kilométeres körben be szeretném jelölni az összes kempinget, akkor mindegyikhez útvonalat kell terveznem. Ettől minimum áttekinthetetlen lesz a track, illetve tekerés közben el fog vinni minden alternatív célponthoz.
Értelemszerűen emiatt a viselkedés miatt nem is tudok olyan gpx fájlt értelmesen beolvasni, amelyikben vannak útvonalon kívüli waypoint-ok. A Komoot útvonalat fog tervezni rájuk.

[Update2]
Az idő csak múlik, a szöveg meg öregedik. Időközben kijött a Komoot-ban egy újabb változtatás: meglévő térképobjektumból, miután ráraktam az útvonalra, track-objektum lett, azaz ezt már át tudom nevezni. A fenti hőbörgéshez képest ez mindenképpen egy újabb pipa. Kár, hogy jelenleg még minden waypoint-nak rajta kell lennie az útvonalon. (Közben kijött egy reménytelien hangzó Saved Place objektum, de ez dajnos nem erről szól.)

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.

    2025.07 Júlia kerülgetése 04: Postojna

    Bármennyire is fura, a Trieszt utáni Giordano Cottur kerékpárutat jobban vártam, mint a Millenniumit. Kevesebben ismerik, pedig látványos, gyönyörű helyeken jár, nekem pedig már évek óta szerepelt a terveim között. Összességében nem csalódtam, bár a szlovének nagyon elcseszték a végét, de az olasz oldal hozta magát. Utána pedig tipikus középhegységi környezetben haladtunk, felkapaszkodtunk egy fennsíkra, majd ott hullámoztunk a tereppel együtt, egészen a Postojna melletti Pivka Jama kempingig. (A jama egyébként barlangot jelent és a névadó barlang tényleg ott volt a kempingen belül, nem messze a híres postojnai cseppkőbarlangtól.)

    Megvágta, meglőtte 06: Judder

    Mielőtt bármit mondanék, nézz bele ebbe a videóba. Nem kell sokat, kábé egy perc bőven elég.

    Katasztrófa. Miközben eget-földet, de legfőképpen a bankszámlánkat megmozgatva mindent elkövetek, hogy a videóim technikailag tényleg jók legyenek.
    Mi történhetett?
    Ami egyből látszik, az az, hogy ez egy mobiltelefonnal felvett betét. A film többi részében a Gopróval vett anyag rendben van, a mobiltelefonos darabok viszont többé-kevésbé ilyenek. Könnyű lenne rávágni, hogy akkor ez egy vacak mobiltelefon, csakhogy nem az. Ez egy Pixel 9a, melyet direkt azért vettem – a sztenderdjeim szerint – szokatlanul drágán, mondhatni csillagászati áron, hogy mindig legyen kéznél egy _igazán jó_ fényképezőgép és videókamera.
    Hát, nem erre számítottam.

    Nyilván van rá magyarázat. Ez az a bizonyos judder.
    Magyarul azt jelenti a szó, hogy vibrálás, remegés. Videógyártásnál pedig a legtipikusabb előfordulása az, amikor fps összehangolatlanság van.

  • FPS: Frame/secundum. Azaz másodpercenként hány képből áll össze a mozgás. Ez befolyásolja azt, hogy mennyire sima, vagy darabos a mozgás a képen.
  • A Gopróval 2,7K/50fps felbontással forgatok, a kész vágott videót pedig 4K/50fps felbontásba renderelem. Látható, hogy ezzel nincs különösebb gond. A Panasonic camcorderrel sem, az 1K/50fps felbontásal vesz, hasonlőképpen az autó fedélzeti kamerája is. Mindenhol sima és legfőképpen egyenletes a mozgás. De mi van a mobiltelefonnal? Baj.

    Nézzük, milyen televíziós szabványok léteznek:
    – PAL: 25/50 fps (Európa, Ausztrália, Kína)
    – NTSC: 30/60 fps (USA, Japán, Kanada)
    – SECAM: 25/50 (Franciaország, Oroszország, Görögország, Észak-Korea)

    Ebből az a lényeg, hogy ha a mobiltelefonod kamerája NTSC rendszerű, akkor 30/60 fps-t használ, ha PAL, akkor 25/50 fps-t. Ha a felvételeket kizárólag a mobiltelcsiden nézed vissza, akkor nincs is gond. De ha videóba vágod, ott már van. A Pixel 9a például NTSC rendszerű, azaz két választási lehetőségem van: 30 vagy 60 fps.
    Képzeljük bele magunkat a Vegas Pro lelkivilágába. (Brrr.) Nyersanyagként kap egy csomó 50 fps videót, de kap mellé egy kevés 60 fps-t is. A végeredményt pedig 50 fps-ben kérem. Egyszerűen nincs más lehetősége, mint az NTSC videónál a másodpercenkénti 60 képből eldob 10-et. Igenám, csakhogy a maradék 50 kép nem egyenletesen lesz elosztva. Ahonnan kidobott egy képet, ott kétszer akkora lesz a képek közötti “szünet”. Ezért fog rángatni a mozgás.

    Oké. Miben reménykedhetek?
    – Létezik olyan androidos alternatív kameraprogram, amelyik képes a Pixel 9a telcsivel 25/50 fps videót rögzíteni.
    – Létezik valami nagyon ügyes technika, valami bravúros alkalmazás, amelyik _kulturáltan_ le tudja kezelni a helyzetet.

    Mindkét kérdést feltettem a Gemininek. Így indult el egy újabb többnapos kaland.

    1. Alternatív kameraprogramok

    Persze, hogy léteznek. Android alatt? Miért ne léteznének?
    Csak éppen… na mindegy, vágjunk bele.
    A struktúra úgy néz ki, hogy van a kamera hardvere. Ehhez tartozik egy API, mely kiajánlja a szoftvereknek a kamera képességeit. És persze van a kameraszoftver, mely az API hívogatásával dolgozik.
    Nézzük a versenyzőket.

    1.1 McPro24fps
    Ez valamikor ingyenes volt, ma már fizetős. (Nem egy vagyon, emlékeim szerint olyan 4000 HUF körüli áron mérik.) Demót lehet letölteni, ez mindent tud, mindent be lehet állítani rajta, egyedül a ‘felvétel indít’ gomb van letiltva.
    Letöltöttem, kipróbáltam.
    Az első döbbenet: ez már ismeri a 25 fps-t. Azaz a kamera képes az NTSC mellett PAL módban is rögzíteni. Csak éppen a Google kameraszoftvere nem él ezzel a lehetőséggel.
    A második döbbenet: nem ismeri az 50 fps-t. Ami nagy valószínűséggel azt jelenti, hogy az 50 fps-t nem vezették ki az API-ban. (Egyébként a szoftver tutira felajánlaná.)

    1.2 Blackmagic
    Ingyenes, reklámmentes, profi. Alapvetően tetszett a GUI, ismerte a 25 fps-t.

    1.3 Open Camera
    Ez tulajdonképpen a Gemini egyik hallucinációja miatt került elő. Ránézésre olyasmi, mint a Blackmagic, de valamivel fapadosabb. Bizonyos téren rosszabb, bizonyos téren jobb. Fps téren elképesztő, mit tud, gyakorlatilag kirakta az API összes lehetőségét.

    Igen, jól látod. Van 25 fps, van 240 fps is, de az 50 fps, az nincs köztük. Egyszerűen hihetetlen, mennyire mocskos disznó a Google.

    Oké, akkor hogy is állunk? A Blackmagic és Open Camera szoftverrel tudok 25 fps videókat rögzíteni. Ez tulajdonképpen már jó, hiszen a képkockák duplázásával a videók beilleszthetők egy 50 fps kimenetbe.

    2. Szoftveres trükközések

    2.1 Lassítás
    A pofonegyszerű megoldás. Ha van egy 60 fps videóm, akkor egyszerűen megnyújtom, azaz lelassítom. Annyira, hogy másodpercenként 50 kép maradjon. Ehhez 83,33%-ra kell lassítani. Működik? Működik. Sima lesz a mozgás? Abszolút. Mi akkor a baj? A hang. Az is belassul, azaz mély lesz. Ettől mondjuk nem kell annyira megijedni, hacsak nem kell kötelezően végig együttmozognia a képnek a hanggal, akkor ez ügyes vágásokkal kezelhető.

    2.2 Vegas Resample
    A Vegas 23 annyira azért nem fogalmatlan kezdő, természetesen vannak beépített eszközei a probléma kezelésére. (Melyeket nem ismertem, amikor az írás elején belinkelt videót készítettem. Azóta leteszteltem, egészen jó.) Mind videódarab szinten, mind projekt szinten be lehet állítani, hogy szeretnék-e Resample funkciót és ha igen, akkor milyet? (Ezeket később tárgyalom részletesebben.)

    2.3 Shutter Encoder
    Egyike a témakör zseniális alkalmazásainak. Egyszerűen kötelező darab. Írtam már, hogy van ez az ffmpeg, a témakör legzseniálisabb alkalmazása. (Nagyon erősen kötelező darab). Ez nem csak megfőzi a kávédat, de előtte leszüreteli a kávécserjét és meg is pörköli a kávészemeket. Egy baj van vele: mivel egy gyakorlatilag mindent tudó parancssori alkalmazás, így elképesztően rengeteg és nehezen érthető, nehezen memorizálható paramétere van, ráadásul ember legyen a talpán, aki kiigazodik ebben a dzsungelben.
    Ezt csinálja meg a Shutter Encoder. Gyakorlatilag egy grafikus felületet rak az ffmpeg elé. Ez se lenne kevés, de Paul Pacifico valami olyan szinten ismeri az ffmpeg-et, amennyire kevesen. Így az egyes nyomógombok mögött nem csak a megfelelő funkciókat találjuk, de azok szénné vannak optimalizálva is.
    Nos, természetesen itt is válogathatunk a lehetőségek közül, a különbség, hogy nem Resample a funkció neve, hanem Conform. Több lehetőség is létezik, később írok majd róluk.

    A lényeg, hogy ezen a vonalon is vannak megoldások: kompromisszumosak is és teljes értékűek is.

    Nézzük, mire lehet jutni velük. (Spoiler: hatalmas pofonok jönnek.)

    De nem most, hanem majd a következő írásban.

    © 2026 MiVanVelem

    Theme by Anders NorénUp ↑