Codec de compressão sem perdas para sequência de imagens em loop

0

Eu tenho 14 imagens PNG ( aqui mas não importantes) que quero colocar em um loop de 2 minutos a 15 fps.

O Photoshop CS3 parecia a melhor ferramenta para isso, então eu os abri como uma seqüência de imagens * e fiz Arquivo - > Exportar - > Renderize vídeo e exporte como AVI.

No entanto, eu só tinha 14 imagens, então usei um script ( aqui mas não importante) para duplicá-las como 1805 imagens (aprox. 2 minutos de vídeo).

Quando eu repeti as etapas do Photoshop, o tamanho do arquivo resultante era de 55 MB, em vez dos 429 KB originais.

Todo o vídeo que realmente precisa são os primeiros 14 arquivos para vincular e depois repetir (sem perdas).

Qual codec posso usar para fazer isso? Como eu uso esse codec? (Eu estou no OS X Lion).

Eu preciso disso como um vídeo, não como um GIF.

* (Abrir - > primeiro arquivo - > sequência de imagens)

    
por gadgetmo 20.01.2013 / 18:29

2 respostas

0

Compressão sem perdas significa que não há perda quando a imagem / vídeo / dados são compactados, link . Exemplo: zip / gzip. Isso não significa repetir arquivos. Para criar um vídeo com imagens usando o ffmpeg, siga os comandos neste link: link

No Mac OS X, você pode instalar o ffmpeg seguindo estas etapas:

    
por 22.01.2013 / 02:19
0

Se você estiver colocando um vídeo na Web, poderá usar o atributo de loop de vídeo do HTML5: link

por exemplo. link , que faz um pequeno clipe slo-mo codificado em x264 do musical Working.

Veja também Converter vídeo para apng / png?

AFAICT, não há formatos de contêiner de vídeo (por exemplo, mp4, mkv, avi, nut, ogm) que o ffmpeg suporte e que tenham uma contagem de loop nos metadados do contêiner. Então você está certo, você teria que alimentar a seqüência de repetição de quadros de entrada para um codec de vídeo, e espero que o codificador possa encontrar a redundância maciça.

Você pode chamar os formatos de vídeo gif, mng e webp, já que você pode armazenar qualquer sequência de quadros neles. Nenhum desses formatos de contêiner suporta qualquer coisa, exceto o único codec de imagem estática para o qual foram projetados. Todos eles suportam animações com looping, provavelmente todos com uma contagem de loop não infinita que lhe daria os 2 minutos que você deseja.

ffmpeg -framerate 15 -loop 1 -i src/b93-'%d.png' -frames 1805 -preset veryslow -crf 23 -movflags +faststart party.mp4
2.5M    party.mp4  # see [1] for the encode log

ffmpeg -framerate 15 -i src/b93-'%d.png' -loop 128 containerloop.gif
684K    containerloop.gif
...
172K    containerloop.webp

ffplay não pode reproduzir webp animado, portanto use o vwebp ou o google chrome.

Eu não tenho ideia de por que você iria querer isso. Se você tiver um gif animado, apenas o toque. ffplay -ignore_loop 0 containerloop.gif fará um loop por 2 minutos (desde que fiz o gif com uma contagem de loop finita).

Se você está criando clipes para um projeto de edição de vídeo, acho que isso faz sentido.

[1] x264 com 16 quadros ref, máximo de 8 quadros b, alimentados com a versão yuv444 da entrada.

frame= 1805 fps=7.2 q=-1.0 Lsize=    2540kB time=00:02:00.20 bitrate= 173.1kbits/s    
video:2518kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.872666%
[libx264 @ 0x1a787e0] frame I:8     Avg QP:21.35  size: 18650
[libx264 @ 0x1a787e0] frame P:515   Avg QP:16.45  size:  1044
[libx264 @ 0x1a787e0] frame B:1282  Avg QP:25.79  size:  1475
[libx264 @ 0x1a787e0] consecutive B-frames:  0.7% 13.9%  0.8% 84.2%  0.0%  0.0%  0.0%  0.4%  0.0%
[libx264 @ 0x1a787e0] mb I  I16..4:  3.4% 64.4% 32.2%
[libx264 @ 0x1a787e0] mb P  I16..4:  0.9% 15.9%  0.9%  P16..4: 80.9%  0.3%  0.6%  0.0%  0.0%    skip: 0.5%
[libx264 @ 0x1a787e0] mb B  I16..4:  0.3%  2.8%  0.5%  B16..8:  4.8%  3.3%  1.9%  direct: 1.2%  skip:85.2%  L0:35.1% L1:64.0% BI: 0.9%
[libx264 @ 0x1a787e0] Weighted P-Frames: Y:75.0% UV:75.0%
[libx264 @ 0x1a787e0] ref P L0:  1.3%  0.1%  0.7%  0.1%  0.3%  0.0% 24.1% 41.7% 27.4%  0.1%  0.0%  0.0%  0.0%  0.4%  3.5%  0.4%
[libx264 @ 0x1a787e0] ref B L0:  8.7%  1.6%  0.8%  0.1%  0.7%  1.2% 74.6%  2.1%  0.0%  0.1%  0.0%  0.0%  0.4%  9.5%
[libx264 @ 0x1a787e0] ref B L1: 99.5%  0.5%
[libx264 @ 0x1a787e0] kb/s:171.40

Observe que o tamanho médio do quadro P é menor que o quadro médio B.

O

x264 no modo sem perdas, rgb ou yuv, não conseguiu manter seus 16 quadros de referência alinhados de forma a permitir que eles continuem referenciando-os sem recodificá-los. IDK suficiente sobre a ordenação de imagens do decodificador e exatamente quais quadros são mantidos como referências para entender o motivo.

    
por 15.01.2015 / 05:59