GoPro & Linux

Bonjour,

Attention, on a changé de page. As-tu lu mon message précédent ?

Voici un autre BUG, bien étrange :


Pourtant, j'utilise le même layout que pour la vidéo précédente qui elle, ne souffre pas de ce manque de tuiles

Code:

<map width="240" height="140" position="top" display="true">
        <source>1</source>
        <zoom>18</zoom>
        <factor>0.3</factor>
        <marker>30</marker>
 <margin-left>8</margin-left>
 <margin-right>8</margin-right>
 <margin-top>12</margin-top>
 <margin-bottom>0</margin-bottom>
        <border>1</border>
        <border-color>#000000ff</border-color>
        <path-thick>1.0</path-thick>
        <path-border>0.33</path-border>
 </map>

Code:

/media/DATA/Workbench/gpx2video/build/gpx2video -q -m Jonzac02O.mp4 -g Jonzac02-VGO.gpx -l layout576p04TP.xml --telemetry 3 -o Jonzac02-VGO.mp4 video
gpx2video v0.0.0
Parsing 'layout576p04TP.xml' layout file
  Download tile 2280 / 2280 [##################################################] DONE

Nota : un clear du cache ne change rien

Bonne recherche !
Pulsar33

Arrr... tu vas plus vite que moi

Bon je viens de corriger 2-3 trucs. J'utilise la librairie OpenImageIO pour "dessiner" sur la vidéo.

Mais je n'étais pas content de son implémentation de la gestion du rendu pour le texte. J'ai donc ré-implémenté cette partie.

1°/
A présent, ça gère le rendu du texte avec un fond shadow ou non et qui supporte la transparence. Et ça fonctionne de la même manière en rendu vidéo et en rendu image.

Ca devrait corriger ton problème de rendu de widget.

De plus, cela va maintenant me permettre de faire une optimisation lors des rendus et gagner en perf !
Refaire le rendu à chaque changement (donc toutes les secondes au pire) et non à chaque frame comme actuellement.

2°/
J'en ai profiter pour corriger le support UTF-8 et du coup, ça supporte les caractères accentués et en fait tous les caractères utf-8.... y compris le mandarin, le russe...
Bien veiller à utiliser une font qui supporte ces caractères.

Pour le manque de tuiles, je vais regarder. Mais avec un factor à 0.3 et un zoom à 18, tu pourrais passer à un zoom de 16 ou 17 et mettre un factor plus proche de 1.0.

Ca fera moins de tuiles et donc une image plus petite (et donc un gain en perf). => tu as tout de même 2280 tuiles de 256x256 à assembler.

Bravo pour les textes, ça semble en effet beaucoup plus joli. Je teste prochainement.

Pour zoom et factor, j'en suis arrivé à ce choix par de nombreux tâtonnements. Ce n'est pas évident de comprendre de cette manière où sont les limites.
Comme je te le disais, dans un système cartographique, on utilise deux notions :
- l'échelle, qui de tout temps a définit le niveau de détail et est associée à une portée. C'est ce que tu sembles appeler zoom
- le zoom, qui n'existe que depuis l'apparition des cartes numériques, et qui définit le grossissement à niveau de détail constant (c'est la "loupe" du cartographe). C'est ce que tu sembles appeler factor.

En fonction de l'échelle pour une portée donnée, il faut bien sûr charger plus ou moins de tuiles et payer le prix de leur traitement.
Je dispose par exemple de l'intégralité de la carte de France à l'échelle 1/25000 ième et cela correspond à 180 CD-Roms !
Aujourd'hui, c'est une taille raisonnable par rapport aux capacités de stockage courantes mais à l'époque où je les ai obtenus, c'était énorme.

J'ai préféré avoir un "zoom" (une échelle) fort et un "factor" (un zoom) très faible (on dit un dézoom fort) parce que la qualité du rendu graphique est suffisante pour augmenter le niveau de détail par rapport aux valeurs que tu proposes dans tes exemples.
Il y a une limite au dézoom (surtout si on met en route le dézoom automatique en fonction de la vitesse). Autant on peut zoomer à l'infini (on ne verra plus qu'une couleur unie), autant on ne peut dézoomer que tant qu'on a des tuiles.

Ceci étant posé, cela n'explique pas pourquoi sur Jonzac04 je n'ai pas le problème alors que je l'ai sur Jonzac02 tout en utilisant les mêmes réglages.
Cela signifie donc qu'il manque la prise en compte de l'un des facteurs (sans doute le "factor") dans la détermination des tuiles à charger et que dans Jonzac02, je m'approche plus des "bords" de la zone chargée que dans Jonzac04.
En d'autres termes, le trajet relativement aux tuiles chargées compte aussi (il n'y a pas assez de marge).

J'espère que ça peut aider
Pulsar33

Oups, aucun texte en mode image.
Est-ce que ça compile sans prévenir s'il me manque des dépendances ?
Normalement non !
C'est quoi le problème ?

@+ Puls

Pulsar33 a écrit:

Oups, aucun texte en mode image.
Est-ce que ça compile sans prévenir s'il me manque des dépendances ?
Normalement non !
C'est quoi le problème ?

Dans certains cas je dois faire une "make clean" et tout rebuilder.

Pulsar33 a écrit:

Pour zoom et factor, j'en suis arrivé à ce choix par de nombreux tâtonnements. Ce n'est pas évident de comprendre de cette manière où sont les limites.

[...]

J'ai préféré avoir un "zoom" (une échelle) fort et un "factor" (un zoom) très faible (on dit un dézoom fort)  parce que la qualité du rendu graphique est suffisante pour augmenter le niveau de détail par rapport aux valeurs que tu proposes dans tes exemples.

C'est tout à fait cela, les serveurs de carto fournissent plusieurs niveaux de zoom (détails) de leur carte.

La loupe "factor" permet de zoomer/dezoomer lors du rendu sans changer le niveau de détail

Dans ton cas, je ne sais pas si tu es si gagnant, car les détails vont devenir illisibles (trop petit) notamment les noms de ville, rue...

De plus appliquer un factor différent de 1, réduit forcément la qualité de l'image (encore pire si c'est un agrandissement)

Dans tous les cas, je vais vérifier ce qui cloche pour le manque de tuiles. J'avais prévu les marges. J'ai dû louper un truc.

Re-Oups !
J'ai compris pour le mode image : il faut maintenant mettre Alpha à FF ! Bravo !
C'est beaucoup plus joli. Il faut maintenant que je fasse l'incrustation avec Kdenlive.

@+ Puls

progweb a écrit:

Dans ton cas, je ne sais pas si tu es si gagnant, car les détails vont devenir illisibles (trop petit) notamment les noms de ville, rue...

Comme je le disais, la qualité du rendu graphique est suffisante pour augmenter le niveau de détail par rapport aux valeurs que tu proposes dans tes exemples et cela même en 576p de mon point de vue
Et puis je ne désespère pas que tu ajoutes le zoom automatique en fonction de la vitesse.
Un subtil choix de zoom, de factor et des paramètres de la fonction zoom automatique devrait faire merveille.

@+ Puls

Bonsoir,

BUG : les écritures "dansent" verticalement. (très visible sur la durée, aussi sur la vitesse ...)
C'est difficile à voir avec la commande vidéo car le fond bouge mais facile à voir avec la commande image, surtout si on met un framerate de 10
Voici la vidéo que je viens de générer

Bonne soirée
Pulsar33

Bien vu

Avec des vidéos en 4k ça ne doit pas trop se voir

Bonjour,

Je n'arrive pas à faire mieux que ça avec le fond vert (en 576p, comme d'habitude).
On voit nettement que c'est moins joli qu'avec la commande video


Reste à mesurer le gain de temps effectif sur un exemple complet
Et peut-être aussi à faire un essai en 1080p ...

Bon dimanche
Pulsar33

Et pourquoi utiliser un fond vert. Utiliser des png transparents, ça me paraît plus simple.

Parce que Insérer les images une par une dans Kdenlive est bien trop laborieux.
L'idée est d'assembler via ffmpeg les images en une vidéo qui sera incrustée à la vidéo d'origine en utilisant la fonction chroma key.
Le vert s'est imposé comme couleur la plus logique pour cette fonction, même si ce n'est pas la seule (à l'origine, c'était le bleu).
En revanche, le noir pose problème car il apparaît souvent dans les vidéos et provoque donc des "trous".
Or lorsqu'on assemble des png transparents en une vidéo, le fond de celle-ci est noir ...

Après, je n'ai pas essayé d'incruster directement image par image avec ffmpeg.
Cela doit pouvoir se faire et du coup sans recourir à la fonction chroma key.
Si ça fonctionne, on devrait gagner sur tous les tableaux (vitesse de réalisation et qualité)

@+ Puls

 Je l'ai !

Code:

ffmpeg -i Jonzac02O.mp4 -framerate 1 -pattern_type glob -i "png/image-*.png" -filter_complex "[1:v][0:v]scale2ref=iw:ih[ovr][base]; [ovr]colorchannelmixer=aa=1.0[ovrl]; [base][ovrl]overlay[v]" -map [v] -map 0:a result.mp4

Test en cours mais ça semble être top (incrustations propres, son intégral, durée des traitements)

Bonne soirée
Pulsar33

Bonsoir,

Mode image png transparents : 8 minutes pour une vidéo de 72 minutes

Code:

./gpx2video -q -m original.mp4 -g original.gpx -l layout.xml --telemetry 3 -o png/image-XXXXXX.png image

Incrustation par ffmpeg : 30 minutes

Code:

ffmpeg -i original.mp4 -framerate 1 -pattern_type glob -i "png/image-*.png" -filter_complex "[1:v][0:v]scale2ref=iw:ih[ovr][base]; [ovr]colorchannelmixer=aa=1.0[ovrl]; [base][ovrl]overlay[v]" -map [v] -map 0:a resultat.mp4

Total : 38 minutes pour 72 minutes soit x1.9
En première estimation, c'est 6 fois plus rapide que le Mode Vidéo. La qualité des incrustations est identique. Le son est recopié directement en intégralité.

En revanche, il semble qu'il manque des images, la "durée" ne varie pas d'une seconde à chaque image.
Du coup, j'ai pas loin de 5 à 6 secondes de décalage à l'arrivée sur 72 minutes alors que le début est parfaitement calé.
Tu peux vérifier cela directement sur les images générées ...

Il me reste à faire le traitement intégral en Mode Video pour comparer et confirmer le gain de 6

Bonne soirée
Pulsar33

Edit Pulsar33 :
Il y a bien le bon nombre d'images, ce qui n'explique pas pourquoi la durée évolue parfois curieusement, ce que tu peux vérifier
Je ne comprends pas non plus pour l'instant le décalage de quelques secondes en fin de vidéo.
Je verrai si le traitement par la commande video a le même problème (traitement en cours)

Tout d'abord, je teste :

Code:

./gpx2video -g Jonzac04O-VG.gpx  -m Jonzac04T-6minutes.mp4 -l layout-my.xml  --output test.csv --telemetry 3 compute

Puis

Code:

./gpx2video -g Jonzac04O-VG.gpx  -m Jonzac04T-6minutes.mp4 -l layout-my.xml  --output test.csv --telemetry 3 --rate 25 compute

dans les 2 cas, j'ai bien le bon nombre de points (il peut manquer le 1er ou le dernier point...) à savoir 5080, qui correspond à 1h24min40sec.

Pulsar33 a écrit:

Mode image png transparents : 8 minutes pour une vidéo de 72 minutes

Code:

./gpx2video -q -m original.mp4 -g original.gpx -l layout.xml --telemetry 3 -o png/image-XXXXXX.png image

J'obtiens bien 5080 images (puisque 1 par seconde).

Note: bien sûr si j'ajoute l'offset de 9s (9000ms) je perds les 9 premières secondes et donc les 9 premières frames.

Le widget durée sur la dernière image affiche bien 1h24min39sec et l'heure est cohérente.

/!\ J'ai modifié localement le code pour générer les images sur tout le CSV (et non seulement sur le durée correspondante à la vidéo... sinon je n'ai que 6 minutes.

Pulsar33 a écrit:

Incrustation par ffmpeg : 30 minutes

Code:

ffmpeg -i original.mp4 -framerate 1 -pattern_type glob -i "png/image-*.png" -filter_complex "[1:v][0:v]scale2ref=iw:ih[ovr][base]; [ovr]colorchannelmixer=aa=1.0[ovrl]; [base][ovrl]overlay[v]" -map [v] -map 0:a resultat.mp4

Total : 38 minutes pour 72 minutes soit x1.9
En première estimation, c'est 6 fois plus rapide que le Mode Vidéo. La qualité des incrustations est identique. Le son est recopié directement en intégralité.

Intéressant !

Ici ta commande ffmpeg n'utilise pas l'accélération hardware.

Pulsar33 a écrit:

En revanche, il semble qu'il manque des images, la "durée" ne varie pas d'une seconde à chaque image.
Du coup, j'ai pas loin de 5 à 6 secondes de décalage à l'arrivée sur 72 minutes alors que le début est parfaitement calé.
Tu peux vérifier cela directement sur les images générées ...

Pulsar33 a écrit:

Il me reste à faire le traitement intégral en Mode Video pour comparer et confirmer le gain de 6

Il faudra voir la différence de temps une fois que j'aurai fait les optimisations concernant le rendu.

Pulsar33 a écrit:

Re-Oups !
J'ai compris pour le mode image : il faut maintenant mettre Alpha à FF ! Bravo !
C'est beaucoup plus joli. Il faut maintenant que je fasse l'incrustation avec Kdenlive.

Oui d'ailleurs, tu peux avoir le texte transparent maintenant (en mettant autre chose que ff)

Quand tu mets rien, ça doit mettre 0... du coup invisible, je vais corriger cela en mettant ff par défaut.

Désolé de t'avoir attiré sur une fausse piste avec le nombre d'images. J'ai indiqué mes doutes dès que j'ai pu en barrant et éditant mon message plus haut.
Je viens de terminer l'encodage avec la commande video et j'ai exactement le même décalage en fin de trajet.
Je pense (je crains) que ce ne soit dû à la conversion 60 Hz => 50 Hz que j'ai faite lorsque j'ai récupéré la vidéo d'origine de la caméra.
Il faudra que je travaille ce sujet et tu n'y es pour rien.

En revanche, la durée qui parfois ne varie pas de une seconde d'une image à l'autre, c'est louche ...

L'encodage avec la commande video vient de se terminer et il est confirmé que toutes choses égales par ailleurs, on peut gagner un facteur 4
Pour convenance personnelle, je dois même ajouter une durée de recodage du résultat (tes choix de paramètres d'encodage ne sont pas réglables)
En effet, en mode video j'obtiens plus de 9 Go là où je n'ai que 1.2 Go sur la vidéo incrustée des images via ffmpeg

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 : certaines tuiles manquent à droite, en haut et en bas lorsque la position courante approche les bords de la zone (factor 0.3)
- BUG : les textes de la symbologie "dansent" verticalement de façon asynchrone indéfinie
- 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.
- 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
- 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 ?

- 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 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

Nota : Les markers font 132x200, il ne faut pas changer leur taille. Le point d'ancrage est situé à 66 x 175
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

@+ Puls

Pulsar33 a écrit:

En revanche, la durée qui parfois ne varie pas de une seconde d'une image à l'autre, c'est louche ...

Peut-être un problème d'arrondi...

Pulsar33 a écrit:

L'encodage avec la commande video vient de se terminer et il est confirmé que toutes choses égales par ailleurs, on peut gagner un facteur 4
Pour convenance personnelle, je dois même ajouter une durée de recodage du résultat (tes choix de paramètres d'encodage ne sont pas réglables)
En effet, en mode video j'obtiens plus de 9 Go là où je n'ai que 1.2 Go sur la vidéo incrustée des images via ffmpeg

Pour l'instant, on ne peut pas choisir les paramètres d'encodage. Je reprends ceux de l'original.

Si chez toi, ça génère une vidéo de 9Go... ce n'est dû coup plus un problème de performances. Mais surtout un problème de paramètres pour l'encodage.

Pulsar33 a écrit:

- 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 : certaines tuiles manquent à droite, en haut et en bas lorsque la position courante approche les bords de la zone (factor 0.3)
- BUG : les textes de la symbologie "dansent" verticalement de façon asynchrone indéfinie
- 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.
- 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

Je vais m'attaquer dans l'ordre :
- à la danse du texte
- tuiles manquantes
- optimisation du temps de rendu (hors accélération matérielle)
- gestion du paramètre DAR
- gestion des vidéos avec orientation (portrait...)

Pulsar33 a écrit:

- 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 ?

Je vais faire en sorte de pouvoir configurer l'échantiollonage... Je vais renommer l'option "rate" en "telemetry-rate" et garder "rate" pour le rendu vidéo lui-même.

Si on a un point toutes les secondes (exact), le paramètre filtre n'aura aucune incidence, puisqu'aucun point ne sera "prédit" lors des calculs

Si les points sont à fréquence élevée, les filtres n'auront pas d'incidence. Et tous les points seront utilisés pour les calculs. Mais au niveau de l'affichage, ça sera mis à jour seulement toutes les secondes.

Si les points sont à fréquence faible, les filtres sont utilisés pour faire de l'interpolation à une fréquence de 1 seconde, Ca évite ainsi les sauts visuels.

Pour les tuiles manquantes, je n'arrive pas à reproduire ton problème.

Mais j'ai l'impression que je n'ai pas le même GPX que toi.

Avec les paramètres zoom & factor, je ne télécharge que 513 tuiles...

De plus, là où il te manque des tuiles, ce n'est pas le bord de la trace (enfin sur ma version de GPX)

As-tu essayer de générer la carte :

Code:

./gpx2video -g Jonzac04O-VG.gpx  -m Jonzac04T-6minutes.mp4 -l layout-my.xml --offset 9000 --duration 1000 --output test.png --map-source 1 --map-zoom 18 --map-factor 0.3 --telemetry 3 track

Avec la commande "track", je n'utilise pas le fichier "layout.xml", il faut donc indiquer les paramètres de la map sur la ligne de commande. Je vais d'ailleurs ajouter les paramètres pour l'épaisseur de la trace...

Merci pour tes réponses et le travail accompli ou à venir
Je suis d'accord sauf pour :

progweb a écrit:

Pour l'instant, on ne peut pas choisir les paramètres d'encodage. Je reprends ceux de l'original.

Renseignements sur Jonzac02 qui m'a servi à valider les derniers traitements :
Les paramètres d'encodage ne sont pas indiqués dans ma vidéo d'origine. Je peux éventuellement retrouver la commande que j'ai lancée à l'époque si nécessaire. Mediainfo indique :

Code:

Format profile                          : Simple@L1
Format settings, BVOP                    : No
Format settings, QPel                    : No
Format settings, GMC                    : No warppoints
Format settings, Matrix                  : Default (H.263)
Codec ID                                : mp4v-20
Duration                                : 1 h 12 min
Bit rate mode                            : Constant
Bit rate                                : 4 057 kb/s
Width                                    : 720 pixels
Height                                  : 576 pixels
Display aspect ratio                    : 16:9
Frame rate mode                          : Constant
Frame rate                              : 25.000 FPS
Standard                                : PAL
Color space                              : YUV
Chroma subsampling                      : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Compression mode                        : Lossy
Bits/(Pixel*Frame)                      : 0.391
Stream size                              : 2.04 GiB (97%)
Writing library                          : Lavc54.59.100

La vidéo que tu génères avec la commande video est renseignée comme suit :

Code:

Format                                  : AVC
Format/Info                              : Advanced Video Codec
Format profile                          : High@L4.1
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                  : Yes
Format settings, Reference frames        : 4 frames
Codec ID                                : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                : 1 h 12 min
Bit rate                                : 18.3 Mb/s
Nominal bit rate                        : 32.0 Mb/s
Maximum bit rate                        : 32.0 Mb/s
Width                                    : 720 pixels
Height                                  : 576 pixels
Display aspect ratio                    : 16:9
Frame rate mode                          : Constant
Frame rate                              : 25.000 FPS
Standard                                : PAL
Color space                              : YUV
Chroma subsampling                      : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                      : 1.765
Stream size                              : 9.22 GiB (100%)
Writing library                          : x264 core 163 r3060 5db6aa6
Encoding settings                        : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=cbr / mbtree=1 / bitrate=32000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=32000 / vbv_bufsize=2000 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00

La vidéo que je génère en incrustant directement les png transparents dans la vidéo d'origine est renseignée comme suit :

Code:

Format                                  : AVC
Format/Info                              : Advanced Video Codec
Format profile                          : High@L3
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                  : Yes
Format settings, Reference frames        : 4 frames
Codec ID                                : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                : 1 h 12 min
Bit rate                                : 2 249 kb/s
Width                                    : 720 pixels
Height                                  : 576 pixels
Display aspect ratio                    : 16:9
Frame rate mode                          : Constant
Frame rate                              : 25.000 FPS
Standard                                : PAL
Color space                              : YUV
Chroma subsampling                      : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                      : 0.217
Stream size                              : 1.13 GiB (94%)
Writing library                          : x264 core 163 r3060 5db6aa6
Encoding settings                        : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

Résultat : pour une vidéo d'origine de 2.11 Go, la commande video génère une vidéo de 9.26 Go et l'incrustation ffmpeg sur la vidéo d'origine génère une vidéo de 1.20 Go
Ceci est parfaitement cohérent avec les bit rate indiqués dans chaque vidéo et donc les paramètres différents qui sont utilisés pour elles.

Il faut d'ailleurs que je m'interroge sur les paramètres que j'utilise habituellement pour mes nombreux encodages car ffmpeg semble faire beaucoup mieux avec ses valeurs par défaut que ce que je fais en définissant mes propres valeurs ...

@+ Puls

Non, je suis passé sur Jonzac02 dont tu ne disposes pas et c'est là que j'ai vu le problème des tuiles
Jonzac04 n'avais pas le problème.

Je peux t'envoyer le gpx et le début de la vidéo si tu veux

@+ Puls

Pulsar33 a écrit:

Non, je suis passé sur Jonzac02 dont tu ne disposes pas et c'est là que j'ai vu le problème des tuiles
Jonzac04 n'avais pas le problème.

Je peux t'envoyer le gpx et le début de la vidéo si tu veux

Juste le GPX qui devrait suffir.