A compactação de vídeos cria arquivos ainda maiores

17

Eu tenho usado a GUI (clique com o botão direito => compactar) para tentar compactar um .tar contendo 3 vídeos no total de 1,7gb (.H264 MP4s). gzip, lrzip, 7z etc. tudo não faz nada com o tamanho do arquivo e a pasta compactada também tem 1,7 gb.

Tentei executar o lrzip na linha de comando (no caso de um problema de interface gráfica) e usei o sinalizador -z (compressão extrema), e essa foi a minha saída.

insira a descrição da imagem aqui

Como mostra a taxa de compactação, o tamanho real da pasta compactada é maior que o original! Não sei por que não estou tendo sorte, o lrzip em particular deve ser eficaz de acordo com as análises aleatórias que li e os documentos oficiais (arquivos maiores que 100mb, quanto maior, melhor) - consulte https: //wiki.archlinux. org / index.php / Lrzip

Por que não consigo compactar meus arquivos?

gzip

— Lee
fonte

2

Pessoalmente, não vou me incomodar em arquivar vídeos mp4, pois esses vídeos já estão compactados pelo codec.

— carrinho de bebê

E você pode obter menos tamanho usando ferramentas de conversor / compressor de vídeo como o FFMpeg .

— Jet

carrinho de bebê e Jet estão corretos. Este é o comportamento esperado. É contraproducente tentar compactar algo que já está bem compactado. Se você usar ferramentas de conversão de vídeo, poderá economizar espaço em detrimento da qualidade do vídeo (aparente ou não). Comece com a cópia menos compactada da mais alta qualidade que você possui, no entanto.

— John S Gruber

25

Como o @pram disse acima no comentário, os vídeos em mp4 já estão compactados e outros formatos de vídeo provavelmente também usam a compressão em certa medida. Portanto, tentar compactá-los não resultará em pequena (se houver) redução no tamanho (isso também se aplica, pelo menos em parte, a imagens e músicas). Nesse caso, parece que os metadados (para o próprio arquivo compactado) podem estar causando o aumento. O único formato de compactação que pode (e é forte) resultar em alguma redução é xz.

Em outra nota, se você deseja reduzir o tamanho desses vídeos, procure recodificá-los usando algo como o Handbrake.

— saiarcot895
fonte

3

Acho que o webm tem boas taxas de compactação em geral. Muito menor que o mp4.

— Seth

@Seth, na verdade, o MP4 (que é o AVC aka h.264 ou o mais novo e melhor h.265 aka HEVC codec) fornece arquivos menores com a mesma qualidade (ou melhor qualidade com o mesmo tamanho de arquivo).

— David Balažic

@ DavidBalažic, estamos comparando maçãs e maçãs aqui, quando estamos tentando falar sobre laranjas. mp4 e webm são dois contêineres, eles não têm nada a ver com compactação. Você está certo que o H.264 e H.265 são ambos codecs comumente usados em recipientes mp4, mas você não pode comparar H.265 para WebM . O h.264 é comparável ao codec vp8 comumente usado em contêineres webm, assim como o h.265 é comparável ao codec vp9, também normalmente contido no webm. tl; dr: use h.265 em mp4 e vp9 em webm e você obterá aproximadamente a mesma qualidade / eficiência.

— forresthopkinsa

13

Realmente, o fato de os arquivos já estarem compactados não é o problema crucial. É isso: a compactação em geral só pode funcionar se os dados tiverem algum tipo de redundância . Esse é praticamente sempre o caso de arquivos não compactados - no entanto, não é necessariamente óbvio qual é a redundância. Os algoritmos de compactação de uso geral visam principalmente o tipo de coisa óbvia nos arquivos de texto: muitas palavras aparecem não apenas uma vez, mas muitas vezes de forma idêntica, talvez frases de palavras possam ser combinadas etc. etc. Os algoritmos são muito bons em generalizando isso para qualquer coisa, de listas de números de telefone codificados em ASCII sobre poesia chinesa a código de máquina binário, mas eles não podem funcionar para qualquer tipo de dados. Em particular, os arquivos de mídia são conceitualmentedados analógicos , em uma representação digital barulhenta. Isso significa que não há realmente nenhum tipo de redunção de arquivo de texto: alguns motivos podem ser recorrentes, mas sempre com uma configuração ligeiramente diferente do ruído do sensor. É por isso que todos os formatos de imagem / AV compactados usam alguma transformação habilmente escolhida como sua primeira etapa de codificação, normalmente baseada em DCT ou wavelets . Essas transformações, grosso modo, movem as porções de imagem e porções de ruído para locais diferentes, para que possam ser separadas e com compressão com perdas, você retém apenas as informações que considera mais "importantes", que não incluem o ruído, enquanto as " boa informação "tem muita redundância. (Não é assim que funciona, mas é o que acontece.)

Se os compressores de uso geral usassem essas transformações, o efeito seria o oposto: a maioria das informações digitais seria na verdade classificada erroneamente como algum tipo de ruído, porque carece da estrutura "suave" encontrada nos sinais analógicos. E após a compactação de vídeo com perda, obviamente não é mais possível encontrar a suavidade analógica ou a recorrência digital (se fosse, os codecs usariam outro estágio bzip ou algo parecido!)

— leftaroundabout
fonte

12

O motivo de você não ter sorte é que o mp4 já está compactado, não é possível compactá-lo ainda mais. Tudo o que você está fazendo é adicionar as informações do cabeçalho do formato de compactação ao arquivo.

Como os arquivos já estão compactados e você não pode compactá-los mais, isso resulta em um aumento no tamanho do arquivo, pois tudo o que você faz é manter as mesmas informações e adicionar mais alguns bytes de informações do cabeçalho.

— Terdon
fonte

5

Este é um bom exemplo do princípio do buraco de pombo .

Como o arquivo já está compactado (com perdas), há pouca ou nenhuma redução em qualquer lugar, o que significa que você já está com ganho líquido zero. Como os outros mencionados, o próprio formato compactado possui uma perda geralmente insignificante em seus próprios metadados. Tudo isso se reúne significa que provavelmente não resta nenhum buraco no conjunto de arquivos iguais ou menores e, portanto, seus dados compactados se enquadram no conjunto de arquivos maiores.

— Livius
fonte

4

Sinto muito, mas isso é uma aplicação incorreta do referido princípio. Você pode aplicar a mesma lógica a um arquivo de 1,7 GB cheio de zeros e obter uma resposta incorreta. O princípio do pigeonhole é geralmente usado para provar a existência de arquivos não compactáveis, não para provar que qualquer arquivo em particular é realmente não compactável. (O último é incontestável, pois a função de complexidade Kolmogorov não é uma função computável).

— Nelineo

1

@nneonneo Então, fique à vontade para corrigir o artigo vinculado da Wikipedia. A existência de arquivos incompressíveis segue diretamente dele e, em seguida, você adiciona os metadados de compactação e, de repente, você tem um arquivo maior que o original. Foi exatamente o que eu disse. A prova de que o arquivo não é mais compactável sob uma dada implementação de um determinado algoritmo é que a saída não é menor. Obviamente, também é possível que os metadados sejam simplesmente maiores que os ganhos de compactação, mas não tenho certeza se descrevi isso como compactado no sentido orientado ao usuário.

— Livius

@Livius O artigo da Wikipedia está correto: ele usa o princípio pigeonhole para provar a existência de arquivos não compactáveis para qualquer algoritmo de compactação sem perdas. Mas você não pode obter a descompactação de nenhum arquivo específico apenas a partir do princípio do buraco de pombo.

— David Richerby

@DavidRicherby Sim, mas o fato de o arquivo não ser compactado por uma determinada implementação de um determinado algoritmo é a prova de que ele não é compactável. A menos que haja outros motivos para a existência de arquivos incompressíveis, a falha na compactação deve-se ao PP. A única outra razão possível seria porque um determinado algoritmo não vê como reduzir seu tamanho, o que novamente parece ser um caso de "sob as premissas do algoritmo, não há arquivo menor com a mesma informação; esses casos necessariamente existem por causa do PP ".

— Livius

Mais precisamente, o PP força o algoritmo a ter entradas cuja imagem não se encontra no espaço de arquivos menores. Toda decisão que leva à imagem de um determinado arquivo que não se encaixa nesse espaço é, portanto, em algum nível orientada pelo PP e pelos comprometimentos que força (assumindo uma definição sã do algoritmo de compactação). Qualquer arquivo cuja imagem não seja menor pertence ao conjunto que o PP excluiu da compactação. A prova de que um determinado arquivo não é compactável é sua falha na compactação; em um sentido amplo, a incompressibilidade é sempre resultado do PP e de seus compromissos.

— Livius

4

Se você deseja compactar esses arquivos, terá que reduzir a qualidade.

Sem saber por quanto tempo e que formato e tipo de conteúdo esses arquivos são difíceis de determinar se esses arquivos têm espaço para serem reduzidos sem muita perda de qualidade visível.

Os BluRays com vídeo 1080p tendem a ter mais de 25 GB, portanto não é improvável que você já tenha uma ótima relação qualidade / tamanho para o H.264.

Você pode tentar usar ffmpegou avconvconverter arquivos.

Você poderia começar com ffmpeg -i input_file.mp4 -preset slower -crf 20 -c:a copy output_file.mp4

O anconvcomando funcionará de maneira semelhante.

Aumente o -crfvalor para diminuir o tamanho e a qualidade do arquivo, não recomendo mais que 25.
Você pode alterar a predefinição para slowou mediumpara aumentar a velocidade, mas o tamanho do arquivo sofrerá comparações slowerou até mesmo veryslow(se você for muito paciente!).
Mais configurações podem ser encontradas aqui: http://mewiki.project357.com/wiki/X264_Settings
Eu recomendo ficar longe da maioria, pois as predefinições fornecem padrões saudáveis, -tunesendo a exceção.
Tente um denoiser se o conteúdo for filme ( -vf hqdn3d), você pode melhorar a qualidade visual em comparação com o uso de um -crfvalor alto .
Reduza o conteúdo -vf scale=-1:720para 720p e -vf scale=-1:480480p para melhorar a velocidade da codificação e manter a qualidade.

— Daniel Hill
fonte