OpenOSV 0.6.4

OpenOSV 0.6.4: VEGAS extension compatibility, Avata 360 stabilisation, Source Settings live sync and 8K exports

Fixes for all four open reports across VEGAS Pro, DaVinci Resolve and Premiere Pro (#7, #8, #9, #10).

What's fixed

• Third-party VEGAS Pro extensions such as Vegasaur no longer fail with E_NOINTERFACE (IVegasCOM / IDockWindow) when OpenOSV is installed (#10). WinForms' default WindowsFormsSynchronizationContext.AutoInstall replaces the UI thread's SynchronizationContext.Current on Control construction and reverts it to a plain System.Threading.SynchronizationContext when a modal dialog loop exits, stranding STA COM marshaling for other extensions in the process. OpenOSV now pins the UI SynchronizationContext with AutoInstall = false across initialization, command callbacks and modal dialogs.
• Changing a control in the OpenOSV Source Settings effect updates the live clip and exports immediately, including when returning a control to its default (#9). All value controls in OpenOSVSourceSettings.aex are now supervised and publish the translated PrefsBlob synchronously to the importer's live instances and direct-GPU engine via OsvEngine_PublishSourceSettings before Premiere re-instantiates the effect or opens a second importer instance for export.
• 8K 50 fps exports and seam analysis no longer exhaust NVDEC's VRAM cache slots and fall back to software decoding (#8, #9). Automatic VRAM budgets now reserve at least four dual-lens cache slots when free device memory allows, and ImporterInstance::anchorPairLocked releases older cached analysis frame leases before retrying when all slots are pinned by multi-bucket lookahead.
• OpenOSV Source in DaVinci Resolve now uses the NVDEC + CUDA own-GPU pipeline by default (#7, #8, #9). Resolve's OpenFX generator host hands CPU output buffers even on CUDA timelines; enabling the own-GPU path for HostProfile::Resolve keeps decoding, stitching and reframing on the GPU and downloads only the finished output window (11.8x faster at 1080p and 4.6x faster at 4K on RTX 5090).
• Stabilisation now works on DJI Avata 360 clips (#7). The Avata 360's IMU records the attitude of the aircraft frame while its lens extrinsics sit in the camera body frame (productMount(Avata360)^T); AttitudeTrack::build now post-multiplies the stored rig-axes quaternion by productMount(schema)^T, attitudeReadingVerified(Avata360) is enabled, stabilizationBodyFromWorld applies the mount across all five stabilisation modes, and CalibrationSelector::choose counts native_refine_far as a native calibration set.

Good to know

• .LRF is not supported — only .OSV. The camera's low-resolution .LRF files are not a supported workflow. Always work from the .OSV.
• Drone / airborne Osmo 360 & Avata 360 settings (#8): For an Osmo 360 hanging under a drone or an Avata 360 in flight, use Stabilisation: Smooth + Horizon Lock (or Horizon Lock to keep the aircraft's yaw while levelling pitch and roll; high-frequency prop/motor vibration above 12 Hz is automatically filtered out of the gyro track), Parallax Grid: Steady (or Auto), and Hide Mount: Auto (or Off if the drone body sits near the seam and you want full lens overlap).

How to update

Close your editor, unzip the zip for it and double-click Install.cmd. Premiere users: launch it once holding Shift.

Downloads

• OpenOSV-0.6.4-premiere-windows-x64.zip: Premiere Pro
• OpenOSV-0.6.4-resolve-windows-x64.zip: DaVinci Resolve (preview)
• OpenOSV-0.6.4-vegas-windows-x64.zip: VEGAS Pro 17.0 (experimental)

ffmpeg-9.0.1-source.tar.gz and ffmpeg-9.0.1-vcpkg-port.zip are the source of the FFmpeg build the zips ship (LGPL-2.1).

SHA-256

d7def9561dfef9292f5b522422880c4308b9830b0dc14c87c5733416b626a46c *OpenOSV-0.6.4-premiere-windows-x64.zip
815b4a6784d66f5e1dc063660d52b81ca220ea097a12007c24873b5b3505502a *OpenOSV-0.6.4-resolve-windows-x64.zip
2a2bf98c6acd8af05a065102b70b48c4bacd3808bee807064c40f568d521f88f *OpenOSV-0.6.4-vegas-windows-x64.zip

OpenOSV 0.6.3

OpenOSV 0.6.3: an edit in Source Settings stays made

One bug, reported on Premiere 2024, 2025 and 2026: change a control in the OpenOSV Source Settings effect and nothing happens, the control snaps back. 0.6.3 fixes it.

What's fixed

• Changing a control in the OpenOSV Source Settings effect did nothing; the controls snapped back to their previous values. Premiere re-creates the effect right after an edit, and the effect answered that by asking the importer what the clip was being decoded with and writing the answer back into the controls. The importer had not been handed the edit yet, so its answer was the old settings, and the edit was undone before it was ever stored. The effect now asks the importer only for a clip whose controls are still untouched. Controls that hold settings are the clip's settings and are left alone. Colour Output, HDR Tone, Stabilisation, every control: pick it, it stays, the clip re-stitches.

Good to know

• Where the settings are. Select the clip in the Project panel, open Effect Controls, pick the Source tab ("Master * clip" on 2024 and older) and twirl open OpenOSV Source Settings. Every option is an ordinary control there, applied as you change it.
• "Source Settings..." greyed out in the Project panel is Premiere's own behaviour for a clip whose settings live in a Source Settings effect (its R3D importer has done the same since CC 2015). It is not a fault, and 0.6.3 does not change it: the Source tab is the route.
• Working in an HDR sequence is what makes BT.2100 PQ output look like HDR. In a Rec. 709 or ACEScct sequence the PQ output is flat and grey by design; set the sequence's working colour space to Rec. 2100 PQ, or pick Rec. 709 output.
• Everything else is 0.6.2: the stitch, the colour, the importer, the LUTs and the Resolve and VEGAS plug-ins are unchanged. The effect's parameter list is unchanged, so existing projects keep every stored value.
• Tests before this release: the Source Settings effect suite against the built module, with a new case for the edit-then-stale-answer path, 67 cases green. No GPU suite was run: no kernel changed.

How to update

Close your editor, unzip the zip for it and double-click Install.cmd. Premiere users: launch it once holding Shift.

Downloads

• OpenOSV-0.6.3-premiere-windows-x64.zip: Premiere Pro
• OpenOSV-0.6.3-resolve-windows-x64.zip: DaVinci Resolve (preview)
• OpenOSV-0.6.3-vegas-windows-x64.zip: VEGAS Pro 17.0 (experimental)

ffmpeg-9.0.1-source.tar.gz and ffmpeg-9.0.1-vcpkg-port.zip are the source of the FFmpeg build the zips ship (LGPL-2.1).

SHA-256

00f358f78fc1953e374fd8da9f1845b93d99723084350928b64f1fdbafc793e9 *OpenOSV-0.6.3-premiere-windows-x64.zip
f4a47a5a8d2db1dda5abdbd2f2709620787ac57906d03f0fd2b032c3b357060d *OpenOSV-0.6.3-resolve-windows-x64.zip
a5dd7616c7ec94a6d737343b1d3d75e64b59e6aff87102a6093ab7253bad8d12 *OpenOSV-0.6.3-vegas-windows-x64.zip

OpenOSV 0.6.2

OpenOSV 0.6.2: the Avata 360's calibration, read as the aircraft writes it

One report, two rounds. 0.6.1 guessed at the schema name; the reporter's osvtool probe output (#7, thank you) showed the name was right and the lens records were not what the Osmo 360 writes. 0.6.2 reads them.

What's fixed

• An Avata 360 clip was refused as "no lens calibration" with the schema read correctly (#7). The Avata 360 writes each lens's extrinsic as Euler angles only (no quaternion, four zeros in its copy), so every record failed the calibration test; and it keeps its lens records in native_refine_far with nothing usable in native_refine. The decoder now builds the quaternion from the angles by the relation the Osmo 360's own records follow (checked on every populated slot of the sample clip: better than 0.03 degrees), and the native choice falls back through native_refine_far, DJI's own order. The clip opens and stitches. A quaternion the camera wrote is never replaced, so nothing changes on an Osmo 360.
• An Avata 360 clip no longer opens looking at the ground, or levelled upside down. Its master lens looks down and its nose is the body's -Z, so the view is placed in that frame before any attitude is read: forward, sky up. Its stored attitude has no verified reading yet (the default one puts up 141 degrees from true up on the clip measured), so stabilisation stays off on it, with a log line, rather than level the world by a reading that is wrong. osvtool --attitude-convention <reading> still builds the track for anyone with footage to verify one.
• osvtool probe --report is the one command for a bug report. It prints every field of sample 0 as the camera wrote it (--raw printed only a node count before), a line per calibration record saying what it holds and what keeps it from being usable, and a new attitude section: which sources every frame carries, the first frame's values, the reading auto would use and whether it is verified on the product. It writes the JSON beside the clip and says what to attach. The "no lens calibration" message points at it.

Good to know

• Still built without an Avata 360 clip to test on: the lens numbers and the frame come from a contributor's measurements of two recorded clips against DJI Studio's output. If 0.6.2 opens yours, please say so on #7. If the stitch or the direction looks wrong, a frame of OpenOSV's output next to DJI Studio's would settle it.
• Stabilisation on the Avata 360 is off until its attitude reading is verified. Horizon Leveling and RockSteady need a clip to check against; the Osmo 360 is unchanged.
• Everything else is 0.6.1: the stitch, the colour, the plug-ins and the LUTs are unchanged.
• Tests before this release: the metadata, protobuf and calibration suites (with new cases for the Euler extrinsic, the native_refine_far fallback and the aircraft's frame), the attitude suite, the importer's CPU suite and the CLI suite with the sample clip, all green. No GPU suite was run: no kernel changed.

How to update

Close your editor, unzip the zip for it and double-click Install.cmd. Premiere users: launch it once holding Shift.

Downloads

• OpenOSV-0.6.2-premiere-windows-x64.zip: Premiere Pro
• OpenOSV-0.6.2-resolve-windows-x64.zip: DaVinci Resolve (preview)
• OpenOSV-0.6.2-vegas-windows-x64.zip: VEGAS Pro 17.0 (experimental)

ffmpeg-9.0.1-source.tar.gz and ffmpeg-9.0.1-vcpkg-port.zip are the source of the FFmpeg build the zips ship (LGPL-2.1).

SHA-256

0d66c7e51a92aa00ab88340004ef80eea125f318eaa8acc093e8ed54865e2cd5  OpenOSV-0.6.2-premiere-windows-x64.zip
e907e625b7163a6c3671d30be5b84e27f76f56e66b73176c6962d76960a4f0ee  OpenOSV-0.6.2-resolve-windows-x64.zip
555782d78393811f17e6a58ff433cda63079941cf538ccbebdcc82fecf7a8467  OpenOSV-0.6.2-vegas-windows-x64.zip

OpenOSV 0.6.1

OpenOSV 0.6.1: an Avata 360 clip is known by its layout

A small release for one report. OpenOSV Source in DaVinci Resolve refused a DJI Avata 360 clip as "no lens calibration (not a dual-fisheye OSV)" (#7). The decoder recognised an Avata 360 clip by one exact spelling of the schema name its metadata carries, the one the recorded clips it was written against used. A clip that names it any other way read in the Osmo 360 numbering, where the Avata 360's calibration slot is something else, and the clip was refused. 0.6.1 reads a clip by what it holds.

What's fixed

• An Avata 360 clip could open as "no lens calibration". The schema name is now matched by its product token whatever its case, and it is no longer the last word: when the numbering a clip's name gives finds no lens calibration, every known schema is tried and the one under which the clip carries a calibration reads the whole clip, its focal length and sensor size and every frame's attitude included. osvtool probe says when the layout, not the name, chose the schema. A clip that describes more than one stream also keeps the stream that carries the calibration, instead of the last one written.
• The "no lens calibration" message says what the clip did carry: the schema name it wrote, its product and firmware, the numbering it was read in, and how to get the rest (cli\osvtool.exe probe --raw <clip>). If you still see it, that line plus the probe output is everything a report needs.

Good to know

• This fix was built without an Avata 360 clip to test on. If 0.6.1 opens yours, please say so on #7; if it does not, paste the new message and the osvtool probe --raw output there.
• Everything else is 0.6.0: the stitch, the colour, the plug-ins and the LUTs are unchanged.
• Tests before this release: the metadata and protobuf suites (40 cases, with five new ones for the schema-by-layout reading), the importer's CPU suite (112 pass, 2 skipped) and the CLI suite with the sample clip, all green. No GPU suite was run: no kernel changed.

How to update

Close your editor, unzip the zip for it and double-click Install.cmd. Premiere users: launch it once holding Shift.

Downloads

• OpenOSV-0.6.1-premiere-windows-x64.zip: Premiere Pro
• OpenOSV-0.6.1-resolve-windows-x64.zip: DaVinci Resolve (preview)
• OpenOSV-0.6.1-vegas-windows-x64.zip: VEGAS Pro 17.0 (experimental)

ffmpeg-9.0.1-source.tar.gz and ffmpeg-9.0.1-vcpkg-port.zip are the source of the FFmpeg build the zips ship (LGPL-2.1).

SHA-256

78397cf579e831c21d782a25428c02791fb0b19bcb9486ddc6b3356960661c12  OpenOSV-0.6.1-premiere-windows-x64.zip
248eaccd55bc773a8659dbdbc3ad5826b1e13699f5fe5cb3fe2f303a8c32b452  OpenOSV-0.6.1-resolve-windows-x64.zip
98e647d9a4b8d5bd808ba2aaff1448cf072bb6320400526dd9166d9616a868bf  OpenOSV-0.6.1-vegas-windows-x64.zip

OpenOSV 0.6.0

OpenOSV 0.6.0: the stitch holds still

0.5.x moved the seam correction to one mesh warp solved per clip and per eight-frame moment, and 0.5.3 stopped a mounted camera's vibration from shaking the mount. On a drive, though, a moment could still settle on a wrong answer along a repeating facade, and the stitch slid the two lenses against each other every few frames. 0.6.0 keeps the clip's own correction everywhere a moment hasn't earned its own, so the stitch only moves where the scene does.

What's fixed

• A stitch on a repeating facade no longer slides back and forth. With Parallax Grid on Auto and a clip judged "follows scene", every eight frames rendered their own correction field. On a reported 8K drive, a hotel 25 m away sat on the seam in the arc where Hide Mount leaves the two lenses a strip only 15 rows deep out of the band's 68. A strip that short holds two periods of the facade's columns, so the flow lined the facade up one period off just as happily as at the truth. Each eight frames picked a different answer, and the glide between them slid one lens's half of the hotel against the other's by up to 60 px. A moment's field now renders only where it lines the lenses up measurably better than the clip's field (a near car passing the seam), and only where the two lenses share enough of the band for that comparison to mean anything. Everywhere else the clip's field holds. On that drive the seam's frame-to-frame motion fell from 1.34 to 0.22-0.50 px per frame (the same as Steady), and the hotel stopped swinging between -37 and +21 px.

Good to know

• .LRF is not supported yet. The camera's low-resolution .LRF files, alone or as a proxy, aren't a supported workflow in this release. Work from the .OSV.
• Where the clip's correction holds, a fixed offset can remain: on that drive the hotel keeps a steady +16 to +25 px of the uncorrected +30 px, a calibration error at that angle. It no longer moves.
• The carved seam still has to cross a near object that sits on it (the sample's propeller and nacelle), and the two lenses see that object from different sides, so its outline keeps a small, fixed step at the cut.
• The importer log's per-bucket line now says how much of the clip field held: "against the clip field: own O / clip C / B blended of N cells, T on a thin overlap (own share x)".
• Tests before this release: the CPU suites of every module with the sample clip, all green except two known failures: the clip-wide mesh against the old per-frame grid at the wing root (as at 0.5.3), and the long-standing OpenCL parity check (within 2 codes on 99.9487% of pixels against a 99.95% bar, the same figure since 0.2.2). The CUDA suites were not run for this release (the CUDA and OpenCL kernels are unchanged since 0.5.2). Checked by eye on the airborne sample, the 8K drive and a night drive: the airborne sample renders bit-identical to 0.5.3.

How to update

Close your editor, unzip the zip for it and double-click Install.cmd. Premiere users: launch it once holding Shift.

Downloads

• OpenOSV-0.6.0-premiere-windows-x64.zip: Premiere Pro
• OpenOSV-0.6.0-resolve-windows-x64.zip: DaVinci Resolve (preview)
• OpenOSV-0.6.0-vegas-windows-x64.zip: VEGAS Pro 17.0 (experimental)

ffmpeg-9.0.1-source.tar.gz and ffmpeg-9.0.1-vcpkg-port.zip are the source of the FFmpeg build the zips ship (LGPL-2.1).

SHA-256

e137c5071ad1422bddef1da3efd6f67ab2ab5187c01eb6cfaa99e48ad36ac6c6  OpenOSV-0.6.0-premiere-windows-x64.zip
b07f43285dad326b2e8ae409b43fa15cd158a8a4e6ee63c07bdc2106d0a556eb  OpenOSV-0.6.0-resolve-windows-x64.zip
a5197d676cf041760de73afc9497c89d9f83df180eca602e4970ce67a34447de  OpenOSV-0.6.0-vegas-windows-x64.zip

OpenOSV 0.5.3: the mount holds still

OpenOSV 0.5.3: the mount holds still

A camera bolted to a wing or a car shares every bit of the mount's vibration, and 0.5.2 (like every version before it) counter-rotated that vibration out of the picture, so the world stood still and the mount shook on screen. The per-clip verdict that used to freeze the seam on such a mount had tipped over to re-measuring it every eight frames, reduced-resolution playback dropped every seam correction, and the .LRF proxy was blown up from a quarter frame. 0.5.3 fixes all four at their causes.

What's fixed

• A mounted camera's vibration no longer shakes the mount on screen. Stabilisation read one attitude sample per frame; on the airborne sample the camera buzzes with the engine at 89 Hz (0.04 degrees, measured on the 1 kHz IMU batches), which one sample per frame reads as a 0.2 degree sign flip every frame, and Smooth + Horizon Lock counter-rotated it faithfully. Every mode now builds its attitude from every IMU sample low-passed at 12 Hz, so what is faster than a visible shake stays in place and the mount holds still. The engine nacelle moves 0.1-0.4 px per frame instead of about 1 px; a turn, a bank and hand shake are removed as before. Clips without IMU batches keep the per-frame attitude.
• Parallax Grid Auto holds a rigid mount still again. 0.3.0 and 0.4.2 judged the airborne sample "steady" (one correction and one seam for the whole clip); 0.5.2 judged it "follows scene" and re-measured, glided and re-carved the nacelle every eight frames. The verdict scored each sample frame's own correction on that same frame, so a spinning propeller's streaks or a reflection on chrome let it win without moving the picture any differently. A sector now counts as lost only where the two corrections really move the picture differently (half a degree of disparity or more); the sample is steady again (0 of 66 judged sectors lost, 4 agreed), and a near object that really moves still fails by its parallax.
• Playback shows the seam correction the parked frame shows. Every frame Premiere asks for at 1/2 or 1/4 playback resolution is a draft request, and a draft rendered with no seam correction, no parallax field, no carved seam and no ghost removal at all. A draft now renders with everything already measured for its bucket and still pays for nothing; a frame whose bucket is not measured yet stays non-final so it never lands in the host's cache.
• The .LRF proxy delivers its native size. Reduced playback resolutions asked the 2000x1000 proxy for half and quarter of that, and a 60 degree reframe magnified a 500x250 frame forty-odd times: the blocky, smeared playback reported for a proxy on the timeline. A proxy (and a lone .LRF) now advertises its native size only.

Good to know

• With the vibration left in place the far background keeps the camera's buzz, as the raw footage has it; on the sample that is under 2 px on hazy ground and sky. Stabilisation Off remains the reference: a rig-fixed object is bit-steady there.
• The carved seam still has to cross a near object that sits on it, and the two lenses see that object from different places, so its outline keeps a small, now fixed, step at the cut. Taking such an object whole from one lens is the next piece of work.
• osvtool seam --steady and the importer log now report, per sector, how far apart the sample's own correction and the clip's are ("fields 0.32 deg apart") and how many sectors were "agreed".
• Tests before this release: the CPU suites of every module with the sample clip, all green except one sample-clip check that compares the clip-wide mesh with the old per-frame grid at the wing root (it keeps 0.25 NCC there against the grid's 0.28-0.34). The GPU parity suites were not run for this release (the CUDA and OpenCL kernels are unchanged since 0.5.2). This is a pre-release.

How to update

Close your editor, unzip the zip for it and double-click Install.cmd. Premiere users: launch it once holding Shift.

Downloads

• OpenOSV-0.5.3-premiere-windows-x64.zip: Premiere Pro
• OpenOSV-0.5.3-resolve-windows-x64.zip: DaVinci Resolve (preview)
• OpenOSV-0.5.3-vegas-windows-x64.zip: VEGAS Pro 17.0 (experimental)

ffmpeg-9.0.1-source.tar.gz and ffmpeg-9.0.1-vcpkg-port.zip are the source of the FFmpeg build the zips ship (LGPL-2.1).

SHA-256

73a734be9d0e27ca8b207f00c1a29b18a32b6b6cdd22945c8a11c2d58c8510d2  OpenOSV-0.5.3-premiere-windows-x64.zip
2f8bbdf05241ebce5ca5d277ce484d3b12ddc1058dd753dc1c2acd5ae61a9826  OpenOSV-0.5.3-resolve-windows-x64.zip
d8c2bec9a1064385bfeed6f4adc7e574e50a732ce3ea06b9521b3a778e5b2d77  OpenOSV-0.5.3-vegas-windows-x64.zip

OpenOSV 0.5.2

OpenOSV 0.5.2: the seam as one field

0.5.1 lined the car body up across the seam, but it did so by switching column by column between a 1-D shift table and a 2-D flow grid, and every switch put a kink into whatever straight line crossed the seam: the car roof and the hood crease waved. The picture also changed between playing and parking, because a frame played during playback borrowed corrections measured on itself. 0.5.2 replaces that three-part correction with one mesh warp, fixes playback at the cause, survives a recording that lost a key picture, and lets the camera's .LRF stand in as Premiere's proxy.

What's fixed

• Straight lines stay straight across the seam. The seam correction is now one smooth field over the seam band, solved at once from the measured parallax, the straight edges detected in both lenses, a shape term that falls to zero away from the seam, and the previous moment's field. There is nothing left to switch between, so there is nothing to kink. On the day drive's hood a panel gap crossing the seam runs within 0.16 px of a straight line instead of 0.55 px (largest bend 0.9 px instead of 3.7 px), detected edges bend 7-14 times less at the seam, and the car body lines up better than before (0.992 against 0.971, median of 18 moments). The 6K sample's propeller blade, which bent at the seam in 0.5.1, renders single and straight.
• Playback shows the frame you get when you stop. Each 8-frame bucket is measured once, on its first frame, and every frame of it renders the same playing or parked. On the day drive's hood, 0.5.1 played 11 of 17 frames differently from the same frames parked (a bolt on the seam sat 2.3 px off); the measured frames are now byte for byte the parked ones. The seam's carve is steered around the sun ghosts of the bucket's first frame, whichever frame carves it. A bucket still being measured shows the previous bucket's correction until its own lands.
• The seam moves less from one moment to the next. Each bucket's field leans on the bucket before it, so measurement noise is held still while a real change (a car passing) still comes through: the field changes 1.4-1.6 times less between buckets.
• A clip that dropped frames no longer fails a whole second of frames. When the camera drops frames it can drop one lens's key picture with them, and no decoder can produce the pictures up to the next key picture (a night drive: 49 frames of one lens). Premiere got an error for each, after the importer had decoded the whole group twice for nothing, and the log blamed "the stream's timing". The decoder now recognises such a run the first time it crosses it, names it in the log, and shows the last frame before the run on both lenses, levelled with that frame's own attitude, at no decode cost. Every other frame is unchanged, bit for bit.
• An .LRF finds its .OSV when the .OSV was renamed by a copy (CAM_..._D-001.OSV beside CAM_..._D.LRF), so it plays on the .OSV's timeline instead of its own 25 fps one. Two such copies beside one .LRF are left alone. A project that used such an .LRF on its own will see its timing change on reopen.
• The importer offers Premiere a settings block for every clip. In the 0.5.0 and 0.5.1 sessions the OpenOSV Source Settings effect never received the per-clip block Premiere hands it, so changes in the clip's Source tab never reached the picture or the project. The importer now offers that block when it opens a clip that has none. Whether Premiere keeps it still has to be confirmed live: launch Premiere once with Shift held after installing, change Colour Output on a clip's Source tab, and see whether the monitor follows. The Source Settings effect is now version 1.1.0 (0.5.1 added Hide Mount but kept 1.0.0); a 0.5.0 project restores every value by its id, with Hide Mount On.

What's new

• The camera's .LRF becomes the .OSV's proxy. With Auto-apply on, the OpenOSV panel attaches the .LRF beside each dropped .OSV as its Premiere proxy (once per master clip, never over a proxy that is already there), and Attach .LRF proxies does it for the clips already in a sequence. Toggle Proxies in the Program Monitor then edits on the light file; export still uses the .OSV. The UXP panel now asks for file access to find the .LRF.
• osvtool seam --mesh scores the new field against the correction it replaces; osvtool render --purpose exact|interactive|playback|play renders the way Premiere asks during playback, so playback and a parked frame can be compared byte for byte; osvtool decode-replay <clip> --trace <plug-in log> replays the frames a Premiere session asked for, in its order and from its threads, and compares every picture with a sequential software decode.

Good to know

• On the night drive the car body next to the mount's blind arc lines up a little worse than in 0.5.1 (0.72 against 0.77 at one moment, 0.92 against 0.95 at another): there is no overlap to measure there, and 0.5.1 copied a neighbour's correction into it. The 6K sample's stick strip is 0.004 worse for the same reason. Lamp poles beside the seam are as straight as before within a few hundredths of a pixel.
• The clip-wide correction (Parallax Grid Steady, and Auto when it chooses Steady) takes about a third longer to measure, because every sample frame is measured twice. Auto now holds the day drive steady and lets the 6K aerial sample follow the scene, the other way round from 0.5.1.
• A smeared .LRF frame at 1/4 playback resolution in Premiere is not the decoder: the frames a session asked for replay bit for bit. What produces it after decoding is still being looked for.
• The 6K sample clip's lens overlap renders differently from 0.5.1 on purpose (the field, and Auto's choice); everything outside the seam band is byte for byte the same.

How to update

Close your editor, unzip the zip for it and double-click Install.cmd. Premiere users: launch it once holding Shift so it picks up the updated Source Settings effect.

Downloads

• OpenOSV-0.5.2-premiere-windows-x64.zip: Premiere Pro
• OpenOSV-0.5.2-resolve-windows-x64.zip: DaVinci Resolve (preview)
• OpenOSV-0.5.2-vegas-windows-x64.zip: VEGAS Pro 17.0 (experimental)

ffmpeg-9.0.1-source.tar.gz and ffmpeg-9.0.1-vcpkg-port.zip are the source of the FFmpeg build the zips ship (LGPL-2.1).

SHA-256

0a05c9c2863f11ba17dc5c123e67eb42d164193f1a7f5b508b008a6a90fea5e9  OpenOSV-0.5.2-premiere-windows-x64.zip
86c6c753f927575d2c1b2a3c4874b3631d56dc7eea8a8dea8350364ceb87a618  OpenOSV-0.5.2-resolve-windows-x64.zip
d98b3ca37c4221eb43a2c79858e618fc089d320bc1b380699cd42d89c292fd69  OpenOSV-0.5.2-vegas-windows-x64.zip

OpenOSV 0.5.1

OpenOSV 0.5.1: Premiere on a car mount, fixed at the cause

0.5.0 was measured with osvtool. Premiere Pro renders a different path: the classical flow solver and the per-column seam table. Run on the same two 8K car drives through that path, the stitch still wobbled, stepped and popped, and the horizon still leaned. Every one of those had a root cause, and every one is fixed in the code Premiere, DaVinci Resolve and VEGAS Pro share.

What's fixed

• Light poles beside the seam are straight, and the seam no longer jumps every eight frames. The seam table took a shift from every column that matched at all, so blank sky handed it random shifts of up to ±4° that bent anything running along the seam, and a change rule turned that noise into a jump at every bucket start. Each column now carries a confidence, the table is a robust smooth of the confident columns only, and it steps at a bucket edge only when both measurements are sure. A lamp pole next to the 8K seam goes from 2.85 px of wobble to 0.19 px; the per-frame change at bucket starts from 3.4° on 16 % of the columns to 0.04° on none.
• Horizon Lock is level, in every host. 0.5.0 still left the car drives leaning 28° (sunset) and 7-11° (night): the camera's stored attitude was read with its axes transposed, and the near-static airborne sample could not tell. The new reading levels both drives within about 4° of their lamp posts and keeps the sunset sun at +6 to +10° through a 106° turn. Full and Smooth now turn with the car instead of against it. This is also the VEGAS "image skewed" report (#5). Saved projects with Pan keyframes on mounted clips will see their horizon move: that is the fix.
• The parallax correction aligns a car body a metre from the lenses. The classical solver could not reach the 2.4° offset a roof rail shows along the seam and left it doubled whenever it was accepted. It now searches along the seam direction first and moves only where the match is unambiguous: the car body's overlap match goes from 0.84-0.87 to 0.93-0.97, at about 10 ms more per bucket on the CPU.
• The correction no longer switches on and off from one moment to the next. Whether a moment used its 2-D correction depended on how much of the whole seam band's flow checked out, and on a car mount most of that band is sky. The check now counts only pixels with detail in both lenses, and a moment near the bar fades its correction out and the seam table in.
• The car's hood lines up across the seam even where the 2-D correction is accepted. The flow cannot follow the hood's 2.5° offset, so the seam table takes over the stretches of the seam the flow could not measure, where the table is at least 60 % sure and found an offset the flow missed. The hood's overlap match goes from 0.95 to 0.97 (median of 15 moments) and the whole seam band to 0.993; the night drive, where the table is unsure of the hood, keeps the flow's alignment; the 6K sample is untouched.
• Non-square projects (HDV, DV, anamorphic) are no longer stretched in VEGAS and Resolve, and the playback proxy smooths over the same seconds as the clip, so its framing stays within 0.1° of the final render.
• A damaged hardware-decoded proxy picture is decoded again in software instead of being delivered. A clip without a recorded focal length still opens, and a proxy never borrows its parent's. A ranged osvtool render plays its own sound.

What's new

• Hide Mount (Source Settings, and the OpenOSV Source generator in Resolve and VEGAS: On, Off, Auto). On a car, helmet or suction mount, Off gives the two lenses their full overlap back where the mask used to cut the seam (the mount can show); Auto measures the clip once and keeps the mask only where the lenses disagree. On is the default and what every existing project keeps, bit for bit.
• The plug-in logs now carry the library's and FFmpeg's messages, name the clip on every per-bucket line, and say how much of a moment's flow was consistent and at what strength it applies.
• Diagnostics for a proxy frame that shows the wrong picture (docs/PREMIERE.md, Troubleshooting): decode and delivery fingerprints, OPENOSV_VERIFY_HW_DECODE=1, OPENOSV_IMPORTER_LRF_SOFTWARE=1, OPENOSV_VERIFY_DELIVERY=1, and a five-minute check that tells the decoder, the stitch, the copy into Premiere and Premiere's own cache apart.
• A car-mount checklist in the same Troubleshooting section: what to set, what the log says, what to send.
• osvtool: --hide-mount on|off|auto, seam --json with per-column confidence and both flow shares, --dump-bands writes raw and table-corrected bands, --attitude-convention ...-rig, and render says which flow solver it runs and whether that is the plug-ins' one.

Good to know

• The lens overlap of the 6K sample clip renders byte for byte as in 0.5.0 on the default settings. Car-mounted clips change on purpose.
• Where a near part of the car crosses the seam inside the mask's arc, the roof edge still steps about 2.7° with Hide Mount On (2.3° with Off): that crossing has no lens overlap, and what remains is the car's own disparity along the seam. The checklist says what to send if your mount looks worse than that.
• The attitude reading was settled on two level car mounts and one airborne clip. A clip with real pitch and roll (a tilted tripod, a slow pan, handheld) would pin the last couple of degrees down; if you have one, open an issue.

How to update

Close your editor, unzip the zip for it and double-click Install.cmd.

Downloads

• OpenOSV-0.5.1-premiere-windows-x64.zip: Premiere Pro
• OpenOSV-0.5.1-resolve-windows-x64.zip: DaVinci Resolve (preview)
• OpenOSV-0.5.1-vegas-windows-x64.zip: VEGAS Pro 17.0 (experimental)

ffmpeg-9.0.1-source.tar.gz and ffmpeg-9.0.1-vcpkg-port.zip are the source of the FFmpeg build the zips ship (LGPL-2.1).

SHA-256

308e574d5f59f94594206a418d8b31da396ee68a1f34905401622dc82b7b60ed  OpenOSV-0.5.1-premiere-windows-x64.zip
c9a52b232edfe3ccca1b377ecd02ee283438ee335bd11e99b1331a3da1cd7d49  OpenOSV-0.5.1-resolve-windows-x64.zip
989b0d0c09e720d1acee959744ef750bb4c3562a8393447a83116fdd7d7d4b9d  OpenOSV-0.5.1-vegas-windows-x64.zip

OpenOSV 0.5.0: 8K and night footage, fixed at the cause

OpenOSV 0.5.0: 8K and night footage, fixed at the cause

A user sent two car-mounted 8K clips, a sunset drive and a night drive, that DJI Studio stitched cleanly and OpenOSV did not. Doubled lamp posts, a halo in the night sky, a crooked horizon, video drifting away from its sound. Every one of those had a root cause, and every one is fixed.

What's fixed

• 8K clips no longer double at the seam. In 8K mode the camera records a focal length 1.3-2.7 % longer than each lens's own calibration. That put everything at the seam 3-4° out: doubled lamp posts, stepped overpass lines, and S-bends where the parallax warp tried to absorb an error it was never built for. Each lens now uses its own calibrated focal, and the .LRF of an 8K clip is mapped as the full frame. The lens overlap's match goes from 0.72-0.87 to 0.92-0.96. 6K clips are unchanged.
• The night sky halo is gone. The sky seam fix reached 20° into the sky and measured a noisy black one. At night it now stays on the seam itself. The correction 10-30° from the seam drops by about 90 %, and its flicker from about ±4 codes to under 1.
• Horizon Lock levels on the gravity the camera measured. On car and tripod mounts the horizon could come out rolled a quarter turn, or leaning up to 29°. Airborne clips level as before.
• Clips that dropped frames stay in sync with their sound. Long night recordings can drop frames. OpenOSV decoded the wrong frame there, or none. Every frame now decodes as itself, and the clip plays at its recorded rate with each gap held. A 5.5-minute night clip that ended 3.4 s before its audio now ends with it.
• Street lamps aren't the sun. Sun Ghost Removal cut dark patches into about 3 % of a night drive's frames. A scene the camera metered too dark for the sun is now left exactly as recorded. Daylight footage is unchanged.
• No more seam pops when a moment's parallax measurement is refused. Corrections fade instead of switching, and an exported frame's seam no longer depends on where playback started.

What's new

• Scene Light (Source Settings: Auto, Day, Night). Auto reads the camera's exposure meter and, when that says dark, checks the sky above the horizon. Daylight clips render exactly as before.
• Lens Focal (Source Settings: Auto, Camera, Calibration). Leave it on Auto. It's there in case straight lines double at the seam on a camera we haven't measured.
• A self-check on delivered frames. If a band of a frame ever comes out black or transparent, the importer's log says so, with the size Premiere asked for and the size it got. docs/PREMIERE.md has a new Troubleshooting section.
• osvtool: render --scene-light, --lens-focal and --alpha.

Good to know

• A clip that dropped frames gets slightly longer (the night clip: 16157 to 16328 frames). In a project already cut in 0.4.2, cuts after its first dropped frame shift. Clips that dropped nothing are byte-identical.
• Per-moment seam corrections are now measured on fixed frames, so renders differ slightly from 0.4.2: about 0.3 % of the sample clip's pixels move by more than one 8-bit code.

How to update

Close your editor, unzip the zip for it and double-click Install.cmd.

Downloads

• OpenOSV-0.5.0-premiere-windows-x64.zip: Premiere Pro
• OpenOSV-0.5.0-resolve-windows-x64.zip: DaVinci Resolve (preview)
• OpenOSV-0.5.0-vegas-windows-x64.zip: VEGAS Pro 17.0 (experimental)

ffmpeg-9.0.1-source.tar.gz and ffmpeg-9.0.1-vcpkg-port.zip are the source of the FFmpeg build the zips ship (LGPL-2.1).

SHA-256

a0604c809bf302ee9f0cc3b9a085cc62ba630b01b06857fa643afec596cd23e5  OpenOSV-0.5.0-premiere-windows-x64.zip
01e6615c0fa768a433e74869a25a61ec773a51fe5a4f116ec58ff4330cae32d7  OpenOSV-0.5.0-resolve-windows-x64.zip
f03796f4d111f92d2841e206dc49e0ddcf7fc4356c9e6c6378f51e3d9a1172ea  OpenOSV-0.5.0-vegas-windows-x64.zip

OpenOSV 0.4.2: VEGAS Pro playback, rebuilt for speed

OpenOSV 0.4.2: VEGAS Pro playback, rebuilt for speed

0.4.1 made VEGAS work. 0.4.2 makes it fast. VEGAS was treating every frame you played as a final render, and OpenOSV was stitching a whole 8K sphere to show a 1080p window. Neither happens now.

What's new (VEGAS Pro)

• Playback is playback. VEGAS tells plug-ins its preview quality in a property of its own, and OpenOSV never read it. So every frame you played waited on every analysis and ran the full seam search, parallax and sun ghost fit. Draft and Preview (the Preview window's default) now render as playback. Good and Best, what File > Render As uses, keep the full stitch.
• The view comes straight from the fisheyes. Only the pixels the camera shows get stitched: 2 MP for a 1080p view instead of the 29.5 MP of an 8K sphere, and 472 MB less VRAM. One resampling instead of two, so it's sharper too.
• New: Playback Proxy (OpenOSV Source > Advanced, on by default). At Draft and Preview quality, OpenOSV plays the small .LRF the camera records beside every .OSV, at the same moment. Good, Best and every render stitch the .OSV. Keep the .LRF next to its .OSV, same name.

On the development machine a 1080p frame now takes about 4 ms either way: 4.1 ms from the .LRF at Preview, 3.8 ms from the full .OSV at Best. On older cards the .LRF is what keeps playback smooth: an 8K .OSV is two 3840 x 3840 HEVC streams, which can be more than an older GPU's video decoder pushes in real time.

Good to know

• Preview quality now shows the .LRF, which is softer. To judge the stitch, set the Preview window to Good or Best.
• Still slow? Set the environment variable OSV_PLUGIN_LOG_LEVEL=debug, restart VEGAS, play ten seconds and send %LOCALAPPDATA%\OpenOSV\OpenOSVOfx.log with your report. Every frame now logs where its time went.
• Premiere Pro and DaVinci Resolve are unchanged from 0.4.1.

How to update

Close VEGAS, unzip OpenOSV-0.4.2-vegas-windows-x64.zip and double-click Install.cmd. The first start rescans plug-ins, so it's slower.

Known issues

• VEGAS HDR and ACES projects: the picture doesn't match the project's output colour space yet. Stick to Rec. 709.
• VEGAS Pro 14 to 16 and 2026 are best effort. Only 17.0 has run live.

Downloads

Pick the zip for your editor. Each one has its own Install.cmd.

• OpenOSV-0.4.2-premiere-windows-x64.zip: Premiere Pro
• OpenOSV-0.4.2-resolve-windows-x64.zip: DaVinci Resolve (preview)
• OpenOSV-0.4.2-vegas-windows-x64.zip: VEGAS Pro 17.0 (experimental)

ffmpeg-9.0.1-source.tar.gz and ffmpeg-9.0.1-vcpkg-port.zip are the source of the FFmpeg build the zips ship (LGPL-2.1).

SHA-256

b6fffcfecde69fe6cc3fed8c3125ab82cc33e7fe354544146bac097e501c4394  OpenOSV-0.4.2-premiere-windows-x64.zip
989a3503f0db4262c1d62475ec40abc564067e152cdc8ff79e6a14d36146129a  OpenOSV-0.4.2-resolve-windows-x64.zip
1476ab84c70ccca6161d4c8806d3860144544b0625d7bd497e3c2910857c2432  OpenOSV-0.4.2-vegas-windows-x64.zip