Help trimming GoPro video files, whilst preserving GPS track data (GPMF)?

[victorhooi]

I have a bunch of GoPro videos (captured with a GoPro Hero 11), and I'm having massive issues trying to figure out a way to trim/split the videos, whilst still preserving the GPS (i.e. GPMF track) data.

One of the issues is I don't have an in-depth understanding of the MP4 container spec, and how all the atom (container) and MOOV stuff works - so if somebody can figure out the issue, would love to know.

For context, I originally asked it on r/GoPro here:

• https://www.reddit.com/r/gopro/comments/1nald8w/how_to_splittrim_gopro_videos_but_preserve_gpmf/
• https://www.reddit.com/r/gopro/comments/1o6dcbq/does_anybody_know_what_the_gopro_udta_atom_is/
• https://www.reddit.com/r/gopro/comments/1nsask3/comment/njfh1nh/

and the consensus was you can do it using ffmpeg (to split the videos), then using the udtacopy utility from GoPro to restore back some GoPro metadata to the file. However, this doesn't seem to actually work properly for me - udtacopy seems to mangle the non-GoPro specific metadata in the video somehow? (You can use the site at https://gopro.github.io/labs/control/metadata/ to view the GoPro metadata - it's things like the camera settings, lens settings etc.)

Before running anything, I took a quick snapshot of the metadata on the source video from the camera:

• ffprobe on original source video
• exiftool on original source video
• Bento4 mp4dump on original source video

Here is my ffmpeg command-line - it trims the video from 00:00:10 to 00:11:20, and copies over all the tracks (except the timecode track - apparently something about the GoPro timecode track breaks ffmpeg?):

ffmpeg -i GX010870.MP4 -ss 00:00:10 -t 00:11:20 -c copy -map 0:0 -map 0:1 -map 0:3 output_trimmed.mp4

Before running udtacopy, I checked all of the metadata again:

• ffprobe before udtacopy
• exiftool before udtacopy
• Bento4 mp4dump before udtacopy

And if you run this intermediary video through the GoPro metadata page, nothing shows up.

Then I ran udtacopy:

~/code/labs/docs/control/chapters/src/udtacopy GX010870.MP4 output_trimmed.mp4

If you check the video now on the GoPro metadata page, you can see all of the GoPro fields.

However, udtacopy seems to mangle the other metadata - if I try to view output_trimmed.mp4 with exiftool, or Bento4 mp4dump - all of it is empty?

ffprobe after udtacopy
exiftool after udtacopy
Bento4 mp4dump after udtacopy

(Let me know if I've made a mistake though, and the metadata is there, and I've missed something else?)

I also tried an alternative approach, using Bento4 and some of their CLI tools.

This seems to preserve all the other metadata properly - but then the GoPro data (which I thought was just in a "user data" atom) doesn't get moved over correctly.

This is to dump the udta atom to a file on disk:

mp4extract moov/udta GX010870.MP4 blah.atom

Then I re-insert it

mp4edit --insert moov:blah.atom:1 output_trimmed.mp4 output_trimmed_reinserted.mp4

If I test this file on the GoPro metadata page however, it doesn't show any data at all for camera settings, lens etc.

[videoAI]

gpmf-parser is a small C library and tools (gpmf-parser, gps2gpx, GPMF_extract, etc.)
for extracting and reinserting GoPro GPMF telemetry from MP4/MOV files.

- It can extract GPMF as a binary or convert to GPX/KML so you can verify GPS before/after trimming.
- Use it alongside ffmpeg when ffmpeg's remux drops or misaligns GPMF.

SHORT ANSWER — what to use
- Tools: gpmf-parser (GitHub), GPMF_extract (included), gps2gpx.
- Workflow: extract GPMF -> lossless ffmpeg remux/trim -> re-insert GPMF or mux sidecar GPX if needed.

WHERE TO GET IT
- Repo: https://github.com/gopro/gpmf-parser
- Prebuilt binaries: Releases page in repo (Windows ZIP contains GPMF_Extract.exe and gps2gpx.exe).

QUICK USAGE (Windows, PowerShell)

1. Extract telemetry:

.\GPMF_Extract.exe -i input.mp4 -o telemetry.bin
.\gps2gpx.exe telemetry.bin telemetry.gpx

2. Verify GPX (open telemetry.gpx).

3. Lossless trim with ffmpeg (use concat-safe method to preserve samples):
incremental change 1: use ffmpeg to copy whole file timestamps rather than -ss input

ffmpeg -i input.mp4 -ss 00:01:30 -to 00:03:00 -c copy -avoid_negative_ts make_zero output_trim.mp4

4. If GPMF lost or desynced, re-insert (re-mux) original GPMF track:

incremental change 2: replace metadata track using GPMF_Extract re-mux or use mp4mux tool
simplest: remux original GPMF track into trimmed file with ffmpeg mapping

ffmpeg -i output_trim.mp4 -i input.mp4 -map 0:v -map 0:a? -map 1:3 -c copy output_trim_with_gpmf.mp4

(Adjust map index 1:3 — the GPMF/metadata track index — use ffprobe to confirm.)

HOW TO FIND the correct metadata track index

ffprobe -show_streams -i input.mp4

note the stream index for data/gpmf (codec_name=gpmd or codec_type=data)

If metadata still misaligns, extract telemetry to GPX, trim GPX timestamps to match clip
start (subtract clip start time), then reinsert or use GPX as sidecar for mapping apps.

[ProWo]

I have a bunch of GoPro videos (captured with a GoPro Hero 11), and I'm having massive issues trying to figure out a way to trim/split the videos, whilst still preserving the GPS (i.e. GPMF track) data.

For further help you shold post such a GoPro video sample here...

[videoAI]

Proprietary data tracks list

When exporting, LosslessCut may be unable to process certain proprietary tracks.
For example tmcd, fdsc and gpmd added by GoPro. These can however be losslessly
exported to separate files if you want to keep this data for later.

https://github.com/mifi/lossless-cut/blob/master/issues.md

[victorhooi]

I have a bunch of GoPro videos (captured with a GoPro Hero 11), and I'm having massive issues trying to figure out a way to trim/split the videos, whilst still preserving the GPS (i.e. GPMF track) data.

For further help you shold post such a GoPro video sample here...

@ProWo - You're absolutely right - I think I just blindly assumed the shell output I pasted was enough - sorry about that.

I've uploaded a very quick GoPro clip here (100MB), that has GPS data on it:

https://drive.google.com/file/d/17OQS3uHK4JUc5PpLH6TXY4nXTzlgFZLS/view?usp=sharing

I did confirm this has valid GPS data already with the gpmf-parser demo tool:

victorhooi@ampere-01 ~/c/g/demo (main)> ./gpmfdemo ~/GX011108.MP4
VIDEO FRAMERATE:
  23.976 with 308 frames
PAYLOAD TIME:
  0.000 to 1.001 seconds
SCALED DATA:
  ACCL 9.950m/s, 0.324m/s, -0.480m/s,
  ACCL 9.964m/s, 0.324m/s, -0.520m/s,
  ACCL 9.916m/s, 0.420m/s, -0.556m/s,
  ACCL 9.811m/s, 0.590m/s, -0.499m/s,
  ACCL 9.947m/s, 0.729m/s, -0.355m/s,
  ACCL 10.333m/s, 0.698m/s, -0.293m/s,
  ACCL 10.530m/s, 0.609m/s, -0.288m/s,
  ACCL 10.444m/s, 0.616m/s, -0.216m/s,
  ACCL 10.204m/s, 0.707m/s, -0.228m/s,
  ACCL 10.010m/s, 0.722m/s, -0.259m/s,
  ACCL 9.923m/s, 0.686m/s, -0.353m/s,
  ACCL 9.875m/s, 0.595m/s, -0.472m/s,

3. Lossless trim with ffmpeg (use concat-safe method to preserve samples):
incremental change 1: use ffmpeg to copy whole file timestamps rather than -ss input

@videoAI - I appreciate the tips around ffmpeg options - I saw you added:

-avoid_negative_ts make_zero

Is that generally a good thing to use with GoPro video files? What's a good tool to inspect the timestamps on video files, and see if they have weirdness (e.g. negative values, or starting at weird places?)

I didn't understand this part of your post though:

use concat-safe method to preserve samples

Are you able to help explain what that means though?

Also - to clarify - I'm not having any issues copying the GPMF (GPS/sensor) data track itself, with ffmpeg.

The issue is the udata (userdata) atom - which seems to get lost in the ffmpeg trim/copy operation. This isn't a track, per se (at least I understand it), but a global metadata section in the video file that has a bunch of camera/lens configurations, along with other information.

https://gopro.github.io/labs/control/metadata/

(If you were curious as I was - that webpage doesn't actually upload your whole video - I was worried I had to sit and upload GBs of data...haha. It just uses some JS trickery, and File.slice() to seek to part of the file locally, and extract the header information). It's from here

Then if I try to use the GoPro labs udtacopy tool, to copy it from the original video file over to the new video file - that seems to stomp all over the other metadata in my file. (But of course, this file has the correct GoPro metadata)

I even tried to use mp4extract and mp4edit from the Bento4 suite to manually move the udata atom over - but the GoPro Labs site doesn't pickup any of that - so I assume I'm not copying it over manually correctly.

Is anybody able to figure out what's so special about the udata atom in a GoPro file, and how to copy it over properly, without stomping over all the other metadata fields?

(All the commands I ran should be in the first post).

Thanks,
Victor

[ProWo]

A 3 sec cut from your sample. Check with your parser if there are the relative GPS track data (GPMF).
Mediainfo shows them.

[victorhooi]

A 3 sec cut from your sample. Check with your parser if there are the relative GPS track data (GPMF).
Mediainfo shows them.

Thanks for checking out the clip!

I just tried both your file, and the original 100MB file using the web parser at https://gopro.github.io/labs/control/metadata/

Here is the original file


[Attachment 89532 - Click to enlarge]

Here is your 3 second cut:


[Attachment 89533 - Click to enlarge]

As you can see - the udata atom (or whatever that parser is expecting) seems to be lost somehow, in the cutting process.

You can run the udatacopy tool using the command-line from my first post - however, when I did that, all of the normal other metadata that say exiftool was looking for was gone.

It's a complete mystery to me why.

[ProWo]

As you can see - the udata atom (or whatever that parser is expecting) seems to be lost somehow, in the cutting process.

That could be also a parser issue, not finding the data where they are aspected.
The data itself could be already present.

[videoAI]

@Victor

GoPro-Specific Considerations
GoPro videos can sometimes have complex timestamp structures, you might want to be cautious about:
- Preserving exact frame accuracy
- Handling potential timestamp discontinuities

This command was just a sample ..

ffmpeg -i input.mp4 -ss 00:01:30 -to 00:03:00 -c copy -avoid_negative_ts make_zero output_trim.mp4

`-avoid_negative_ts make_zero`: Adjusts timestamps to start from zero

For inspecting video timestamps, I recommend two tools:

1. FFprobe

ffprobe -v error -show_entries format=start_time,duration -of default=noprint_wrappers=1:nokey=1 input.mp4

2. MediaInfo
mediainfo input.mp4

Regarding "Concat-Safe Method"

The "concat-safe method to preserve samples" refers to a technique ensuring that when you trim or concatenate
video files, you maintain sample-level accuracy without introducing artifacts or timestamp shifts.

For GoPro videos, a more robust trimming approach might be [sample]:

ffmpeg -i input.mp4 -ss 00:01:30 -to 00:03:00 -c copy -map 0 -avoid_negative_ts 1 output_trim.mp4

@videoAI - I appreciate the tips around ffmpeg options - I saw you added:

-avoid_negative_ts make_zero

Is that generally a good thing to use with GoPro video files?
What's a good tool to inspect the timestamps on video files,
and see if they have weirdness (e.g. negative values, or starting at weird places?)

I didn't understand this part of your post though:

use concat-safe method to preserve samples

Are you able to help explain what that means though?
Thanks,
Victor

[victorhooi]

As you can see - the udata atom (or whatever that parser is expecting) seems to be lost somehow, in the cutting process.

That could be also a parser issue, not finding the data where they are aspected.
The data itself could be already present.

Yeah - but I suspect all the other GoPro editing tools that use these fields will probably expect it to the same place - so I will need to figure out a way to get the video file to "comply" with their standard. Also, your guess was quite prescient .

I'm trying to understand the logic at the GoPro Metadata Extraction - Global Settings page (source code). Cheated a bit, and used Zed's AI for some of it...haha.

It seems to make some assumptions about the ordering of the atoms in the MP4 file.

I also used mp4analyser to try to understand the atom hierarchy in the MP4 files. (If anybody has another tool they'd recommend for viewing, or editing atoms in a MP4 file, please let me know!).

I *think* GoPro assumes that the "moov" (metadata) comes after the "mdat" (audio/video/GPS sensor tracks). That's my guess so far.


[Attachment 89552 - Click to enlarge]

However, AFAIK it's perfectly valid for a MP4 file to have the "moov" (metadata) section before the "mdat" (video tracks), right?

In fact, reading online, it seems that's how faststart works?

However, if I want to try re-ordering the atoms in my MP4 file, to see if changing the ordering gets it to work with GoPro's parser - what's the easiest way to do that?

(I think I might be able to do it using Bento4 mp4extract and mp4edit, like I tried before with moov/udta - although I'm not sure if that works with the entire "moov" atom? And that means I have to dump to a file, delete the existing, then re-insert from the file - there's no re-order operation in mp4edit.)

Does anybody know an easier way to experiment with re-ordering atoms in a MP4 container?