factor=0.1 # Pour avoir une vitesse « x 0,1 » (ie 10 fois plus lente)
ffmpeg -i myvideo.mp4 -vf "setpts=(1/$factor)*PTS" -an
-max_muxing_queue_size 4000 myvideo-slow.mp4
1. Est-ce que la façon de faire ci-dessus est correcte d'après vous ?
Peut-être qu'il existe des outils plus simples pour faire cela ?
factor=0.1 # Pour avoir une vitesse « x 0,1 » (ie 10 fois plus lente)
ffmpeg -i myvideo.mp4 -vf "setpts=(1/$factor)*PTS" -an
-max_muxing_queue_size 4000 myvideo-slow.mp4
1. Est-ce que la façon de faire ci-dessus est correcte d'après vous ?
Peut-être qu'il existe des outils plus simples pour faire cela ?
factor=0.1 # Pour avoir une vitesse « x 0,1 » (ie 10 fois plus lente)
ffmpeg -i myvideo.mp4 -vf "setpts=(1/$factor)*PTS" -an
-max_muxing_queue_size 4000 myvideo-slow.mp4
1. Est-ce que la façon de faire ci-dessus est correcte d'après vous ?
Peut-être qu'il existe des outils plus simples pour faire cela ?
Voici mes questions :
1. Est-ce que la façon de faire ci-dessus est correcte d'après vous ?
Peut-être qu'il existe des outils plus simples pour faire cela ?
Voici mes questions :
1. Est-ce que la façon de faire ci-dessus est correcte d'après vous ?
Peut-être qu'il existe des outils plus simples pour faire cela ?
Voici mes questions :
1. Est-ce que la façon de faire ci-dessus est correcte d'après vous ?
Peut-être qu'il existe des outils plus simples pour faire cela ?
Je suis sous Ubuntu 18.04 et je cherche (pour un usage perso) à modifier
la vitesse de vidéos .mp4 prises avec mon smartphone. Je préviens, je n'y
connais rien encodage de vidéos. Point important peut-être, je me moque
de l'audio, la vidéo que je génère n'a pas de son (seule l'image m'importe).
En cherchant sur le Web, c'est vers ffmpeg que je me suis tourné mais je
n'ai aucune préférence, si un autre outil peut faire le job, je suis preneur.
Un peu par tâtonnement, j'ai trouvé cette commande qui me semble marcher :
factor=0.1 # Pour avoir une vitesse « x 0,1 » (ie 10 fois plus lente)
ffmpeg -i myvideo.mp4 -vf "setpts=(1/$factor)*PTS" -an
-max_muxing_queue_size 4000 myvideo-slow.mp4
L'option « -max_muxing_queue_size 4000 », je l'ai mise car, sur certaines de
mes vidéos, je suis tombé sur le message d'erreur :
Too many packets buffered for output stream 0:0
et avec l'option l'erreur disparaissait (constat empirique).
2. En fait, je pensais que modifier la vitesse d'une vidéo était une
opération rapide où il fallait juste modifier une sorte de metadata du
fichier vidéo (une peu comme on modifierait un header dans une requête
HTTP). Mais je constate que :
a) l'encodage prend du temps (qq dizaines de secondes pour une vidéo
de 38MB en entrée);
b) la taille de la vidéo générée est plus grosse que la vidéo en
entrée (toujours avec mon exemple de vidéo de 38MB en entrée,
la vidéo « ralentie » générée fait 53MB).
Mon idée de la metadata à modifier est donc fausse ? C'est plus compliqué
que ça ?
3. Avec ma commande, j'ai parfois les messages suivants :
More than 1000 frames duplicated
Ils sont en jaune dans mon terminal, comme si c'était un warning ou une
erreur. Est-ce grave ?
Je suis sous Ubuntu 18.04 et je cherche (pour un usage perso) à modifier
la vitesse de vidéos .mp4 prises avec mon smartphone. Je préviens, je n'y
connais rien encodage de vidéos. Point important peut-être, je me moque
de l'audio, la vidéo que je génère n'a pas de son (seule l'image m'importe).
En cherchant sur le Web, c'est vers ffmpeg que je me suis tourné mais je
n'ai aucune préférence, si un autre outil peut faire le job, je suis preneur.
Un peu par tâtonnement, j'ai trouvé cette commande qui me semble marcher :
factor=0.1 # Pour avoir une vitesse « x 0,1 » (ie 10 fois plus lente)
ffmpeg -i myvideo.mp4 -vf "setpts=(1/$factor)*PTS" -an
-max_muxing_queue_size 4000 myvideo-slow.mp4
L'option « -max_muxing_queue_size 4000 », je l'ai mise car, sur certaines de
mes vidéos, je suis tombé sur le message d'erreur :
Too many packets buffered for output stream 0:0
et avec l'option l'erreur disparaissait (constat empirique).
2. En fait, je pensais que modifier la vitesse d'une vidéo était une
opération rapide où il fallait juste modifier une sorte de metadata du
fichier vidéo (une peu comme on modifierait un header dans une requête
HTTP). Mais je constate que :
a) l'encodage prend du temps (qq dizaines de secondes pour une vidéo
de 38MB en entrée);
b) la taille de la vidéo générée est plus grosse que la vidéo en
entrée (toujours avec mon exemple de vidéo de 38MB en entrée,
la vidéo « ralentie » générée fait 53MB).
Mon idée de la metadata à modifier est donc fausse ? C'est plus compliqué
que ça ?
3. Avec ma commande, j'ai parfois les messages suivants :
More than 1000 frames duplicated
Ils sont en jaune dans mon terminal, comme si c'était un warning ou une
erreur. Est-ce grave ?
Je suis sous Ubuntu 18.04 et je cherche (pour un usage perso) à modifier
la vitesse de vidéos .mp4 prises avec mon smartphone. Je préviens, je n'y
connais rien encodage de vidéos. Point important peut-être, je me moque
de l'audio, la vidéo que je génère n'a pas de son (seule l'image m'importe).
En cherchant sur le Web, c'est vers ffmpeg que je me suis tourné mais je
n'ai aucune préférence, si un autre outil peut faire le job, je suis preneur.
Un peu par tâtonnement, j'ai trouvé cette commande qui me semble marcher :
factor=0.1 # Pour avoir une vitesse « x 0,1 » (ie 10 fois plus lente)
ffmpeg -i myvideo.mp4 -vf "setpts=(1/$factor)*PTS" -an
-max_muxing_queue_size 4000 myvideo-slow.mp4
L'option « -max_muxing_queue_size 4000 », je l'ai mise car, sur certaines de
mes vidéos, je suis tombé sur le message d'erreur :
Too many packets buffered for output stream 0:0
et avec l'option l'erreur disparaissait (constat empirique).
2. En fait, je pensais que modifier la vitesse d'une vidéo était une
opération rapide où il fallait juste modifier une sorte de metadata du
fichier vidéo (une peu comme on modifierait un header dans une requête
HTTP). Mais je constate que :
a) l'encodage prend du temps (qq dizaines de secondes pour une vidéo
de 38MB en entrée);
b) la taille de la vidéo générée est plus grosse que la vidéo en
entrée (toujours avec mon exemple de vidéo de 38MB en entrée,
la vidéo « ralentie » générée fait 53MB).
Mon idée de la metadata à modifier est donc fausse ? C'est plus compliqué
que ça ?
3. Avec ma commande, j'ai parfois les messages suivants :
More than 1000 frames duplicated
Ils sont en jaune dans mon terminal, comme si c'était un warning ou une
erreur. Est-ce grave ?
0. As-tu essayé de poser la question dans le groupe ad hoc ?
0. As-tu essayé de poser la question dans le groupe ad hoc ?
0. As-tu essayé de poser la question dans le groupe ad hoc ?
En fait, je n'ai pas réussi au début à reproduire l'erreur. C'est parce
que l'erreur apparaît seulement quand je ne mets *pas* l'option "-an"
(chose que je n'avais pas remarqué hier). Voici un exemple (sans l'option
"-an" donc) :
WARNING: library configuration mismatch
Ok, je vois. En effet, ne pas à avoir à transcoder la vidéo serait optimal
pour moi, vu que je souhaite conserver une vidéo en l'état (ie de même
qualité que l'originale) et seulement en modifier la vitesse de lecture. Par
contre, je n'ai pas dû bien comprendre le fonctionnement de l'option -r car
j'obtiens une vidéo qui me semble de même vitesse. Voici ma tentative :
Ce cette sortie, je conclue (à tort peut-être, je n'y connais rien) que la
vitesse de lecture de la vidéo est de 240 frames par secondes.
Ah ok. Mon but est de conserver la qualité de la vidéo identique à l'originale.
Voici un exemple (je ne mets pas en verbose car c'est vraiment long, j'espère
qu'il y aura assez d'éléments) :
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/bt709/smpte170m), 1920x1080, 72527 kb/s, SAR 1:1 DAR 16:9, 239.68 fps, 240 tbr, 90k tbn, 180k tbc (default)
Stream #0:0(eng): Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 1080x1920 [SAR 1:1 DAR 9:16], q=-1--1, 240 fps, 15360 tbn, 240 tbc (default)
En fait, je n'ai pas réussi au début à reproduire l'erreur. C'est parce
que l'erreur apparaît seulement quand je ne mets *pas* l'option "-an"
(chose que je n'avais pas remarqué hier). Voici un exemple (sans l'option
"-an" donc) :
WARNING: library configuration mismatch
Ok, je vois. En effet, ne pas à avoir à transcoder la vidéo serait optimal
pour moi, vu que je souhaite conserver une vidéo en l'état (ie de même
qualité que l'originale) et seulement en modifier la vitesse de lecture. Par
contre, je n'ai pas dû bien comprendre le fonctionnement de l'option -r car
j'obtiens une vidéo qui me semble de même vitesse. Voici ma tentative :
Ce cette sortie, je conclue (à tort peut-être, je n'y connais rien) que la
vitesse de lecture de la vidéo est de 240 frames par secondes.
Ah ok. Mon but est de conserver la qualité de la vidéo identique à l'originale.
Voici un exemple (je ne mets pas en verbose car c'est vraiment long, j'espère
qu'il y aura assez d'éléments) :
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/bt709/smpte170m), 1920x1080, 72527 kb/s, SAR 1:1 DAR 16:9, 239.68 fps, 240 tbr, 90k tbn, 180k tbc (default)
Stream #0:0(eng): Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 1080x1920 [SAR 1:1 DAR 9:16], q=-1--1, 240 fps, 15360 tbn, 240 tbc (default)
En fait, je n'ai pas réussi au début à reproduire l'erreur. C'est parce
que l'erreur apparaît seulement quand je ne mets *pas* l'option "-an"
(chose que je n'avais pas remarqué hier). Voici un exemple (sans l'option
"-an" donc) :
WARNING: library configuration mismatch
Ok, je vois. En effet, ne pas à avoir à transcoder la vidéo serait optimal
pour moi, vu que je souhaite conserver une vidéo en l'état (ie de même
qualité que l'originale) et seulement en modifier la vitesse de lecture. Par
contre, je n'ai pas dû bien comprendre le fonctionnement de l'option -r car
j'obtiens une vidéo qui me semble de même vitesse. Voici ma tentative :
Ce cette sortie, je conclue (à tort peut-être, je n'y connais rien) que la
vitesse de lecture de la vidéo est de 240 frames par secondes.
Ah ok. Mon but est de conserver la qualité de la vidéo identique à l'originale.
Voici un exemple (je ne mets pas en verbose car c'est vraiment long, j'espère
qu'il y aura assez d'éléments) :
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/bt709/smpte170m), 1920x1080, 72527 kb/s, SAR 1:1 DAR 16:9, 239.68 fps, 240 tbr, 90k tbn, 180k tbc (default)
Stream #0:0(eng): Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 1080x1920 [SAR 1:1 DAR 9:16], q=-1--1, 240 fps, 15360 tbn, 240 tbc (default)
Sans -an, c'est normal : tu ralentis la vidéo mais pas l'audio, donc les
paquets vidéos doivent être mis en attente le temps que les paquets
audio les rattrapent.
WARNING: library configuration mismatch
Cette version de ffmpeg semble médiocrement compilée.
L'option -r en entrée est censée marcher, mais elle cassez de temps en
temps. Essaie avec la toute dernière version, et si ça ne marche
signale-le sur le bug-tracker.
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/bt709/smpte170m), 1920x1080, 72527 kb/s, SAR 1:1 DAR 16:9, 239.68 fps, 240 tbr, 90k tbn, 180k tbc (default)
Stream #0:0(eng): Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 1080x1920 [SAR 1:1 DAR 9:16], q=-1--1, 240 fps, 15360 tbn, 240 tbc (default)
Voilà le problème : l'entrée semble être à 240 images par seconde, comme
tu l'as dit. Donc la sortie est mise au même rythme. Or le muxer MP4 de
ffmpeg ne supporte que les débits d'image constants. Donc il va chercher
à faire vraiment du 240 images par seconde, en décuplant chaque image.
Il faudrait préciser -r en sortie.
Sans -an, c'est normal : tu ralentis la vidéo mais pas l'audio, donc les
paquets vidéos doivent être mis en attente le temps que les paquets
audio les rattrapent.
WARNING: library configuration mismatch
Cette version de ffmpeg semble médiocrement compilée.
L'option -r en entrée est censée marcher, mais elle cassez de temps en
temps. Essaie avec la toute dernière version, et si ça ne marche
signale-le sur le bug-tracker.
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/bt709/smpte170m), 1920x1080, 72527 kb/s, SAR 1:1 DAR 16:9, 239.68 fps, 240 tbr, 90k tbn, 180k tbc (default)
Stream #0:0(eng): Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 1080x1920 [SAR 1:1 DAR 9:16], q=-1--1, 240 fps, 15360 tbn, 240 tbc (default)
Voilà le problème : l'entrée semble être à 240 images par seconde, comme
tu l'as dit. Donc la sortie est mise au même rythme. Or le muxer MP4 de
ffmpeg ne supporte que les débits d'image constants. Donc il va chercher
à faire vraiment du 240 images par seconde, en décuplant chaque image.
Il faudrait préciser -r en sortie.
Sans -an, c'est normal : tu ralentis la vidéo mais pas l'audio, donc les
paquets vidéos doivent être mis en attente le temps que les paquets
audio les rattrapent.
WARNING: library configuration mismatch
Cette version de ffmpeg semble médiocrement compilée.
L'option -r en entrée est censée marcher, mais elle cassez de temps en
temps. Essaie avec la toute dernière version, et si ça ne marche
signale-le sur le bug-tracker.
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/bt709/smpte170m), 1920x1080, 72527 kb/s, SAR 1:1 DAR 16:9, 239.68 fps, 240 tbr, 90k tbn, 180k tbc (default)
Stream #0:0(eng): Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 1080x1920 [SAR 1:1 DAR 9:16], q=-1--1, 240 fps, 15360 tbn, 240 tbc (default)
Voilà le problème : l'entrée semble être à 240 images par seconde, comme
tu l'as dit. Donc la sortie est mise au même rythme. Or le muxer MP4 de
ffmpeg ne supporte que les débits d'image constants. Donc il va chercher
à faire vraiment du 240 images par seconde, en décuplant chaque image.
Il faudrait préciser -r en sortie.
L'option -r en entrée est censée marcher, mais elle cassez de temps en
temps. Essaie avec la toute dernière version, et si ça ne marche
signale-le sur le bug-tracker.
Ok, je testerai.
L'option -r en entrée est censée marcher, mais elle cassez de temps en
temps. Essaie avec la toute dernière version, et si ça ne marche
signale-le sur le bug-tracker.
Ok, je testerai.
L'option -r en entrée est censée marcher, mais elle cassez de temps en
temps. Essaie avec la toute dernière version, et si ça ne marche
signale-le sur le bug-tracker.
Ok, je testerai.
C'est la version packagée dans Ubuntu 18.04.
Et bien, sauf erreur, ça ne marche pas où alors je n'ai pas fait comme il
fallait :
$ ffmpeg -i myvideo.mp4 -an -c copy -r 10 myvideo-slow.mp4; echo $?
Et la vidéo générée a toujours une vitesse identique à l'originale.
C'est la version packagée dans Ubuntu 18.04.
Et bien, sauf erreur, ça ne marche pas où alors je n'ai pas fait comme il
fallait :
$ ffmpeg -i myvideo.mp4 -an -c copy -r 10 myvideo-slow.mp4; echo $?
Et la vidéo générée a toujours une vitesse identique à l'originale.
C'est la version packagée dans Ubuntu 18.04.
Et bien, sauf erreur, ça ne marche pas où alors je n'ai pas fait comme il
fallait :
$ ffmpeg -i myvideo.mp4 -an -c copy -r 10 myvideo-slow.mp4; echo $?
Et la vidéo générée a toujours une vitesse identique à l'originale.
Je viens de tester avec la dernière version de ffmpeg (sauf erreur) et j'ai
$ ./ffmpeg -r 10 -i myvideo.mp4 -an -c copy myvideo-slow.mp4; echo $?
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/bt709/smpte170m), 1920x1080, 72527 kb/s, SAR 1:1 DAR 16:9, 239.68 fps, 240 tbr, 90k tbn, 180k tbc (default)
Est-ce qu'il faut considérer qu'il y a un bug ou je m'y suis mal pris ?
echo $?
Je viens de tester avec la dernière version de ffmpeg (sauf erreur) et j'ai
$ ./ffmpeg -r 10 -i myvideo.mp4 -an -c copy myvideo-slow.mp4; echo $?
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/bt709/smpte170m), 1920x1080, 72527 kb/s, SAR 1:1 DAR 16:9, 239.68 fps, 240 tbr, 90k tbn, 180k tbc (default)
Est-ce qu'il faut considérer qu'il y a un bug ou je m'y suis mal pris ?
echo $?
Je viens de tester avec la dernière version de ffmpeg (sauf erreur) et j'ai
$ ./ffmpeg -r 10 -i myvideo.mp4 -an -c copy myvideo-slow.mp4; echo $?
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/bt709/smpte170m), 1920x1080, 72527 kb/s, SAR 1:1 DAR 16:9, 239.68 fps, 240 tbr, 90k tbn, 180k tbc (default)
Est-ce qu'il faut considérer qu'il y a un bug ou je m'y suis mal pris ?
echo $?
Est-ce qu'il faut considérer qu'il y a un bug ou je m'y suis mal pris ?
Oui.
Est-ce qu'il faut considérer qu'il y a un bug ou je m'y suis mal pris ?
Oui.
Est-ce qu'il faut considérer qu'il y a un bug ou je m'y suis mal pris ?
Oui.
