Découper une vidéo (avec ffmpeg ou avconv ?)

Le
Olivier Miakinen
Bonjour,

J'ai récupéré sur le web un extrait du journal télévisé de TF1, pour
un reportage qu'il m'intéresse de conserver. Le découpage n'étant pas
parfaitement calé (3 secondes en trop avant, quelques secondes en trop
après), j'ai voulu le redécouper avec ffmpeg, puis avec avconv suite
à un message annonçant que sur Ubuntu le premier était remplacé par le
second.

Après avoir recherché des infos dans le man et sur la toile, J'ai
essayé la commande suivante :

$ avconv -i source.mp4 -vcodec copy -acodec copy -ss 00:00:03
-t 00:02:11 dest.mp4

Résultat : le découpage est parfait pour l'image, par contre le son
démarre avec quelques secondes de retard, ce qui est parfaitement
insupportable. J'ai essayé la même chose en remplaçant avconv par
ffmpeg, et ai obtenu le même résultat.

Des idées ?

P.-S. : voici ce que m'affiche la commande ffmpeg (les fichiers source
et destination sont respectivement bisons0.mp4 et bisons2.mp4) :

> ffmpeg version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013 the Libav developers
> built on Apr 2 2013 17:00:59 with gcc 4.6.3
> *** THIS PROGRAM IS DEPRECATED ***
> This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.
> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'bisons0.mp4':
> Metadata:
> major_brand : isom
> minor_version : 512
> compatible_brands: isomiso2avc1mp41
> encoder : Lavf54.32.101
> Duration: 00:02:33.60, start: 0.000000, bitrate: 745 kb/s
> Stream #0.0(und): Video: h264 (Main), yuv420p, 640x360 [PAR 1:1 DAR 16:9], 657 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc
> Stream #0.1(und): Audio: aac, 48000 Hz, stereo, s16, 80 kb/s
> Output #0, mp4, to 'bisons2.mp4':
> Metadata:
> major_brand : isom
> minor_version : 512
> compatible_brands: isomiso2avc1mp41
> encoder : Lavf53.21.1
> Stream #0.0(und): Video: libx264, yuv420p, 640x360 [PAR 1:1 DAR 16:9], q=2-31, 657 kb/s, 25 tbn, 25 tbc
> Stream #0.1(und): Audio: libvo_aacenc, 48000 Hz, stereo, 80 kb/s
> Stream mapping:
> Stream #0.0 -> #0.0
> Stream #0.1 -> #0.1
> Press ctrl-c to stop encoding
> frame= 3100 fps= 0 q=-1.0 Lsize= 11690kB time0.92 bitrate= 731.5kbits/s
> video:10296kB audio:1297kB global headers:0kB muxing overhead 0.836823%


Cordialement,
--
Olivier Miakinen
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Alf92
Le #25326442
Olivier Miakinen
Bonjour,

J'ai récupéré sur le web un extrait du journal télévisé de TF1, pour
un reportage qu'il m'intéresse de conserver. Le découpage n'étant pas
parfaitement calé (3 secondes en trop avant, quelques secondes en trop
après), j'ai voulu le redécouper avec ffmpeg, puis avec avconv suite
à un message annonçant que sur Ubuntu le premier était remplacé par le
second.

Après avoir recherché des infos dans le man et sur la toile, J'ai
essayé la commande suivante :

$ avconv -i source.mp4 -vcodec copy -acodec copy -ss 00:00:03
-t 00:02:11 dest.mp4

Résultat : le découpage est parfait pour l'image, par contre le son
démarre avec quelques secondes de retard, ce qui est parfaitement
insupportable. J'ai essayé la même chose en remplaçant avconv par
ffmpeg, et ai obtenu le même résultat.

Des idées ?

P.-S. : voici ce que m'affiche la commande ffmpeg (les fichiers source
et destination sont respectivement bisons0.mp4 et bisons2.mp4) :
======================================================================= >> ffmpeg version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013 the
Libav developers built on Apr 2 2013 17:00:59 with gcc 4.6.3
*** THIS PROGRAM IS DEPRECATED ***
This program is only provided for compatibility and will be removed in a
future release. Please use avconv instead. Input #0,
mov,mp4,m4a,3gp,3g2,mj2, from 'bisons0.mp4': Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf54.32.101
Duration: 00:02:33.60, start: 0.000000, bitrate: 745 kb/s
Stream #0.0(und): Video: h264 (Main), yuv420p, 640x360 [PAR 1:1 DAR
16:9], 657 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc Stream #0.1(und):
Audio: aac, 48000 Hz, stereo, s16, 80 kb/s Output #0, mp4, to 'bisons2.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf53.21.1
Stream #0.0(und): Video: libx264, yuv420p, 640x360 [PAR 1:1 DAR 16:9],
q=2-31, 657 kb/s, 25 tbn, 25 tbc Stream #0.1(und): Audio: libvo_aacenc,
48000 Hz, stereo, 80 kb/s Stream mapping:
Stream #0.0 -> #0.0
Stream #0.1 -> #0.1
Press ctrl-c to stop encoding
frame= 3100 fps= 0 q=-1.0 Lsize= 11690kB time0.92 bitrate=
731.5kbits/s video:10296kB audio:1297kB global headers:0kB muxing
overhead 0.836823%


======================================================================= >
Cordialement,




avec ffmpeg :


ffmpeg -ss 5 -t 800 -i fichierIN.XXX -vcodec copy -acodec copy
fichierOUT.XXX

5 : debute à la 5ème seconde
800 : pour une durée de 800 secondes (termine à 805ème seconde)
Répondre en citant
Olivier Miakinen
Le #25327002
Bonjour,

Le 08/04/2013 01:07, Alf92 m'a répondu :

$ avconv -i source.mp4 -vcodec copy -acodec copy -ss 00:00:03
-t 00:02:11 dest.mp4

[...] J'ai essayé la même chose en remplaçant avconv par
ffmpeg, et ai obtenu le même résultat.





C'est-à-dire donc :
$ ffmpeg -i source.mp4 -vcodec copy -acodec copy -ss 00:00:03
-t 00:02:11 dest.mp4

avec ffmpeg :

ffmpeg -ss 5 -t 800 -i fichierIN.XXX -vcodec copy -acodec copy
fichierOUT.XXX

5 : debute à la 5ème seconde
800 : pour une durée de 800 secondes (termine à 805ème seconde)



Si je comprends bien, ce serait la syntaxe pour écrire les temps
qui aurait causé le décalage ? Et donc, si j'écris -ss 3 au lieu
de -ss 00:00:03, et -t 131 au lieu de -t 00:02:11, ça a des chances
de mieux fonctionner ?

J'essaierai ce soir, là je ne suis pas sur mon Linux.

Cordialement,
--
Olivier Miakinen
Répondre en citant
Alf92
Le #25327172
Olivier Miakinen
Bonjour,

Le 08/04/2013 01:07, Alf92 m'a répondu :

$ avconv -i source.mp4 -vcodec copy -acodec copy -ss 00:00:03
-t 00:02:11 dest.mp4

[...] J'ai essayé la même chose en remplaçant avconv par
ffmpeg, et ai obtenu le même résultat.





C'est-à-dire donc :
$ ffmpeg -i source.mp4 -vcodec copy -acodec copy -ss 00:00:03
-t 00:02:11 dest.mp4

avec ffmpeg :

ffmpeg -ss 5 -t 800 -i fichierIN.XXX -vcodec copy -acodec copy
fichierOUT.XXX

5 : debute à la 5ème seconde
800 : pour une durée de 800 secondes (termine à 805ème seconde)



Si je comprends bien, ce serait la syntaxe pour écrire les temps
qui aurait causé le décalage ? Et donc, si j'écris -ss 3 au lieu
de -ss 00:00:03, et -t 131 au lieu de -t 00:02:11, ça a des chances
de mieux fonctionner ?



non, je pense que ta syntaxe est bonne aussi.
attention simplement à la version de ffmpeg que tu emploies.
elles ne réagissent pas toute de même façon.
moi c'est une version Windows "zeranoe"
http://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-latest-win32-static.7z

J'essaierai ce soir, là je ne suis pas sur mon Linux.



autre piste en cas de pb :
si le décalage audio n'est pas présent dans la verion initiale de ta
video et apparait dans ta version "cut", c'est peut être un pb de type
"transport stream" avec des balises de synchro qui disparaissent qd tu
passes en flux "programm stream".
dans ce cas tente : faire le cut en passant pas un container M2TS, puis
faire ensuite un direct stream copy vers le container de ton choix
(celui qui pose le moins de pb est souvent le MKV).
Répondre en citant
pehache
Le #25328032
Le 08/04/13 14:51, Alf92 a écrit :

autre piste en cas de pb :
si le décalage audio n'est pas présent dans la verion initiale de ta
video et apparait dans ta version "cut", c'est peut être un pb de type
"transport stream" avec des balises de synchro qui disparaissent qd tu
passes en flux "programm stream".
dans ce cas tente : faire le cut en passant pas un container M2TS, puis
faire ensuite un direct stream copy vers le container de ton choix
(celui qui pose le moins de pb est souvent le MKV).



Souvent ces problèmes de décalages A/V sont résolus en mettant un
"-async 100000" (n'importe quel grand nombre convient). Je n'ai jamais
compris ce que ça faisait au juste mais bon...
Répondre en citant
pehache
Le #25328022
Le 08/04/13 22:56, pehache a écrit :
Le 08/04/13 14:51, Alf92 a écrit :

autre piste en cas de pb :
si le décalage audio n'est pas présent dans la verion initiale de ta
video et apparait dans ta version "cut", c'est peut être un pb de type
"transport stream" avec des balises de synchro qui disparaissent qd tu
passes en flux "programm stream".
dans ce cas tente : faire le cut en passant pas un container M2TS, puis
faire ensuite un direct stream copy vers le container de ton choix
(celui qui pose le moins de pb est souvent le MKV).



Souvent ces problèmes de décalages A/V sont résolus en mettant un
"-async 100000" (n'importe quel grand nombre convient). Je n'ai jamais
compris ce que ça faisait au juste mais bon...




Ceci dit sa source est un .mp4, donc ça m'étonnerait que ce soit ça le
problème...
Répondre en citant
Alf92
Le #25328242
pehache
Le 08/04/13 14:51, Alf92 a écrit :

autre piste en cas de pb :
si le décalage audio n'est pas présent dans la verion initiale de ta
video et apparait dans ta version "cut", c'est peut être un pb de type
"transport stream" avec des balises de synchro qui disparaissent qd tu
passes en flux "programm stream".
dans ce cas tente : faire le cut en passant pas un container M2TS, puis
faire ensuite un direct stream copy vers le container de ton choix
(celui qui pose le moins de pb est souvent le MKV).



Souvent ces problèmes de décalages A/V sont résolus en mettant un "-async
100000" (n'importe quel grand nombre convient). Je n'ai jamais compris ce que
ça faisait au juste mais bon...



j'ai trouvé ça...(ci-dessous)
si je comprends bien -async sert à faire matcher audio et video.
bizarre cette valeur gigantesque... tu dis qu'elle corrige le pb des
trames manquantes des transport stream ??


-vsync parameter
Video sync method. 0 Each frame is passed with its timestamp from
the demuxer to the muxer 1 Frames will be duplicated and dropped to
achieve exactly the requested constant framerate. 2 Frames are passed
through with their timestamp or dropped so as to prevent 2 frames from
having the same timestamp -1 Chooses between 1 and 2 depending on muxer
capabilities. This is the default method.
With -map you can select from which stream the timestamps should be
taken. You can leave either video or audio unchanged and sync the
remaining stream(s) to the unchanged one.

-async samples_per_second
Audio sync method. "Stretches/squeezes" the audio stream to match
the timestamps, the parameter is the maximum samples per second by
which the audio is changed. -async 1 is a special case where only the
start of the audio stream is corrected without any later correction.
Répondre en citant
Olivier Miakinen
Le #25328232
Le 08/04/2013 14:51, Alf92 m'a répondu :

Si je comprends bien, ce serait la syntaxe pour écrire les temps
qui aurait causé le décalage ? Et donc, si j'écris -ss 3 au lieu
de -ss 00:00:03, et -t 131 au lieu de -t 00:02:11, ça a des chances
de mieux fonctionner ?



non, je pense que ta syntaxe est bonne aussi.



J'ai essayé, ça donne le même résultat.

attention simplement à la version de ffmpeg que tu emploies.
elles ne réagissent pas toute de même façon.



ffmpeg version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013
the Libav developers
built on Apr 2 2013 17:00:59 with gcc 4.6.3

avconv version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013
the Libav developers
built on Apr 2 2013 17:00:59 with gcc 4.6.3

autre piste en cas de pb :
si le décalage audio n'est pas présent dans la verion initiale de ta
video et apparait dans ta version "cut",



En effet. D'ailleurs il n'apparaît pas si je ne coupe que la fin.

Sinon, j'ai essayé des valeurs différentes de 3 secondes pour le
début. Quand je mets 1 ou 2, l'image démarre quand même au début
du reportage qui m'intéresse, mais le son commence avant. Quand je
mets plus de 3, l'image commence bien après et le son est toujours
décalé.

Au fait, j'aurais peut-être dû commencer par donner un lien vers la
vidéo d'origine puisqu'elle est facilement accessible :
Je l'ai téléchargée via l'extension de Firefox DownloadHelper.

c'est peut être un pb de type
"transport stream" avec des balises de synchro qui disparaissent qd tu
passes en flux "programm stream".
dans ce cas tente : faire le cut en passant pas un container M2TS, puis
faire ensuite un direct stream copy vers le container de ton choix
(celui qui pose le moins de pb est souvent le MKV).



Ahem... tu as peut-être bien raison, mais je n'y comprends rien.
Désolé. ;-)

Tu pourrais m'indiquer la ou les commandes à utiliser ?

Cordialement,
--
Olivier Miakinen
Répondre en citant
Olivier Miakinen
Le #25328222
Le 08/04/2013 22:58, pehache se répondait :

Souvent ces problèmes de décalages A/V sont résolus en mettant un
"-async 100000" (n'importe quel grand nombre convient). Je n'ai jamais
compris ce que ça faisait au juste mais bon...



Ceci dit sa source est un .mp4, donc ça m'étonnerait que ce soit ça le
problème...



Et tu as raison, ce paramètre n'a rien changé du tout. Dommage.
Répondre en citant
Alf92
Le #25328212
pehache
Le 08/04/13 22:56, pehache a écrit :
Le 08/04/13 14:51, Alf92 a écrit :

autre piste en cas de pb :
si le décalage audio n'est pas présent dans la verion initiale de ta
video et apparait dans ta version "cut", c'est peut être un pb de type
"transport stream" avec des balises de synchro qui disparaissent qd tu
passes en flux "programm stream".
dans ce cas tente : faire le cut en passant pas un container M2TS, puis
faire ensuite un direct stream copy vers le container de ton choix
(celui qui pose le moins de pb est souvent le MKV).



Souvent ces problèmes de décalages A/V sont résolus en mettant un
"-async 100000" (n'importe quel grand nombre convient). Je n'ai jamais
compris ce que ça faisait au juste mais bon...




Ceci dit sa source est un .mp4, donc ça m'étonnerait que ce soit ça le
problème...



j'ai eu une fois le cas de figure suivant :
.TS vers MKV : pas de désynchro du MKV sur un PC (VLC), mais désynchro
sur Fbx et platine.
c'est peut être le cas de son .MP4...

je ne m'étonne plus de rien en video :-)
Répondre en citant
Alf92
Le #25328202
Olivier Miakinen
Le 08/04/2013 14:51, Alf92 m'a répondu :

Si je comprends bien, ce serait la syntaxe pour écrire les temps
qui aurait causé le décalage ? Et donc, si j'écris -ss 3 au lieu
de -ss 00:00:03, et -t 131 au lieu de -t 00:02:11, ça a des chances
de mieux fonctionner ?



non, je pense que ta syntaxe est bonne aussi.



J'ai essayé, ça donne le même résultat.

attention simplement à la version de ffmpeg que tu emploies.
elles ne réagissent pas toute de même façon.



ffmpeg version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013
the Libav developers
built on Apr 2 2013 17:00:59 with gcc 4.6.3

avconv version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013
the Libav developers
built on Apr 2 2013 17:00:59 with gcc 4.6.3

autre piste en cas de pb :
si le décalage audio n'est pas présent dans la verion initiale de ta
video et apparait dans ta version "cut",



En effet. D'ailleurs il n'apparaît pas si je ne coupe que la fin.

Sinon, j'ai essayé des valeurs différentes de 3 secondes pour le
début. Quand je mets 1 ou 2, l'image démarre quand même au début
du reportage qui m'intéresse, mais le son commence avant. Quand je
mets plus de 3, l'image commence bien après et le son est toujours
décalé.

Au fait, j'aurais peut-être dû commencer par donner un lien vers la
vidéo d'origine puisqu'elle est facilement accessible :
Je l'ai téléchargée via l'extension de Firefox DownloadHelper.

c'est peut être un pb de type
"transport stream" avec des balises de synchro qui disparaissent qd tu
passes en flux "programm stream".
dans ce cas tente : faire le cut en passant pas un container M2TS, puis
faire ensuite un direct stream copy vers le container de ton choix
(celui qui pose le moins de pb est souvent le MKV).



Ahem... tu as peut-être bien raison, mais je n'y comprends rien.
Désolé. ;-)

Tu pourrais m'indiquer la ou les commandes à utiliser ?



je me penche dessus demain.
bonne nuit !
Répondre en citant
Publicité
Poster une réponse
Anonyme