-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Identify all clips in recording session via gpmf (incl udta gpmf) possible? #142
Comments
I just did exactly that (for mp4 I used |
Hey, that's cool! I tried to find something on identifiers that would link clips in your code, but can't see anything? If it's supposed to be UUID, I haven't found that in any of the MP4-files I have (Hero7 + 9). Currently I do the parse in two steps, one general, recursive parse, then I try to build filters + processing on top of that. No idea if that's the most effective way. Did it that way for FIT as well. Unfortunately, I couldn't compile your code on rust 1.55 (issue). |
I didn't find any indicator of multiple clips in the metadata, there is an extra GPMF box ( I was just letting you know that Rust GPMF parser exists, but for merging the same clips I guess we have to rely just on filenames. Unless someone from GoPro has some additional information |
No worries, I'm over interpreting in hope of finding something. Regardless, I love seeing various solutions for parsing binary data, since I'm quite new at it, so thank you! Filenames are "ok" , but not ideal. Most people I work with will probably rename and reorganise files before can take a look at them. The intention is to automate where ever possible. Looking at udta data, "MUID" is logged twice. Once as a "pure" udta field, and again in a udta gpmf stream. The values in the "pure" udta field changes between clips in the same session, but the reinterpreted bytes in a udta gpmf stream (array of UInt32:s) have the same values for clips in the same session. A bit weird, but I'm grasping at straws here and they may be generic identifiers that are actually unrelated to each other. No obvious identifiable sequence at first glance either. Yes, if a GoPro developer has additional information, I'd be very grateful, even if it's just to confirm that the clips contain no identifier that can be used to determine clip sequence (other than e.g. utc timestamps for the gps). How does GoPro's own software determine clip sequence and grouping? |
I have looked, and not found a solution beyond the file naming pattern, which is what GoPro software uses. I thought it existed, but it was only used in the early 360 camera products like Omni and Fusion, were each lens was recorded separately (n-chapters, with m-lens, became too much to do without metadata.) |
Thanks for checking and confirming! I had hopes for the udta data, but no luck. Filename patterns it is. |
Is it possible to somehow automatically identify clips that belong to the same recording session? I'm thinking unique identifiers embedded within the MP4 that link clips. For their legacy camera, Garmin did this by embedding identifiers within the MP4 then logging this identifier in the external FIT-file. I've used that to automatically concatenate clips etc.
If this exists it'd be possible to locate and concatenate both GoPro MP4 and GPMF streams.
Sorry if this is the wrong place to ask, but I can't find a technical forum for the GPMF standard.
I'm trying to write a GPMF parser in Rust from scratch using the documentation in this repo. So far I have successfully used this to automatically extract, concatenate, and parse the mdat DEVC + udta GPMF chunks in the MP4 together with the relative timestamp, derived from the relevant stts, stsz, and stco atoms (the time units in stts seems be plain milliseconds, but perhaps that's just plain luck on my end). A relative timeline is also established for the GPMF stream using these atoms.
The text was updated successfully, but these errors were encountered: