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%
========================================================================
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é.
Le problème quand on fait des cut en ne réencodant pas, c'est qu'en principe on ne peut pas les faire n'importe où : le début doit être une image clef.
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les paramètres d'encodage)
Le 09/04/13 00:53, Olivier Miakinen 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",
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é.
Le problème quand on fait des cut en ne réencodant pas, c'est qu'en
principe on ne peut pas les faire n'importe où : le début doit être une
image clef.
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec
copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les
paramètres d'encodage)
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é.
Le problème quand on fait des cut en ne réencodant pas, c'est qu'en principe on ne peut pas les faire n'importe où : le début doit être une image clef.
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les paramètres d'encodage)
pehache
Le 09/04/13 00:51, Alf92 a écrit :
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 ??
En principe oui. Bon j'ai juste constaté que ça marchait dans certains cas, sans comprendre ce que ça faisait.
La description de vsync et async dans la doc est plutôt cryptique (comme souvent dans la doc de ffmpeg). Mais à la relecture, -async ne peut fonctionner que si le flux audio est réencodé.
-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.
Le 09/04/13 00:51, Alf92 a écrit :
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 ??
En principe oui. Bon j'ai juste constaté que ça marchait dans certains
cas, sans comprendre ce que ça faisait.
La description de vsync et async dans la doc est plutôt cryptique (comme
souvent dans la doc de ffmpeg). Mais à la relecture, -async ne peut
fonctionner que si le flux audio est réencodé.
-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.
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 ??
En principe oui. Bon j'ai juste constaté que ça marchait dans certains cas, sans comprendre ce que ça faisait.
La description de vsync et async dans la doc est plutôt cryptique (comme souvent dans la doc de ffmpeg). Mais à la relecture, -async ne peut fonctionner que si le flux audio est réencodé.
-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.
jdanield
Le 09/04/2013 08:10, pehache a écrit :
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les paramètres d'encodage)
alors utiliser avidemux qui permet de se caler sur les images clé.
j'utilise en général kdenlive pour ce genre de travail, c'est plus lourd mais moins rustique.
kdenlive utilise ffmpeg et peut écrire le script au lieu d'exécuter la commande, la lecture du script est instructive (mais pas facile)
jdd
Le 09/04/2013 08:10, pehache a écrit :
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec
copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les
paramètres d'encodage)
alors utiliser avidemux qui permet de se caler sur les images clé.
j'utilise en général kdenlive pour ce genre de travail, c'est plus
lourd mais moins rustique.
kdenlive utilise ffmpeg et peut écrire le script au lieu d'exécuter la
commande, la lecture du script est instructive (mais pas facile)
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les paramètres d'encodage)
alors utiliser avidemux qui permet de se caler sur les images clé.
j'utilise en général kdenlive pour ce genre de travail, c'est plus lourd mais moins rustique.
kdenlive utilise ffmpeg et peut écrire le script au lieu d'exécuter la commande, la lecture du script est instructive (mais pas facile)
Le problème quand on fait des cut en ne réencodant pas, c'est qu'en principe on ne peut pas les faire n'importe où : le début doit être une image clef.
Je sens que j'ai beaucoup de choses à découvrir sur les principes d'encodage audio et vidéo ! Cela m'intéresse, mais les journées ne sont pas extensibles malheureusement, et j'ai aussi d'autres centres d'intérêt.
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les paramètres d'encodage)
Ça marche ! Le résultat est un peu plus gros que celui obtenu avec les acodec et vcodec copy en gardant les trois secondes du début (3,8 secondes exactement) donc un peu plus gros bien qu'étant 3,8 secondes plus court, mais la différence n'est pas énorme.
Fichier d'origine : 14,3 Mo Avec -ss 0 -t 134 -acodec copy -codec copy : 12,6 Mo Avec -ss 3.8 -t 130.2 : 12.7 Mo
Cela dit, je suis quand même curieux de savoir si on peut faire mieux en ne réencodant pas tout.
Cordialement, -- Olivier Miakinen
Le 09/04/2013 08:10, pehache a écrit :
Le problème quand on fait des cut en ne réencodant pas, c'est qu'en
principe on ne peut pas les faire n'importe où : le début doit être une
image clef.
Je sens que j'ai beaucoup de choses à découvrir sur les principes
d'encodage audio et vidéo ! Cela m'intéresse, mais les journées ne
sont pas extensibles malheureusement, et j'ai aussi d'autres centres
d'intérêt.
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec
copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les
paramètres d'encodage)
Ça marche ! Le résultat est un peu plus gros que celui obtenu avec
les acodec et vcodec copy en gardant les trois secondes du début
(3,8 secondes exactement) donc un peu plus gros bien qu'étant 3,8
secondes plus court, mais la différence n'est pas énorme.
Fichier d'origine :
14,3 Mo
Avec -ss 0 -t 134 -acodec copy -codec copy :
12,6 Mo
Avec -ss 3.8 -t 130.2 :
12.7 Mo
Cela dit, je suis quand même curieux de savoir si on peut faire
mieux en ne réencodant pas tout.
Le problème quand on fait des cut en ne réencodant pas, c'est qu'en principe on ne peut pas les faire n'importe où : le début doit être une image clef.
Je sens que j'ai beaucoup de choses à découvrir sur les principes d'encodage audio et vidéo ! Cela m'intéresse, mais les journées ne sont pas extensibles malheureusement, et j'ai aussi d'autres centres d'intérêt.
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les paramètres d'encodage)
Ça marche ! Le résultat est un peu plus gros que celui obtenu avec les acodec et vcodec copy en gardant les trois secondes du début (3,8 secondes exactement) donc un peu plus gros bien qu'étant 3,8 secondes plus court, mais la différence n'est pas énorme.
Fichier d'origine : 14,3 Mo Avec -ss 0 -t 134 -acodec copy -codec copy : 12,6 Mo Avec -ss 3.8 -t 130.2 : 12.7 Mo
Cela dit, je suis quand même curieux de savoir si on peut faire mieux en ne réencodant pas tout.
Cordialement, -- Olivier Miakinen
Olivier Miakinen
Le 09/04/2013 08:20, jdanield a écrit :
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les paramètres d'encodage)
alors utiliser avidemux qui permet de se caler sur les images clé.
j'utilise en général kdenlive pour ce genre de travail, c'est plus lourd mais moins rustique.
kdenlive utilise ffmpeg et peut écrire le script au lieu d'exécuter la commande, la lecture du script est instructive (mais pas facile)
J'essaierai aussi, mais pas maintenant car je devrais déjà être parti depuis longtemps. Merci !
Le 09/04/2013 08:20, jdanield a écrit :
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec
copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les
paramètres d'encodage)
alors utiliser avidemux qui permet de se caler sur les images clé.
j'utilise en général kdenlive pour ce genre de travail, c'est plus
lourd mais moins rustique.
kdenlive utilise ffmpeg et peut écrire le script au lieu d'exécuter la
commande, la lecture du script est instructive (mais pas facile)
J'essaierai aussi, mais pas maintenant car je devrais déjà être parti
depuis longtemps. Merci !
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les paramètres d'encodage)
alors utiliser avidemux qui permet de se caler sur les images clé.
j'utilise en général kdenlive pour ce genre de travail, c'est plus lourd mais moins rustique.
kdenlive utilise ffmpeg et peut écrire le script au lieu d'exécuter la commande, la lecture du script est instructive (mais pas facile)
J'essaierai aussi, mais pas maintenant car je devrais déjà être parti depuis longtemps. Merci !
jdanield
Le 09/04/2013 09:40, Olivier Miakinen a écrit :
J'essaierai aussi, mais pas maintenant car je devrais déjà être parti depuis longtemps. Merci !
tu ne pourra pas juger, alors, car on ne peut pas être juge et parti :-)
jdd
Le 09/04/2013 09:40, Olivier Miakinen a écrit :
J'essaierai aussi, mais pas maintenant car je devrais déjà être parti
depuis longtemps. Merci !
tu ne pourra pas juger, alors, car on ne peut pas être juge et parti :-)
J'essaierai aussi, mais pas maintenant car je devrais déjà être parti depuis longtemps. Merci !
tu ne pourra pas juger, alors, car on ne peut pas être juge et parti :-)
jdd
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 ?
j'ai chargé la video et essayé de faite le cut.
avec FFMPEG : ------------------ ffmpeg -ss 3 -t 131 -i Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY.MP4 -vcodec copy -acodec copy Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY-FFMPEG-CUT.MP4 pause ------------------ resultat : pas de désynchro mais les 3 premières secondes n'ont pas été coupées. http://frpn.free.fr/0divers/testvideo/Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY-FFMPEG-CUT.MP4
avec VideoRedo : au chargement de la video VideoRedo m'indique une "erreur de positionnement à 00:00:00" et propose de corriger. si j'accepte de corriger le solt tourne en boucle. si je ne corrige pas, le soft accepte de faire le cut proprement (les 3 seconde et la fin sont bien coupés) et il n'y a pas de désynchro. http://frpn.free.fr/0divers/testvideo/Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY-VIDEORODO-CUT.mp4
autre essai avec FFMPEG : cette fois ci je passe par une étape intermédiare avec un container M2TS réputé robuste ------------------ ffmpeg -i Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY.mp4 -bsf h264_mp4toannexb -vcodec copy -acodec copy Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY.M2TS
pause ------------------ à noter que FFMPEG m'aréclamé les fitres -bsf h264_mp4toannexb et -absf aac_adtstoasc dont j'ignore la fonction. résultat : le cut est bien fait à la seconde 3 mais la video est noir jusqu'à la seconde 6. http://frpn.free.fr/0divers/testvideo/Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY-FFMPEG2-CUT.MP4
conclusion : la video a bien un problème à son début. seul VideoRedo semble capable de le traiter sans réencoder. (je n'ai pas fait le test en réencodant la vidéo avec FFMPEG mais il est probable que cela écrase le problème).
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 ?
j'ai chargé la video et essayé de faite le cut.
avec FFMPEG :
------------------
ffmpeg -ss 3 -t 131 -i
Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY.MP4
-vcodec copy -acodec copy
Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY-FFMPEG-CUT.MP4
pause
------------------
resultat : pas de désynchro mais les 3 premières secondes n'ont pas été
coupées.
http://frpn.free.fr/0divers/testvideo/Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY-FFMPEG-CUT.MP4
avec VideoRedo :
au chargement de la video VideoRedo m'indique une "erreur de
positionnement à 00:00:00" et propose de corriger.
si j'accepte de corriger le solt tourne en boucle.
si je ne corrige pas, le soft accepte de faire le cut proprement (les 3
seconde et la fin sont bien coupés) et il n'y a pas de désynchro.
http://frpn.free.fr/0divers/testvideo/Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY-VIDEORODO-CUT.mp4
autre essai avec FFMPEG :
cette fois ci je passe par une étape intermédiare
avec un container M2TS réputé robuste
------------------
ffmpeg -i
Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY.mp4 -bsf
h264_mp4toannexb -vcodec copy -acodec copy
Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY.M2TS
pause
------------------
à noter que FFMPEG m'aréclamé les fitres
-bsf h264_mp4toannexb
et -absf aac_adtstoasc
dont j'ignore la fonction.
résultat : le cut est bien fait à la seconde 3 mais la video est noir
jusqu'à la seconde 6.
http://frpn.free.fr/0divers/testvideo/Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY-FFMPEG2-CUT.MP4
conclusion :
la video a bien un problème à son début.
seul VideoRedo semble capable de le traiter sans réencoder.
(je n'ai pas fait le test en réencodant la vidéo avec FFMPEG mais il
est probable que cela écrase le problème).
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 ?
j'ai chargé la video et essayé de faite le cut.
avec FFMPEG : ------------------ ffmpeg -ss 3 -t 131 -i Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY.MP4 -vcodec copy -acodec copy Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY-FFMPEG-CUT.MP4 pause ------------------ resultat : pas de désynchro mais les 3 premières secondes n'ont pas été coupées. http://frpn.free.fr/0divers/testvideo/Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY-FFMPEG-CUT.MP4
avec VideoRedo : au chargement de la video VideoRedo m'indique une "erreur de positionnement à 00:00:00" et propose de corriger. si j'accepte de corriger le solt tourne en boucle. si je ne corrige pas, le soft accepte de faire le cut proprement (les 3 seconde et la fin sont bien coupés) et il n'y a pas de désynchro. http://frpn.free.fr/0divers/testvideo/Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY-VIDEORODO-CUT.mp4
autre essai avec FFMPEG : cette fois ci je passe par une étape intermédiare avec un container M2TS réputé robuste ------------------ ffmpeg -i Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY.mp4 -bsf h264_mp4toannexb -vcodec copy -acodec copy Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY.M2TS
pause ------------------ à noter que FFMPEG m'aréclamé les fitres -bsf h264_mp4toannexb et -absf aac_adtstoasc dont j'ignore la fonction. résultat : le cut est bien fait à la seconde 3 mais la video est noir jusqu'à la seconde 6. http://frpn.free.fr/0divers/testvideo/Des_bisons_en_Loz_re_-_Replay_JT_Le_Journal_du_week-end_-_MY-FFMPEG2-CUT.MP4
conclusion : la video a bien un problème à son début. seul VideoRedo semble capable de le traiter sans réencoder. (je n'ai pas fait le test en réencodant la vidéo avec FFMPEG mais il est probable que cela écrase le problème).
pehache
Le 09/04/13 09:39, Olivier Miakinen a écrit :
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les paramètres d'encodage)
Ça marche ! Le résultat est un peu plus gros que celui obtenu avec les acodec et vcodec copy en gardant les trois secondes du début (3,8 secondes exactement) donc un peu plus gros bien qu'étant 3,8 secondes plus court, mais la différence n'est pas énorme.
Fichier d'origine : 14,3 Mo Avec -ss 0 -t 134 -acodec copy -codec copy : 12,6 Mo Avec -ss 3.8 -t 130.2 : 12.7 Mo
OK... Il faudrait maintenant mettre quelques paramètres d'encodage pour optimiser le résultat, si tant est que ça ait une importance pour ce que tu fais de cette video. Mais je passe la main à Alf pour ça :-)
Le 09/04/13 09:39, Olivier Miakinen a écrit :
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec
copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les
paramètres d'encodage)
Ça marche ! Le résultat est un peu plus gros que celui obtenu avec
les acodec et vcodec copy en gardant les trois secondes du début
(3,8 secondes exactement) donc un peu plus gros bien qu'étant 3,8
secondes plus court, mais la différence n'est pas énorme.
Fichier d'origine :
14,3 Mo
Avec -ss 0 -t 134 -acodec copy -codec copy :
12,6 Mo
Avec -ss 3.8 -t 130.2 :
12.7 Mo
OK... Il faudrait maintenant mettre quelques paramètres d'encodage pour
optimiser le résultat, si tant est que ça ait une importance pour ce que
tu fais de cette video. Mais je passe la main à Alf pour ça :-)
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les paramètres d'encodage)
Ça marche ! Le résultat est un peu plus gros que celui obtenu avec les acodec et vcodec copy en gardant les trois secondes du début (3,8 secondes exactement) donc un peu plus gros bien qu'étant 3,8 secondes plus court, mais la différence n'est pas énorme.
Fichier d'origine : 14,3 Mo Avec -ss 0 -t 134 -acodec copy -codec copy : 12,6 Mo Avec -ss 3.8 -t 130.2 : 12.7 Mo
OK... Il faudrait maintenant mettre quelques paramètres d'encodage pour optimiser le résultat, si tant est que ça ait une importance pour ce que tu fais de cette video. Mais je passe la main à Alf pour ça :-)
pehache
Le 09/04/13 08:20, jdanield a écrit :
Le 09/04/2013 08:10, pehache a écrit :
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les paramètres d'encodage)
alors utiliser avidemux qui permet de se caler sur les images clé.
Il ne veut pas se caler sur les images clefs, justement, mais couper là où il a envie de couper. Ce qui implique en principe un réencodage.
Le 09/04/13 08:20, jdanield a écrit :
Le 09/04/2013 08:10, pehache a écrit :
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec
copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les
paramètres d'encodage)
alors utiliser avidemux qui permet de se caler sur les images clé.
Il ne veut pas se caler sur les images clefs, justement, mais couper là
où il a envie de couper. Ce qui implique en principe un réencodage.
Essaye en réencodant (tu vires simplement les -acodec copy et -vcodec copy, juste pour vérifier. Si ça marche il faudra ensuite affiner les paramètres d'encodage)
alors utiliser avidemux qui permet de se caler sur les images clé.
Il ne veut pas se caler sur les images clefs, justement, mais couper là où il a envie de couper. Ce qui implique en principe un réencodage.
