GoPro & Linux

Je confirme que la version GPX skip point if same time du 7 mai fonctionnait bien avec les vidéos 25 hz et mal avec les vidéos 30 hz
A priori, tu as corrigé ça depuis. Cette correction est donc à conserver.
En revanche, le ré-échantillonnage et le filtrage sont moins bons avec toutes les versions qui suivent GPX skip point if same time du 7 mai

Bon dimanche
Pulsar33

Ce que tu me dis me rassures

Effectivement j'ai travaillé sur le problème des vidéos 25Hz / 30Hz... Cette régression est arrivée quand j'ai travaillé sur les vidéos HyperLapse.

Et effectivement la télémétrie est moins bonne, puisqu'il n'y a plus de traitement... Et ce qui est actuellement fait ne me satisfait pas...

Mais je suis enfin sur quelque chose qui me convient. Me reste à finir d'intégrer tout cela.

Tout d'abord, je dois pouvoir traiter des GPX qui proviennent d'activités à vélo, mais aussi moto/voiture, marche, course, aviron, avion... etc.

Bref, le process que je suis à présent :

1°/ Je filtre les points incohérents via la méthode "Iglewicz and Hoaglin"

2°/ Je calcule les données de télémétrie

3°/ J'applique un filtre moyenneur glissé sur le temps

4°/ Je corrige les points que j'ai virés à l'étape (1)

5°/ Interpolation des données pour affichage

Je traite également toutes les problématiques de début et fin du GPX ainsi que les retards dus au filtrage.

Voici ce que j'obtiens sur ton gpx, pour la vitesse :



pour la pente :



Tu noteras qu'il reste à règler le problème de l'altitude qui varie à l'arrêt.

Dans ton cas, filtrer les données améliorent la courbe de vitesse (et autre), mais les données ne sont pas si mauvaises.

Concernant ma descente à la planche des Belles Filles, j'ai enfin une courbe de vitesse cohérente :



On voit bien tous les points incohérents (bleus) qui ont été supprimés sur la courbe rouge ; puis en orange, les données sont lissées.

Me reste à terminer la détection des pauses (afin d'afficher une vitesse nulle)

Note: pour chaque courbe
- bleu : données brutes issues du GPX (je calcule les données pour chaque point)
- filter : données calculées une fois les points incohérents filtrés
- smooth : données calculées une fois le filtre moyenneur appliqué

Ok
Ben je patiente alors
Bon courage
Pulsar33

Bonjour,

En attendant, j'ai voulu faire une essai avec une vidéo générée par mon smartphone et l’enregistrement GPS par l'application GPS Logger
Il y a visiblement incompatibilité au niveau des dates / heures des deux applications
Du coup j'ai installé exiftool pour voir et modifier les champs mais je ne sais pas lequel est important pour toi :

Code:

File Modification Date/Time     : 2024:11:04 14:18:35+01:00
File Access Date/Time           : 2024:11:04 16:13:50+01:00
File Inode Change Date/Time     : 2024:11:04 16:11:41+01:00
Create Date                     : 2024:11:04 13:18:35
Modify Date                     : 2024:11:04 13:18:35
Track Create Date               : 2024:11:04 13:18:35
Track Modify Date               : 2024:11:04 13:18:35
Media Create Date               : 2024:11:04 13:18:35
Media Modify Date               : 2024:11:04 13:18:35

Je vais essayer Create Date mais s'il y en a d'autres à changer, dis-le moi stp

Bonne journée
Pulsar33

Bon, qui peut le plus peut le moins. J'ai trouvé exiftool -P -*Date= nom_du_fichier (attention à l'espace après le =) pour obtenir ceci facilement :

Code:

File Modification Date/Time     : 2024:11:04 14:18:35+01:00
File Access Date/Time           : 2024:11:05 09:43:12+01:00
File Inode Change Date/Time     : 2024:11:05 09:43:06+01:00
Create Date                     : 0000:00:00 00:00:00
Modify Date                     : 0000:00:00 00:00:00
Track Create Date               : 0000:00:00 00:00:00
Track Modify Date               : 0000:00:00 00:00:00
Media Create Date               : 0000:00:00 00:00:00
Media Modify Date               : 0000:00:00 00:00:00

Et ça fonctionne. Le résultat se cale sur le GPX.

Après j'ai (re)découvert l'option --start-time de gpx2video (il manque la description du champ time dans le help pour cette option)
J'ai tenté --start-time 2024-11-04T13:16:40Z qui est l'heure du premier trkpt avec la vidéo d'origine non modifiée par exiftool
Et ça ne fonctionne pas : l'heure reste figée à 13:16:40 (donc c'est bien pris en compte) et les autres valeurs restent à zéro
Encore un sac de nœuds sur les heures  Comme j'aurais préféré voir 14:16:40 j'ai tenté --start-time 2024-11-04T14:16:40Z
Et là ça fonctionne. Il semble que le Z soit ignoré dans cette option.
Ultime vérification : 2024-11-04T14:16:40 et 2024-11-04T14:16:40Z donnent le même résultat.

Mais au moins, pas besoin de charcuter le fichier vidéo avec exiftool, ce n'est pas plus mal

@+ Puls

Effectivement j'ai calqué l'option start-time sur le champ creation_time de la gopro.

Et la gopro comme beaucoup d'autres caméras indiquent l'heure que l'utilisateur a configurée avec un format UTC, alors que c'est simplement l'heure configurée par l'utilisateur (donc heure locale).

Cela s'explique parce que la caméra n'a pas connaissance du fuseau horaire.

Bonjour,

Pour cette utilisation, il s'agit de l'outil le plus répandu à ce jour : le smartphone, qui enregistre simultanément la vidéo d'une part et le GPX d'autre part
C'est dommage qu'ils ne soient pas d'accord sur le format de la date et de l'heure mais c'est ainsi
Il faut que ton champ start-time qui permet de s'affranchir de cette incohérence soit simple d'utilisation et pour cela, il suffit qu'il soit conforme à l'ISO 8601
Je me demande d'ailleurs si je ne vais pas systématiser ce mode d'enregistrement pour mes sorties à vélo, au lieu d'avoir deux appareils dédiés en plus

Bonne journée
Pulsar33

Je pense que je vais corriger cela, en respectant le format. Et seulement quand je détecterai une vidéo gopro je by-passerai l’info utc.

Peut-être une mise à jour ce soir, pour tester.

Voilà une première ébauche en ligne...

Attention, plusieurs changements :

1°/ J'ai simplifié l'histoire de la gestion de la date de début de la vidéo.
a) si le champ "creation_time" est renseigné, je le parse - aujourd'hui seule la gopro renseigne ce champ
b) je parse la piste gpmd... si je peux obtenir la date de début, j'utilise ce champ et non plus (a) - idem spécifique gopro
c) si l'utilisateur utilise l'option "--start-time=YYYY-MM-DD HH:MM:SS" (date au format local), j'utilise en priorité cette date.

2°/ concernant les données de télémétrie
a) si --telemetry-offset est défini, j'applique un offset (en ms) sur tous les timestamp du fichier.
b) si --telemetry-begin / --telemetry-end sont définis, je supprime les données de télémétrie en dehors du range
c) si --telemetry-from / --telemetry-to sont définis, je calcule la moyenne, la distance... sur ce range. (la vitesse instantanée... reste calculée)

3°/ synchro video / données de télémétrie
j'avance dans la vidéo en commençant par la date obtenue au (1), puis pour chaque frame (moyennant l'option --telemetry-method & --telemetry-rate) je cherche les données de télémétrie
--telemetry-method pour choisir la méthode d'interpolation
--telemetry-rate permet de définir le taux de rafraîchissement des widgets.

4°/ filtrage / lissage des données de télémétrie
a) --telemetry-check = true / false : supprime les points invalides (exemple: souvent j'ai 2 points qui se suivent avec strictement les mêmes lat / lat / elevation)
b) --telemetry-filter = 0 / 1 (aujourd'hui un seul filtre, détermine les points incorrects)
c) --telemetry-smooth = number (lisse sur +/- number - valeur usuelle "2", donc pour une fenêtre de lissage de 5 points)

Ce qui reste à faire :
A/ Améliorer le calcul de la pente - il n'est pas bon si on déplace à petite vitesse. (en cours)
B/ les options --start-time / --telemetry-from / --telemetry-to / --telemetry-begin / --telemetry-end acceptent aujourd'hui seulement le format "YYYY-MM-DD HH:MM:SS" (et les interprète au format local). Ca doit supporter l'indication du fuseau horaire et d'autres formats iso.


Note:
Toutes les tests sur les données de télémétrie peuvent être fait avec gpxtools

Code:

gpxtools -i input.(csv|gpx] -o output.(csv|gpx)

La commande "convert" permet seulement de supprimer les données (begin / end)
La commande "compute" permet de modifier le fichier.
Si l'option "-o" n'est pas indiquée, les données sont écrites sur la console.

Bonsoir,

Je regarde ça demain

C'est quoi le champ creation_time ?
Voir plus haut les différents champs de date et heure présents dans les données exif et leurs noms tels qu'affichés par exiftool
Les vidéos créés par mon smartphone remplissent tous ces champs, dont Create Date : 2024:11:04 13:18:35 qui est l'heure GMT même si ce n'est pas indiqué (manque le Z)

Je ne le sens pas cette affaire
Pulsar33

Code:

❯ ffprobe GH022440.MP4
ffprobe version 7.1-3 Copyright (c) 2007-2024 the FFmpeg developers
  built with gcc 14 (Debian 14.2.0-7)
[...]
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x556a54fce540] All samples in data stream index:id [4:5] have zero duration, stream set to be discarded by default. Override using AVStream->discard or -discard for ffmpeg command.
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'GH022440.MP4':
  Metadata:
    major_brand    : mp41
    minor_version  : 538120216
    compatible_brands: mp41
    creation_time  : 2023-08-07T12:49:28.000000Z
    location        : +47.7727+006.7750/
    location-eng    : +47.7727+006.7750/
    firmware        : HD9.01.01.72.00
  Duration: 00:02:21.62, start: 0.000000, bitrate: 100248 kb/s
  Stream #0:0[0x1](eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709, progressive), 2704x1520 [SAR 1:1 DAR 169:95], 100012 kb/s, 50 fps, 50 tbr, 90k tbn (default)
      Metadata:
        creation_time  : 2023-08-07T12:49:28.000000Z
        handler_name    : GoPro AVC 
        vendor_id      : [0][0][0][0]
        encoder        : GoPro AVC encoder
        timecode        : 12:54:48:23

Metadata dans le fichier MP4.

Bonjour

Avant de tester ta nouvelle version, je reformule ce que j'ai décrit quand j'ai évoqué ce problème, à la lumière de ta précision
Avec la version Commits on Oct 31, 2024, ma vidéo du moment et son GPX ont ces caractéristiques :

Code:

exiftool 20241104-141519-Tram.mp4 => Create Date : 2024:11:04 13:18:35
ffprobe 20241104-141519-Tram.mp4 => creation_time   : 2024-11-04T13:18:35.000000Z
GPX metadata et premier trkpt : <time>2024-11-04T13:16:40Z</time>

Je ne sais pas pourquoi il y a un tel décalage entre la vidéo et le GPX, je vais refaire des essais d'enregistrement.
Actuellement je suis obligé d'ajouter --start-time 2024-11-04T14:16:40 à la commande

Bonne journée
Pulsar33

Pour exiftool, je ne sais pas quelle donnée il utilise.

La date de dernière modification du fichier ? (Qui serait à peu près creation_time + durée vidéo.

Pour la metadata creation_time, il est (sur gopro) défini par l'heure configurée par l'utilisateur. (donc pas strictement à l'heure)

Le gpx issu de la gopro a l'heure qui vient de la trame gps. Toutefois il y a un delta dû à la capture, process et écriture dans le flux. (cf doc gpmf)

Sur le gpx garmin, j'ai jusqu'à 7 sec d'erreur sur l'heure écrite dans le gpx.

C'est pour cela que la synchronisation entre un gpx garmin et le flux video d'une caméra ne peut pas être basé sur l'heure. => qiand j'aurai le temps ke ferai la synchronisation non plus sur l'heure mais la position gps.

Concernant tes gpx, est-ce que tu en as un sur lequel tu veux que je teste davantage les calculs de télémétrie ?

Sur celui que tu m'as fourni lors du problème 25Hz/30Hz, l'altitude me semble assez farfelue.

Enfin, si tu ecris un gpx directement depuis les trames NMEA d'un capteur gps, il te manque tout s le process de correction des données. Normalement le gps te donne plein de données notamment les info sur la précision de chaque point. Ça te permet de calculer la covariance et de corriger les points. (souvent c'est Kalman qui est utilisé pour cela). Je te laisse potasser, tu verras c'est loin d'etre si simple.

Pour l'instant, j'ai un problème sur le calcul de la pente lors de faible déplacement, principalement à vitesse lente.
Exemple sur ton gpx (25Hz/30Hz) j'ai à peine 1 mètre de parcouru entre 2 points (et une variation d'altitude énorme pour cette distance)


Pour info, il vaut mieux fournir le gpx complet de l'activité qu'un court extrait, puisque les filtres se basent sur des statistiques (plus il y a de données et meilleur est le résultat).

J'ai refait un essai Vidéo + GPS Logger avec mon Smartphone : 20241107-092014.gpx et 20241107_092018.mp4
Les fichiers sont nommés automatiquement en fonction de l'heure locale de début d'enregistrement.
Le décalage de 4 secondes est dû au passage d'une application à l'autre lors des déclenchements

exiftool 20241107_092018.mp4

Code:

File Modification Date/Time     : 2024:11:07 09:21:51+01:00  <= date/heure locale avec décalage GMT de la fin d'enregistrement
File Access Date/Time           : 2024:11:07 09:24:10+01:00  <= (à ignorer : utilisé par le filesystem)
File Inode Change Date/Time     : 2024:11:07 09:37:44+01:00  <= (à ignorer : utilisé par le filesystem)
Create Date                     : 2024:11:07 08:21:51  <= date/heure UTC de la fin de l'enregistrement
Modify Date                     : 2024:11:07 08:21:51  <= date/heure UTC de la fin de l'enregistrement
Track Create Date               : 2024:11:07 08:21:51  <= date/heure UTC de la fin de l'enregistrement
Track Modify Date               : 2024:11:07 08:21:51  <= date/heure UTC de la fin de l'enregistrement
Media Create Date               : 2024:11:07 08:21:51  <= date/heure UTC de la fin de l'enregistrement
Media Modify Date               : 2024:11:07 08:21:51  <= date/heure UTC de la fin de l'enregistrement

ffprobe 20241107_092018.mp4

Code:

Metadata  : creation_time   : 2024-11-07T08:21:51.000000Z  <= date/heure Zulu de la fin de l'enregistrement
Stream #0:0 creation_time   : 2024-11-07T08:21:51.000000Z  <= date/heure Zulu de la fin de l'enregistrement
Stream #0:1 creation_time   : 2024-11-07T08:21:51.000000Z  <= date/heure Zulu de la fin de l'enregistrement

BasicAirData GPS Logger for Android - ver. 3.2.2 20241107-092014.gpx

Code:

Metadata <name>GPS Logger 20241107-092014</name>    <= date/heure locale du début d'enregistrement
Metadata <time>2024-11-07T08:23:04Z</time>          <= (à ignorer : date/heure d'exportation du fichier)
Track <name>Tracé 20241107-092014</name>            <= date/heure locale sans décalage GMT du début d'enregistrement
Trackpoint   1 <time>2024-11-07T08:20:14Z</time>    <= date/heure Zulu pour le point
Trackpoint 105 <time>2024-11-07T08:21:58Z</time>    <= date/heure Zulu pour le point

A partir du moment où les seules date/heure disponibles sont la fin de la vidéo et le début du tracé GPX, ça ne peut pas fonctionner tout seul
Il faut nécessairement passer par l'option --start-time

@+ Puls

Creation_time = fin de la video... Ca porte bien son nom alors

Du coup chez toi, il faut faire creation_time - video duration pour avoir le debut (a condition que ce ne soit pas un timelapse, sinon fait tout recalculer)

Et oui, c'est cool non ?

Bon, je ne suis pas certain qu'il faille automatiser pour tous les cas particuliers.
C'est pourquoi je préférerais une méthode conforme à l'ISO 8601 pour définir le champ --start-time dans la commande
A partir de là, il n'y a plus de question à se poser

Pas encore essayé la nouvelle version, j'ai du jardinage en retard
@+ Puls

Tu peux à présent formater les dates en ISO ou non partout
--start-time
--telemetry-begin / end
--telemetry-from / to
etc...

Pour voir les formats de date, tu peux faire :
gpxtools test
(tu verras les formats acceptés ou non)

Si pas de timezone indiquée, je considère que c'est l'heure locale de l'ordinateur.

Bonsoir,

Désolé j'ai été très pris pendant deux jours,
Merci pour ces bonnes nouvelles
Je m'y remets dès demain !

Bonne soirée
Pulsar33

Bonjour

Bon, on n'a pas tout perdu, si la vidéo n'a pas de date de création ou que celle-ci est nulle, ça se cale sur le GPX sans nécessité d'utiliser --start-time

En revanche pour le champ --start-time, soit on ne s'est pas compris soit il y a un truc qui ne marche pas
Et gpxtools test ne fait qu'ajouter à la confusion car tous les formats listés sont du type '2020:12:13 08:55:48 ...'
Ce n'est pas du tout ce à quoi je m'attendais, à savoir privilégier le format 2024-11-07T08:20:22Z
D'ailleurs, : dans la date au lieu de - c'est peu conventionnel ...

Ma vidéo : ffprobe creation_time : 2024-11-07T08:21:51.000000Z => heure de fin de la vidéo
Mon fichier GPX : trkpt1 2024-11-07T08:20:14Z => heure de début de la trace

Quel que soit ce que j'essaye ci-dessous, l'heure démarre à 21:26:40  
Les données sont bien sûr figées puisque l'heure ne correspond pas
--start-time 2024-11-07T09:20:22
--start-time 2024-11-07T08:20:22Z
--start-time '2024:11:07 09:20:22'
--start-time '2024:11:07 08:20:22Z'

J'ai raté quoi ?
Pulsar33

Un petit loupé, tu peux mettre à jour.

Pour les dates, j’accepte quelques formats exotiques... car déjà vu.

J'ai testé avec la dernière vidéo que tu m'as donnée :

Code:

./tools/gpx2video -g ../../videos/jonzac-issue/progweb.gpx -m ../../videos/jonzac-issue/video/progweb25hz.mp4 -l ../../videos/jonzac-issue/layout576p-best.xml --telemetry-filter=1 --telemetry-smooth=2 --telemetry-method=3 --telemetry-rate=250 --telemetry-offset=0 --time-factor auto --output test.mp4

J'ai un résultat très satisfaisant.

Je note la pente qui me semble farfelue, mais elle est correctement calculée par rapport à l'altitude et la distance que tu parcours.

Je note également que ta vidéo manque de stabilisation... tout comme avec ma caméra garmin.

Evolution que je prévois (mais pas pour tout de suite) :
- ajout / remplacement de l'altitude via les données DEM publiques.
- ajout / utilisation du plugin ffmeg "libvidstab"

Pour stabiliser ta vidéo (à faire avant gpx2video) :

Code:

ffmpeg -i ../../videos/jonzac-issue/video/progweb25hz.mp4 -vf vidstabdetect=shakiness=7 output.mp4

rapidement vérifié pour les dates. C'est validé pour :
--start-time 2024-11-07T09:20:22
--start-time 2024-11-07T08:20:22Z

Je regarde le reste asap

Pour l'instant, j'ai un clone bas de gamme de caméra sportive, une caméra 360°, un caméscope  mini-DV et mon smartphone.
Coté GPS, le BT-338 et plusieurs applications sur smartphone avec le site VisuGpx si l'élévation est absente de l'enregistrement
La seule caméra stabilisée que j'ai est celle de mon drone mais celui-ci n'enregistre pas le GPX (j'ai d'ailleurs envoyé une demande à la marque à ce sujet)
J'ai pensé fixer le drone sur le vélo et l'utiliser comme caméra embarquée mais je n'ai pas encore essayé

@+ Puls

Edit : précision VisuGpx

Pour la stabilisation par ffmpeg, je ne connaissais pas mais ce que je viens d'essayer ne fonctionne pas vraiment.
C'est pire, en particulier en rotation où ça génère un violent "roulis" à chaque changement de cap un peu conséquent.
D'ailleurs d'après ce que j'ai lu, ce que tu indiques n'est que la première passe qui calcule le fichier de correction .trf
Il faut ensuite utiliser le filtre vidstabtransform genre :

Code:

ffmpeg -i inp.mpeg -vf vidstabtransform,unsharp=5:5:0.8:3:3:0.4 inp_stabilized.mpeg

Bon, je laisse de coté pour l'instant
Pulsar33

Bonjour

Je viens de vérifier la dernière version sur la trajectoire intégrale dont je t'ai passé un extrait (d'ailleurs à ce sujet, je vais faire le ménage dans mon cloud)
Ça me semble franchement pas mal, que ce soit pour le dessin de la trajectoire sur la carte (mais il faut que je vérifie ce point sur d'autres trajets) ou même pour la vitesse et l'altitude.
Comme il me semblait, l'altitude n'est pas précise mais la dérive est plutôt lente. Reste bien sûr la pente qu'il faut encore travailler ...
Ceci dit, lorsque je compare un CSV créé avant et celui créé maintenant, les différence d'altitude ne sont pas si flagrantes. Impression ? A confirmer ...

Bon dimanche
Pulsar33

En corrigeant l'altitude via les données DEM, j'ai un bien meilleur résultat. Sur le courbe ci-dessous, tu as la courbe de niveau DEM et la tienne à côté...
(mais je n'ai pas intégré l'utilisation des données DEM dans gpx2video ; en fait la plupart du temps j'utilise un GPX qui provient de Garmin Connect et l'altitude a déjà été corrigée par Garmin)

Tu passes sur ta portion de GPX de 50m à 23m sur 600m....



Normalement, le tracé ne devrait pas changer, car les coordonnées des points lat & lon ne sont pas modifiées excepté pour certains points (Ils ont le tag 'F').

D'ailleurs pour info, quand tu exportes en CSV les données de télémétrie, tu as :
- 'M' : point Mesuré
- 'P' : Prédiction (donc interpolé)
- 'E' : Point Erroné (donc ignoré)
- 'F' : Point Fixé (corrigé) => donc ne devrait plus y avoir de 'E')
- 'U' : Unchanged (non modifié)

L'élévation est juste filtrée. Donc oui peu de changement visible par rapport à avant.