[Question] Writing GPMF data on Android

[SmartDeltaRaymon]

Hi,

Please forgive me if I do not use the GitHub Issue system correctly as I have never used features like theses on GitHub.

We are trying to use this gpmf-write library on Android. First we wrote a POC project on Windows that uses this gpmf-writer library on Windows (on X64 CPU) to add fake GPS ("GPS5" and "GPSU") data to an MP4 video file using FFMPEG. We use CMake for our build and have CMake download the library from GitHub and build it as a dependency of our project. Our POC seems to work as expected. We did notice that for some reason the order in which different data is fed to the library using GPMFWriteStreamStore seems to matter but if we got the order correctly the output video could succesfully be read by "exiftool -ee <videoname.mp4>".

Now we have ported this code to Android. It basically does the same thing but then with real GPS data. On Android we have a 64-bit ARM CPU. For some reason we get lots of SIGSEG's and SIGBUS'es. It seems to happen when the GPMFWriteStreamStore call is made to add the "GPSU" data. We only put one sample of five int32_t's in one call at a time. The memory that contains our GPS data is allocated using posix_memalign and is aligned at multiples of sizeof(void*). After the call, the memory is freed using free() as it should be according to the documentation of posix_memalign. We noticed that the SIGSEG's and SIGBUS'es would not happen if we do a memset before supplying the data to the library. So somehow the contents of the data seem to matter (this is not behavior I would expect).

Could you please help us find out what the issue could be here? Could it be an endianness thing? Or a memory alignment thing?
Any help would be greatly appreciated.

Thanks in advance,

Raymon @ SmartDelta

[dnewman-gpsw]

Not too much to go on here. Just a couple of notes:

1. 'GSPU' is typically of data type 'U' for a UTC Date and Time string. This is 16 chars, not 5 int32_t's. This is not likely the issue, as you can write whatever you want.
2. GPSU and GSP5 are depreciated on GoPro cameras, now using GPS9 for higher precision.

Maybe share the code around the GPMFWriteStreamStore call.

[SmartDeltaRaymon]

Hi and thank you for your response.

Please excuse me as I seem to have made a little mistake in my question. I meant GPS5 when I was referring to 5 int32_t's.

We did notice that when we leave out the injection of the GPSU timestamps that everything seems to go well. We also noticed that the frequency with which the calls to GPMFWriteGetPayload are made seems to matter. The problem seems to be some memory management issue we have yet been unable to locate and fix. We also made a small, clean app without our other logic, that just does GPMF payloading and this seems to go well regardless of frequency.

The reason that we use GPS5 is simply that that is what we could find in online examples and we know that it works with the exiftool, which is a requirement for us.