gopro / gpmf-parser

Parser for GPMF™ formatted telemetry data used within GoPro® cameras.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

udta MUID as identifier for clips in a recording session?

blipmusic opened this issue · comments

I've asked before regarding identifying clips in the same recording session, and recently bumped into the udta field MUID. Since this is supposed to represent "MediaUniqueID", and seems to have values that are identical for clips in the same session (inclusive array indices 0-18), could this be used to identify clips in the same recording session? The remaining part seems unique for each individual clip.

Would anyone have any hints as to what data types MUID should be interpreted as?

Actually, in the GPMF chunk in the udta atom, MUID is repeated as a GPMF-stream with FourCC MUID and type L/32-bit unsigned (repeats 8, but the final four values are all 0). From what I can see, these four values are identical to the first 16 "raw" udta MUID "field" bytes interpreted as uint32:s. Perhaps this is it, as far as ID:ing clips belonging to the same session goes?

Looking at the samples in this repo, Hero 6 and up (for the Hero series) all have a GPMF stream in the udta atom, whereas the Hero 5 sample only has this as a "regular" MP4 data chunk in the udta atom.

MUID is a 256-bit identifier based on the version 1 UUID from RFC 4122. All chapters with from one capture will share the same MUID. It is annoying the chapter number does not appear in today's metadata, and MUID + chapter_num I would be more useful (limited to Omni and Fusion 360 products.)

@dnewman-gpsw That's good to know, thanks! Yes, a sequence number of sorts would be good to have. Since the GPS will be turned on at all times in our case, I could probably use the first half of the MUID as "session ID", then use GPSU to derive the sequence for the clips automatically.

Though, UUID1 has a time component. Perhaps that could be used? Assuming the cameras' clocks are properly set and that those are somehow used for the UUID time stamping, that is.

@dnewman-gpsw Hmm, it seems GPMF MUID and udta CAME are the same if you truncate the zeroes in GPMF UDTA...? I.e. is MUID more of a device ID? I compared with GoPro Max footage from DC Rainmaker's site (presumably all recorded on the same device), none chaptered, and they all share the same udat CAME and the first half of the values in MUID (udta and GPMF). For Hero 7 Black footage it's the same, but if I'm right it means I can't match clips from the same recording session based on MUID, since clips from a different recording session may have the same GPMF MUID.

Or is Max different to the Hero series in this regard?

Here are the values from three independent (not chaptered) GoPro Max clips from DC Rainmaker:

GS010002.mp4
GPMF MUID uint32: [618974091, 2108933548, 369129341, 998971701, 0, 0, 0, 0]
udta MUID uint32: [618974091, 2108933548, 369129341, 998971701, 245687047, 1157693440, 21853, 0]
udta CAME uint8:  [139, 203, 228, 36, 172, 197, 179, 125, 125, 119, 0, 22, 53, 25, 139, 59]
udta MUID uint8:  [139, 203, 228, 36, 172, 197, 179, 125, 125, 119, 0, 22, 53, 25, 139, 59, 7, 227, 164, 14, 0, 0, 1, 69, 93, 85, 0, 0, 0, 0, 0, 0]

GS010010.mp4
GPMF MUID uint32: [618974091, 2108933548, 369129341, 998971701, 0, 0, 0, 0]
udta MUID uint32: [618974091, 2108933548, 369129341, 998971701, 245687047, 2886533120, 50305, 0]
udta CAME uint8:  [139, 203, 228, 36, 172, 197, 179, 125, 125, 119, 0, 22, 53, 25, 139, 59]
udta MUID uint8:  [139, 203, 228, 36, 172, 197, 179, 125, 125, 119, 0, 22, 53, 25, 139, 59, 7, 227, 164, 14, 0, 0, 13, 172, 129, 196, 0, 0, 0, 0, 0, 0]

GS010018.mp4
GPMF MUID uint32: [618974091, 2108933548, 369129341, 998971701, 0, 0, 0, 0]
udta MUID uint32: [618974091, 2108933548, 369129341, 998971701, 1269097223, 3071083520, 52902, 0]
udta CAME uint8:  [139, 203, 228, 36, 172, 197, 179, 125, 125, 119, 0, 22, 53, 25, 139, 59]
udta MUID uint8:  [139, 203, 228, 36, 172, 197, 179, 125, 125, 119, 0, 22, 53, 25, 139, 59, 7, 227, 164, 75, 0, 4, 13, 183, 166, 206, 0, 0, 0, 0, 0, 0]

Three chaptered clips (same recording session) from a Hero 7 Black:

GH010026.MP4
GPMF MUID uint32: [1719790048, 1861961699, 853951305, 3208863477, 0, 0, 0, 0]
udta MUID uint32: [1719790048, 1861961699, 853951305, 3208863477, 3433161223, 1829306624, 57022, 0]
udta CAME uint8:  [224, 233, 129, 102, 227, 71, 251, 110, 73, 67, 230, 50, 245, 94, 67, 191]
udta MUID uint8:  [224, 233, 129, 102, 227, 71, 251, 110, 73, 67, 230, 50, 245, 94, 67, 191, 7, 226, 161, 204, 0, 1, 9, 109, 190, 222, 0, 0, 0, 0, 0, 0]

GH020026.MP4
GPMF MUID uint32: [1719790048, 1861961699, 853951305, 3208863477, 0, 0, 0, 0]
udta MUID uint32: [1719790048, 1861961699, 853951305, 3208863477, 3433161223, 3624734976, 490, 0]
udta CAME uint8:  [224, 233, 129, 102, 227, 71, 251, 110, 73, 67, 230, 50, 245, 94, 67, 191]
udta MUID uint8:  [224, 233, 129, 102, 227, 71, 251, 110, 73, 67, 230, 50, 245, 94, 67, 191, 7, 226, 161, 204, 0, 17, 13, 216, 234, 1, 0, 0, 0, 0, 0, 0]

GH030026.MP4
GPMF MUID uint32: [1719790048, 1861961699, 853951305, 3208863477, 0, 0, 0, 0]
udta MUID uint32: [1719790048, 1861961699, 853951305, 3208863477, 3449938439, 1107501568, 36111, 0]
udta CAME uint8:  [224, 233, 129, 102, 227, 71, 251, 110, 73, 67, 230, 50, 245, 94, 67, 191]
udta MUID uint8:  [224, 233, 129, 102, 227, 71, 251, 110, 73, 67, 230, 50, 245, 94, 67, 191, 7, 226, 161, 205, 0, 34, 3, 66, 15, 141, 0, 0, 0, 0, 0, 0]

Seems I'm back to square one and will have to identify clips in the same recording session via filename. :( I'll try to get more Hero test footage.

@dnewman-gpsw, we just received a Hero11 Black and I realise I have follow up questions.

The main question is: is it possible to let us know how MUID and GUMI are used between models?

I realise this is outside of GPMF (first half of udta MUID is available as part of the GPMF section in the udta for Hero6 and up, but GUMI only exists as a normal udta field from what I can see).

For Hero11 it seems all clips that belong to the same recording session will get the same MUID - no sequential info, but I can at least identify recording sessions this way. However, this is not true for e.g. Hero7 (only the first half matches but that is more of a unique device ID?). However, GUMI instead seems to be the same between clips for the same recording session for the Hero7.

Other than a Hero11, Hero7, and a Hero5, I don't have access to much in terms of cameras and test footage (which in this case need to be multi-clip recordings). I'm trying to automate most of the process (matching clips, merging GPMF etc) for researchers who use GoPros in the field with a tool I'm building (https://gitlab.com/rwaai/geoelan - though GoPro file/clip matching is broken/insufficient for this version, but geoelan i -g GOPROVIDEO.MP4 --verbose will print all GPMF data in "raw" form for that file for example).

Do you have any insight here, or information you are able to share? Especially if any of the above is true for models Hero6, and Hero8 - 10 as well. E.g. do Hero5-10 use the same GUMI for clips in the same session?

Sorry I don't have this info per camera model.

That's ok, thank anyway. But if you happen to come across something in the future I think it would help others as well. There are a lot of GoPros out there, that are used in many different ways. :)

I'll edit my code if I find more multi-clip recordings from previous models. So far I'm bundling clips from Hero11 recoding sessions on MUID and others on GUMI. I want/need to keep track of the low-resolution clips as well when available, so I match LRV with MP4 by comparing a hash of the full GPMF stream in raw form (just an array of uint8, perhaps just comparing the first DEVC stream will do), then order clips on GPS time stamps. Works so far and is quick enough, but I'll add ordering on file name as a fall back (often the researchers who use the cameras want to rename files to something a little more descriptive).