GoPro & Linux

Le voici
@+ Puls

Je t'ai rajouter des options non documentées pour les paramètres d'encoding :

--video-bitrate = 16 000 000 // 16 MB
--video-max-bitrate = 32 000 000 // 32 MB
--video-min-bitrate = 0 // 0 MB

C'est les valeurs par défaut si tu ne mets rien.

Si tu veux un bitrate constant, min = max.

Enfin, j'ai renommé le paramètre "rate" en "telemetry-rate".

Pour faire tes comparaisons de perf, ça sera plus facile et surtout plus juste. Car chez moi je travaille en 2.7K et gpx2video a des perf proche de ffmpeg (ce qui est plutôt logique puisque je suis basé sur ffmpeg).

Je n'arrive pas à passer ces nouvelles options malgré plusieurs essais de syntaxe.
Quelle est la syntaxe exacte pour un bitrate min et max de 2249 kb/s par exemple et faut-il définir les 3 si min = max ou bien définir min et max suffit ?

Merci
@+ Puls

Pulsar33 a écrit:

Je n'arrive pas à passer ces nouvelles options malgré plusieurs essais de syntaxe.
Quelle est la syntaxe exacte pour un bitrate min et max de 2249 kb/s par exemple et faut-il définir les 3 si min = max ou bien définir min et max suffit ?

C'est corrigé

Code:

--video-bitrate=2249000
--video-min-bitrate=2249000
--video-max-bitrate=2249000

Là ça fonctionne et j'ai bien le bon bit rate
En revanche, je n'ai pas l'impression que ça change grand chose niveau performance.
Je vais lancer un génération intégrale pour mesurer.

Bonne soirée
Pulsar33

PS :
Du coup, c'est --telemetry 3 ou bien --telemetry=3 ?
J'utilise la première formulation depuis toujours

Pulsar33 a écrit:

Là ça fonctionne et j'ai bien le bon bit rate
En revanche, je n'ai pas l'impression que ça change grand chose niveau performance.
Je vais lancer un génération intégrale pour mesurer.

Rien que les accès disque pour écrire plusieurs Go devraient coûter du temps !

Pulsar33 a écrit:

PS :
Du coup, c'est --telemetry 3 ou bien --telemetry=3 ?
J'utilise la première formulation depuis toujours

Comme tu veux, ça s'appuie sur la libc... du coup plusieurs syntaxes possibles.

Correction du problème concernant le manque de tuiles

La génération par la commande video prend le même temps quel que soit le bitrate demandé.
Les accès disques sont masqués par les traitements.
La vidéo obtenue fait bien la taille attendue compte tenu du bitrate imposé.
Bravo pour les options video-bitrate, c'est une avancée utile !

Pour la correction des tuiles, je te fais un retour dès que possible

Bonne nuit
Pulsar33

Bonjour,

A l'Est c'est corrigé, mais au Nord (17h52) et au Sud (18h21) ça ne l'est pas, désolé
A l'Ouest, je n'ai jamais vu le problème mais ça ne veut pas dire qu'il n'existe pas

Bon courage pour la recherche
Pulsar33

Pulsar33 a écrit:

A l'Est c'est corrigé, mais au Nord (17h52) et au Sud (18h21) ça ne l'est pas, désolé
A l'Ouest, je n'ai jamais vu le problème mais ça ne veut pas dire qu'il n'existe pas

C'est enfin corrigé !

 je lance la génération complète en mode video et je reviens dans ... 3h

Bravo pour tes efforts
Pulsar33

PS : pour info
Comme départ et arrivée sont souvent confondus, j'ai essayé de changer start et end en drapeaux asymétriques, mais il y a toujours des cas où ça ne va pas.
Finalement, j'ai mis une opacité à 66% sur tes fichiers et c'est pas mal je trouve. Du moins ça répond à mon besoin.

Bonsoir,

C'est donc bien corrigé pour les tuiles et la danse verticale il me semble.
En revanche, la correction des textes a introduit de nouveaux défauts, visibles au moins en 576p :
- Les textes sont ancrés trop haut (par rapport au logo et au fond semi-transparent) si le label n'est pas affiché.
- S'il est affiché, l'ensemble label + valeur semble être centré correctement en vertical
- En revanche, le label est compressé contre la valeur et plus petit qu'elle

Mise à jour de mes constats :
- BUG : perte systématique de la piste sonore du milieu de la vidéo jusqu'à la fin (qu'on arrête l'encodage ou qu'on le laisse terminer)
- BUG : les commandes image et video doivent générer des images de largeur=(DAR x Height) et de hauteur=Height (Width doit être ignoré)
- BUG : le dessin de la symbologie ne doit pas dépendre du format W x H de sortie. Actuellement, elle est déformée si le DAR n'est pas 5/4.
- BUG : Les textes sont ancrés trop haut si le label n'est pas affiché. Le label est écrasé contre la valeur sinon (test fait en 576p)
- Option : Zoom automatique en fonction de la vitesse (4 paramètres) : (Zmax,Zmin) = F(Vmin,Vmax) (augmenter la portée quand on va vite)
- Option : Utilisation au choix un gpx ou un csv au format que tu génères y compris avec l'option --rate

- perte (pseudo)aléatoire de certains widgets (pente, vitesse, durée) visiblement calculés par différence => corrigé
- le fond vert n'est présent que sur la première image (testé seulement en 576p) en mode image => corrigé
- le fond vert avec alpha à 00 sur les widgets est satisfaisant mais incohérente du mode video => corrigé, alpha = FF
- effet pervers sur les fonds de contraste (gris semi-transparent de la génération sur fond vert => désormais sans objet
- finesse de la trace dans la map fonction de la résolution de la vidéo (actuellement pâteuse en 576p) => paramétrable, ok
- option rendu sur fond vert dans l'espoir de booster notablement les performances => solution partielle via image puis ffmpeg
- cercler l'icone vélo de jaune (surtout la pointe) au lieu de bleu (actuellement même couleur que la trace) => ok, assets modifiables
- option incrustation sans légende ni symbole => ok grâce à with-label et with-picto
- variation saccadée au passage des secondes sur la pente et la vitesse => corrigé
- Nota : Le post-traitement nécessaire du csv est très lourd => inutile
- Option --lang fre ou -- lang eng pour la génération du csv => utiliser le choix de la lange anglaise lors de l'import
- La taille du fichier de sortie en mode video est élevée => gestion du bitrate ajoutée : ok
- BUG : certaines tuiles manquent à droite, en haut et en bas (factor 0.3) => corrigé
- BUG : les textes de la symbologie "dansent" verticalement de façon asynchrone indéfinie => corrigé

Nota : Les markers font 132x200, il ne faut pas changer leur taille. Le point d'ancrage est situé à 66 x 175
Nota : Mettre une transparence à 66% sur les markers améliore leur rendu en cas de superposition
Nota : L'importation du csv sous Libreoffice sature à 65536 lignes soit une vidéo de 43 minutes
Nota : [mode image fond vert + génération vidéo + chroma key sous Kdenlive] qualité inférieure à [mode video]
Nota : [mode image transparente + incrustation directe par ffmpeg] 4 fois plus rapide que mode video pour une qualité identique
Question : La variation à la seconde s'avère acceptable. Que se passe-t-il avec un gpx ou un csv ayant une fréquence plus élevée ?

@+ Puls

Je viens de mettre en ligne quelques optimisations de rendu.

Je serai curieux de connaître le gain chez toi.

Je teste ça dans la soirée
@+ Puls

Je laisse aller au bout mais je pense que tu as gagné un facteur entre 2 et 3  

Euh ... La première seconde, il n'y a ni carte ni textes

@+ Puls

Pulsar33 a écrit:

Je laisse aller au bout mais je pense que tu as gagné un facteur entre 2 et 3  

Euh ... La première seconde, il n'y a ni carte ni textes

Oui, c'est en cours... je voulais déjà avoir un retour au niveau perf

Parce que en 2.7K & 50 fps, ça fait un joli gain.

Je pense que je peux gagner encore un peu ; et ensuite ça sera via accélération hardware...

Bonsoir,

Pas eu le temps de vérifier la vidéo mais le timing est de 00:59:13 au lieu de 02:30:52
Soit un facteur 2.5 de gagné. Bravo !!!

La durée de traitement est inférieure à la durée de la vidéo originale, ça commence à sentir bon

Bonne soirée
Pulsar33

Hello,

En ligne une refonte de la gestion de la taille du texte dans les widgets.

Un nouveau paramètre "text-lineheight" qui permet de définir l'espace entre le label et la valeur dans un widget.

gpx2video utilise le max d'espace vertical disponible dans un widget pour afficher le texte. A l'utilisateur d'ajuster la largeur du widget.

Bonjour,

Sans label, c'est (corrigé) beaucoup mieux. Le texte est centré et de taille tout à fait cohérente avec celle du widget, et cela sans définir text-lineheight

Avec label :
J'ai essayé 0, 1, 8, 10, 20, 30 comme valeurs, ça change l'écart en effet
Mais selon text-lineheight tout devient minuscule (même avec 0)
Avant on arrivait à loger un label de taille moyenne et un texte de taille un peu plus grande (non paramétrables).
Voir la comparaison et encore, c'est ce que j'arrive à faire de mieux.

Je ne comprends pas.

En fait, c'est pas le line-height qu'on définit mais l’intervalle entre les lignes si j'ai bien compris
C'est quoi la valeur par défaut et l'unité ? Pour un widget de 40 de haut, quelle est la valeur raisonnable ?

@+ Puls

line height, C'est interligne.

Ça correspond à l'espace entre le label et la valeur.

Attention, il y a aussi le padding-top et le padding-bottom (padding modifie tout)

Si padding = 0 et line height = 0, alors le label et la valeur occupe tout l'espace

Regarde la comparaison
J'ai toujours fonctionné avec padding=10 et j'avais le résultat de droite
Je ne comprends pas pourquoi tout devient riquiqui sans rien changer
Quelle est la valeur pas défaut du text-height ?
Le padding joue aussi sur la position du symbole dans le widget ?

@+ Puls

Ok, en mettant un padding à 0 ou à 2 je vais peut-être retrouver quelque chose de similaire
@+ Puls

PS : padding 3 et text-height 6 c'est bon

PPS : in english, interligne semble être "line spacing" alors que text-height est littéralement la hauteur du texte

Pulsar33 a écrit:

Ok, en mettant un padding à 0 ou à 2 je vais peut-être retrouver quelque chose de similaire
@+ Puls

PS : padding 3 et text-height 6 c'est bon

Oui, pour retrouver ce que tu avais avant, c'est un peu différent. Mais maintenant, c'est correct. Avant ça n'allait pas.

Je vais peut-être ajouter un paramètre pour définir un ratio entre la taille du label et celui de la valeur. Aujourd'hui c'est 2/3.

J'ai fait une génération intégrale de Jonzac02, je trouve que les textes sont plus "percutants" qu'avant.
Je ne trouve pas d'autre mot pour exprimer mon ressenti, c'est très joli.

Je te livre en vrac une idée qui vient de me venir : pourquoi ne pas rajouter un widget "profil du trajet" (style coupe tour de France) ?

Bonne soirée
Pulsar33

Pulsar33 a écrit:

Je te livre en vrac une idée qui vient de me venir : pourquoi ne pas rajouter un widget "profil du trajet" (style coupe tour de France) ?

Oui, il faut que j’étudies une solution pour faire des widgets graphiques avec des compteurs, des graphes...