GoPro & Linux

Bonsoir,

Effectivement, ce schéma confirme que mon vieux GPS BT-338 n'est pas bon en vertical ! Ce n'est pas trop une surprise. Il fonctionne avec au maximum 10 satellites du réseau GPS d'origine.
On a l'impression que ça se casse la figure quand un des satellites sort du champ de vision et que ça revient brusquement lorsqu'un autre est capté pour le remplacer.
J'ai un outil qui mesure la qualité sur un point fixe avec ce GPS, c'est clairement ce qu'on observe généralement.

A ce jour pour l'élévation, j'ai trois solutions :
1) ce vieux GPS BT-338 sans correction interne ni externe puisque j'enregistre directement la trame NMEA et que j'en extrais simplement le GPX correspondant sans traitement
2) l'application GeoVelo qui m'affiche l'altitude mais ne l'exporte pas. Jusqu'à présent, je passais par VisuGpx pour importer le GPX et l'exporter avec l'élévation issue de leur modèle numérique de terrain.
3) l'application GPS Logger découverte récemment qui exploite plus de 20 satellites avec un algorithme récent et qui dispose de la correction d'altitude EGM96.
Je ne sais pas certifier ce qu'elle apporte mais elle n'est pas là par hasard. Je suppose qu'il s'agit d'une modélisation détaillée du géoïde qui compense les irrégularités de la surface terrestre.

Je vais privilégier la troisième solution maintenant que je l'ai validée et faire des essais plus précis avec elle

Je suis en train de regarder la vidéo que tu as appelée Jonzac et qui en fait se situe en Gironde
L'altitude ne varie pas de plus de 3 mètres et du coup, la pente reste à 0.
C'est cool mais je ne suis pas certain que ce soit significatif d'une amélioration sur le traitement de la pente
J'ai roulé sur une zone extrêmement plate comme souvent par chez moi, mais qu'en serait-il sur un parcours vallonné et à des vitesses faibles ?

Bonne soirée
Pulsar33

Un petit bug pour la route, détecté en recodant une vidéo de Jonzac
Heure du premier point dans le GPX : 2023-04-23T14:57:04.516000+0200
--start-time utilisé pour recaler le début de la vidéo :2023-04-23T15:04:03.522000+0200
Durée affichée au démarrage de la vidéo : 0:06:59 au lieu de 0:00:00

@+ Puls

La durée "gpx2video" n'est pas la durée de la vidéo, mais la durée de l'activité.

Si tu veux ignorer une partie du gpx, il faut faire :

Code:

--start-time "2023-04-23T15:04:03.522000+0200" --gpx-from "2023-04-23T14:57:04.516000+0200"

--gpx-from et --gpx-to permettent de définir la plage où sont calculés les données.
Les données "instantanées" (vitesse, heure, cadence...) seront toujours affichées, les autres (vitesse max, moyenne, distance, durée...) seront mis à jour seulement dans la plage.

Ah ok, je n'avais pas percuté là-dessus
Bonne soirée
Pulsar33

PS : euh ça ne marche pas. J'ai ensuite inversé les deux valeurs et c'est pire
Je réfléchis à ça demain

Faut pas inverser

start-time c'est l'heure de la vidéo
gpx-from c'est l'heure à laquelle tu veux commencer à "compter" dans le GPX (le début de l'activité)

--start-time "2023-04-23T15:04:03.522000+0200" --gpx-from "2023-04-23T15:04:03.522000+0200"

Là tu auras durée de l'activité qui commence à compter au début de ta vidéo
(donc distance, durée, moyenne... commenceront au début de cette vidéo)

Bonjour,

Je n'y arrive pas.
Pour cet essai, je suis avec ma pseudo caméra sportive et l'application GeoVelo puis je récupère l'élévation sur VisuGpx
Comment je procède lors du trajet :
- Je démarre l'enregistrement de trajectoire et je mets le smartphone en sécurité
- Je m'assois sur le trike puis quand je suis prêt à partir (ce fut un peu long sur cet exemple), je lance la vidéo
- Je clipse les pédales puis je démarre après quelques secondes
Ce que je souhaite : que l'activité démarre à zéro à l'heure où je lance la vidéo et bien sûr que les données soient synchro de la vidéo

La vidéo n'est pas datée en interne et le GPX commence ainsi :

Code:

 <metadata>
    <name>23 avr. 14h57 - 16h06</name>
  </metadata>
  <trk>
    <name><![CDATA[23 avr. 14h57 - 16h06_1]]></name>
    <trkseg>
      <trkpt lat="45.44088" lon="-0.42721">
        <ele>37</ele>
        <time>2023-04-23T14:57:04.516000+0200</time>
      </trkpt>

Coment je synchronise les deux :
Je lance un encodage d'une durée suffisante pour que le symbole atteigne un point remarquable (fixe ou virage)
Pour cet encodage "perdu" je mets l'heure de début du GPX comme heure de début de la vidéo
Sur la vidéo générée, je note les durées de passage au point remarquable choisi. Exemple :
- Sortie du premier virage sur la vidéo : 01:04
- Sortie du premier virage pour le symbole vélo : 08:03
Je devrais donc utiliser la formule suivante (comme tu le dis d'ailleurs) :
--start-time 2023-04-23T15:04:03.522000+0200 --gpx-from 2023-04-23T15:04:03.522000+0200
Et bien si je fais ça, la vidéo commence bien à 15:04:04 mais la durée commence à 0:06:59
Les données sont bien synchrones de la vidéo (du moins au début de la vidéo, nous en reparlerons)

Bonne journée
Pulsar33

Ce que tu fais est bon.

--start-time c'est l'heure du début de la video. Aucun lien avec le gpx
--gpx-from heure du debut de l'activité

Es tu sûr d'être a jour

Git fetch
Git rebase
Make

Bonsoir,

Je suis avec Commits on Nov 9, 2024 Use datetime api c'est à dire la version que tu avais corrigée pour le start-time
J'ai vu que ça a bougé depuis mais j'attendais d'avoir traité ce problème pour basculer

Bonne soirée
Pulsar33

Pour info :
Je refais l'installation complète à chaque fois et je garde plusieurs versions en renommant le dossier racine au cas où ...
Actuellement j'ai plusieurs versions depuis Commits on May 7, 2024 GPX skip point if same time qui est ma référence

Pulsar33 a écrit:

Bonsoir,

Je suis avec Commits on Nov 9, 2024 Use datetime api c'est à dire la version que tu avais corrigée pour le start-time
J'ai vu que ça a bougé depuis mais j'attendais d'avoir traité ce problème pour basculer

C'est justement Telemetry adjustment qui règle ces derniers problèmes/détails.

Ok, désolé
Je bascule demain
Bonne soirée
Pulsar33

Finalement je viens d'essayer rapidement, pas mieux

Code:

pulsar33@Minerve:/media/DATA/Technique/Velos/Trajets/Pacman$ /media/DATA/Workbench/gpx2video/build/tools/gpx2video -q --video-preset=ultrafast --video-crf=25 -m Jonzac05.mp4 --start-time 2023-04-23T15:04:03.522000+0200 --gpx-from 2023-04-23T15:04:03.522000+0200 -g Jonzac05VG.gpx -l layout576p-best.xml --telemetry-filter=3 --telemetry-method=3 --telemetry-rate=1000 -o Jonzac05_ovl.mp4
gpx2video v0.0.0
Parsing 'layout576p-best.xml' layout file
  Download tile 360 / 360 [##################################################] DONE      
[FRAME  2156] 00:01:26.240 / 00:56:36.800 |   2% - Remaining time: 00:39:01^C
2157 frames 720x576 to 720x576 proceed in 00:01:01

L'heure est bonne. La durée démarre avec des tirets puis saute à 0:07:00

Curieux
Pulsar33

Corrigé, c'est le widget qui n’affichait pas la bonne valeur.

Bonjour,

Cette fois c'est bon

En revanche j'ai eu un truc curieux : la première fois que j'ai lancé tout était bon y compris la trajectoire mais la carte n'était pas affichée
J'ai relancé plusieurs fois depuis et je n'ai pas revu le problème
Variable non initialisée ?

Bonne journée
Pulsar33

Bien quelques petites corrections. J'ai également essayé de rendre les choses plus claires.

Code:

/tools/gpx2video -g activity.gpx -m input.mp4 -l layout.xml \
--start-time "2024-10-24T15:07:04.000Z" \             // Heure du début de la vidéo
--gpx-from "2024-10-24T15:07:10.000Z" \              // Heure à laquelle on commence à calculer les données dans le GPX (ligne de départ)
--gpx-to "2024-10-24T15:07:15.000Z" \                  // Heure à laquelle on arrête de calculer (ligne d'arriver)
--gpx-begin "2024-10-24T15:07:00.000Z" \            // Toutes les données présentes dans le gpx avant cette heure sont ignorées              
--gpx-end "2024-10-24T15:07:20.000Z" \               // Toutes les données présentes après sont ignorées
--telemetry-filter=1 --telemetry-smooth=2 --telemetry-method=3 --telemetry-rate=250 --telemetry-offset=0 \
--time-factor auto \
--output output.mp4 video

Si "begin" & "end" ne sont pas définies, ça utilise tout le GPX.
Lorsque l'on est dans la plage "gpx-from" - "gpx-to", durée, moyenne, distance... sont caculées.
Lorsque des données sont dispo, la vitesse, altitude, pente... sont toujours calculées.

Hors plage, on affichera "--" en absence de données ; ou on affichera la dernière donnée connue et calculée.

Typiquement, avant la ligne de départ on a "distance = --" (la vitesse qui peut être indiquée), une fois la ligne d'arrivée franchie, la distance ne bouge plus, mais la vitesse continue d'être calculée... si plus de données GPX, alors la vitesse devient "--" (la distance reste toujours renseignée)

Lors du rendu, tu as un résumé de ce qui est fait :

Code:

Rendering...
Video: start at '2024-10-24 17:07:04.000'
GPX: Filter telemetry data in using 'Iglewicz & Hoaglin' method.
GPX: 4 outliers detected
GPX: Compute telemetry data from '2024-10-24 17:07:10.000' to '2024-10-24 17:07:15.000'
GPX: Smooth telemetry data on window size '5' (+/- 2 points)
GPX: Telemetry available data range from '2024-10-24 17:07:00.000' to '2024-10-24 17:07:20.000'

Prochaine étape, widget avec cumul montée et cumul descente ; correction détection des "tours" (mode circuit) ; puis je commencerai à faire des widgets graphiques.

Bonjour,

J'ai un peu de mal à comprendre la différence entre from/to et begin/end
Je comprends confusément que ça joue sur l'affichage et/ou sur la comptabilisation de certaines données mais c'est difficile à appréhender

En tout état de cause, mon besoin (décrit plus haut) se limite à synchroniser la vidéo avec le GPX et recaler le début des calculs sur le début de la vidéo
Je crois comprendre qu'il faut donc désormais que j'utilise start-time et gpx-begin avec la même date/heure, et que j'e peux ignorer les autres paramètres

Je vais essayer ça asap
Pulsar33

Bon, ben je n'ai pas dû comprendre
Si je remplace gpx-from par gpx-begin la durée démarre en disant des grossièretés puis passe à 0:07:xx
Avec grpx-from, ça semble fonctionner comme avant

J'ai remplacé  --telemetry-filter=3 --telemetry-method=3 --telemetry-rate=1000
par ce que tu proposes : -telemetry-filter=1 --telemetry-smooth=2 --telemetry-method=3 --telemetry-rate=250 --telemetry-offset=0 --time-factor auto

A première vue, la vitesse est beaucoup plus fidèle et réactive. Elle est totalement en phase avec le son du moteur.
La pente semble calmée même si dans les quelques minutes que j'ai testées, c'est plutôt plat. Mais justement, elle n'a pas de valeurs erratiques comme avant
Je laisse encoder complètement pour voir ce que ça donne

@+ Puls

Donc je n'ai pas été assez clair

--gpx-begin pour indiquer l'heure à partir de laquelle on conserve les données GPX ; tout ce qui est avant est ignoré et non utilisé.
--gpx-end pour indiquer l'heure à partir de laquelle on supprime les données GPX ; tout ce qui est après est ignoré et non utilisé
=> avec l'outil "gpxtools" ça pemret par exemple d'extraire une portion de gpx.
Si non défini, on utilise tout le GPX.

--gpx-from pour indiquer l'heure à partir de laquelle on calcule
--gpx-to pour indiquer l'heure à partir de laquelle on arrête de calculer.
=> Ca permet par exemple de définir une ligne de départ et une ligne d'arrivée ; et donc de ne calculer les données que sur cette portion (exemple une course)
Si non défini, ça applique la limite sur --gpx-begin & --gpx-end.

Typiquement sur une course, j'ai un GPX qui contient le parcours pour accéder au départ,, la course elle-même, et le retour.

J'indique gpx-from pour l'heure où je franchis la ligne de départ
J'indique gpx-to pour l'heure où je franchis la ligne d'arrivée.
Ainsi, moyenne, vitesse max, durée... seront correspondront à la course.

Ensuite pour chaque clip vidéo pris pendant cette activité, j'indique le start-time de la prise de vue.

Si la vidéo commence avant la ligne de départ, j'aurai : "--" dans les données calculées (moyenne, max, durée...)
J'aurai la vitesse, altitude, pente... si j'ai des données GPX (donc après "begin"), sinon également des "--".

Si la vidéo est pendant la course, j'aurai tous les widgets renseignés et mis à jour.

Si la vidéo est après la course, les données calculées (moyenne, max, durée...) seront figées (affichées mais elles n'évolueront plus)
Je continuerai d'avoir la vitesse, altitude, pente.... si j'ai des données GPX (donc avant "end). Si plus de données, retour des "--".

---

Pour ce qui concerne le start-time, une chose qui peut aider, c'est quand tu déclenches la caméra, c'est de filmer ta montre. Ainsi si tu auras l'heure de début.

Sinon, effectivement il faut le faire sur des repères géographiques, mais ce n'est pas très facile, surtout si c'est hors route.

Bonjour,

Si, si, c'était assez clair et ça l'est encore plus avec ces nouvelles explications, mais ...

1) je n'ai pas besoin de toutes ces fonctionnalités. Tant mieux si elles existent et ne me compliquent pas l'usage du logiciel
2) je ne comprends donc pas ce que je constate

Comme indiqué, je souhaite (uniquement jusqu'à présent) synchroniser l'heure du début de la vidéo par rapport au GPX et démarrer l'activité immédiatement
Le repérage temporel % géographique avec un point fixe ou remarquable de la trajectoire au moyen d'un encodage partiel "perdu" me convient tout à fait
Je démarre toujours l'enregistrement du GPX avant la vidéo. Je l'arrête généralement après l'arrêt de la vidéo donc la fin ne me préoccupe pas.
Une fois l'heure de début de la vidéo "temporellement" identifiée, il me suffit de l'utiliser pour start-time et ce paramètre fonctionne parfaitement
Avant ta dernière version, j'utilisais uniquement gpx-from avec la même heure et ça fonctionnait, et ça fonctionne toujours

Pourtant suite à tes explications, utiliser uniquement gpx-begin à la place de gpx-from et avec l'heure utilisée pour start-time devrait donner le même résultat
Si tout ce qui est avant gpx-begin est ignoré, la durée devrait démarrer à zéro. Et bien ce n'est pas le cas. La durée démarre en disant des grossièretés puis passe à 0:07:xx

La commande qui fonctionne :

Code:

/media/DATA/Workbench/gpx2video/build/tools/gpx2video -q --video-preset=ultrafast --video-crf=25 -m Jonzac05.mp4 --start-time 2023-04-23T15:04:03.522000+0200 --gpx-from 2023-04-23T15:04:03.522000+0200 -g Jonzac05VG.gpx -l layout576p-best.xml --telemetry-filter=1 --telemetry-smooth=2 --telemetry-method=3 --telemetry-rate=250 --telemetry-offset=0 --time-factor auto -o Jonzac05_ovl.mp4

Avec gpx-begin en lieu et place de gpx-from, la durée tient compte de tout le GPX au lieu d'ignorer le début de la trace

Bonne journée
Pulsar33

Re
La version de ce matin testée à l'instant ne corrige pas le problème, bien qu'elle ne dise plus de gros mots
@+ Puls

Hello,

Je viens de modifier le comportement de begin & end. Et en effet, il y avait un petit bug.

J'ai modifié, car finalement il n'y avait pas gros intérêt par rapport à from & to.

En fait le but est de masquer le début et/ou la fin de la trace (zone de confidentialité sur Strava).

Cela évite via la map & la track de savoir où tu habites par exemple.

ET SURTOUT, lorsque tu utilises begin & end, de ne pas perdre la distance totale que tu as réellement parcourue.
(donc elles ne sont plus ignorées)

Dans ton cas, si tu n'indiques que "from" (et qui est identique au start-time), lors du rendu tu auras sur le widget track & map un bout de trace qui correspond à ce qui est avant "from". Donc 2 solutions :

1°/ Tu calcules à partir de from ; et tu caches tout ce qui est avant begin :

Code:

/media/DATA/Workbench/gpx2video/build/tools/gpx2video -q --video-preset=ultrafast --video-crf=25 -m Jonzac05.mp4 --start-time 2023-04-23T15:04:03.522000+0200 --gpx-begin 2023-04-23T15:04:03.522000+0200  --gpx-from 2023-04-23T15:04:03.522000+0200 -g Jonzac05VG.gpx -l layout576p-best.xml --telemetry-filter=1 --telemetry-smooth=2 --telemetry-method=3 --telemetry-rate=250 --telemetry-offset=0 --time-factor auto -o Jonzac05_ovl.mp4

2°/ Tu supprimes les données avant begin, puis tu calcules depuis le début du nouveau gpx :

Code:

/media/DATA/Workbench/gpx2video/build/tools/gpxtools -i Jonzac05VG.gpx --gpx-begin 2023-04-23T15:04:03.522000+0200 -o Jonzac05VGCrop.gpx

/media/DATA/Workbench/gpx2video/build/tools/gpx2video -q --video-preset=ultrafast --video-crf=25 -m Jonzac05.mp4 --start-time 2023-04-23T15:04:03.522000+0200 -g Jonzac05VGCrop.gpx -l layout576p-best.xml --telemetry-filter=1 --telemetry-smooth=2 --telemetry-method=3 --telemetry-rate=250 --telemetry-offset=0 --time-factor auto -o Jonzac05_ovl.mp4

Bonsoir

Pulsar33 a écrit:

1) je n'ai pas besoin de toutes ces fonctionnalités. Tant mieux si elles existent et ne me compliquent pas l'usage du logiciel

Je ne comprends pas ton choix que je ressens comme une régression fonctionnelle.
Et le problème signalé depuis que nous parlons de ce sujet n'est pas résolu justement compte tenu de ton choix (si je ne mets que begin, ça démarre à 0:07:00)
Je suis donc obligé de passer deux fois le même paramètre (begin et from) ou de charcuter mon GPX sinon j'affiche des choses qui pour moi n'ont pas de sens et que je ne veux pas afficher.
C'est de plus beaucoup moins intuitif pour l'utilisateur.

Les définitions proposées au départ étaient limpides. Si j'ai dit que je n'avais pas compris, c'est parce que le résultat constaté ne correspondait pas à la définition (tu as bien corrigé un bug).
Pour moi :
- on ignore tout ce qui est avant begin et tout ce qui est après end (calage temporel ou protection de vie privée)
- on mesure l'activité entre from et to uniquement et si from n'est pas défini alors from = begin

Bonne soirée
Pulsar33

Voilà, j'ai repris le dernier commit pour restaurer le comportement précédent en y ajoutant quelques corrections.

En effet, si begin/end ou from/to n'étaient pas des points du GPX (ce qui arrive sur les GPX garmin puisque tu peux avoir des points toutes les 10 secondes), c'est à présent pris en compte et ne pose plus de problème.

J'ajouterai une autre fonctionnalité pour définir les zones "privées" qui là, cacheront les départs et/ou arrivées sur la track et la map (à la manière de Strava). Et dans ce cas, les données seront bien calculées.

Bonjour,
Les premiers essais sont bons
En utilisant gpx-begin seulement : la durée démarre bien à zéro et le tracé n'inclut pas les parties non souhaitées
J'ai fait un essai de  protection de vie privée en décalant d'une minute le gpx-begin par rapport au start-time.
Le début de la trajectoire est bien masqué et l'icone est placée en cohérence
Du début de la vidéo au point gpx-begin, les données suivantes sont affichées avec des tirets :
Altitude, pente, vitesse, vitesse moyenne, durée, distance
Je ne sais pas si c'est ce que tu souhaitais

Bonne journée
Pulsar33

Cest exactement ce que ca doit faire.

Begin/end n'ont pas vocation à être utilisé pour definir une zone privée. Mais uniquement à supprimer des données.

Lorsqu'il y aura une zone privée, ca cachera les données mais uniquement sur la carte (et la track).

Ça sera dans un fichier de conf pour ne pas avoir à les mettre à chaque fois sur la ligne de commandes.

Ok, c'est cool; Mon besoin primaire est bien rempli.

Reste à améliorer cette fichue pente
Actuellement, elle varie beaucoup moins erratiquement qu'avant
Cependant, elle semble "à la traîne" et intuitivement excessive (j'ai du mal à croire que je monte du 15%)

Bonne journée
Pulsar33