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 :
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 time=130.92 bitrate= 731.5kbits/s
> video:10296kB audio:1297kB global headers:0kB muxing overhead 0.836823%
========================================================================
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 :
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%
5 : debute à la 5ème seconde 800 : pour une durée de 800 secondes (termine à 805ème seconde)
Olivier Miakinen <om+news@miakinen.net> a formulé :
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 :
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%
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 :
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%
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.
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.
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.
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).
Olivier Miakinen <om+news@miakinen.net> a formulé :
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).
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).
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...
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...
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...
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...
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...
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...
Alf92
pehache a formulé :
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.
pehache <pehache.7@gmail.com> a formulé :
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.
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.
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 : <http://videos.tf1.fr/jt-we/des-bisons-en-lozere-7917027.html>. 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
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 :
<http://videos.tf1.fr/jt-we/des-bisons-en-lozere-7917027.html>.
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 ?
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 : <http://videos.tf1.fr/jt-we/des-bisons-en-lozere-7917027.html>. 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
Olivier Miakinen
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.
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.
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.
Alf92
pehache a formulé :
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 :-)
pehache <pehache.7@gmail.com> a formulé :
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...
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 :-)
Alf92
Olivier Miakinen <om+ a formulé :
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 : <http://videos.tf1.fr/jt-we/des-bisons-en-lozere-7917027.html>. 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 !
Olivier Miakinen <om+news@miakinen.net> a formulé :
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 :
<http://videos.tf1.fr/jt-we/des-bisons-en-lozere-7917027.html>.
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 ?
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 : <http://videos.tf1.fr/jt-we/des-bisons-en-lozere-7917027.html>. 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 ?
