Three goals for the project:
- Break a list of camera clips and GPS data into trips library. A trip consists of a lists of clips and a series of GPS paths. The camera footage clips either touch each other back-to-back, or there is some small, configurable gap between a series of clips inside a single trip.
- Extract GPS data from camera footage. Since the camera I got is the 70mai pro, this is where I will start from.
- Provide a GUI application able to present the footage and the GPS data.
The src\mgps (movies+GPS) library defines all the types an extractor might use to build a library and hand it over to any application.
The extras\mgps-70mai reads the MP4 files produced by 70mai dash cam and produces a library out of a directory containing said MP4 files.
The apps\html+svg is an example taking a library (provided by the mgps-70mai) and printing out a HTML sheet of all the trips. The "+svg" part of the name comes from embedded <svg> images built from GPS data.
The apps\qt5-player aims at presenting the GPS data over a map and animating a marker in sync with the video.
The apps\uwp-player aims to be more integrated into Windows 10, than any Qt app could.
This app is only planned and scheduled after Qt5 application is ready-ish.
The apps\android-player aims at presenting the clips using a DCIM directory directly, without downloading the clips to the PC first.
This app is only planned and scheduled after Qt5 application is ready-ish.
If you want to compile qt5-player
For external libraries. Currently, the extras-70mai depends on compile time regular expressions by Hana Dusíková and the libmgps (and by extensions — everything else) depends on date by Howard Hinnant.
The CMake config uses few options to let you decide, what do you want to build or not. All of them are OFF by default and you need to set them to ON as needed.
MGPS_BUILD_TOOLS— controls, whether or notapps\html+svgis built.MGPS_BUILD_QT5— turns on theapps\qt5-player. This one also needsQt5_DIRenvironment variable pointing to the Qt5 cmake dir ($QT_HOME/5.$VER/$COMPILER/lib/cmake)MGPS_BUILD_70MAI— turns on theextras\mgps-70mai.
With Conan, the build script would be
mkdir build && cd build
conan install .. --build missing
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release \
-DMGPS_BUILD_70MAI=ON \
-DMGPS_BUILD_QT5=ON \
-DMGPS_BUILD_TOOLS=ON \
..With Conan, setting up debug builds and run tests/collect coverage from them should be easy. Priority is on the libraries (src\mgps, extras\mgps-70mai).
Before 1.0, the version might be 0.$MINOR.$PATCH-$STABILITY+dev.$DATE$TIME for normal builds and 0.$MINOR.$PATCH-$STABILITY+build.$NIGHTLY if built from tags v0.$MINOR.$PATCH/$NIGHTLY.
- STABILITY will be present only, if the CMake variable is not empty.
- PATCH will idealy be updated before each push, MINOR after a new functionality is finished, NIGHTLY through a cron job (checking if anything was pushed between consecutive runs).
- MINOR would only reset the PATCH, but not NIGHTLY. For file names, the meta separator will need to be
-.
Starting with 1.0, the MAJOR will also be present. This means, that before each push an analysis of the change must be done to try and check, if there were any API-breaking updates.
Releases should follow the X.Y.Z short form — there are no stability tag past the rc.#, there should be no metadata needed.
The build meta would require a single point of truth, a Jenkins stage checking the time and/or setting the build number.
Produce a DLL/SO library from the libmgps, with some sensible fallback on JNI/Android.
- Base package with
libmgpsruntime dev/develpackage with headers, lib files on Windows,pkgconfig/archive files on *nixen70maipackage with plugin runtime (for products ofMGPS_BUILD_70MAI)toolspackage for products ofMGPS_BUILD_TOOLSqt5package for theapps\qt5-player, possibly with linux/mac/windeployqt libraries already inuwppackage for theapps\uwp-player- Installers for Qt5/UWP payloads
The APK will have to be signed for sure. There need to be (Jenkins-fueled?) way to sign all the shared libraries, programs, packages, installers?