Why are quaternions used for 360° video camera movement?

Quaternions enable smooth camera rotations without gimbal lock or abrupt transitions, making them ideal for creating natural-looking camera movements in 360° video reframing.

How does Flutter handle smooth 360° video rendering?

Flutter uses spherical projection for live previews, quaternion-based interpolation for camera motion, and a native OpenGL GPU pipeline to export high-quality reframed videos efficiently.

What challenges make 360° video reframing difficult?

Accurate reframing requires handling spherical projection, seamless rotation across the ±180° boundary, smooth camera interpolation, and synchronized GPU rendering to produce stable, cinematic video output.

Why is GPU acceleration important for 360° video export?

GPU acceleration significantly reduces rendering time by processing projection and video encoding on the graphics hardware, making high-resolution 360° video export practical on mobile devices.

Reframing 360 Video in Flutter with GPU Export

360-videon uudelleenkehystys Flutterissa: Pallomainen projektio, Quaternion-avainruudut ja GPU-vienti

Kuinka muutimme raa'an tasasuorakulmaisen 360°-materiaalin tasaiseksi, kehystetyksi, litteäksi videoksi – kokonaan Flutter-sovelluksen sisällä.

Ongelma, josta kukaan ei varoita sinua

Normaalissa videossa on yksi ilmeinen asia näytettävänä: ruutu, johon kamera oli suunnattu. 360°-videossa sellaista ei ole. Kamera tallensi kaiken – täyden pikselipallon, joka on tallennettu tasaisena tasasuorakulmaisena suorakaiteena (2:1-kuva, jossa X-akseli on pituusaste ja Y-akseli leveysaste). Ennen kuin voit laittaa tämän materiaalin Instagramiin, YouTubeen tai puhelimen näytölle, jonkun on vastattava kysymykseen, johon kamera tarkoituksellisesti kieltäytyi vastaamasta:

Minne katsojan tulisi katsoa ja milloin?

"Uudelleenkehystys" on virtuaalikameran lennättämistä pallon läpi ajan myötä – panorointia, kallistusta, zoomausta – ja normaalin litteän 16:9 (tai 9:16 tai 2.35:1) videon renderöintiä. Tämä on ominaisuus, jonka ympärille GoPro Player, Insta360 Studio ja Adobe Premièren GoPro VR Reframe -laajennus on rakennettu.

Rakensimme sen kokonaan Flutterissa. Tämä kirjoitus on katsaus osiin, jotka olivat aidosti vaikeita: projektion matematiikka, gimbal-lock-vapaa interpolointi, ±180° sauma ja GPU-vientiputki, jonka on kestettävä oikeita Android-dekoodereita.

Päästä päähän -työnkulku:

360-videon tallennus/tuonti
→ kevyen esikatselu-proksin transkoodaus
→ käyttäjä napauttaa / piirtää / tunnistaa kohteen automaattisesti
→ kohteen seuranta tuottaa polun
→ avainruutujen generointi + tasoitus
→ SLERP-interpolointi ruutukohtaiselle kameran suunnalle (reaaliaikainen esikatselu)
→ natiivi GPU-vienti litteäksi videoksi
→ FFmpeg-jälkikäsittely (moov atom + A/V-synkronoinnin korjaus)

Arkkitehtuuri lyhyesti

Pidimme järjestelmän kolmessa selkeässä kerroksessa, jotta matematiikka on testattavissa erillään Flutterista:

Kerros	Sijainti	Vastuu
Mallit	lib/data/models/reframe/	SphericalCoordinates/Quaternion, CameraOrientation/MotionConstraints, ReframeKeyframe, ReframeProject
Palvelut	lib/services/reframe/	SphericalProjection (säteenseuranta), CoordinateConverter, KeyframeInterpolator/Generator/Smoother, ReframeExportService
Esityskerros	lib/presentation/.../reframe/	Riverpod ReframeNotifier, natiivi OpenGL Spherical360Player, bbox-piirustuspeite, avainruutuaikajana

Kultainen sääntö: koko trigonometria on puhdasta Dartia ilman Flutter-tuonteja. Tämä tarkoittaa, että jokainen projektio- ja interpolointifunktio on yksikkötestattavissa ilman widget-puuta, ja sama matematiikka ohjaa sekä reaaliaikaista esikatselua että vientiä.

1. Kaiken ydin: tasasuorakulmainen ⟷ pallomainen

Kaikki alkaa yhdestä kuvauksesta. Tasasuorakulmainen kehys on vain suorakulmio, jossa:

X (0 → leveys) pyyhkäisee pituusastetta (yaw) −180°:sta +180°:een
Y (0 → korkeus) pyyhkäisee leveysastetta (pitch) +90°:sta (ylä/zeniitti) −90°:een (ala/nadiiri)

SphericalCoordinates on tarkoituksella pieni – vain yaw ja pitch. Roll, FOV ja zoom kuuluvat kameraan, eivät suuntaan. Tässä on muunnos, johon koko ominaisuus perustuu:

factory SphericalCoordinates.fromEquirectangular({
required double x, required double y,
required double videoWidth, required double videoHeight,
}) {
final normalizedX = x / videoWidth;
final normalizedY = y / videoHeight;
// X maps to yaw: 0->-180°, 0.5->0°, 1.0->180°
final yaw = (normalizedX - 0.5) * 360.0;
// Y maps to pitch: 0->90° (top), 0.5->0° (horizon), 1.0->-90° (bottom)
final pitch = (0.5 - normalizedY) * 180.0;
return SphericalCoordinates(
yaw: yaw.clamp(-180.0, 180.0),
pitch: pitch.clamp(-90.0, 90.0),
);
}

Käänteinen on peilikuva (normalizedX = yaw/360 + 0.5), ja käytämme sitä jatkuvasti piirtääksemme seurattavan rajauslaatikon takaisin soittimeen.

"Napauta sitä, mitä näet" — perspektiivi-säteenseuranta

Käyttäjä ei vuorovaikuta tasasuorakulmaisen suorakulmion kanssa. He vuorovaikuttavat renderöidyn perspektiivinäkymän kanssa. Joten kun he napauttavat kohtaa soittimessa, meidän on lähetettävä säde virtuaalisen neulanreikäkameran läpi ja löydettävä, minkä suunnan pallosta he osuvat. Se on SphericalProjection.screenToSpherical:

final ndcX = (2.0 * screenPoint.dx / playerSize.width) - 1.0;
final ndcY = 1.0 - (2.0 * screenPoint.dy / playerSize.height);
final aspectRatio = playerSize.width / playerSize.height;
final tanHalfFov = math.tan(cameraFov * math.pi / 360.0); // half-angle
double rayX = ndcX * aspectRatio * tanHalfFov;
double rayY = ndcY * tanHalfFov;
double rayZ = 1.0;
// ...normalize, rotate the ray by pitch (around X) then yaw (around Y)...
final sphericalYaw = math.atan2(finalRayX, finalRayZ) * 180.0 / math.pi;
final sphericalPitch = math.asin(finalRayY.clamp(-1.0, 1.0)) * 180.0 / math.pi;

.clamp(-1.0, 1.0) ennen asin-funktiota saattaa vaikuttaa vainoharhaiselta, mutta liukulukuvirhe voi antaa arvon 1.0000001 ja asin palauttaa NaN:n – ja yksi NaN pilaa jokaisen seuraavan ruudun. Puolustava rajaaminen käänteisten trigonometristen funktioiden ympärillä on toistuva teema tässä koodikannassa.

2. Tasainen kameran liike: Quaternionit, ei Euler-kulmat

Naivi lähestymistapa on tallentaa yaw/pitch jokaiseen avainruutuun ja interpoloida luvut lineaarisesti. Se näyttää kauhealta. Euler-kulmien interpolointi aiheuttaa gimbal lockin, epätasaisen kulmanopeuden ja rumia nykäyksiä napojen lähellä.

Interpoloimme suuntaa Quaternionina käyttäen SLERPiä (pallomaista lineaarista interpolointia). Jokainen suunta muunnetaan Quaternioniksi ZYX Euler -konvention avulla:

Quaternion toQuaternion() {
final yawRad = yaw * math.pi / 180.0;
final pitchRad = pitch * math.pi / 180.0;
final cy = math.cos(yawRad * 0.5); final sy = math.sin(yawRad * 0.5);
final cp = math.cos(pitchRad * 0.5); final sp = math.sin(pitchRad * 0.5);
return Quaternion(w: cy * cp, x: cy * sp, y: sy * cp, z: -sy * sp);
}

Ja SLERP-funktiossa itsessään on kaksi tuotantotasoisen toteutuksen tarvitsemaa turvaventtiiliä:

static Quaternion slerp(Quaternion a, Quaternion b, double t) {
a = a.normalize(); b = b.normalize();
var dotProduct = a.dot(b);
if (dotProduct < 0.0) { b = -b; dotProduct = -dotProduct; }   // take the shortest hemisphere
if (dotProduct > 0.9995) {   // near-parallel -> fall back to LERP
  return Quaternion(w: a.w + t*(b.w-a.w), x: a.x + t*(b.x-a.x),
y: a.y + t*(b.y-a.y), z: a.z + t*(b.z-a.z)).normalize();
}
final theta0 = math.acos(dotProduct);
final theta = theta0 * t;
final sinTheta = math.sin(theta);
final sinTheta0 = math.sin(theta0);
final s0 = math.cos(theta) - dotProduct * sinTheta / sinTheta0;
final s1 = sinTheta / sinTheta0;
return Quaternion(w: s0*a.w + s1*b.w, /* ...*/).normalize();
}

Kaksi ehdotonta yksityiskohtaa:

Lyhyin pallonpuolisko – q ja −q edustavat samaa suuntaa. Jos pistetulo on negatiivinen, negatoit toisen syötteen tai kamerasi kulkee pitkän reitin pallon ympäri.
Lähes yhdensuuntainen LERP-palautus – kun kaksi avainruutua ovat lähes identtiset, sinTheta0 → 0 ja jaat lähes nollalla. Paluu tavalliseen LERP-interpolointiin, kun pistetulo > 0.9995, välttää ongelman.

Hienovarainen mutta tärkeä suunnittelupäätös: me SLERP-interpoloimme suuntaa, mutta LERP-interpoloimme FOV/zoomia ja kulma-LERP-interpoloimme rollia. Pallomainen interpolointi on oikea työkalu suunnalle; zoom on vain skalaari ja sen tulisi liikkua lineaarisesti:

final qInterp = Quaternion.slerp(from.direction.toQuaternion(), to.direction.toQuaternion(), t);
final interpDirection = SphericalCoordinates.fromQuaternion(qInterp).normalize();
final interpFov = _lerp(from.fov, to.fov, t);
final interpRoll = _lerpAngle(from.roll, to.roll, t); // wraps across ±180
final interpZoom = _lerp(from.zoom, to.zoom, t);

💡 Kun muunnamme takaisin Quaternionista yaw/pitch-arvoihin, käytämme atan2-funktiota asin-funktion sijaan "numeerisen vakauden vuoksi (välttää asin-funktion määrittelyalueen ongelmat)." SLERP-interpoloinnin jälkeen Quaternion voi olla hyvin lievästi denormalisoitu, ja atan2 toimii sujuvammin, kun taas asin heittää NaN:n.

Pehmennys: käsin toteutettu, saapuvan siirtymän yhteydessä

Jokainen avainruutu omistaa pehmennyskäyrän siirtymälle siihen. Käyrät on kirjoitettu käsin, jotta ne ovat identtiset kaikilla alustoilla:

case KeyframeEasing.linear:   return t;
case KeyframeEasing.easeInOut: return t * t * (3 - 2 * t); // smoothstep S-curve
case KeyframeEasing.easeIn:   return t * t;   // quadratic
case KeyframeEasing.easeOut:   return 1 - (1 - t) * (1 - t);

3. ±180° sauma: virhe, joka kummittelee jokaisessa 360-ominaisuudessa

Tässä on ansa. Yaw-arvo elää ympyrän kehällä: +179° ja −179° ovat 2°:n päässä toisistaan, eivät 358°:n. Heti kun kohteesi kävelee pallon takaosan poikki, naiivi matematiikka nykäisee kameran puoli maailmaa ympäri. Tämä yksi ongelma ilmenee järjestelmän neljässä eri kerroksessa, ja jokainen vaatii oman korjauksensa.

Kerros 1 – primitiivit. Kaksi pientä apufunktiota, joihin koko koodikanta tukeutuu:

static double normalizeYaw(double yaw) {
while (yaw > 180) { yaw -= 360; }
while (yaw < -180) { yaw += 360; }
return yaw;
}

// "CRITICAL for seam-safe tracking ... avoids 180° snaps"
static double shortestYawDelta(double from, double to) {
double delta = to - from;
if (delta > 180) delta -= 360;
if (delta < -180) delta += 360;
return delta;
}

Kerros 2 – avainruutujen generointi kerää jatkuvan (rajoittamattoman) yaw-arvon, jotta SLERP interpoloi aina lyhimmän reitin. Sen sijaan, että rajoittaisimme jokaisen näytteen ±180°:een, laskemme lyhimmät deltat yhteen ja annamme jatkuvan arvon tarkoituksella ylittää 180°:

final normalizedContinuousYaw = SphericalCoordinates.normalizeYaw(continuousYaw);
final yawDelta = SphericalCoordinates.shortestYawDelta(normalizedContinuousYaw, rawCoords.yaw);
continuousYaw = continuousYaw + yawDelta; // may exceed ±180 on purpose
coords = SphericalCoordinates(yaw: continuousYaw, pitch: rawCoords.pitch);

Kerros 3 – rajauslaatikon rekonstruktio. Kun käyttäjä piirtää sauman yli ulottuvan laatikon, neljä nurkkaa ilmoittavat yaw-arvot, kuten +170°, +175°, −175°, −170°. SphericalProjection tunnistaa tämän (mikä tahansa nurkka > 90° ja mikä tahansa nurkka < −90°) ja rakentaa uudelleen jatkuvan yaw-arvon "seam-safe"-rajauslaatikon siirtämällä negatiivisia arvoja +360°:lla ennen sen laajuuden mittaamista.

Kerros 4 – reaaliaikainen soitin tasoittaa kohti kohdettaan shortestYawDelta-funktion avulla, jotta vetäminen sauman poikki ei koskaan nyi.

Jos muistat yhden asian 360-työkalujen rakentamisesta: sauma ei ole reunatapaus, se on läpileikkaava huolenaihe. Varaa sille resursseja kaikkialle, missä yaw esiintyy.

4. Saada se tuntumaan Insta360/GoPro:lta

Tasainen interpolointi antaa teknisesti oikean kameran. Se ei kuitenkaan anna hyvää kameraa. Kolme "tuntumatekniikan" osaa kuromassa umpeen tätä kuilua.

Liikerajoitukset – nopeuden ja kiihtyvyyden rajoittaminen. Raaka seurantadata on nykivää. Käsittelemme avainruutuja MotionConstraints-rajojen kautta, jotka rajoittavat virtuaalikameran liikkumisnopeutta ja -jyrkkyyttä (e.g. maxYawSpeed = 120°/s, maxPitchSpeed = 90°/s, maxAcceleration = 180°/s²), käyttäen cinematic(), responsive() ja production() esiasetuksia. Tämä on ero "turvakameran lentävän kärpäsen seurannan" ja "vakaakätisen operaattorin" välillä.

Mukautuva FOV – zoomataan kohteen mukaan. Mittaamme kohteen kulmakoon tasasuorakulmaisessa tilassa ja valitsemme FOV:n niin, että se täyttää tietyn osuuden kuvasta:

final angularWidth = (bboxWidth / videoWidth) * 360.0;
final angularHeight = (bboxHeight / videoHeight) * 180.0;
final objectAngularSize = math.max(angularWidth, angularHeight);
final idealFov = objectAngularSize / targetFillRatio; // targetFillRatio ≈ 0.4
return idealFov.clamp(minFov, maxFov); // 45°–120°

Liikkeen ennakointi + kasvojen→vartalon yhdistäminen. Siirrämme kehystystä noin 15 % rajauslaatikon leveydestä eteenpäin kulkusuuntaan, jotta kohde ei ole kiinni siinä reunassa, johon se on kävelemässä. Ja kun kasvojentunnistus katkeaa, emme siirry suoraan vartalon keskipisteeseen – vaan lerp-interpoloimme viimeksi tunnetusta kasvojen keskipisteestä vartalon keskipisteeseen noin 10 ruudun aikana.

5. Kahden videon temppu: esikatseluproksi vs. alkuperäinen täyden resoluution tiedosto

Tämä on arkkitehtoninen päätös, joka tekee koko asiasta käyttökelpoisen oikeissa puhelimissa.

360° GoPro/Insta360-tiedosto on usein 4096×2048 HEVC. Edulliset Android-dekooderit tukehtuvat yrittäessään toistaa sitä sujuvasti, puhumattakaan kohteen seurannan suorittamisesta sen päällä. Siksi suoritamme seurannan ja reaaliaikaisen esikatselun transkoodatulla proksilla (~1440×720, libx264 -preset veryfast -crf 28), ja varaamme täyden resoluution alkuperäisen tiedoston vain lopulliseen vientiin.

// "more reliable than MediaMetadataRetriever for 360° videos
// which often use unusual codecs (HEVC, high-res)"
final maxSafeWidth = 2048, maxSafeHeight = 1080;
// 2:1 4K (4096×2048) is unsafe -> trigger transcodeForPlayback()

Ongelma, joka sinun on käsiteltävä: avainruutujen rajauslaatikot lasketaan proksin koordinaateissa ja ne on skaalattava alkuperäisiin koordinaatteihin ennen vientiä. Jos skaalaus menee pieleen, vientisi rajaa hieman eri alueen kuin käyttäjä esikatseli. (Käytämme myös ffprobea, emme MediaMetadataRetrieveriä, metadatan ja ensimmäisen ruudun poimimiseen – Androidin sisäänrakennettu retriever on epäluotettava 360-kameroiden epätavallisilla koodekeilla.)

6. GPU-vienti: OpenGL + MediaCodec MethodChannelin kautta

Jokaisen 4K-pallon ruudun uudelleenprojisointi FFmpeg-ohjelman v360-suodattimen kautta puhelimen CPU:lla on aivan liian hidasta. (Pidämme v360-merkkijonon kuitenkin tallessa – se dokumentoi siististi projektion semantiikan, v360=e:flat:... tarkoittaa "tasasuorakulmainen sisään, litteä ulos" – mutta se ei ole suora suorituspolku.)

Todellinen vienti antaa avainruudut natiiville OpenGL ES + MediaCodec -renderöijälle MethodChannelin kautta:

final result = await _methodChannel.invokeMethod('exportVideoGPU', {
'videoPath': resolvedVideoPath,
'outputPath': outputPath,
'keyframes': keyframesList,
'initialOrientation': initialOrientationMap,
'width': settings.exportWidth,
'height': settings.exportHeight,
'fps': settings.outputFps.toInt(),
'includeAudio': settings.includeAudio,
if (isTrimmed) 'trimStartMs': trimStartMs,
if (isTrimmed) 'trimEndMs': trimEndMs
});

Rajoitamme tämän ominaisuuden tarkistuksen taakse (Android API 21+, laitteistopohjainen H.264-enkooderi, OpenGL ES 3.0) ja striimaamme edistymisen takaisin EventChannelin kautta. Muutama vaikeasti opittu sudenkuoppa:

−90° yaw-siirtymä. Dart-konventiomme sijoittaa yaw = 0 tasasuorakulmaisen kuvan keskelle (u = 0.5); OpenGL-renderöijä sijoittaa yaw = 0 kohtaan u = 0.75. Joten jokaisen avainruudun yaw-arvo uudelleenmäärätään −90°:lla (ja kääritään uudelleen ±180°:een) kanavan yli – symmetrisesti sovellettuna sekä vientikanavaan että reaaliaikaisen soittimen kanavaan, jotta esikatselu ja vienti ovat yhdenmukaisia.
Epäonnistuneet avainruutujen määrät. Nolla avainruutua → syntetisoidaan kaksi identtistä alkuperäisestä suunnasta (staattinen vienti). Yksi avainruutu → duplikoidaan se. Renderöijä haluaa aina vähintään alun ja lopun.
Leikkaus uudelleenasettelee aikaleimat. Leikattu vienti siirtää jokaista avainruutua arvolla t − trimStartMs.

FFmpeg-jälkikäsittely, jota kukaan ei odota

Voisit luulla, että GPU-vienti on maaliviiva. Se ei ole – koska Androidin MediaMuxer kirjoittaa moov-atomin tiedoston loppuun ja voi sisältää lähdeäänen PTS-siirtymän. Tulos: ExoPlayer (ja Flutterin video_player) jäädyttää kuvan kellon käydessä. Joten GPU-käsittelyn jälkeen FFmpeg tekee nopean, häviöttömän siivouksen:

// copy video (no re-encode -> zero quality loss), re-encode audio to fix PTS,
// move moov atom to the front for instant playback.
-c:v copy -af "aresample=async=1:first_pts=0" -movflags +faststart

Ja raaka pieni sudenkuoppa, joka sitä suojaa: tunnistamme ensin ääniraidan, koska äänilippujen välittäminen videolle, jossa ei ole ääniraitaa, saa FFmpeg-ohjelman jumiin ikuisesti joissakin laitteissa. Koko jälkikäsittely on kääritty 60 sekunnin aikakatkaisuun, jossa on keskeytys aikakatkaisun tapahtuessa.

7. Reaaliaikainen esikatselu on myös natiivi soitin

Editorin sisäinen esikatselu ei ole Flutter CustomPaint – se on natiivi OpenGL-pinta, joka on upotettu AndroidView:n kautta (viewType-arvolla kuten 'your_app/spherical360player'), ja sillä on oma näkymäkohtainen method/event channel. Dart Spherical360PlayerController peilaa yaw/pitch/roll/fov-arvot ja soveltaa saman −90° siirtymän ennen lähettämistä.

Yksityiskohdat, jotka tekevät siitä miellyttävän:

Kuvanopeudesta riippumaton tasoitus — kerroin = 1 - exp(-nopeus * dt), jotta pehmennys näyttää samalta 60 fps:llä ja 90 fps:llä, saumaturvallisella lyhimmän polun yaw-arvolla.
Momentti/inertia heilautuksen jälkeen, kitkaan perustuvalla vaimenemisella – pois päältä toiston aikana, koska toiston aikana kameran on noudatettava avainruutuja, ei käyttäjän viimeisintä pyyhkäisyä.
Yksi GestureDetector, jonka onScaleUpdate tekee panoroinnin ja nipistyszoomin yhdessä; kaksoisnapautus vaihtaa toiston/tauon välillä. FOV rajoittuu 30°–120°:een, pitch ±90°:een ohjaimen rajalla.

Yksi pieni mutta paljastava UX-korjaus: ennen siirtymistä "seurannasta" "avainruutujen generointiin" lisään 120 ms:n viiveen, jotta Flutter todella piirtää "100 %". Ilman sitä lopullinen edistymisruutu ja tilamuutos päätyvät samaan mikrotehtäväerään, eikä käyttäjä koskaan näe valmistumista.

Tilakone, lyhyesti

Kaikkea tätä koordinoi Riverpod ReframeNotifier, joka ohjaa tilaluetteloa:

joutokäynti → videon lataus → transkoodaus
→ (tunnistus | kohteen valinta | rajauslaatikon piirto soittimeen | automaattinen tunnistus soittimessa)
→ seuranta → avainruutujen generointi → muokkaus → vienti → valmis | virhe

Useat sisääntulopisteet syöttävät samaa seurainta: napauta tunnistaaksesi (YOLO-peite), manuaalinen rajauslaatikko tai Insta360-tyylinen suoraan soittimeen piirtämisliike. Ne kaikki yhtyvät KeyframeGenerator.production().generate(...) → KeyframeSmoother.smooth(...)-funktioihin, ja sieltä interpoloija ohjaa jokaista esikatseltua ja vietyä ruutua.

Opetukset

Pidä matematiikka puhtaana. Ei Flutter-tuonteja projektio-/interpolointikerroksessa. Se on ainoa syy, miksi tämä oli testattavissa.
Quaternion SLERP suunnalle; LERP skalaareille. Älä interpoloi Euler-kulmia, äläkä SLERP-interpoloi zoomiasi.
±180° sauma on läpileikkaava huolenaihe, ei reunatapaus. Se ilmestyy uudelleen primitiiveissä, generoinnissa, projektiossa ja soittimessa.
Yhdenmukaista konventiosi kerran, symmetrisesti. −90° yaw-siirtymä Dartin ja OpenGL:n välillä sovelletaan molempiin kanavarajoihin, jotta esikatselu == vienti.
Proksi vuorovaikutukseen, alkuperäinen tuotokseen. Muista vain skaalata koordinaattisi näiden kahden välillä.
"Renderöinti valmis" ≠ "toistaa oikein." Varaa resursseja FFmpeg-jälkikäsittelyyn moov-atomin sijoittelun ja äänen PTS-virheiden korjaamiseksi, ja tunnista ääniraidat ennen kuin lisäät äänilippuja.
Tuntuma on ominaisuus. Liikerajoitukset, mukautuva FOV ja liikkeen ennakointi erottavat "teknisesti uudelleenkehyksetyn" siitä, "miltä ammattilainen sen kuvasi".

Tulos: täysin laitteessa toimiva 360°-uudelleenkehystyseditori – napauta kohdetta, anna sen seurata, säädä avainruutuja ja vie puhdas litteä video – rakennettu Flutterissa ohuella natiivilla GPU-kerroksella, joka tekee vain sen työn, mihin Dart ei pysty tarpeeksi nopeasti.

360-videon uudelleenkehystys Flutterissa: Pallomainen projektio, Quaternion-avainruudut ja GPU-vienti

360-videon uudelleenkehystys Flutterissa: Pallomainen projektio, Quaternion-avainruudut ja GPU-vienti

Ongelma, josta kukaan ei varoita sinua

Arkkitehtuuri lyhyesti

1. Kaiken ydin: tasasuorakulmainen ⟷ pallomainen

"Napauta sitä, mitä näet" — perspektiivi-säteenseuranta

2. Tasainen kameran liike: Quaternionit, ei Euler-kulmat

Pehmennys: käsin toteutettu, saapuvan siirtymän yhteydessä

3. ±180° sauma: virhe, joka kummittelee jokaisessa 360-ominaisuudessa

4. Saada se tuntumaan Insta360/GoPro:lta

5. Kahden videon temppu: esikatseluproksi vs. alkuperäinen täyden resoluution tiedosto

6. GPU-vienti: OpenGL + MediaCodec MethodChannelin kautta

FFmpeg-jälkikäsittely, jota kukaan ei odota

7. Reaaliaikainen esikatselu on myös natiivi soitin

Tilakone, lyhyesti

Opetukset

Tietoa kirjoittajasta

Haluatko oppia lisää?

Usein kysytyt kysymykset

Comments (0)

Leave a Comment