Comprimir videos crea archivos aún más grandes

17

He estado usando la GUI (clic derecho => comprimir) para intentar comprimir un .tar que contiene 3 videos con un total de 1.7gb (.H264 MP4s). gzip, lrzip, 7z etc. no hacen nada al tamaño del archivo y la carpeta comprimida también tiene 1.7 gb.

Luego intenté ejecutar lrzip desde la línea de comandos (en caso de que fuera un problema de interfaz gráfica de usuario), y usé el indicador -z (compresión extrema), y este fue mi resultado.

ingrese la descripción de la imagen aquí

Como muestra la relación de compresión, ¡el tamaño real de la carpeta comprimida es más grande que el original! No sé por qué no tengo suerte, lrzip en particular debería ser efectivo de acuerdo con las revisiones aleatorias que he leído y los documentos oficiales (archivos de más de 100 mb , cuanto más grande, mejor) - vea https: //wiki.archlinux. org / index.php / Lrzip

¿Por qué no puedo comprimir mis archivos?

gzip

— Sotavento
fuente

2

Personalmente, no me molestaré en archivar videos mp4 ya que esos videos ya están comprimidos por el códec.

— Cochecito

Y puede lograr menos tamaño utilizando herramientas de conversión / compresión de video como FFMpeg .

— Jet

cochecito y chorro son correctos. Este es el comportamiento esperado. Es contraproducente intentar comprimir algo que ya está bien comprimido. Si utiliza herramientas de conversión de video, puede ahorrar espacio a expensas de la calidad del video (aparente o no). Sin embargo, comience con la copia menos comprimida de la más alta calidad que tenga.

— John S Gruber

25

Como @pram dijo anteriormente en el comentario, los videos mp4 ya están comprimidos, y otros formatos de video probablemente también usan la compresión en cierta medida. Por lo tanto, tratar de comprimirlos no dará como resultado una pequeña (si es que la hay) reducción de tamaño (esto también se aplica, al menos en parte, a las imágenes y la música). En este caso, parece que los metadatos (para el archivo comprimido en sí) podrían estar causando el aumento. El único formato de compresión que podría (y ese es un fuerte poder) resultar en alguna reducción es xz.

En otra nota, si desea reducir el tamaño de esos videos, busque volver a codificar los videos usando Handbrake.

— saiarcot895
fuente

3

Encuentro que webm tiene buenas tasas de compresión en general. Mucho más pequeño que mp4.

— Seth

@Seth en realidad MP4 (que es AVC aka h.264 o el códec más nuevo y mejor h.265 aka HEVC) proporciona archivos más pequeños con la misma calidad (o mejor calidad con el mismo tamaño de archivo).

— David Balažic

@ DavidBalažic estamos comparando manzanas y manzanas aquí, cuando intentamos hablar de naranjas. mp4 y webm son ambos contenedores, no tienen nada que ver con la compresión. Tienes razón en que h.264 y h.265 son códecs de uso común en contenedores mp4, pero no puedes comparar h.265 con webm . h.264 es comparable al códec vp8 comúnmente utilizado en los contenedores de webm, así como h.265 es comparable al códec vp9, también contenido típicamente por webm. tl; dr: use h.265 en mp4 y vp9 en webm y obtendrá aproximadamente la misma calidad / eficiencia.

— forresthopkinsa

13

Realmente, el hecho de que los archivos ya estén comprimidos no es el problema crucial. Es esto: la compresión en general solo puede funcionar si los datos tienen algún tipo de redundancia . Ese es prácticamente siempre el caso de los archivos sin comprimir; sin embargo, no es necesariamente obvio cuál es la redundancia. Los algoritmos de compresión de propósito general se dirigen principalmente al tipo de cosas obvias en los archivos de texto: muchas palabras aparecen no solo una vez sino muchas veces en forma idéntica, tal vez se pueden combinar frases de palabras, etc. etc. Los algoritmos son bastante buenos en generalizando esto a cualquier cosa, desde listas de números de teléfono codificados en ASCII sobre poesía china hasta código de máquina binario, pero no pueden funcionar para ningún tipo de datos. En particular, los archivos multimedia son conceptualmentedatos analógicos , en una representación digital ruidosa. Eso significa que en realidad no hay ningún tipo de redundancia de archivos de texto: algunos motivos pueden ser recurrentes, pero siempre con una configuración ligeramente diferente del ruido del sensor. Es por eso que todos los formatos de imagen / AV comprimidos usan alguna transformación ingeniosamente elegida como su primer paso de codificación, normalmente basado en DCT o wavelets . Estas transformaciones, en términos generales, mueven las porciones de imagen y las porciones de ruido a diferentes ubicaciones, por lo que pueden separarse bien y con una compresión con pérdida, retiene solo la información que cree que es más "importante", que no incluye el ruido, mientras que " buena información "tiene mucha redundancia. (En realidad no es así, pero más o menos).

Si los compresores de uso general usaran estas transformaciones, el efecto sería el opuesto: la mayoría de la información digital se clasificaría erróneamente como algún tipo de ruido, porque carece de la estructura "uniforme" que se encuentra en las señales analógicas. Y después de la compresión de video con pérdida, obviamente, ya no se puede encontrar ni la suavidad analógica ni la recurrencia digital (si lo fuera, ¡los códecs usarían otra etapa bzip o algo por sí mismos!)

— a la izquierda
fuente

12

La razón por la que no tienes suerte es que mp4 ya está comprimido, no puedes comprimirlo más. Todo lo que está haciendo es agregar la información del encabezado del formato de compresión al archivo.

Dado que los archivos ya están comprimidos y no puede comprimirlos más, esto aumenta el tamaño del archivo, ya que todo lo que está haciendo es mantener la misma información y agregar algunos bytes más de información de encabezado.

— terdon
fuente

5

Este es un buen ejemplo del principio del casillero .

Dado que el archivo ya está comprimido (con pérdida), hay poca o ninguna reducción en cualquier lugar, lo que significa que ya tiene una ganancia neta cero. Como los otros mencionaron, el formato comprimido en sí tiene una pérdida cierta, generalmente insignificante, en sus propios metadatos. Todo esto se combina significa que probablemente no quede ningún casillero en el conjunto de archivos iguales o más pequeños y, por lo tanto, sus datos comprimidos caen en el conjunto de archivos más grandes.

— Livius
fuente

44

Lo siento, pero esta es una aplicación errónea de dicho principio. Podría aplicar la misma lógica a un archivo de 1.7GB lleno de ceros y obtener una respuesta incorrecta. El principio del casillero se usa generalmente para demostrar la existencia de archivos no comprimibles, no para probar que un archivo en particular no es realmente comprimible. (Esto último es indiscutible, ya que la función de complejidad de Kolmogorov no es una función computable).

— nneonneo

1

@nneonneo Entonces, siéntase libre de corregir el artículo vinculado de Wikipedia. La existencia de archivos incompresibles se deriva directamente de él y luego agrega los metadatos de compresión y de repente tiene un archivo más grande que el original. Que es exactamente lo que dije. La prueba de que el archivo no es más comprimible bajo una implementación dada de un algoritmo dado es que la salida no es más pequeña. Por supuesto, también es posible que los metadatos sean simplemente más grandes que la ganancia de compresión, pero no estoy seguro de haberlo descrito como comprimido en el sentido orientado al usuario.

— Livius

@Livius El artículo de Wikipedia es correcto: utiliza el principio de casillero para demostrar la existencia de archivos no comprimibles para cualquier algoritmo de compresión sin pérdida. Pero no se puede derivar la incompresibilidad de un archivo en particular solo por el principio del casillero.

— David Richerby

@DavidRicherby Sí, pero el hecho de que el archivo no esté comprimido por una implementación dada de un algoritmo dado es la prueba de que no es compresible. A menos que existan otras razones para la existencia de archivos incompresibles, se deduce que la falla de compresión se debe al PP. La única otra razón posible sería porque un algoritmo dado no ve la forma de reducir su tamaño, lo que nuevamente parece ser un caso de "bajo los supuestos del algoritmo, no hay un archivo más pequeño con la misma información; tales casos necesariamente existen por el PP ".

— Livius

Más precisamente, el PP obliga al algoritmo a tener entradas cuya imagen no se encuentre en el espacio de archivos más pequeños. Cada decisión que lleva a que la imagen de un archivo dado no encaje en ese espacio es, por lo tanto, impulsada por el PP y los compromisos que impone (suponiendo una definición sensata de algoritmo de compresión). Entonces, cualquier archivo cuya imagen no sea más pequeña pertenece al conjunto que el PP excluyó de ser compresible. La prueba de que un archivo dado no es compresible es su falla al comprimir; En un sentido amplio, la incompresibilidad es siempre el resultado del PP y sus compromisos.

— Livius

4

Si desea comprimir estos archivos, deberá reducir la calidad.

Sin saber cuánto tiempo y qué tipo de formato y contenido son estos archivos, es difícil saber si estos archivos tienen espacio para reducirse sin mucha pérdida de calidad visible.

BluRays con video de 1080p tiende a superar los 25 GB, por lo que no es improbable que ya tenga una relación calidad / tamaño óptima para H.264.

Puede intentar usar ffmpego avconvpara convertir archivos.

Podrías comenzar con ffmpeg -i input_file.mp4 -preset slower -crf 20 -c:a copy output_file.mp4

El anconvcomando funcionará de manera similar.

Aumente el -crfvalor para disminuir el tamaño y la calidad del archivo, no recomiendo más de 25.
Puede cambiar el valor predefinido de slowo mediumpara aumentar la velocidad, pero el tamaño del archivo sufrirán en comparación con slower, o incluso veryslow(si eres muy paciente!).
Más configuraciones se pueden encontrar aquí: http://mewiki.project357.com/wiki/X264_Settings
Recomiendo mantenerse alejado de la mayoría, ya que los preajustes proporcionan valores predeterminados sanos, con -tunela excepción.
Pruebe con un eliminador de ruido si su contenido es película ( -vf hqdn3d) puede mejorar la calidad visual en comparación con el uso de un -crfvalor alto .
Reduce tu contenido -vf scale=-1:720a 720p y -vf scale=-1:480480p para mejorar la velocidad de codificación y mantener la calidad.

— Daniel Hill
fuente