For privacy reasons and such (videos of parking the car are not interesting on Mapillary) I want to cut out beginnings and endings of Dashcam videos.
I have a Vantrue E1 Pro and I tried using FFMpeg, but this removes the GPS stream.
Is there an easy way to trim such videos? Would be nice to have this included in the desktop uploader and/or mapillary tools.
The mobile app features “privacy locations” where it does not record - would be cool if such a triming could be GPS aware and just ignore certain zones from the video.
It should be easy to do for images (you can already select and delete images before upload with the new editing tools) but not for videos as I don’t think there’s a tool to do that without losing GPS data.
Hi @alexaddismap - this is a good feature request and something we have on our backlog, however I’m not certain we’ll be able to get to it in the near future. For now you can trim video and gpx either manually or by using a tool like KVRouite (GoPro Hero 12 external GPS track workflow)
Thanks, the tool sounds cool but I was not able to run it properly. Showed some strange window artifacts on Wayland.
Also I am looking for an automated workflow:
Define geofences which should be excluded
Cut the video accordingly after extracting the GPS positiongs, and preserve the GPS data (I was not able to to this with ffmpeg, stream always was lost)
Right, I agree with your automated workflow (the way I’m imaging it is you’ll set the geofence, and we’ll automatically discard anything that is within that geofence, so you won’t have to cut the video on your end at all). However that functionality only exists for the the mobile apps for now (on our backlog for desktop uploader/mapillary_tools uploads)
Try to specify both streams at the same time explicitly. The video stream with -map 0:0 and the metadata stream with -map 0:x, where x is the metadata stream number. Keep in mind that the order of -map options passed is relevant. You should be able to lookup the metadata stream number ahead of time with ffprobe.
However, there is a chance that ffmpeg does not know how to demux and thus also cut an arbitrary (meta)data stream. In this case exporting the entire original metadata stream separately and then importing it also entirely uncut into the cut video file may be an option. The backend can then possibly handle that overlong GPS metadata stream like an overlong GPX track and everything should fall into place. Though, I am guessing that for this to work completely flawlessly the cut video is also going to need a correctly cut (or adjusted) timecode stream and/or correctly adjusted creation_time metadata tag timestamp value because the backend always needs a reference timestamp for the start of the video. If I am not mistaken, ffmpeg should be able to automatically adjust timecode streams, so long as you specify the timecode stream to be processed explicitly with an appropriate -map option.
Note that -map_metadata applies to the container video file’s metadata only, not a metadata stream.
Are you sure this is the complete read out? Because I can hardly imagine that the h264 stream itself would have GPS data interwoven. I guess that in your camera’s case the GPS metadata is written as part of the MOV/MP4 container in a proprietary atom. ffmpeg drops atoms it is not aware of from the original file when it copies streams because it de facto creates a new MOV/MP4 container on every write. Unfortunately, the -map_metadata option applies to standard atoms and the mdta atom only.
Perhaps all that mapillary_tools (or rather exiftool in the background) needs is just the moov atom to be at the beginning of the file? You can pass the -movflags +faststart option to move the moov atom to the beginning of the file. Usually, the GPS and other (proprietary) metadata atoms are members of the moov atom. See also other -movflags option flags. Potentially, omit_tfhd_offset or default_base_moof may help. Generally speaking, whenever a MOV/MP4 video stream is cut it requires the creation of new (atom) fragments, which may or may not be referenced by the proprietary GPS metadata. Fragments may get resized, reorganized, or reordered, so that the original GPS metadata may become useless at this point.
Alternatively, you can try to pass -err_detect ignore_err to potentially preserve all original atoms, although I doubt that this option is going to do just that.
Your safest bet is probably going to be to extract the proprietary GPS metadata with exiftool (because it can read MOV atoms selectively) and then convert it to a standard GPX file, which you can then pass to mapillary_tools or the DU together with the cut video file.
It all comes down to the fact that GPS metadata has not been standardized for MP4 containers. Hence, cutting and processing such video files is always going to be tricky. The easiest and probably sanest solution to this is GoPro’s approach with a time indexed dedicated stream because then it is obvious that one can cut or splice it anywhere, just like a video stream.
Are you sure this is the complete read out? Because I can hardly imagine that the h264 stream itself would have GPS data interwoven. I guess that in your camera’s case the GPS metadata is written as part of the MOV/MP4 container in a proprietary atom. 
Hence, cutting and processing such video files is always going to be tricky. The easiest and probably sanest solution to this is GoPro’s approach with a time indexed dedicated stream because then it is obvious that one can cut or splice it anywhere, just like a video stream.