Especificando parâmetros para criar vídeos para o demuxer de concat do ffmpeg (para evitar uma grande recodificação)

2

ffmpeg pode ser usado para concatenar arquivos juntos :

If you have media files with exactly the same codec and codec parameters you can concatenate them [...]

(ênfase minha) Minha intenção 1 é produzir arquivos de mídia com o mesmo codec e parâmetros para que eu possa aproveitar a concatência sem incorrer em um longo re-encode .

Preâmbulo:

Eu tenho um arquivo que gostaria de cortar e manter partes úteis. Eu escrevi um script python para encontrar o quadro-chave mais próximo para o ponto de corte desejado, e cortar lá, pois ao fazer uma cópia de fluxo o ffmpeg só pode usar quadros I:

Using -ss as input option together with -c:v copy might not be accurate since ffmpeg is forced to only use/split on i-frames.

Por acaso, as divisões não estão acontecendo exatamente no momento certo, mas estão próximas o suficiente para que eu possa me concentrar em outra parte da equação. Se eu usar o concat demuxer neste ponto, as diferentes partes serão unidas perfeitamente - até agora, tudo bem!

No entanto, gostaria que houvesse transições suaves entre esses segmentos, então dividi ainda mais esses segmentos para que os atalhos possam ser usados para criar uma transição de crossfade sem recodificar todo o conjunto de arquivos.

Um diagrama básico provavelmente ajudaria a ilustrar isso:

  [111AAAA111BBBBB111111CCCCCCC1111DDDDD111]   | (original file)
     [AAAA] [BBBBB]    [CCCCCCC]  [DDDDD]      | (desired clips extracted)
[AAA] [A][B] [BBB] [B][C] [CCCCC] [C][D] [DDDD]| (split ends from clips)
      [AAA][ab][BBB][bc][CCCCC][cd][DDD]       | (transitions between short ends)
            [AAAabBBBbcCCCCCcdDDD]             | (intended output)

Problema:

Aqui é onde eu cheguei. Quando usei ffmpeg ' concat demuxer para juntar os clipes acima, obtenho vídeo e artefatos de áudio significativos na reprodução. Meu palpite é que há uma incompatibilidade nos parâmetros do codec, conforme observado como um pré-requisito no início dessa questão. Então, verificar o vídeo com ffprobe dá:

$ ffprobe -i ab-transition.mkv 2>&1 | grep Stream.*Video ; ffprobe -i B.mkv 2>&1 | grep Stream.*Video
Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709/bt709/iec61966-2-1), 1280x720, SAR 1:1 DAR 16:9, 62.50 fps, 62.50 tbr, 1k tbn, 120 tbc (default)
Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709/bt709/iec61966-2-1), 1280x720 [SAR 1:1 DAR 16:9], 62.50 fps, 62.50 tbr, 1k tbn, 125 tbc (default)

(omiti a saída do stream de áudio, já que os streams têm ostensivamente os mesmos parâmetros, mas o áudio não está unido corretamente)

Existem diferenças. Eu usei o -show_streams para obter informações mais detalhadas, que estão disponíveis no link (uma linha em branco separando duas saídas). diff ing a saída dá:

7c7
< codec_time_base=1/120
---
> codec_time_base=1/125
70,71c70,71
< start_pts=12
< start_time=0.012000
---
> start_pts=11
> start_time=0.011000

Atualização:

Eu encontrei opções e parâmetros correspondentes para tudo o que eu posso ver, exceto a base de tempo do codec (tbc). Existe uma configuração que me permitirá definir codec_time_base (tbc) ? A configuração -r não tem efeito.

Atualização 2: Temendo que essa questão fosse muito específica para SU, fiz a pergunta da lista de discussão ffmpeg-user. Infelizmente -time_base não é uma opção de codificador apropriada neste caso:

This is an option for FFmpeg-internal encoders that you try to use for an external encoder (x264).

E mais, infelizmente, quando perguntei sobre viabilidade geral, a resposta foi

I don't think this is possible.

Eu pedi esclarecimentos e possibilidades em torno do software de codificação original - neste caso, OBS - que é potencialmente menos flexível na especificação de opção do que ffmpeg devido a ter que corresponder às especificações de formato de consumidor ao vivo (Twitch). Eu ainda tenho que receber uma resposta da lista de discussão, mas pedi nos fóruns da OBS também.

Mais importante, o controle para isso permite que eu use o concat demuxer em ffmpeg para juntar tudo isso sem a necessidade de um longo processo de codificação ? Muito obrigado antecipadamente.

(Eu percebo que este é um mural de texto e meio, então adições, subtrações ou sugestões de esclarecimento são bem-vindas, é claro. Eu teria um link para mais informações oficiais, mas sendo < 10 rep I não pode incluir mais de 2 links!)

1 : Para mais contexto, veja minha pergunta relacionada: Como ingressar de maneira eficiente e automatizada em videoclipes usando transições curtas?

    
por bertieb 24.06.2015 / 13:49

1 resposta

1

De acordo com as opções genéricas de codec , você pode adicionar -time_base ao codificador libx264 configurado durante a criação dos clipes de transição.

Se eu estou lendo suas comparações de arquivos corretamente - ab-transition.mkv está mostrando um tcb de 1/120 enquanto B.mkv está mostrando 1/125 (qual é o valor que você quer, certo?) - Eu sugeriria incluir um valor -r também para garantir que tanto a taxa de quadros quanto a base de tempo sejam mantidas:

-c:v libx264 [preset & crf/qp settings] -r 62.50 -time_base 1/125 [output]

Como uma observação, gostaria de mencionar que minhas próprias tentativas de usar o demuxer de concat sem recodificar totalmente o (s) arquivo (s) de saída sempre resultaram em problemas, principalmente sincronização de áudio e gotas de quadro. Os melhores resultados vieram da codificação de clipes separados com áudio e vídeo sem perdas para preservar a qualidade original ...

-c:v -libx264 -preset ultrafast -qp 0 -c:a pcm_s16le

... então codifica o arquivo final usando as mesmas configurações de áudio / vídeo usadas para criar o (s) vídeo (s) de origem.

    
por 27.06.2015 / 08:01