J'utilise énormément ma GoPro Hero9 pour faire du ski, de la rando à ski ou à pied. Cette dernière dispose d'un GPS et de plein d'autres télémétries et la manière "officielle" de l'exploiter est d'utiliser la fameuse application Quick de GoPro, disponible à l'époque que sur téléphone. Malheureusement, la génération de la moindre vidéo prend des heures et surtout, sa gestion du stockage va user rapidement la flash du téléphone. Bref, j'ai à la recherche d'une solution autre, et tant qu'à faire ce peu, sous Linux.
A l'époque, je n'ai pas trouvé grand-chose hormis quelques scripts Python qui étaient bien loin de mes objectifs. Du coup, j'ai décidé de prendre mon clavier et ai créé GPMFMetersGenerator en me basant sur le code open source fourni par GoPro eux-même.
Après quelques années de dev, la version actuelle permet :
- de générer des GPX / KML depuis les videos (il prend en charge automatiquement les multipart).
- de générer des widgets pour la vitesse, la position, l'altitude, … directement depuis les vidéos.
Contrairement à d'autres solutions, ces widgets ne sont pas intégrés directement, mais sont de petites vidéos externes à monter dans votre logiciel d'édition préféré. Le GROS avantage est que vous les placez où vous voulez, comme vous voulez, avec les effets que vous voulez.
Mieux, les versions récentes permettent aussi de regrouper différentes vidéos dans des "stories" : quand on fait une longue rando par exemple, on n'en filme pas son entièreté (la batterie ne supporterait pas de toute façon) mais juste les meilleurs moments. Grace aux stories, les graphiques prendront en compte TOUTE la rando.
La version actuelle, 4.xx, est déjà bien aboutie et correspond bien à mon besoin. Mais il reste plein de choses à améliorer :
- ajout d'une carte de fond
- améliorer l'insertion des vidéos dans les stories (il peut se tromper si vous passez à plusieurs reprises au même endroit)
- ajouter les télémétries manquantes.
- faire une procédure d'installation plus civilisée : pour le moment, c'est vraiment un outil de Geek pour les Geek. Peut-être aussi une IHM serait la bienvenue.
Testé donc avec ma Hero9 (mais devrait fonctionner avec les anciennes jusqu'à la 11) et avec une applie de suivi sur mon téléphone (Décathlon Coach en l'occurrence) sur Gentoo, Arch et Debian. C'est du C++, peu de dépendances donc sans doute pas trop difficilement portable sur d'autres distribs.
Le répo est là et tout le monde est évidemment le bienvenu pour l'améliorer : https://github.com/destroyedlolo/GPMFMetersGenerator.
Et le résultat peut être vu sur les quelques vidéos de ma chaine Youtube.
# Pas libre?
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Pourquoi avoir choisi une licence non libre ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas libre?
Posté par jihele . Évalué à 2.
C'est expliqué en bas du README :
Je suppose que tu l'as vu et que tu cherches à ouvrir le débat.
[^] # Re: Pas libre?
Posté par Psychofox (Mastodon) . Évalué à 3.
N'est-ce pas à ça que sert la license GPL?
[^] # Re: Pas libre?
Posté par BAud (site web personnel) . Évalué à 5.
moui il fait bien ce qu'il veut, il ne prétend pas que c'est libre, même si ça limitera in fine les contributions (de GoPro notamment, le NC étant notoirement incompatible avec une activité commerciale :D).
Cela reste compatible avec la licence MIT retenue par GoPro pour ses API : https://github.com/gopro/OpenGoPro
Pour rajouter des fonds de carte OSM, il faudrait de toute façon indiquer les licences distinctes selon les différents éléments…
[^] # Re: Pas libre?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Je ne comprends pas abuse open source developers kindness: un développeur qui choisit une licence privatrice n'est ni opensource, ni gentil, mais on peut toujours en abuser :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas libre?
Posté par Destroyedlolo (site web personnel) . Évalué à 2.
Ben j'ai bossé pendant 10 ans pour une ESN dont 9/10 du "business model" était de vendre à prix d'or de l'open-source. Là-dessus, pas grand-chose à redire vu que c'est prévu par la licence.
Là ou par contre, c'est affligeant, c'est que les améliorations sont toujours restées en interne, qu'on n'avait même pas le droit de contribuer ou même simplement de fournir des solutions quand on trouvait des bugs … car "c'est notre IP", franchement non.
[^] # Re: Pas libre?
Posté par BAud (site web personnel) . Évalué à 4.
oh bah, ça…
spa comme si des gens comme webMethods revendaient de « l'intégration » (relativement réussie on va dire…) composée de projets Apache à 90% (voire plus) pour la partie interopérabilité. On va dire que les 10 derniers pourcents valaient le « coût ».
Ce n'est pas pour rien àmha que WSO2 — même si c'est IBM — a désormais un peu plus le vent en poupe chez certains clients qui souhaitent maîtriser les échanges au sein de leur SI… et certains pondent même des indicateurs contractuels correspondant aux remontées upstream (donc au projet amont) à leurs fournisseurs lorsque la solution proposée est basée sur des briques libres. Cela va dans le bon sens de la roue de Deming : cela va dans le sens de l'amélioration commune, plutôt qu'un pré-carré qui va finir par s'effondrer (c'est un minimum local par nature qui va finir par coûter plus cher à maintenir des patchs spécifiques, moins manœuvrant, moins réactifs, comme cela s'est vu aussi par moments avec grsecurity…).
Heureusement qu'il est maintenant plus facile pour la doc' de déployer de l'Alfresco (resté relativement libre) que du Documentum (racheté par son outsider puis avalé par un mastodonte o_O même si je n'ai pas tout suivi…), et des exemples comme ça, je commence à en avoir à la pelle ;-)
ça c'est ballot : c'est tout de même moins cher de faire maintenir ses patchs par quelqu'un d'autre (donc en amont) pour éviter de faire tourner une CI/CD de plus en plus spécifique, alors qu'elle aussi pourrait tourner en amont : ça coûtera moins cher à tout le monde, sera plus réactif (moins d'étapes), le client pourra être plus satisfait d'être facturé le même prix — sauf si ses demandes spécifiques sont trop spécifiques :p (l'occasion de jouer son rôle de conseil ou lui facturer le spécifique, eh oh hein bon, business as usual :p)
[^] # Re: Pas libre?
Posté par Destroyedlolo (site web personnel) . Évalué à 0.
Héhé, ca tombe bien, ca fait partie des domaines d'expertise de la suite d'intégration depuis la V6 : si j'aime bien le concept que j'ai d'ailleurs repris dans ma solution domotique, c'était (… ok, c'est) vraiment la galère pour obtenir quelque chose de stable. Mais bon, comme disait l'un de mes collègue : "ca fait manger" :)
Ha, mais 100% d'accord. Mais surtout, je trouve affligeant qu'on fasse une marge pas possible sur du code donnée "gratuitement" mais en refusant de participer d'une manière ou d'une autre.
Ceci dit, ce n'est pas un problème nouveau : on avait eu le même genre de discussion quand, ado, je développais des DPs pour Amiga et où des boites revendraient largement au-dessus du prix de la distribution. Mais a l'époque, on ne s'embêtait pas les définitions actuelles d'open-source : gratos, c'étais gratos. Pas d'utilisation commerciale, point.
[^] # Re: Pas libre?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
C'est quoi le problème avec l'utilisation commerciale des logiciels libres ?
Encore une inversion des valeurs ? La gauche libriste est pro business tandis que la droite privatrice est pour le non commercial :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# todo et à venir
Posté par BAud (site web personnel) . Évalué à 3. Dernière modification le 03 juillet 2024 à 11:50.
À lire https://github.com/destroyedlolo/GPMFMetersGenerator?tab=readme-ov-file#todo-list j'imagine que ce qui est coché est déjà réalisé ? (peut-être à améliorer ?)
Une bonne pratique est d'avoir un fichier TODO (ou CONTRIBUTIONS/CONTRIBUTING) et pour chaque proposition un lien vers une entrée de demande (quitte à être sur github autant utiliser https://github.com/destroyedlolo/GPMFMetersGenerator/issues :p), permettant de faire le lien avec des pull requests ou des branches en cours.
Déjà l'affichage dans le README permet d'indiquer des priorités, en plus selon la méthode MoSCoW ce qui est encore mieux ;-)
Sympathique projet en tout cas ; même s'il y aurait des tournures à revoir (pas mal de
s/took/taken/gmais pas que…), bel effort d'avoir une présentation en anglais et avec des exemples illustratifs.[^] # Re: todo et à venir
Posté par Destroyedlolo (site web personnel) . Évalué à 2.
Merci pour tes commentaires.
En effet, je viens de passer le ReadMe dans l'excellent languagetool.org et c'est pathétique … Je corrigerai lors de la prochaine maj (je suis sur autre chose pour le moment).
[^] # Re: todo et à venir
Posté par BAud (site web personnel) . Évalué à 2.
mieux vaut se faire relire par un language native… je puis corriger quelques tournures
si tu acceptes les patchs sous licence MIT, je veux bien collaborer
bin les issues de github permettent de gérer les sujets à traiter (le reste à faire, la TODO évoquée…)
les branches proposées par git sont plutôt bien gérées par github, permettant de forker et proposer des améliorations, ça laisse libre le projet d'évoluer sans toi puis être intégrées au produit principal… à toi de choisir
[^] # Re: todo et à venir
Posté par Destroyedlolo (site web personnel) . Évalué à 1.
Avec plaisir :)
Pour peu que je puisse merger sans être obligé d'autoriser une utilisation commerciale de mon code sans m'en référer.
ps: quand je parlais "d'autres choses", c'est que je suis en train de moderniser ma domotique dont les composants sont dans d'autres projets de mon hub (Marcel, Majordome, Selene, …) dont je parlerais sans doute une autre fois … mais donc les docs sont tout aussi pitoyables. C'est ma priorité du moment avant mon départ en vacances (faut savoir se donner des objectifs :) ).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.