I am currently in the process of writing a small tool to go directly from native insta360 video files (insv) to upload-ready MP4 files for Mapillary. I think I am on a good path. Could someone verify that nothing obvious is wrong with that track?
I am concerned if I need to do something special to get the heading of the 360 image right. Here it looks right, but I am not sure if this is by accident, if Mapillary calculates this on the optical flow, or if I should provide some metadata in the MP4-file for that. See Screenshot:
Chiming in because I’m quite interested in the X5 and since it’s exciting to see progress with native .insv support.
From my minimal understanding of the Mapillary ingestion process, I believe post processing and SfM take care of everything as long as the frame coordinates are within its tolerance for success. Surely others will chime in with more detail and confirmation, but your successful results suggest as much and seem to support that theory.
Also, for the life of me I can’t find the UI panel featuring the Captured with details to confirm, but I uploaded a GoPro MP4 capture with the Desktop Uploader and used the API to check plausible fields for this value. I see the make and model fields in Mapillary Image API results and would presume the Captured with field maps to this info but haven’t had visual confirmation yet. Checking the exif on my MP4 suggest that Camera Model Name and possibly Color Mode provide the data in question for my upload, but from the looks of it I’d guess they probe the metadata and will use the best possible value based on the realm of various field names. I’d expect supplying make and model info in your MP4 exif data in any commonly named field value would likely resolve the Unspecified value.
Just stumbled across the UI panel that I seemingly hadn’t noticed before and updating for reference and to confirm the source GoPro/Hero 9 values I was seeing in the exif data matches what Mapillary uses
Thank you for searching and providing all the information! I adapted the prototype of the tool and will try with my next videos if the model name is recognised by Mapillary
Hello, I’ve gotten the hang of how it works with the X3 now. I can see certain advantages in manual editing. The most important point is that every camera has problems recording GPS tracks. This is where manual post-processing of the GPX track makes sense. I use the JOSM editor for this, which lets you load GPX tracks into a JOSM layer. JOSM offers powerful editing tools. After editing, the JOSM track can be easily converted back into a GPX track. A second point is that when it comes to optimal quality, I export Insta data as Pro Res 422 rather than MP4. This file format generates larger amounts of data, so Insta recordings have to be divided into segments. The result: optimal image quality is impressive.
Very cool @senden9 - one issue I see is that the first frame in the capture you linked to looks sharp, but the next frames look heavy compressed (for example the grass is quite blurry). I don’t know which settings/compression you’re using, but it would be good to double check.
Thanks for all the feedback! I use ffmpeg partly. The parts that use ffmpeg use -c copy. I assume that the problem is in the conversion from insv into the 2:1 mp4 file using the insta360 SDK. Maybe I can somewhere tweak the settings to have every frame a i-frame, extract still-frames and put them together somehow enable lossless encoding there.
My current flow is roughly:
Use Insta360 SDK to convert the time-lapse insv Video (that has the two separate 180⁰ video streams) into a normal 2:1 MP4 file.
Use ffmpeg to extract the raw h264 stream from the MP4. Using -c copy here.
Construct a new MP4 file with that raw stream. Using the right metadata and FPS here. Again using -c copy here.
I just took frame-by-frame a look at the MP4 file strait from the SDK and can confirm that there are a few havy compressed frames in there.
In fact even the (on PC unprocessed) insv file has that problem when opened with VLC!
Third frame zoomed in:
