OGV Format é reproduzido corretamente no meu computador, mas a transcodificação descarta os quadros (duplicados?)

Eu fiz um conjunto de screencasts usando o recordmydesktop no ubuntu 12.10. A saída é um arquivo ogv. Quando assisto o arquivo ogv usando o player de filme padrão (totem), ele fica bem - o áudio e o vídeo estão sincronizados. Quando é transcodificado (por mim ou pelo youtube), o áudio e o vídeo ficam fora de sincronia. Parece que eu pulo um slide ou dois enquanto narro.

Atualizar

Suspeito que o problema seja mais adequadamente caracterizado como descartar quadros duplicados durante a transcodificação. A conversão de vídeo para onde o mouse está se movendo parece normalmente funcionar bem. Mas quando estou falando durante um slide, esses quadros duplicados são descartados.

Eu vi isso, mas não é bem a minha situação (tentando ir do ogv -> qualquer coisa) /superuser/436187/ffmpeg-convert-video-w-dropped-frames-out-of-sync

Arquivos AVI parecem traduzir corretamente! Presumo que isso seja uma grande dica para alguém. Eu ainda gostaria de rastrear o problema subjacente. Estou testando a conversão dos meus vídeos anteriores para AVI, mas isso demora um pouco, pois preciso verificar cada transição.

Exemplos

Este é o arquivo OGV original do gtk-recordmydesktop: http://dl.dropbox.com/u/64693533/sync_test/sync_test1.ogv

O vídeo começa com um slide por 10s e depois avança para mais 3 slides 5s cada. Cada vez que avanço os slides, toco no microfone também (10s, 15s, 20s, 25s).

Aqui estão algumas conversões que foram feitas (cada uma exibe seus próprios problemas de tempo do vídeo):

http://dl.dropbox.com/u/64693533/sync_test/sync_test1.mp4

• este mostra o primeiro slide no primeiro quadro, mas avança rapidamente
• isso foi feito usando o estoque ffmpeg

http://dl.dropbox.com/u/64693533/sync_test/sync_test1.ffmpeg-static.mp4

• este é bem próximo - por algum motivo, aos 13 anos, decide avançar
• isso foi feito usando a construção estática do ffmpeg de alguns dias atrás

Aqui está no youtube - você pode ver que, por volta dos 13 anos, avança mais cedo (do slide 1 -> slide 2):

Aqui está a prova de que o arquivo OGV funciona corretamente:

tradução ffmpeg

Usando ffmpeg ou avconv, parece-me que obtém resultados semelhantes aos do youtube (as transições parecem acontecer cedo, mas não necessariamente ao mesmo tempo).

Aqui está o comando que eu uso (com uma compilação estática recente de ffmpeg) e a saída:

$ ~ / ffmpeg / ffmpeg -i JSP.ogv JSP.mp4
versão ffmpeg N-50025-gb8bb661 Copyright (c) 2000-2013 the FFmpeg developers
  construído em 17 de fevereiro de 2013 05:23:03 com gcc 4.6 (Debian 4.6.3-1)
  configuração: --prefixo = / 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-grey --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
  dispositivo de biblioteca 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] Vários ossos do corpo para o mesmo fluxo não estão implementados. Atualize sua versão do FFmpeg para a mais recente do Git. Se o problema persistir, significa que seu arquivo possui um recurso que não foi implementado.
[ogg @ 0x34d4640] A análise do cabeçalho falhou no fluxo 0
[ogg @ 0x34d4640] Arquivo quebrado, quadro-chave não marcado corretamente.
Entrada # 0, ogg, de 'JSP.ogv':
  Duração: 00: 12: 49.67, início: 0.000000, taxa de bits: 224 kb / s
    Fluxo # 0: 0: Dados: nenhum
    Stream # 0: 1: Vídeo: theora, yuv420p, 1600x880 [SAR 1: 1 DAR 20:11], 15 fps, 15 tbr, 15 tbn, 15 tbc
    Metadados:
      RECORDMYDESKTOP: 0.3.8.1
    Stream # 0: 2: Áudio: vorbis, 22050 Hz, mono, fltp, 89 kb / s
[libx264 @ 0x369c5e0] usando SAR = 1/1
[libx264 @ 0x369c5e0] usando recursos de CPU: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
Perfil [libx264 @ 0x369c5e0] Alto, nível 4.0
[libx264 @ 0x369c5e0] 264 - núcleo 129 r2230 1cffe9f - codec H.264 / MPEG-4 AVC - Copyleft 2003-2012 - http://www.videolan.org/x264.html - options: cabac = 1 ref = 3 deblock = 1: 0: 0 analisar = 0x3: 0x113 me = hex subme = 7 psy = 1 psy_rd = 1,00: 0,00 mixed_ref = 1 me_range = 16 chroma_me = 1 treliça = 1 8x8dct = 1 cqm = 0 zona morta = 21,11 fast_pskip = 1 chroma_qp_offset = -2 threads = 6 lookahead_threads = 1 sliced_threads = 0 nr = 0 dizimado = 1 entrelaçado = 0 bluray_compat = 0 constrained_intra = 0 quadros de quadros = 3 b_pyramid = 2 b_adapt = 1 b_bias = 0 direto = 1 weightb = 1 open_gop = 0 pesop = 2 keyint = 250 keyint_min = 15 cenários = 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
Saída # 0, mp4, para 'JSP.mp4':
  Metadados:
    codificador: Lavf54.63.100
    Stream # 0: 0: Vídeo: h264 ([33] [0] [0] [0] / 0x0021), yuv420p, 1600x880 [SAR 1: 1 DAR 20:11], q = -1--1, 15360 tbn 15 tbc
    Metadados:
      RECORDMYDESKTOP: 0.3.8.1
    Stream # 0: 1: Áudio: aac ([64] [0] [0] [0] / 0x0040), 22050 Hz, mono, s16, 128 kb / s
Mapeamento de stream:
  Stream # 0: 1 -> # 0: 0 (theora -> libx264)
  Fluxo # 0: 2 -> # 0: 1 (vorbis -> libvo_aacenc)
Pressione [q] para parar, [?] Para obter ajuda
[ogg @ 0x34d4640] Arquivo quebrado, sem quadro-chave não marcado corretamente.
    Última mensagem repetida 2 vezes
Arquivo quebrado, quadro não-chave não marcado corretamente. = 00: 00: 08.37 taxa de bits = 28.7kbits / s dup = 66 drop = 0    
Arquivo quebrado, quadro-chave não marcado corretamente.time = 00: 00: 51.01 bitrate = 125.3kbits / s dup = 675 drop = 0    
Arquivo quebrado, quadro-chave não marcado corretamente. Time = 00: 00: 55.05 bitrate = 140.2kbits / s dup = 782 drop = 0    
Arquivo quebrado, quadro-chave não marcado corretamente.time = 00: 00: 59.60 bitrate = 140.5kbits / s dup = 836 drop = 0    
[ogg @ 0x34d4640] Arquivo quebrado, quadro-chave não marcado corretamente.
Arquivo quebrado, quadro-chave não marcado corretamente.time = 00: 01: 08.00 bitrate = 143.0kbits / s dup = 900 drop = 0    
Arquivo quebrado, quadro-chave não marcado corretamente.time = 00: 01: 11.86 bitrate = 141.6kbits / s dup = 910 drop = 0    

... repetido muitas vezes ...

Arquivo quebrado, quadro-chave não marcado corretamente.time = 00: 12: 47.62 bitrate = 153.0kbits / s dup = 9087 drop = 0    
quadro = 11521 fps = 87 q = -1,0 Lsize = 14849kB tempo = 00: 12: 49,48 bitrate = 158,1kbits / s dup = 9087 drop = 0    
vídeo: 2401kB áudio: 12024kB legenda: 0 cabeçalhos globais: 0kB muxing overhead 2.938094%
[libx264 @ 0x369c5e0] quadro I: 49 Média QP: 16.05 tamanho: 29658
[libx264 @ 0x369c5e0] quadro P: 2912 QP médio: 9,88 tamanho: 114
[libx264 @ 0x369c5e0] quadro B: 8560 QP médio: 12,76 tamanho: 78
[libx264 @ 0x369c5e0] quadros B consecutivos: 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% skip: 99.9%
[libx264 @ 0x369c5e0] mb B I16..4: 0,0% 0,0% 0,0% B16..8: 0,3% 0,0% 0,0% direto: 0,0% pule: 99,7% L0: 65,3% L1: 34,6% BI: 0,1%
[libx264 @ 0x369c5e0] Transformação 8x8 intra: 0,5% inter: 15,8%
[libx264 @ 0x369c5e0] codificado 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% 5%
[libx264 @ 0x369c5e0] i8c dc, h, v, p: 100% 0% 0% 0%
[libx264 @ 0x369c5e0] Quadros P ponderados: 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] kb / s: 25,60

O vídeo ainda avança mais cedo, mas em momentos diferentes. Parece que o gtk-recordmydesktop está gerando um "arquivo quebrado". O que é irritante é que o OGV funciona, então parece que eu devo fazer isso funcionar com algum conjunto de opções.

Descobri que posso renderizar o vídeo no kdenlive e parece estar funcionando lá. Eu ainda gostaria de saber o que está acontecendo. O kdenlive faz um trabalho muito melhor, mas ainda avança cedo às vezes.

Por que converter para OGV quando seu upload final for para o youtube, eu posso estar errado, mas você pode converter para codec de vídeo x264 com AAC Audio, mesmo no linux, e enviá-lo para o youtube, considerando que é o que eles preferem ser enviados de qualquer maneira. Você já tentou fazer um h264 e fazer o upload para o YouTube em vez do arquivo OGV e ver se esse era o problema. Porque eu apostaria que, se isso resolver, você sabe que foi um problema com o carregamento do OGV no youtube e, se isso não resolver, poderia ser um problema de taxa de quadros com a interpretação do youtube ou algo semelhante.

Houve muitos problemas com arquivos OGV enviados para o YouTube no passado. Não consigo imaginar que seja 100% fixo, mesmo neste momento.

http://support.google.com/youtube/bin/answer.py?hl=pt_PT&answer=1722171

EDIT: também acabei de perceber que sua filmagem original está a 15 qps ... isso pode muito bem ser a fonte do problema

EDIÇÃO 2: Eu parecia ter interpretado mal a pergunta um pouco ... sendo que você está começando com um arquivo de vídeo que é OGV, e vi que você está indo para o MP4 ... isso muda um pouco as coisas .. .mas acho que tem algo a ver com o áudio de 15fps e 22050 Hz ... Eu sei que a taxa de amostragem não tem nada a ver com a sincronização do áudio, mas com a experiência ao usar taxas de quadros e samplerates de áudio fora do padrão, Eu costumava ver à deriva ... conseguir sincronizá-las pode ser um pouco difícil, embora não seja possível editá-las após a gravação inicial com um editor de vídeo barato ...

Embora o software tenha melhorado com a deriva do áudio, ainda é um problema comum ao usar taxas de quadros e samplerates incomuns, pois os pontos de sincronização do quadro-chave não são padrão e podem arredondar os quadros-chave etc.

Você vê onde está escrito "Arquivo quebrado, quadro-chave não marcado corretamente". é a isso que se refere ...

meu conselho é que você chegue o mais perto possível, leve-o para um editor de vídeo, escorregue e corte o áudio para que ele corresponda da maneira que você deseja. Infelizmente, às vezes é assim que é corrigido ...

Os transcodificadores baseados em software nem sempre funcionam como deveriam ... entenda por que uma configuração do protools e / ou uma instalação ávida viria com hardware para garantir ainda mais os recursos de sincronização e taxas de quadros constantes, etc.

Outra coisa que você pode tentar é converter a filmagem em uma taxa de quadros padrão e tentar remarcar o áudio ... pois tenho certeza de que é o vídeo que está à deriva ... provavelmente muito devagar e desacelerando rapidamente. o fim ou vice-versa.

Edição: Consegui obter o vídeo para sincronizar com o original usando este comando ffmpeg ... pode ser necessário a cláusula de taxa que é o que eu suspeitava

ffmpeg -i sync_test1.ogv -strict experimental -pix_fmt yuv420p -r 15 -vcodec h264 -acodec aac sync_test1.mp4

Eu lutei com um problema semelhante no Ubuntu 12.04.3 LTS. Corrigi o problema usando a compilação estática ffmpeg, disponível em http://johnvansickle.com/ffmpeg/

Tente mudar o contêiner para avi em vez de transcodificar, o que parece funcionar melhor no youtube:

ffmpeg -i JSP.ogv -vcodec copy -acodec copy JSP.avi