J'ai fait un ensemble de captures d'écran en utilisant recordmydesktop sur Ubuntu 12.10. La sortie est un fichier ogv. Lorsque je regarde le fichier ogv à l'aide du lecteur de film par défaut (totem), il semble bien - l'audio et la vidéo sont synchronisés. Lorsqu'il est transcodé (par moi ou youtube), l'audio et la vidéo sont désynchronisés. On dirait que je saute une ou deux diapositives pendant la narration.
Mise à jour
Je soupçonne que le problème est plus correctement caractérisé comme la suppression de trames en double pendant le transcodage. La conversion de vidéo là où la souris se déplace semble normalement fonctionner correctement. Mais quand je parle juste pendant une diapositive, ces images en double sont supprimées.
J'ai vu cela mais ce n'est pas tout à fait ma situation (essayer de passer de ogv -> n'importe quoi) /superuser/436187/ffmpeg-convert-video-w-dropped-frames-out-of-sync
Les fichiers AVI semblent se traduire correctement! Je suppose que ce sera un gros indice pour quelqu'un. J'aimerais toujours retrouver le problème sous-jacent. Je teste la conversion de mes vidéos précédentes en AVI mais cela prend un certain temps car je dois vérifier chaque transition.
Exemples
Il s'agit du fichier OGV d'origine de gtk-recordmydesktop: http://dl.dropbox.com/u/64693533/sync_test/sync_test1.ogv
La vidéo commence par une diapositive de 10 secondes, puis passe à 3 diapositives supplémentaires de 5 secondes chacune. Chaque fois que j'avance des diapositives, je tape aussi sur le microphone (10s, 15s, 20s, 25s).
Voici quelques conversions qui ont été effectuées (chacune affiche ses propres problèmes de synchronisation vidéo):
http://dl.dropbox.com/u/64693533/sync_test/sync_test1.mp4
- celui-ci montre la première diapositive dans la première image mais passe rapidement devant
- cela a été fait en utilisant le stock ffmpeg
http://dl.dropbox.com/u/64693533/sync_test/sync_test1.ffmpeg-static.mp4
- celui-ci est assez proche - pour une raison quelconque à 13 ans, il décide d'avancer bien
- cela a été fait en utilisant la version statique de ffmpeg d'il y a quelques jours
Le voici sur YouTube - vous pouvez voir qu'à 13 ans environ, il avance tôt (de la diapositive 1 à la diapositive 2):
Voici la preuve que le fichier OGV fonctionne correctement:
traduction ffmpeg
En utilisant ffmpeg ou avconv, je semble obtenir des résultats similaires à youtube (les transitions semblent se produire tôt mais pas nécessairement en même temps).
Voici la commande que j'utilise (avec une version statique récente de ffmpeg) et la sortie:
$ ~ / ffmpeg / ffmpeg -i JSP.ogv JSP.mp4 ffmpeg version N-50025-gb8bb661 Copyright (c) 2000-2013 les développeurs FFmpeg construit le 17 février 2013 05:23:03 avec gcc 4.6 (Debian 4.6.3-1) configuration: --prefix = / root / ffmpeg-static / 64bit --extra-cflags = '- I / root / ffmpeg-static / 64bit / include -static' --extra-ldflags = '- L / root / ffmpeg- static / 64bit / lib -static '--extra-libs =' - lxml2 -lexpat -lfreetype '--enable-static --disable-shared --disable-ffserver --disable-doc --enable-bzlib --enable -zlib --enable-postproc --enable-runtime-cpudetect --enable-libx264 --enable-gpl --enable-libtheora --enable-libvorbis --enable-libmp3lame --enable-gray --enable-libass - -enable-libfreetype --enable-libopenjpeg --enable-libspeex --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-version3 --enable-libvpx libavutil 52. 17.101 / 52. 17.101 libavcodec 54. 91.103 / 54. 91.103 libavformat 54. 63.100 / 54. 63.100 libavdevice 54. 3.103 / 54. 3.103 libavfilter 3. 38.100 / 3. 38.100 libswscale 2. 2.100 / 2. 2.100 libswresample 0. 17.102 / 0. 17.102 libpostproc 52. 2.100 / 52. 2.100 [ogg @ 0x34d4640] Plusieurs fisbones pour le même flux ne sont pas implémentés. Mettez à jour votre version FFmpeg vers la plus récente de Git. Si le problème persiste, cela signifie que votre fichier possède une fonctionnalité qui n'a pas été implémentée. [ogg @ 0x34d4640] L'analyse des en-têtes a échoué pour le flux 0 [ogg @ 0x34d4640] Fichier cassé, l'image clé n'est pas correctement marquée. Entrée # 0, ogg, de 'JSP.ogv': Durée: 00: 12: 49.67, début: 0.000000, débit: 224 kb / s Flux # 0: 0: Données: aucune Stream # 0: 1: Vidéo: theora, yuv420p, 1600x880 [SAR 1: 1 DAR 20:11], 15 ips, 15 tbr, 15 tbn, 15 tbc Métadonnées: RECORDMYDESKTOP: 0.3.8.1 Stream # 0: 2: Audio: vorbis, 22050 Hz, mono, fltp, 89 kb / s [libx264 @ 0x369c5e0] en utilisant SAR = 1/1 [libx264 @ 0x369c5e0] en utilisant les capacités du processeur: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX [libx264 @ 0x369c5e0] profil Haut, niveau 4.0 [libx264 @ 0x369c5e0] 264 - core 129 r2230 1cffe9f - codec AVC H.264 / MPEG-4 - Copyleft 2003-2012 - http://www.videolan.org/x264.html - options: cabac = 1 ref = 3 deblock = 1: 0: 0 analyse = 0x3: 0x113 me = hex subme = 7 psy = 1 psy_rd = 1.00: 0.00 mixed_ref = 1 me_range = 16 chroma_me = 1 treillis = 1 8x8dct = 1 cqm = 0 zone morte = 21,11 fast_pskip = 1 chroma_qp_offset = -2 threads = 6 lookahead_threads = 1 sliced_threads = 0 nr = 0 decimate = 1 entrelacé = 0 bluray_compat = 0 constrained_intra = 0 bframes = 3 b_pyramid = 2 b_adapt = 1 b_bias = 0 direct = 1 weightb = 1 open_gop weightp = 2 keyint = 250 keyint_min = 15 scenecut = 40 intra_refresh = 0 rc_lookahead = 40 rc = crf mbtree = 1 crf = 23,0 qcomp = 0,60 qpmin = 0 qpmax = 69 qpstep = 4 ip_ratio = 1,40 aq = 1: 1,00 Sortie # 0, mp4, vers 'JSP.mp4': Métadonnées: encodeur: Lavf54.63.100 Flux # 0: 0: Vidéo: h264 ([33] [0] [0] [0] / 0x0021), yuv420p, 1600x880 [SAR 1: 1 DAR 20:11], q = -1--1, 15360 tbn , 15 cuillères à soupe Métadonnées: RECORDMYDESKTOP: 0.3.8.1 Flux # 0: 1: Audio: aac ([64] [0] [0] [0] / 0x0040), 22050 Hz, mono, s16, 128 kb / s Cartographie de flux: Flux # 0: 1 -> # 0: 0 (theora -> libx264) Flux # 0: 2 -> # 0: 1 (vorbis -> libvo_aacenc) Appuyez sur [q] pour arrêter, [?] Pour obtenir de l'aide [ogg @ 0x34d4640] Fichier cassé, non-image clé non correctement marqué. Dernier message répété 2 fois Fichier cassé, les images non clés ne sont pas correctement marquées. = 00: 00: 08,37 débit binaire = 28,7 kbits / s dup = 66 drop = 0 Fichier cassé, l'image clé n'est pas correctement marquée. Time = 00: 00: 51.01 bitrate = 125.3kbits / s dup = 675 drop = 0 Fichier cassé, l'image clé n'est pas correctement marquée. Time = 00: 00: 55.05 bitrate = 140.2kbits / s dup = 782 drop = 0 Fichier cassé, l'image clé n'est pas correctement marquée. Time = 00: 00: 59.60 bitrate = 140.5kbits / s dup = 836 drop = 0 [ogg @ 0x34d4640] Fichier cassé, l'image clé n'est pas correctement marquée. Fichier cassé, l'image clé n'est pas correctement marquée. Time = 00: 01: 08.00 bitrate = 143.0kbits / s dup = 900 drop = 0 Fichier cassé, l'image clé n'est pas correctement marquée. Time = 00: 01: 11.86 bitrate = 141.6kbits / s dup = 910 drop = 0
... répété plusieurs fois ...
Fichier cassé, l'image clé n'est pas correctement marquée. Time = 00: 12: 47.62 bitrate = 153.0kbits / s dup = 9087 drop = 0 frame = 11521 fps = 87 q = -1.0 Lsize = 14849kB time = 00: 12: 49.48 bitrate = 158.1kbits / s dup = 9087 drop = 0 vidéo: 2401kB audio: 12024kB sous-titre: 0 en-têtes globaux: 0kB overhead de multiplexage 2.938094% [libx264 @ 0x369c5e0] trame I: 49 QP moyen: 16.05 taille: 29658 [libx264 @ 0x369c5e0] trame P: 2912 QP moyen: 9,88 taille: 114 [libx264 @ 0x369c5e0] trame B: 8560 QP moyen: 12,76 taille: 78 [libx264 @ 0x369c5e0] trames B consécutives: 0,9% 0,1% 0,2% 98,9% [libx264 @ 0x369c5e0] mb I I16..4: 90,8% 0,4% 8,8% [libx264 @ 0x369c5e0] mb P I16..4: 0,0% 0,0% 0,0% P16..4: 0,0% 0,0% 0,0% 0,0% 0,0% saut: 99,9% [libx264 @ 0x369c5e0] mb B I16..4: 0,0% 0,0% 0,0% B16..8: 0,3% 0,0% 0,0% direct: 0,0% saut: 99,7% L0: 65,3% L1: 34,6% BI: 0,1% [libx264 @ 0x369c5e0] Transformation 8x8 intra: 0,5% inter: 15,8% [libx264 @ 0x369c5e0] codé y, uvDC, uvAC intra: 6,4% 0,1% 0,1% inter: 0,0% 0,0% 0,0% [libx264 @ 0x369c5e0] i16 v, h, dc, p: 94% 4% 2% 0% [libx264 @ 0x369c5e0] i8 v, h, dc, ddl, ddr, vr, hd, vl, hu: 19% 22% 44% 1% 2% 2% 3% 1% 6% [libx264 @ 0x369c5e0] i4 v, h, dc, ddl, ddr, vr, hd, vl, hu: 35% 17% 19% 4% 5% 5% 5% 5% 5% [libx264 @ 0x369c5e0] i8c dc, h, v, p: 100% 0% 0% 0% [libx264 @ 0x369c5e0] Cadres P pondérés: Y: 0,0% UV: 0,0% [libx264 @ 0x369c5e0] ref P L0: 82,5% 1,4% 11,9% 4,3% [libx264 @ 0x369c5e0] ref B L0: 47,2% 52,4% 0,4% [libx264 @ 0x369c5e0] ref B L1: 99,2% 0,8% [libx264 @ 0x369c5e0] ko / s: 25,60
La vidéo avance encore tôt mais à des moments différents. Il semble que gtk-recordmydesktop génère un "fichier cassé". Ce qui est ennuyeux, c'est que l'OGV fonctionne donc il semble que je devrais être capable de faire fonctionner cela avec un ensemble d'options.
J'ai trouvé que je peux rendre la vidéo dans kdenlive et cela semble fonctionner là-bas. J'aimerais toujours savoir ce qui se passe. kdenlive fait un bien meilleur travail, mais il avance encore tôt parfois.
la source
ffmpeg
binaire inclus .Réponses:
Pourquoi convertir en OGV lorsque votre téléchargement final va être sur YouTube, je me trompe peut-être, mais vous pouvez convertir au codec vidéo x264 avec AAC Audio même sur Linux et le télécharger sur YouTube étant donné que c'est ce qu'ils préfèrent être téléchargé de toute façon. Avez-vous essayé de créer un h264 et de le télécharger sur YouTube au lieu du fichier OGV et de voir si c'était le problème. Parce que je parierais que si cela le résout, vous savez alors que c'était un problème avec le téléchargement de l'OGV sur YouTube, et si cela ne le résout pas, cela pourrait être un problème de fréquence d'images avec l'interprétation de YouTube ou quelque chose de similaire.
Il y a eu beaucoup de problèmes avec les fichiers OGV téléchargés sur YouTube dans le passé. Je ne peux pas imaginer qu'il soit 100% fixe même à ce stade.
http://support.google.com/youtube/bin/answer.py?hl=en&answer=1722171
EDIT: a également remarqué que votre métrage d'origine est à 15 images par seconde ... cela pourrait très bien être la source du problème
EDIT 2: J'ai semblé avoir un peu mal lu la question un peu ... étant que vous commencez avec un fichier vidéo qui est OGV, et j'ai vu que vous allez au MP4 ... cela change un peu les choses .. .mais je vais supposer que cela a quelque chose à voir avec l'audio 15fps et 22050 Hz ... Je sais que la fréquence d'échantillonnage n'a rien à voir avec la synchronisation de l'audio, mais par expérience lors de l'utilisation de fréquences d'images non standard et d'échantillonnages audio, J'ai eu tendance à voir dériver ... les synchroniser peut être assez difficile sans pouvoir les modifier après l'enregistrement initial avec un éditeur vidéo bon marché ...
Bien que les logiciels se soient améliorés sur la dérive audio, cela reste un problème courant lors de l'utilisation de fréquences d'images et d'échantillonnages inhabituels car les points de synchronisation d'images clés ne sont pas standard et pourraient arrondir les images clés, etc.
Vous voyez où il est dit "Fichier cassé, l'image clé n'est pas correctement marquée." c'est à cela qu'il fait référence ...
mon conseil pour vous serait de le rapprocher le plus possible, de le prendre dans un éditeur vidéo et de le glisser et de couper l'audio pour qu'il corresponde à la façon dont vous le souhaitez. Malheureusement, c'est parfois ainsi que cela est résolu ...
Les transcodeurs basés sur logiciel ne fonctionnent pas toujours comme ils le devraient ... pourquoi une configuration protools et / ou une configuration avide viendraient avec du matériel pour assurer davantage les capacités de synchronisation et des fréquences d'images constantes etc ...
Une autre chose que vous pourriez essayer est de convertir le métrage en un taux de rafraîchissement standard, et d'essayer de recomposer l'audio ... car je suis presque sûr que c'est la vidéo qui dérive ... probablement très légèrement ralentir puis accélérer la fin ou vice versa.
EDIT: J'ai réussi à synchroniser la vidéo avec l'original en utilisant cette commande ffmpeg ... il peut avoir besoin de la clause de taux, ce que je soupçonnais
ffmpeg -i sync_test1.ogv -strict experimental -pix_fmt yuv420p -r 15 -vcodec h264 -acodec aac sync_test1.mp4
la source
-r 15
revient à l'omettre car ffmpeg héritera par défaut de la fréquence d'images en entrée, et les fichiers de sortie résultants, avec ou sans,-r 15
sont exactement les mêmes avec ffmpeg de git head (version N-50285-gad89952). Si cela fonctionne pour vous en utilisant une ancienne version de ffmpeg, cela peut être une régression et doit être signalé au traqueur de bogues FFmpeg .J'ai rencontré des problèmes similaires sur Ubuntu 12.04.3 LTS. J'ai résolu le problème en utilisant la version statique de ffmpeg qui est disponible sur http://johnvansickle.com/ffmpeg/
la source
Essayez simplement de changer le conteneur en avi plutôt que de transcoder, ce qui semble mieux fonctionner pour youtube:
la source