GoPro & Linux

Quelques évolutions...

L'ajout de la cartographie a bien avancé.

Liste des cartes supportées :

Code:

$ ./gpx2video -l
gpx2video v0.0.0
Map list: ./gpx2video
 - 0: None
 - 1: OpenStreetMap I :copyright: OpenStreetMap contributors
 - 4: Maps-For-Free Maps :copyright: Maps-For-Free
 - 5: OpenCycleMap Maps :copyright: thunderforest.com, Data :copyright: osm.org/copyright
 - 6: OpenTopoMap :copyright: OpenTopoMap (CC-BY-SA)
 - 7: Public Transport Maps :copyright: ÖPNVKarte, Data :copyright: OpenStreetMap contributors
 - 8: Google Maps Map provided by Google
 - 9: Google Satellite Map provided by Google
 - 10: Google Hybrid Map provided by Google
 - 11: Virtual Earth Map provided by Microsoft
 - 12: Virtual Earth Satellite Map provided by Microsoft
 - 13: Virtual Earth Hybrid Map provided by Microsoft

Pour générer une vidéo :

Code:

./gpx2video -m GH010321.MP4 -g ACTIVITY.gpx -o output.mp4 --map-source=8 --map-zoom=12 --map-factor 2.0

Après avoir choisi le type de cartographie, on choisit le niveau de zoom des tuiles à télécharger et on peut appliquer un facteur pour les redimensionner.

Ensuite, on peut placer la carte, comme n'importe quelle autre jauge.

gpx2video télécharge toutes les tuiles, construit la carte, dessine la trace de tout le GPX (pas seulement celui correspondant à la vidéo).
gpx2video synchronise automatiquement le GPX avec la vidéo via la date de la prise de vue (ou mieux via les données GPS de la caméra).



Prochaines étapes :
- améliorer l'affichage des jauges (taille, position...)
- affichage de la carte (transparence, couleur du tracé effectué, couleur du tracé restant...)
- optimisation de la carte (charger les tuiles au fur et à mesure)
- optimisation des jauges (mise en cache)

Une première version devrait bientôt pouvoir être diffusée !

bravo pour le boulot !

Hello,

Bien que l'application est loin d'être terminée.

J'ai publié le début de mes travaux :

https://github.com/progweb/gpx2video

Bien sûr, pour le moment ça demande quelques bases afin d'être capable de builder les sources, voir de faire quelques modifications.

Bons tests...

Je viens de tester une build (sur debian stable), pas trop de soucis, ça compile (j'ai relevé 2-3 trucs si ça peut t'intéresser).

Il faut encore que je test ça avec une vrai source gopro (là j'ai bricolé un fichier GPX et une vidéo juste pour tester) mais ça a l'aire prometteur !

Je vais surveiller ce projet de près, bravo !

Oui, bien que le projet en soit à ses tout début, bien sûr je suis intéressé par tes retours et idées.

En théorie, ça devrait fonctionner avec n'importe quel type de vidéo et un GPX...

Mes vidéos sont en 2.7K. Donc pour des résolutions différentes, il faudra re-positionner les gauges.
Et pout cela, il faut éditer le code à la main (ça va venir...).

Pour le GPX, j'ai testé avec un GPX extrait depuis l'interface Garmin Connect.

La synchro entre le GPX et la vidéo est pour l'instant automatique. Et il n'est pour l'instant pas possible
de la faire manuellement (ça va venir également...)

J'aimerai connaître le format de sortie d'une caméra action de chez DJI avec GPS intégré.

J'aimerai aussi avoir des vidéos 360° (quelques secondes) pour tester.

J'ai trouvé une petite vidéo 360 sample faite avec une GoPro Max.

J'arrive bien à lire la vidéo et extraite les données GPS. Par contre je ne sais pas quels outils il faut utiliser pour pouvoir la lire correctement avec ffmpeg, vls ou autre...

La dernière version en ligne permet de juste construire les cartes et traces.



Le rendu des traces est à présent amélioré en passant à des images vectorielles.

Map

Utilise les cartes OSM avec un niveau de zoom à 12, puis applique le facteur 0.5 sur l'image obtenue.

Code:

$ ./gpx2video -s 1 -z 12 -g BRM.GPX -f 0.5 -o brm.png map

Map + trace

Utilise les cartes OSM avec un niveau de zoom à 12, puis applique le facteur 0.5 sur l'image obtenue.
Et enfin, dessine la trace du parcours.

Code:

$ ./gpx2video -s 1 -z 12 -g BRM.GPX -f 0.5 -o brm.png track

Le dessin des traces est ainsi grandement amélioré et ce quelque soit le niveau de zoom.

super ça s'étoffe bien !

Bonjour,
@progweb : cette application est de belle facture, merci
Vu le titre du sujet et étant sous Linux, j'ai une petite question :
- Je dispose de plusieurs caméras qui ne sont pas GoPro. En final avec toutes, j'ai un fichier mp4 classique sans aucune information complémentaire incluse a priori.
- Je dispose également de plusieurs gps et applications (ou pas), mais en final j'ai toujours moyen d'obtenir un fichier gpx contenant au moins ceci :

Code:

<trkpt lat="44.84775" lon="-0.721205">
<ele>10.9</ele>
<time>2017-03-23T13:59:25Z</time></trkpt>

Puis-je utiliser ton application et que puis-je espérer obtenir ?

Je suppose que la carte et l'altitude devraient fonctionner, c'est déjà bien. Peut-être aussi la pente et la vitesse si ton application les calcule au lieu de les récupérer dans les fichiers ?...

Cordialement
Pulsar33

Hello,

Effectivement, gpx2video devrait être capable de fonctionner avec vos données. Si ce n'est pas le cas, je corrigerai.

Via "ffprobe", on peut obtenir plusieurs infos sur le mp4, notamment la date de création (en espérant que la caméra soit à l'heure).

Puis gpx2video, lira les données depuis le GPX fourni. En effet, vitesse, pente... sont calculés.

La cartographie fonctionnera également.

Finalement les seules informations que vous n'aurez pas seront par exemple : cadence, fréquence cardiaque.

Rendu que permet la version actuelle de gpx2video :

@progweb : merci pour ta réponse rapide.
Je vais essayer tout ça mais je sais déjà grâce à ffprobe que les vidéos que je stocke après réencodage ne contiennent pas les champs temporels nécessaires
Il faut que je vois avec les vidéos d'origine des différentes caméras. Je reviens dès que possible ...

Bonne soirée
Pulsar33

Oui, il faut faire attention, dès que l'on ré-encode les vidéos, on perd les pistes data qui contiennent les infos du GPS et des autres capteurs (accéléromètres, gyroscope...)

gpx2video a une commande "extract" pour extraire les données des cette piste :
- au format "raw", équivalent aux commandes "ffmpeg" que l'on trouve dans certaines doc
- au format "text", affiche les infos parsées mais pas interprétées (c'est plus pour les développeurs)
- au format "gpx", génère un GPX avec les infos de la trace... intéressant mais on perd toutes les autres infos

Mais personnellement, je préfère utiliser les GPX issus de mon compteur Garmin, beaucoup plus riches et plus fiables que le GPS de la GoPro.

Bonjour,

A ce stade, je pense qu'aucune de mes caméras ne génère de données utilisables par gpx2video. Je dispose en effet d'un caméscope DV, d'un clone bas de gamme de caméra sportive et d'une caméra 360° qui est sans doute la seule dont je pourrais espérer quelque chose. Cependant, gpx2video n'est pas prévu pour incruster dans une vidéo 360°. Je suis donc conduit quoi qu'il arrive à utiliser des données GPS acquises par ailleurs, soit au format NMEA, soit au format GPX qui peut d'ailleurs être déduit du NMEA (je l'ai déjà fait même si là, je ne me souviens plus comment)

Bref, en final, il me faut synchroniser la vidéo et le GPX. Il y a au moins une solution qui devrait marcher je pense, c'est de rajouter le timecode dans la vidéo qui en est dépourvue, par exemple ainsi :

Code:

ffmpeg -i $1 -map 0 -map -0:d -c copy -timecode $2 TC.$1

Le timecode $2 est au format hh : mm : ss : cc       (sans les espaces, rajoutés ici à cause du forum)

ffprobe m'indique alors par exemple :

Code:

   Metadata:
      handler_name    : TimeCodeHandler
      timecode        : 16:22:57:00

Est-ce qu'avec ça, je peux espérer que ça fonctionne ?
L'autre solution serait que gpx2video intègre une option permettant de positionner une valeur initiale pour chaque valeur qui lui manque.

Cordialement
Pulsar33

PS : j'ai l'impression que ce n'est pas le bon champ :
"gpx2video uses the creation_time field to synchronize your video with your GPX file. [...] If gpx2video finds the 'GoPro MET' stream, it determines the offset time to use."

Bon, j'ai le bon champ maintenant :

Code:

ffmpeg -i $1 -metadata creation_time=$2.0000000+00:00 -c copy TC.$1

Le champ creation_time $2 est au format yyyy-mm-ddThh : mm : ss      (sans les espaces, rajoutés ici à cause du forum)

J'obtiens alors :

Code:

 Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    creation_time   : 2016-09-24T16:22:57.000000Z
    encoder         : Lavf57.83.100
  Duration: 01:13:27.92, start: 0.000000, bitrate: 2487 kb/s
    Stream #0:0(und): Video: mpeg4 (Simple Profile) (mp4v / 0x7634706D), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 2354 kb/s, 25 fps, 25 tbr, 12800 tbn, 25 tbc (default)
    Metadata:
      creation_time   : 2016-09-24T16:22:57.000000Z
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
    Metadata:
      creation_time   : 2016-09-24T16:22:57.000000Z
      handler_name    : SoundHandler

J'ai bon ?
Pulsar33

Bonjour,

En effet, si ta caméra n'a pas de GPS intégré, il faudra fournir un GPX externe. D'ailleurs, si on veut utiliser le GPS intégré de la caméra, il faut au préalable extraire les données GPS de la caméra au format GPX :

Code:

./gpx2video -m VIDEO.MP4 -o trace.gpx -f 0 extract

Ensuite, on fournit ce GPX pour générer sa vidéo. Pour l'instant, je n'offre pas la possibilité de synchroniser manuellement la vidéo & le GPX.

Je ne sais pas à quoi sert le stream "Timecode"... je n'ai pas vraiment l'impression qu'il soit d'ailleurs utilisé.

gpx2video commence par utiliser le champ "creation_time" qui est en heure/date locale. Il transforme cette date locale en heure UTC (en supposant que l'ordinateur sur lequel on travaille à le même fuseau horaire que la caméra Puis il va chercher les données dans le GPX (qui lui est en heure UTC).

Mais souvent la caméra n'est pas forcément à l'heure Et on se retrouve avec un décalage entre les données du GPX et la vidéo !

Du coup, si gpx2video trouve une piste "GoPro MET" (donc la même piste que celle qui pourrait être utilisée pour extraire les données du GPS), il va chercher l'heure GPS en veillant à avoir le "FIX". Si on trouve l'heure, on utilisera cette dernière et non celle du champ "creation_time".

Le champ creation_time à pour format par exemple :

Code:

creation_time   : 2022-01-22T10:55:48.000000Z

(heure locale)

Donc oui, tu as bon

Pulsar33 a écrit:

Je dispose en effet d'un caméscope DV, d'un clone bas de gamme de caméra sportive et d'une caméra 360° qui est sans doute la seule dont je pourrais espérer quelque chose. Cependant, gpx2video n'est pas prévu pour incruster dans une vidéo 360°. Je suis donc conduit quoi qu'il arrive à utiliser des données GPS acquises par ailleurs, soit au format NMEA, soit au format GPX qui peut d'ailleurs être déduit du NMEA (je l'ai déjà fait même si là, je ne me souviens plus comment)

Quelle caméra 360° ? Si une GoPro, c'est possible d'en extraire les données GPS.

Si autre marque, et qui a un GPS, je suis intéressé par le format

Pour l'instant, je n'ai fait que regarder le support des vidéos 360° dans ffmpeg, il devrait être possible de faire des choses. Mais chaque chose en son temps. Le problème avec les vidéos 360°, c'est que chaque caméra a sa façon de les encoder et chacune à sa façon de voir la perspective. Bref, en étant basé sur ffmpeg, j'espère bien pouvoir lire et encoder les vidéos 360° comme le ferait ffmpeg !

Merci pour la confirmation.
Je suis d'accord pour le 360°, c'est sans doute faisable mais c'est un peu plus chaud  pas d'urgence !

Le fait de pouvoir utiliser n'importe quelle vidéo en ajoutant le creation_time et en utilisant un GPX obtenu par ailleurs est de mon point de vue déjà suffisant. Le reste est souplesse et plaisir d'utilisation mais non indispensable.

Ma 360° est une KODAK PIXPRO 4KVR360 rachetée d'occas sur LBC. Je l'utilise sans application, uniquement pour récupérer les fichiers vidéo qu'elle stocke sur la SD. Je n'ai jusqu'à présent jamais cherché à savoir si elle fait plus. C'est justement le fait que je pouvais l'utiliser simplement sous Linux qui me l'a fait choisir, même si au niveau résolution en 360°, c'est un peu juste.

Bonne journée
Pulsar33

PS : rapide coup d'oeil au site KODAK ne montre pas vraiment plus de fonctionnalités (aucun GPS en tout cas)

Bonjour,
Voici le ffprobe d'une vidéo de la 4KVR360. Il y a bien le champ creation_time :

Code:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '100_0001.MP4':
  Metadata:
    major_brand    : mp42
    minor_version  : 1
    compatible_brands: mp42avc1
    creation_time  : 2021-07-26T16:35:51.000000Z
    original_format : JK Imaging Ltd.
    comment        : KODAK PIXPRO 4KVR360
  Duration: 00:00:12.01, start: 0.000000, bitrate: 18369 kb/s
    Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p(pc, smpte170m/smpte170m/bt709), 1920x960 [SAR 1:1 DAR 2:1], 18220 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default)
    Metadata:
      creation_time  : 2021-07-26T16:35:51.000000Z
    Side data:
      spherical: equirectangular (0.000000/0.000000/0.000000)
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 127 kb/s (default)
    Metadata:
      creation_time  : 2021-07-26T16:35:51.000000Z

Mais rien d'autre

Bon dimanche
Pulsar33

Bonsoir,

J'ai suivi les indications du .md et j'obtiens cette erreur :

Code:

[...]
-- Checking for module 'cairo'
--   Found cairo, version 1.15.10
CMake Error at /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find OpenImageIO: Found unsuitable version "1.7.17", but required
  is at least "2.1.12" (found   /usr/lib/libOpenImageIO.so;/usr/lib/libOpenImageIO_Util.so)
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:376 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindOpenImageIO.cmake:148 (find_package_handle_standard_args)
  CMakeLists.txt:74 (FIND_PACKAGE)

Pas content de ma version d'OpenImageIO ? Pourtant j'ai fait l'install de libopenimageio-dev
Cordialement
Pulsar33 (sous Mint 19.3)

Effectivement, elle est trop vieille

Pour le moment, je peux faire en sorte que ça fonctionne avec ta version ; mais je vais utiliser à terme certaine fonctionnalité qu'elle ne sait pas faire !

Je dois avoir un Mint 20.x qui traine sur un disque dur. Je vais essayer avec, voir si ça va mieux.
Mais je n'envisageais pas pour le moment de migrer ma station principale en 20.x
Il y a toujours des impacts et du temps à y passer pour une évolution majeure, je n'ai pas le temps en ce moment.

Cordialement
Pulsar33

Bonjour,

Après migration d'une 20.2 en 20.3 fraîche et ajout des outils nécessaires sur le disque de test, j'ai pu compiler le projet ('à condition d'ajouter openssl.dev => rajouter dans les dépendances)
Malheureusement, il ne trouve pas les coordonnées. Je n'ai pas ramené les messages exacts pour l'instant mais voici quand même quelques infos :

- chaque point du fichier GPX est constitué de (et dans ce format exact, sauts de ligne inclus) :

Code:

<trkpt lat="44.93138333333333" lon="-0.8241816666666666">
<ele>32.1</ele>
<time>2016-09-24T16:54:49Z</time></trkpt>

- la date/heure du premier point est la même que la creation_time de la vidéo (au .000000000 près)

Est-ce qu'il est sensé trouver les coordonnées et les synchroniser avec ces seules infos ?

Bonne journée
Pulsar33

Peux tu mettre en-tête et fin du XML correspondant à ton fichier GPX.
(une seule section trkpt suffit puisque je suppose elles ont toutes le même format)

Oui, voici la forme générale du GPX :

Code:

<?xml version="1.0" encoding="UTF-8"?>
<gpx xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/0" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd" version="1.0" creator="gpx.py -- https://github.com/tkrajina/gpxpy">
<trk>
<trkseg>
[...]
<trkpt lat="44.93138333333333" lon="-0.8241816666666666">
<ele>32.1</ele>
<time>2016-09-24T16:54:49Z</time></trkpt>
[...]
</trkseg></trk></gpx>

Merci pour ton aide
Pulsar33