Que signifie «Durée passée X.XXX trop grande»?


142

Lors de l'encodage H.264 à l'aide de ffmpeg, j'obtiens en masse le type d'avertissement suivant:

Past duration 0.603386 too large
Past duration 0.614372 too large
Past duration 0.606377 too large

Que signifient-ils? Je n'ai rien trouvé de clair en ligne ou dans la documentation ffmpeg.


2
Veuillez adresser les questions ffmpeg à video.stackexchange.com beta. Voir la description de la balise ffmpeg.
Ondra Žižka

34
@Ondra Encore un autre échange de pile? Je suis confus avec ces 100 sous-sites, je ne suis pas sûr que ce soit une direction positive vers laquelle stackexchange se dirige.
mxmlnkn

1
@mxmlnkn Je suis d'accord, ça vous fait désirer des temps plus simples ... :)
Erik

4
Je pense que c'est. StackOverflow est pour la programmation, ce n'est pas de la programmation. Il existe un site de questions / réponses pour le traitement vidéo, c'est une question sur le traitement vidéo. Qu'est-ce qu'il ne faut pas comprendre?
Ondra Žižka

Lisez également la description de la balise.
Ondra Žižka

Réponses:


23

Je recevais des milliers de ces avertissements avec un encodage particulier. Je réduisais la vidéo 1080p à 480p. À un point de montage, où il y avait une vidéo douteuse en raison d'un défaut dans le disque laser source, ces messages ont commencé à apparaître et sont ensuite apparus pour, je pense, chaque image par la suite. Ils ont continué encore et encore, comme ce court extrait:

Past duration 0.901115 too large=  535031kB time=00:54:15.06 bitrate=1346.5kbits/s dup=0 drop=19 speed=1.15x    
    Last message repeated 31 times
Past duration 0.901115 too large=  535031kB time=00:54:15.62 bitrate=1346.3kbits/s dup=0 drop=19 speed=1.15x    
    Last message repeated 34 times
Past duration 0.901115 too large=  535031kB time=00:54:16.21 bitrate=1346.0kbits/s dup=0 drop=19 speed=1.15x    
    Last message repeated 36 times
Past duration 0.901115 too large=  535338kB time=00:54:16.83 bitrate=1346.5kbits/s dup=0 drop=19 speed=1.15x    
    Last message repeated 39 times

L'appel original de ffmpeg était le suivant:

ffmpeg -i input.mp4 -s 720x480 -c:v libx264 -preset slower -crf 17 -c:a copy -y output.mkv

Suite aux suggestions ici, j'ai d'abord ajouté -framerate 60000/1001 à l'entrée. Cela n'a rien amélioré. J'ai conservé -framerate et ajouté -r 60000/1001 à la sortie. Cela n'a toujours rien amélioré. En conservant les deux, j'ai finalement ajouté -async 1 -vsync 1. Cela m'a permis de recevoir un seul avertissement, et c'est tout. Cette invocation était:

ffmpeg -i input.mp4 -framerate 60000/1001 -s 720x480 -c:v libx264 -preset slower -crf 17 -c:a copy -y output.mkv -r 60000/1001 -async 1 -vsync 1

La seule différence que j'ai trouvée dans un vidage détaillé de MediaInfo était la suppression de cette ligne trouvée dans l'invocation d'origine mais pas dans la seconde:

Delay relative to video                  : -33ms

Cependant, j'ai vérifié la synchronisation A / V vers le début des fichiers et vers la fin, et il n'y avait aucune différence perceptible de synchronisation entre les deux fichiers. Leurs temps de fonctionnement étaient également les mêmes, mais cela n'était mesuré qu'à la seconde près, en VLC. J'ai donc vérifié le nombre d'images en utilisant ffmpeg comme ceci:

ffmpeg -i output.mkv -map 0:v:0 -c copy -f null -

et recherchez "frame = #" vers la fin de la sortie.

Il s'avère que la vidéo source a une longueur de 375226 images, l'invocation d'origine a donné 375195 images et la deuxième invocation a donné 375200. Ainsi, la deuxième invocation, avec beaucoup moins de messages d'avertissement, a également perdu 5 images de moins.

Des tests ultérieurs ont montré que -framerate et -r n'étaient pas nécessaires et que l'utilisation des deux indicateurs de synchronisation était suffisante. Cela a produit des résultats identiques à la deuxième invocation ci-dessus, donc la troisième et la plus simple invocation que j'ai trouvée pour résoudre le problème est la suivante:

ffmpeg -i input.mp4 -s 720x480 -c:v libx264 -preset slower -crf 17 -c:a copy -y output.mkv -async 1 -vsync 1

Et encore un autre fichier a produit par la suite un tas de ces avertissements même avec les drapeaux de synchronisation, mais en rajoutant les indicateurs de taux "corrigés" il (produit seulement deux au lieu de milliers d'avertissements). Parfois, la deuxième invocation fonctionne alors que la troisième ne fonctionne pas. Pour mes besoins immédiats, je vais me contenter de la deuxième invocation et j'espère qu'elle résoudra la plupart de ces problèmes.

C'était tout avec ffmpeg version 4.0.


2
Merci pour ça! Après des jours de problèmes, -async 1 -vsync 1je l'ai résolu.
Offek

1
Merci pour cette analyse @larryy très utile
deepelement

90

Un des responsables du projet DVDStyler sur SourceForge a dit ceci à ce sujet:

Les versions FFMpeg après le 15 janvier 2015 affichent souvent cet avertissement. Il a été ajouté pour avertir d'une éventuelle distorsion du contrôle de débit, sinon il ne cause aucun dommage.


La `` distorsion du contrôle de débit '' est liée à l'encodage (principalement vidéo) et n'a aucun rapport avec cet avertissement, qui consiste à savoir si l'horodatage de sortie diffère trop (relativement) par rapport à l'horodatage d'entrée
Gyan

Les premières fois que j'ai reçu l'avertissement, j'ai mis fin à la conversion, mais ce conseil m'a obligé à la laisser s'exécuter et les avertissements se sont arrêtés après un certain temps et la conversion s'est terminée avec succès. Merci.
IRTFM le

58

Ce message d'avertissement apparaît lorsque vous essayez d'encoder une source à fréquence d'images élevée sur une sortie à faible fréquence d'images, ce qui signifie que les images doivent être supprimées.


J'ai eu cette erreur car je voulais convertir une série d'images en vidéo:

ffmpeg -i %05d.png -r 24 -c:v libx264 -crf 5 out.mkv

Le problème semble être que si aucune fréquence d'images n'est donnée pour l'entrée, une fréquence d'images de 25 ips est supposée:

Input #0, image2, from 'frames/%04d.bmp':
  Duration: 00:00:15.96, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: bmp, bgra, 920x650, 25 fps, 25 tbr, 25 tbn, 25 tbc

Cela peut également être vu sur le nombre total de trames codées. J'avais 400 images, mais la commande ci-dessus n'a encodé que 384:

frame=  384 fps= 68 q=-1.0 Lsize=   10931kB time=00:00:15.91 bitrate=5626.1kbits/s dup=0 drop=15    
video:10928kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.033807%

Les messages d'erreur disparaissent en définissant la fréquence d'images d'entrée à la place si la fréquence d'images de sortie. La fréquence d'images de sortie sera alors automatiquement choisie pour être celle de l'entrée. De plus, dans les versions plus récentes de ffmpeg, vous devez faire attention, car lorsque vous utilisez des images PNG avec l' -ioption ou plutôt le format d'entrée image2ou v4l2, vous devez utiliser à la -framerateplace de -r, voir la documentation de l' -roption .

ffmpeg -framerate 24 -i %05d.png -c:v libx264 -crf 5 out.mkv

Il est également possible de spécifier séparément la fréquence d'images de l'entrée et de la sortie:

ffmpeg -framerate 25 -i %05d.png -r 10 -c:v libx264 -crf 5 out.mkv

Dans ce cas, seules 161/400 trames seront encodées. Les autres images intermédiaires seront supprimées. De plus, le message d'erreur disparaît, je suppose que pour ne pas ralentir ffmpeg en envoyant du spam à stdout, voir:


3
"parce que seulement lorsque vous utilisez des images PNG avec l'option -i, vous devez utiliser -framerate au lieu de -r" - cela a complètement résolu mon problème, merci!
Anonyme

1
En essayant de convertir un wmv en mp4, en utilisant -rtravaillé là où l'utilisation -frameratene l'a pas fait.
1934286

+1 et je suggère de déplacer votre "résumé" en haut. De plus, cela a résolu mon cas de conversion d'images en vidéo et d'essayer d'augmenter le taux de trame de sortie et d'accélérer la sortie. Je suis parti de ceci ffmpeg -pattern_type glob -i '*.jpg' -filter:v "setpts=0.25*PTS" -r 50 "$( date "+%Y-%m-%d_%H%M%S")-timelapse-x4-50fps.mp4"pour cela sans plus d'avertissement ffmpeg -framerate 50 -pattern_type glob -i '*.jpg' -filter:v "setpts=0.25*PTS" -r 50 "$( date "+%Y-%m-%d_%H%M%S")-timelapse-x4-50fps.mp4"(notez l' -framerate 50ajout pour l'entrée)
el-teedee

49

En regardant le code source, il semble que la différence entre le temps de présentation (pts) dans le flux d'entrée diffère de celle du flux de sortie de plus d'une limite fixe fixée à 0,6.

Extraits de la source:

    delta0 = sync_ipts - ost->sync_opts;
    delta  = delta0 + duration;

...

        if (delta0 < 0 &&
        delta > 0 &&
        format_video_sync != VSYNC_PASSTHROUGH &&
        format_video_sync != VSYNC_DROP) {
        double cor = FFMIN(-delta0, duration);
        if (delta0 < -0.6) {
            av_log(NULL, AV_LOG_WARNING, "Past duration %f too large\n", -delta0);
        } else
            av_log(NULL, AV_LOG_DEBUG, "Cliping frame in rate conversion by %f\n", -delta0);
        sync_ipts += cor;
        duration -= cor;
        delta0 += cor;
    }

Ce n'est qu'un rapide coup d'œil, alors n'hésitez pas à creuser plus profondément.


Y a-t-il quelque chose que nous pouvons faire pour "résoudre" ce problème, ou définir explicitement les points de sortie?
Baodad

1
Je ne me souviens pas des détails entourant ce problème, mais si par "réparer" vous voulez dire se débarrasser de l'avertissement, alors en fonction du code ci-dessus, vous pouvez examiner l'option format_video_sync = VSYNC_DROPou format_video_sync = VSYNC_PASSTHROUGHvoir si l'une de ces options est viable dans votre cas d'utilisation.
Erik

Merci. J'ai découvert le réglage de la fréquence d'images explicitement en utilisant le -rcommutateur "fixe" ces avertissements.
Baodad

1
Juste quelque chose par expérience personnelle: j'ai eu le problème de spam des messages de «durée passée» et je l'ai résolu en forçant la fréquence d'images d'entrée avec -r 25, mais j'ai alors commencé à désynchroniser fortement l'audio. La suppression de l'option -r et l'utilisation de «-async 1 -vsync 1» pour empêcher la désynchronisation audio a évité le problème audio, mais le spam «de durée passée» semble également avoir disparu.
Jason Lang

Dans la version 4.1 et ultérieure, le niveau de journalisation a été mis à niveau, il n'apparaît donc pas au niveau de journalisation par défaut.
Gyan le


1

La commande devrait en fait être:

ffmpeg -loglevel quiet -i input_file.xyz ...

Il n'y a pas de préfixe "-" pour le paramètre "quiet", car ce n'est pas une option, mais plutôt une valeur pour l'option "-loglevel".

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.