Is this possible to manipulate/add/change metadata tracks?

[Phil Harvey]

I searched the code for "wrong sample size", but can't find where that warning is issued.  Is that the exact warning string?

- Phil

[Cheloute]

Well look (these are very small files)
Original File (Pro 1)
Modified File (with Errror Sample Size)

The exact message is :

[Phil Harvey]

OK.  "Sample size error".

You should look at the format of the stsz box.  Just looking at my code and without reading the specification, it seems that the sample size for fixed-sized samples should be at offset 4 in this box, and the number of samples should be at offset 8.

- Phil

[Cheloute]

OK.  "Sample size error".

You should look at the format of the stsz box.  Just looking at my code and without reading the specification, it seems that the sample size for fixed-sized samples should be at offset 4 in this box, and the number of samples should be at offset 8.

- Phil

You're right. Size is correctly placed at offset 4, but number of samples is missing. It seems that the library I'm using is not allowing setting this param, I'll need to extend it. Well, I made a try setting directly the right number at the right offset and it started to detect samples. I've now other errors, but because everything has been moved by my manual change.

Thanks for this, I keep on doing my test... 

[Cheloute]

Hi,

I'm still facing some difficulties to identify all the entries, I can't understand how this is working with exiftool.

My STSC box looks like this :


Which can be decoded to this :


There's no "first chunk=3" nor "first chunk=5" entry.

Obviously my stco box defines a "chunk 3 and chunk 5", and exiftool is able to locate the samples located at the offset specified in chunk 3 and chunk 5 (and how many, as there are more than one sample), with the correct size, etc etc.

So... where's the magic? How can I locate these not documented samples if they're not written in the sample-to-chunk table? (And why aren't they written there?).
They are not specific custom samples but just other camm2, camm3 and camm6 records not documented into stsc but found by exiftool... And I need them to correctly use my stsz table to affect the correct sizes to the correct samples

Thanks

[Phil Harvey]

It looks to me as if the missing chunks use the same sampling parameters as the chunk before them.

- Phil

[Cheloute]

You're right, I just checked this and... it works!
Thanks for this, that's what i was not able to understand reading the specs.

Great!

[Cheloute]

Hi,

I finally managed to change my source MP4 to separate Gyro data from GPS data correctly.

I saw several interesting things, btw. Before stitching, all the gyro/gps metadata of Pro2 are located into the sixth lens low-res mp4, and don't respect the google CAMM specification : There are 2 different CAMM Track boxes, and only camm1 (exposure), camm2 (angular speed) and camm6 (gps) are generated.

Camm6 samples are generated as Google specifications defined them: size of 60 bytes, all fields are present.
Camm2 samples are composed by a "real" camm2 sample (angular speed) and a concatenated camm3 sample (acceleration), The first 16 reserved bytes are not 0 as they should be, but another random fixed value.
Camm1 samples are composed by 6 camm1 samples, one per lens. In case we choose an automatic or fixed exposure, we'll always have the same value for each lens, and the rolling shutter skew time will always be 0.

Nevertheless when we stitch the 6 lenses using the Insta360 tool, everything is converted into a unique CAMM track box (that's to say, mixing camm1, camm2, camm3 and camm6 samples). Camm2 samples size is now 16 (as it should be) and new camm3 samples start with 00 00, as they should be. But the camm1 samples are still the same: that's to say a 72 bytes long sample containing the exposure for the six lenses, and replacing the first reserved bytes of each sample by a random value, except the very first one (to allow the sample to be detected as a sample).
For instance :

Code Select Expand

00 00 01 00 aa 72 ca 01 00 00 00 00
7f 00 01 00 aa 72 ca 01 00 00 00 00
d0 1a 01 00 aa 72 ca 01 00 00 00 00
7e 00 01 00 aa 72 ca 01 00 00 00 00
58 b3 01 00 aa 72 ca 01 00 00 00 00
00 00 01 00 aa 72 ca 01 00 00 00 00Each time a camm1 will appear in the video from where I extracted this sample, it will be exactly the same.

Google Street View seems to allow this kind of longer camm1 samples, as these videos are totally accepted and certified by the Google service. It may be interesting to incorporate this to exiftool...

Going back to my initial goal, I missed the exposure data which seems to be required while Insta Pro 1 never writes it.
Analyzing Pro2 footages, I can see exposure data are always the same. We can set it at he beginning, and it is maintained until the end. From the metadata point of view, that means the camm1 metadata is always the same. So what I need now is to inject a fake exposure data to my Pro 1 footage to have a complete coherent generated mp4 that match Pro 2 specification.

Google says "This metadata is per video frame. The presentation time (PTS) of this metadata should be the start of the exposure of the first-used scanline in a video frame."[...]"The PTS of the corresponding frame should be within pts_of_this_metadata and pts_of_this_metadata + pixel_exposure_time_ns + rolling_shutter_skew_time_ns."

But, how can I see the different PTS ? Is there anything with exiftool to see where there are to allow me to "add" these missing samples? (I know I'll next have to modify all the offsets accordingly... But I need to identify where are the PTS flags to determine where I can write my fake samples...)

Thanks

[StarGeek]

But, how can I see the different PTS ? Is there anything with exiftool to see where there are to allow me to "add" these missing samples?

If -ee -v3 doesn't show the data, then your answer will have to wait until Phil gets back sometime next week.

[Phil Harvey]

I don't have a lot of time to think about this right now, but I'm guessing that the "PTS" is what ExifTool extracts as SampleTime?

ExifTool 12.51 or later should extract information from the longer camm1 records.  If not send me a sample and I'll take a look.

- Phil