Hi,
I'm looking for a way to add a timecode to insta360 insv files but have difficulties to get a common reference.
Premiere Pro is showing in its "Media Start" column the timecode set into the mdat box if any, or 00:00:00:00 if nothing is set. In case of insv files, there's no timecode into the mdat box, something I'm trying to fix.
I'm able to write a timecode using ffmpeg, and able to reinject the insta metadata extracting them from the original file and appending them to the end of the new timecoded file, this part is ok, files keep on working as expected.
I also managed to find a way to decode the insta360 metadata and get the first frame timestamp from here, but it seems to take the camera starts as reference, nothing related to any universal clock. The developer working on gyroflow (who helped me to decode the insta metadata) suggested to use GPS data to get a real time reference: GPS data contains a real timestamp, and the first GPS sample matches the GPS start timestamp present into insta metadata, which is related to the first frame timestamp. So... if the first GPS sample is generated at 15:00:00, and the GPS start timestamp is 1000 (ms) and the first frame timestamp is 850000 (ns), first frame timestamp would be 14:59:59.150.
It could work, but only if the insv footage contains GPS data.
As it doesn't seem to have any other real time references into insta360 metadata, the only other way to find such a reference would be trying to exploit the creation date of the video track. But this creation date matches any other track creation date (and modification date), so I'm not sure if I can use this as a "reference" of anything. For instance, I can see that in a GoPro footage, the timecode is before the creation date.. Someone knows if there is any kind of relation between the two? Or if there's another way to find the first frame "real" timestamp?
Thanks
If you own the camera then you are the best one to answer these questions. I suggest shooting footage of the most accurate digital clock you can find, then compare the images of this clock in the video with the metadata and GPS stored by the camera. It probably uses the internal camera clock for the metadata, so be sure to set this as accurately as possible.
And be sure to post back with your findings because I'm sure other people will be interested.
- Phil
Actually, my question was more generic... I just wanted to know if there was some kind of relation between the trak atom creation date and the "real" first frame timestamp according to the MP4 specifications. I read them and couldn't find anything, but I may miss something.
On the other hand, your suggestion is a very good one. I effectively can record a millisecond clock, and compare what's the difference between the track creation date and the time present on the first frame. And do that several times to see if the difference is constant or not. Or stuff like that. Thanks for this!
By the way, do you know the open source project telemetry-parser? https://github.com/AdrianEddy/telemetry-parser/tree/master/src/insta360
The guy behind this project found a protobuf message definition to decode the insta360 metadata. It's not up to date with X3 and Ace/Pro, but is giving a lot of details about how to decode the metadata. Some of them are very interesting, especially how the lens offsets work, or how the gyro/exposure/gps data are synced with the video stream. You may be interested in incorporate some of those metadata to the -ee option of exiftool.
Quote from: Cheloute on February 16, 2024, 04:45:17 AMI just wanted to know if there was some kind of relation between the trak atom creation date and the "real" first frame timestamp according to the MP4 specifications.
Regardless of the specification, different cameras treat this differently. I have seen times which appear to be at the start of the video for some cameras, and the end of the video for others, but I haven't done any accurate testing.
QuoteBy the way, do you know the open source project telemetry-parser? https://github.com/AdrianEddy/telemetry-parser/tree/master/src/insta360
No. This looks interesting, but the code is cryptic (the ExtraMetadata::decode function seems to contain all of the decoding code, but I can't find the definition of this function anywhere. Also, basically a complete lack of comments in the code.)
- Phil
Quote from: Phil Harvey on February 16, 2024, 09:21:22 AMRegardless of the specification, different cameras treat this differently. I have seen times which appear to be at the start of the video for some cameras, and the end of the video for others, but I haven't done any accurate testing.
Ok, well, it seems your idea has been the better way I could use to achieve this. I noticed on my One R it seems to have exactly 10s between the creation date and the time recorded on the first frame. Creation date doesn't give me a millisecond precision, but event if some correction is needed, it won't be superior to the number of frames during 1sec, that's acceptable. To achieve that, I just run a ffmpeg -i input.insv -map_metadata 0 -c copy -timecode <creationDate + 10s> output.mp4, change mp4 for insv, and append the insta360 metadata at the end. insv is still working correctly and the timecode is now present and recognized by Premiere.
QuoteNo. This looks interesting, but the code is cryptic (the ExtraMetadata::decode function seems to contain all of the decoding code, but I can't find the definition of this function anywhere. Also, basically a complete lack of comments in the code.)
It costed me a lot to understand the code, as I'm not familiar with Rust neither. But that's normal you can't find the code for the decode function. Those metadata are serialized by protobuf. The decode function will be part of the Rust core or some libraries used by the developer. What the ExtraMetadata file is, is the protobuf message implementation used by the decoder to decode the metadata. Also take care with the int/long values read, as they can be varint instead of regular int (due to protobuf).
As I didn't want to use external libraries in my development, I started to identify some "key byte" to recognize the fields of interest (for my purpose). Here is a "mappack-like" of those fields: . Remember it's not exhaustive (i didn't need it to be complete), but I think you'll understand how to read the missing part if you're interested in: https://drive.google.com/drive/folders/135QPaTDl2JM31hDTnSoJ8KJ1E_-9xdUR?usp=sharing
Thanks. I need to find some time to look at this in more detail.
A question: Decoding the structure requires previous knowledge about the data format/size for each different tag? So to decode this I would have to abort at any unknown tag? I hate formats like this -- no forward compatibility.
- Phil