GoPro & Linux

Bonjour,

Avec Jonzac01, j'ai des secondes entières par ci par là (25 frames exactement) où il y a des tirets à la place des textes. Je n'ai pas remarqué ça sur Jonzac02 ni Jonzac04.
J'utilise pourtant --telemetry 3 :

Code:

/media/DATA/Workbench/gpx2video/build/gpx2video -q --video-bitrate=2249000 --video-min-bitrate=2249000 --video-max-bitrate=2249000 --telemetry 3 -m Jonzac01O.mp4 -g Jonzac01-VGO.gpx -l layout576p04TP.xml -o Jonzac01-VGO.mp4 video

Je croyais que cela interpolait les données en cas de manque ...?

Ce n'est pas dû à une modification récente. J'ai essayé avec la version du 29/07 après-midi, c'est pareil.

Qu'en penses-tu ?
Pulsar33

Pulsar33 a écrit:

Avec Jonzac01, j'ai des secondes entières par ci par là (25 frames exactement) où il y a des tirets à la place des textes. Je n'ai pas remarqué ça sur Jonzac02 ni Jonzac04.

Les "--" veulent dire qu'il y a une donnée invalide dans le GPX (ou qu'il ne sait pas parser).

Ils seront utilisés également si la vidéo est hors zone GPX. Exemple tu veux faire la vidéo d'un segment. Hors segment, les données vitesse, cadence, fréq. cardiaque... seront affichées si dispo (sinon "--") ; par contre les données durée, moyenne, vitesse max... n'évolueront pas. A l'intérieur du segment, tout est calculé. Puis à la sortie, à nouveau durée, moyenne, vitesse max... seront figées.
=> pour cela il faut utiliser les options "--gpx-from" et "--gpx-to"

Ton GPX contient parfois des dates de la forme :

"2023-04-19T16:33:59+0200"

C'est corrigé.

Bravo
C'est bon maintenant. Belle réactivité !

Merci
Pulsar33

Vidéo Jonzac01 de 44 minutes générée en 34 minutes.
Cool, pas vu de défaut pour l'instant

@+ Puls

Petite mise à jour

text-lineheight => text-linespace

3.0 pour avoir une valeur 3x plus grosse que le label

left pour aligner le label horizontalement (left, center, right)
left pour aligner la valeur horizontalement (left, center, right)

Du coup avec les valeurs de padding & linespace on peut faire ce que l'on veut maintenant.

Maintenant, je passe à la suite de ma TODO list

Bonsoir,

Testé rapidement sauf les centrages
Ça semble bon

Bonne soirée
Pulsar33

Nouvelle version qui supporte à présent la vidéo avec un sens d'orientation (portrait / paysage...)

Bonjour,

J'espère que tu as un autre testeur pour ce point car je n'ai rien pour vérifier ça

Bonne journée
Pulsar33

Pulsar33 a écrit:

J'espère que tu as un autre testeur pour ce point car je n'ai rien pour vérifier ça

Une simple vidéo réalisée par un téléphone en changeant son orientation.

Sinon, tu vas pouvoir tester la dernière fonctionnalité ajoutée ce jour... le support du DAR & SAR.
Fonction d'ailleurs liée à la gestion de l'orientation, puisque j'applique toutes les transformations en une passe !

Normalement, tu ne devrais pas avoir de retouche à faire.

Par contre en rendu "image", tu devras juste les redimensionner (voir les pivoter) lors de l'incrustation.

Prochaine étape, le bug de l'audio coupé... par contre je ne sais pas le reproduire. Je pense que ça doit dépendre de la vidéo en entrée.

Waou ! c'est beaucoup mieux !
Les ronds sont ronds, les carrés sont carrés ! Bravo
Excellent !

Je viens de (me) confirmer que le problème audio existe même sur des encodage très courts.
Je t'envoie un petit bout de vidéo non traitée dès que j'ai un créneau sur ma liaison ADSL pourrie.

@+ Puls

Video 1 minute pour correction audio tu as déjà le gpx
Chez moi, j'ai bien le problème audio
Tu remarqueras aussi que la pente affichée est loin d'être stable sur cette route plate

@+ Puls

- BUG : value-align right => se décale à droite si le nombre termine par 1 puis revient en place quand le dernier chiffre du nombre est différent de 1
C'est le cas par exemple pour la durée et pour l'heure que je place à droite de l'image sans label ni logo

Bon courage
Pulsar33

Pulsar33 a écrit:

- BUG : value-align right => se décale à droite si le nombre termine par 1 puis revient en place quand le dernier chiffre du nombre est différent de 1
C'est le cas par exemple pour la durée et pour l'heure que je place à droite de l'image sans label ni logo

Bon courage

C'est parce que le texte ne fait pas la même largeur.

Si je comprends bien tu voudrais que les ":" se superposent entre deux affichages.

Le plus simple est de changer la police.

Je ne crois pas que c'est ça ...
Effectivement, lorsqu'on a des compteurs animés, il faut utiliser une font non proportionnelle si on veut éviter que ça danse horizontalement.
Mais j'ai l'impression que c'est déjà ce que tu fais. Quand la durée passe de 0:00:09 à 0:00:10 rien ne se décale horizontalement.
En revanche, quand la durée passe de 0:00:10 à 0:00:11 l'ensemble du texte se décale à droite, puis quand elle passe de 0:00:11 à 0:00:12, l'ensemble du texte se recale normalement.
Il reste ensuite calé normalement jusqu'à ce que le dernier chiffre passe à 1 et ça recommence. Le texte est décalé à droite uniquement si le dernier chiffre est un 1

Est-ce plus clair ?
Pulsar33

PS : je suppose du coup qu'il y a le même problème à gauche en align left mais ça ne se voit presque jamais puisque le chiffre de gauche est très stable
Il faut que je scrute la vitesse et la pente

Je comprends. Je regarderai ce que je peux faire.

Pulsar33 a écrit:

Video 1 minute pour correction audio tu as déjà le gpx
Chez moi, j'ai bien le problème audio
Tu remarqueras aussi que la pente affichée est loin d'être stable sur cette route plate

Merci,

J'arrive effectivement à reproduire le problème.

Pour l'instant je ne sais pas le corriger, parce que je ne connais rien à l'audio et aux codecs...

Ce que je comprends, c'est que je récupère du flux en entrée un paquet qui correspond à une durée (laquelle je ne sais pas encore) et que je le ré-injecte dans le muxer ffmpeg de l'encder.

Et visiblement, je lis les données audio et les injecte trop vite, et donc le muxer finit par mettre à la poubelle les packets.

Là j'ai fait un teste en divisant par 10 la vitesse du flux audio en lecture, et je n'ai plus le problème sur ta vidéo.

Il va falloir que j'étudie un peu cette partie. Pour l'instant, je n'ai travailler que la partie image.


Pour la pente... si je ne travaille qu'à partir du GPX sans "filtrer" / "lisser", les données calculées sont bonnes.

Dans le GPX, on voit bien l'élévation fluctuer entre 29 et presque 32m... en soit c'est énorme sur de petites distances.

Il faudrait lisser les données issues du GPS qui ne semblent pas très précis.

Ok pour l'audio, tu as donc ce qu'il faut pour trouver. Courage !

Pour la pente, l'altitude m'a été fournie par le site VisuGPS car elle n'est pas dans mes gpx originaux.
Pour progresser sur le filtrage, il faudrait pouvoir utiliser un csv à la place du gpx comme nous l'avions envisagé
Ceci me permettrait de mettre au point un filtrage optimisé pour notre utilisation sans toucher à ton logiciel dans un premier temps.
Ensuite, une fois le filtrage idéal trouvé (s'il existe), il te suffirait de le mettre dans ton code.
Enfin, c'est ce que je peux te proposer pour t'aider

Bonne soirée
Pulsar33

Bonjour,

Je commence à m'intéresser en détail au contenu du csv en fonction de telemetry-rate et je ne comprends pas ce que sont les champs Total duration, Partial duration et RideTime.
Bien que leurs noms soient parlants, leur contenu me semble étrange et irrégulier alors que Timestamp et Time évoluent parfaitement.

Peux tu m'en dire plus sur ces décalages temporels et surtout sur l'utilité de ces champs dans tes traitements ?

Merci
Pulsar33

La durée totale est la durée total enregistrée dans le gpx

Partial, c'est la durée entre le début et la fin de la zone d'intérêt définie par les options gpx-from et gpx-to.

Ride c'est la durée roulée (> à 3-4km/h) à l'intérieur de la zone partial

Mais il se peut que j'ai cassé un truc

Je referai un check complet prochainement et j'essaierai d'ajouter un filtre sur les données d'entrée.

Bonjour,

Bon, j'ai pas vraiment mieux compris pour la durée totale : c'est une valeur unique, pas une variable ...
Et surtout, puisque le temps est à la seconde, pourquoi ces valeurs n'évoluent pas régulièrement d'une seconde à chaque cycle ?
Enfin bref, je ne vois pas leur intérêt mais ce n'est pas grave.

Je te propose un filtrage de l'altitude qui semble (à l'oeil) donner de bon résultats même si je ne peux pas le valider puisque je ne peux pas utiliser un csv à la place du gpx.


J'ai mis un maximum de parenthèses pour éviter les erreurs de préséance (attention à la recopie)
Il convient sans doute d'utiliser le résultat du cycle 3 comme valeur de d'affichage au cycle 0 histoire de rattraper un peu le décalage injecté par le filtre.

Qu'en penses-tu ?
Pulsar33

Bonjour,

En attendant que tu t'y retrouves dans toutes mes remarques et suggestions précédentes, je rajoute un constat concernant le traitement des tuiles.
J'ai commencé à traiter un trajet fait hier entre Le Haillan et Ste Hélène via la piste cyclable soit 19 km pratiquement en ligne droite.
Contrairement aux trajets de Jonzac qui faisaient généralement la même distance mais en tournant en rond, là, l'extension géographique est plus grande.
Avec exactement les mêmes paramètres que pour les vidéos de Jonzac (zoom et factor) je me retrouve avec beaucoup plus de tuiles.
Avec mon ADSL pourri, j'ai un overhead excessif pour leur chargement mais c'est normal et je fais avec pour nourrir le cache qui est bienvenu !
Ceci fait quand je relance, je n'ai plus cette phase désagréable. Tant mieux.

En revanche, je subis plus de 4 minutes de calcul préliminaire de ce que je suppose être une énorme "image locale" de la zone utilisée pour la map.
Du moins est-ce l'interprétation que j'en devine quand je vois la taille mémoire coller au plafond et le swap commencer à se remplir, sans parler de la CPU qui chauffe.
J'ai commenté la vidéo de cette phase (et accéléré certaines parties sans intérêt) pour que tu te rendes compte du problème.
Je n'ose imaginer ce que ça donnerait sur un trajet de 100 ou 200 km ...

Il est bien sûr nécessaire de disposer d'une image locale de la zone à afficher, tenant compte des paramètres d'échelle et de zoom tels que définis plus haut.
Cependant, elle n'a aucune raison d'être l'image intégrale de toute la zone à couvrir. Cette image locale doit être mise à jour en fonction de la position et des-dits paramètres.
Il convient pour cela de supprimer les tuiles devenues inutiles et de les remplacer par les tuiles devenues nécessaires au fur et à mesure du déplacement.
Sinon, on va vers une saturation assurée.

Si tu fonctionnes déjà comme ça, je ne vois pas pourquoi on a une telle saturation mémoire au début du traitement.

Cordialement
Pulsar33

Bonjour,

J'espère que tes vacances sont agréables !
Pour ton retour, tu as de la lecture dans les messages au-dessus (ne pas lire que le dernier ! Relire au moins à partir du 4 août)
Et je t'en rajoute une couche ... Suite (sans doute) à une mise à jour banale de Mint comme il s'en produit régulièrement, j'ai eu des segmentation fault à chaque lancement.
J'ai alors recompilé comme indiqué ci-dessous et le défaut a disparu. Pourtant j'ai bien du mal à dire ce qu'il a fait vu les indications fournies :

Code:

pulsar33@Minerve:/media/DATA/Workbench/gpx2video/build$ cmake ..
make
-- Configuring done
-- Generating done
-- Build files have been written to: /media/DATA/Workbench/gpx2video/build
Consolidate compiler generated dependencies of target gpxlib
[ 39%] Built target gpxlib
Consolidate compiler generated dependencies of target layoutlib
[ 56%] Built target layoutlib
Consolidate compiler generated dependencies of target gpx2video
[ 94%] Built target gpx2video
Consolidate compiler generated dependencies of target extract-gpx
[ 97%] Built target extract-gpx
Consolidate compiler generated dependencies of target time
[100%] Built target time
pulsar33@Minerve:/media/DATA/Workbench/gpx2video/build$

Est-ce que ceci te semble normal ?
Est-il acceptable de devoir recompiler quand le système évolue légèrement ?
A part linux-header je ne vois pas ce qui peut déclencher ça ni pourquoi ça ferait des segmentation fault

Cordialement
Pulsar33

Hello,

Oui encore plein de petits points à corriger / améliorer.

Pour la cartographie, oui il faut que je construise une portion de la carte et non une énorme image.

Pour le segfault, si une librairie a été mise à jour et que son api a changé, tu es effectivement obligé de re-compiler le projet.

Bonjour,

Merci pour ces confirmations

Concernant les segfault, il serait plus propre de détecter l'absence de la (version de la) librairie attendue et de suggérer la recompilation

Bonne journée
Pulsar33

Hum, désolé, en voila sans doute une nouvelle.

Pulsar33 a écrit:

J'ai commenté en disant que le décalage de 2h était de ma faute mais il semble que non.
Les +0200 du gpx sont totalement ignorés, de même que si on met -0200
Il semble que l'heure affichée soit l'heure en tête de fichier sans offset mais corrigée du décalage actuel du PC.
Bref, pas sûr d'avoir compris mais ça reste obstinément décalé de 2h

@+ Puls