압축 비디오는 더 큰 파일을 만듭니다


17

GUI (오른쪽 클릭 => 압축)를 사용하여 총 1.7GB (.H264 MP4s)의 비디오 3 개가 포함 된 .tar을 압축하려고했습니다. gzip, lrzip, 7z 등은 모두 파일 크기에 아무런 영향을 미치지 않으며 압축 폴더도 1.7GB입니다.

그런 다음 명령 줄에서 lrzip을 실행하려고 시도하고 (gui 문제인 경우) -z 플래그 (극단 압축)를 사용했으며 이것이 내 출력이었습니다.

여기에 이미지 설명을 입력하십시오

압축 비율에서 알 수 있듯이 압축 폴더의 실제 크기는 원본보다 큽니다! 왜 운이 없는지 모르겠습니다. 특히 lrzip은 내가 읽은 임의의 리뷰와 공식 문서 (100mb보다 큰 파일, 더 큰 파일)에 따라 효과적이어야합니다 -https : //wiki.archlinux를 참조 하십시오. org / index.php / Lrzip

파일을 압축 할 수없는 이유는 무엇입니까?


2
개인적으로 mp4 비디오를 코덱으로 압축했기 때문에 mp4 비디오를 보관하지 않아도됩니다.
pram

FFMpeg 와 같은 비디오 변환기 / 압축기 도구를 사용하면 크기를 줄일 수 있습니다 .
Jet

유모차와 제트기가 맞습니다. 이것은 예상되는 동작입니다. 이미 잘 압축 된 것을 압축하는 것은 비생산적입니다. 비디오 변환 도구를 사용하면 비디오 품질 (명백하거나 아님)을 희생하여 공간을 절약 할 수 있습니다. 그러나 최고 품질의 최소 압축 사본으로 시작하십시오.
John S Gruber

답변:


25

@pram이 코멘트에서 위에서 언급했듯이 mp4 비디오는 이미 압축되어 있으며 다른 비디오 형식도 어느 정도 압축을 사용합니다. 따라서 압축을 시도해도 크기가 거의 줄어들지 않습니다 (적어도 부분적으로 사진 및 음악에도 적용됨). 이 경우 메타 데이터 (압축 파일 자체의 경우)가 증가한 것처럼 보입니다. 있는 유일한 압축 포맷 힘이 일부 감소 결과 (그 강력한 힘이다) XZ입니다.

다른 참고로, 해당 비디오의 크기를 줄이려면 수동 브레이크와 같은 것을 사용하여 비디오를 다시 인코딩하십시오.


3
나는 webm이 일반적으로 좋은 압축률을 가지고 있음을 발견했습니다. mp4보다 훨씬 작습니다.
세스

@Seth 실제로 MP4 (AVC는 h.264 또는 더 새로운 h.265는 HEVC 코덱)는 더 작은 파일을 동일한 품질 (또는 동일한 파일 크기에서 더 나은 품질)로 제공합니다.
David Balažic

@ DavidBalažic 우리는 오렌지에 대해 이야기하려고 할 때 사과와 사과를 비교하고 있습니다. mp4와 webm은 모두 컨테이너이며 압축과 관련이 없습니다. h.264와 h.265는 mp4 컨테이너에서 일반적으로 사용되는 코덱이지만 h.265와 webm을 비교할 수는 없습니다 . h.265가 일반적으로 webm에 포함되어있는 vp9 코덱과 비슷한 h.264는 webm 컨테이너에 일반적으로 사용되는 vp8 코덱과 비슷합니다. tl; dr : mp4에서 h.265를 사용하고 webm에서 vp9를 사용하면 거의 동일한 품질 / 효율성을 얻을 수 있습니다.
forresthopkinsa

13

실제로 파일이 이미 압축되어 있다는 사실은 중요한 문제가 아닙니다. : 그것은이의 데이터가 거기에 중복의 어떤 종류가있는 경우 일반적으로 캔에 압축에게에만 작업을 . 압축되지 않은 파일의 경우 실제로는 항상 그렇습니다. 그러나 중복성이 무엇인지 반드시 명확하지는 않습니다 . 범용 압축 알고리즘은 대부분 텍스트 파일에서 분명한 종류의 대상을 지정합니다. 많은 단어가 한 번이 아니라 여러 번 동일한 형태로 나타납니다. 어쩌면 단어의 구 등을 결합 할 수 있습니다. 이를 ASCII로 인코딩 된 전화 번호 목록에서 중국시의 이진 기계 코드에 이르기까지 모든 종류의 데이터에 사용할 수는 없습니다 . 특히 미디어 파일은 개념적으로시끄러운 디지털 표현의 아날로그 데이터 . 이는 실제로 어떤 종류의 텍스트 파일 중복성도 전혀 없다는 것을 의미합니다. 일부 동기는 반복적이지만 항상 약간 다른 센서 노이즈 구성을 갖습니다. 그렇기 때문에 모든 압축 이미지 / AV 형식은 일반적으로 DCT 또는 웨이블릿을 기반으로 첫 번째 인코딩 단계로 영리하게 선택된 변환을 사용 합니다. 대략적으로 말하면 이러한 변환은 그림 부분과 잡음 부분을 다른 위치로 옮기므로 잘 분리 할 수 ​​있으며 손실 압축으로 가장 중요하다고 생각되는 정보 만 유지합니다. 좋은 정보 "는 많은 중복성을 가지고 있습니다. (실제로 작동하는 방식이 아니라 일종의 방식입니다.)

범용 컴프레서가 이러한 변환을 사용하는 경우 그 효과는 반대입니다. 대부분의 디지털 정보는 아날로그 신호에서 찾을 수있는 "부드러운"구조가 없기 때문에 실제로는 일종의 노이즈로 잘못 분류됩니다. 그리고 손실 비디오 압축 후에는 아날로그 평활도 또는 디지털 재발을 더 이상 찾을 수 없습니다 (만약 있다면 코덱은 다른 bzip 단계 또는 그 자체를 사용할 것입니다!)


12

운이없는 이유는 mp4가 이미 압축되어 있기 때문에 더 이상 압축 할 수 없기 때문입니다. 압축 형식의 헤더 정보를 파일에 추가하기 만하면됩니다.

파일은 이미 압축되어 있으며 더 이상 압축 할 수 없으므로 동일한 정보를 유지하고 몇 바이트의 헤더 정보를 추가하기 만하면 파일 크기가 증가합니다.


5

이것은 비둘기 구멍 원리 의 좋은 예입니다 .

파일이 이미 (손실) 압축되어 있기 때문에 어느 곳에서나 줄어드는 것이 거의 없거나 전혀 없기 때문에 이미 순 이득이 0입니다. 다른 사람들이 언급했듯이 압축 형식 자체는 일반적으로 자체 메타 데이터에서 무시할만한 손실이 있습니다. 이 모든 것이 함께 제공됨에 따라 동일하거나 작은 파일 세트에 비둘기 구멍이 남지 않았으므로 압축 된 데이터가 더 큰 파일 세트에 포함됩니다.


4
죄송하지만이 원칙이 잘못 적용되었습니다. 0으로 가득 찬 1.7GB 파일에 동일한 논리를 적용하면 잘못된 대답을 얻을 수 있습니다. 비둘기 구멍 원리는 일반적으로 압축 불가능한 파일 의 존재 를 증명하기 위해 사용되며 특정 파일이 실제로 압축 불가능하다는 것을 증명하지는 않습니다. (Kolmogorov 복잡도 함수는 계산 가능한 함수가 아니기 때문에 후자는 계산할 수 없습니다).
nneonneo

1
@nneonneo 그런 다음 연결된 Wikipedia 기사를 자유롭게 수정하십시오. 압축 할 수없는 파일의 존재는 직접 압축 된 다음 압축 메타 데이터를 추가하면 갑자기 원본보다 큰 파일이 생깁니다. 정확히 내가 말한 것입니다. 주어진 알고리즘의 주어진 구현 에서 파일이 더 압축 가능하지 않다는 증거 는 출력이 더 작지 않다는 것입니다. 물론 메타 데이터가 압축 승리보다 단순히 클 수도 있지만 사용자 지향적 의미로 압축 된 것으로 설명하지는 않습니다.
Livius

@Livius Wikipedia 기사는 정확합니다. pigeonhole 원칙을 사용하여 주어진 무손실 압축 알고리즘에 대해 압축 할 수없는 파일 이 존재 함 을 증명합니다 . 그러나 비둘기 구멍 원리에서 특정 파일의 압축을 풀 수는 없습니다.
David Richerby

@DavidRicherby 네, 그러나 주어진 알고리즘의 주어진 구현에 의해 파일이 압축되지 않았다는 사실은 압축 불가능하다는 증거입니다. 압축 할 수없는 파일이 존재하는 다른 이유가없는 한, 압축 실패는 PP로 인한 것입니다. 다른 가능한 이유는 주어진 알고리즘이 크기를 줄일 수있는 방법을 볼 수 없기 때문입니다. "알고리즘의 가정하에 동일한 정보를 가진 더 작은 파일이 없습니다. PP 때문에 "
Livius

보다 정확하게, PP는 알고리즘이 작은 파일 공간에 이미지가없는 입력을 갖도록 알고리즘을 강제합니다. 주어진 공간에 맞지 않는 주어진 파일의 이미지로 이끄는 모든 결정은 PP에 의해 어느 정도 진행되고 있으며, 압축 알고리즘의 정의가 제대로 정해져 있다고 가정 할 때 강제로 타협합니다. 그런 다음 이미지가 작지 않은 파일은 PP가 압축에서 제외 된 세트에 속합니다. 주어진 파일이 압축 가능하지 않다는 증거는 압축 실패입니다. 넓은 의미에서, 비압축성은 항상 보호 프로파일과 보호 프로파일의 결과이다.
Livius

4

이러한 파일을 압축 하려면 품질을 줄여야합니다.

이러한 파일의 길이와 형식 및 내용 유형을 알지 못하면 이러한 파일이 눈에 띄는 품질 손실없이 축소 될 여지가 있는지 알기가 어렵습니다.

1080p 비디오를 사용하는 BluRays는 25GB 이상인 경향이 있으므로 H.264에 대한 최적의 품질 대 크기 비율이 아닐 것입니다.

파일을 사용 ffmpeg하거나 avconv변환 할 수 있습니다.

당신은 시작할 수 있습니다 ffmpeg -i input_file.mp4 -preset slower -crf 20 -c:a copy output_file.mp4

anconv명령은 비슷하게 작동합니다.

  • -crf파일 크기와 품질을 낮추 려면 값을 늘리십시오 . 25보다 큰 값은 사용하지 않는 것이 좋습니다.

  • 사전 설정을 변경 slow하거나 medium속도를 증가시킬 수 있지만 파일 크기는 그와 비교하여 slower또는 심지어 고생합니다 veryslow(인내심이 강한 경우).

  • 더 많은 설정은 여기에서 찾을 수 있습니다 : http://mewiki.project357.com/wiki/X264_Settings

  • 사전 설정 -tune은 예외를 제외 하고 는 기본 기본값을 제공하므로 최대한 멀리 유지하는 것이 좋습니다 .

  • 컨텐츠가 영화인 경우 Denoiser를 사용해보십시오 ( -vf hqdn3d)-crf . 높은 가치 를 사용하는 것과 비교하여 시각적 품질을 향상시킬 수 있습니다 .

  • 인코딩 속도를 높이고 품질을 유지하려면 -vf scale=-1:720720p 및 -vf scale=-1:480480p로 컨텐츠 를 축소하십시오 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.