비디오 코덱은 어떻게 작동하나요? 2부. 무엇을, 왜, 어떻게

Первая의 часть : 비디오 및 이미지 작업의 기본 사항

뭐라구? 비디오 코덱은 디지털 비디오를 압축 및/또는 압축 해제하는 소프트웨어/하드웨어입니다.

무엇을 위해서? 대역폭과 측면에서 특정 제한에도 불구하고
데이터 저장 공간 측면에서 시장은 점점 더 높은 품질의 비디오를 요구합니다. 지난 게시물에서 해상도 30x24, 초당 480프레임, 픽셀당 240비트에 필요한 최소값을 어떻게 계산했는지 기억하시나요? 압축 없이 82,944 Mbit/s를 수신했습니다. 압축은 현재 일반적으로 HD/FullHD/4K를 TV 화면과 인터넷으로 전송하는 유일한 방법입니다. 이것이 어떻게 달성됩니까? 이제 주요 메소드를 간단히 살펴보겠습니다.

번역은 EDISON Software의 지원을 받아 이루어졌습니다.

우리는 비디오 감시 시스템 통합과 우리는 현미경 단층촬영기를 개발 중입니다.

코덱과 컨테이너

초보자가 흔히 범하는 실수는 디지털 비디오 코덱과 디지털 비디오 컨테이너를 혼동하는 것입니다. 컨테이너는 특정 형식입니다. 비디오(및 오디오) 메타데이터를 포함하는 래퍼입니다. 압축된 비디오는 컨테이너 페이로드로 생각할 수 있습니다.

일반적으로 비디오 파일의 확장자는 해당 컨테이너 유형을 나타냅니다. 예를 들어 video.mp4 파일은 아마도 컨테이너일 것입니다. MPEG-4 파트 14, video.mkv라는 파일이 있을 가능성이 가장 높습니다. 러시아 인형. 코덱과 컨테이너 형식을 완전히 확인하려면 다음을 사용할 수 있습니다. 는 FFmpeg 또는 Mediainfo를.

역사의 비트

우리가 도착하기 전에 어떻게해야합니까?, 일부 오래된 코덱을 좀 더 잘 이해하기 위해 역사를 조금 살펴보겠습니다.

비디오 코덱 H.261 1990년(기술적으로는 1988년)에 등장했으며 64Kbps의 데이터 전송 속도로 작동하도록 만들어졌습니다. 이미 색상 서브샘플링, 매크로블록 등과 같은 아이디어를 사용했습니다. 비디오 코덱 표준은 1995년에 발표되었습니다. H.263, 2001년까지 개발되었습니다.

첫 번째 버전은 2003년에 완성되었습니다. H.264 / AVC. 같은 해 TrueMotion은 무료 손실 비디오 코덱을 출시했습니다. VP3. 구글은 2008년에 이 회사를 인수하여 출시했습니다. VP8 같은 해. 2012년 XNUMX월 구글이 출시한 VP9, 브라우저 시장(모바일 장치 포함)의 약 XNUMX/XNUMX에서 지원됩니다.

AV1 에서 개발한 새로운 무료 오픈 소스 비디오 코덱입니다. 오픈미디어연맹 (AO미디어) 여기에는 Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel 및 Cisco와 같은 가장 유명한 회사가 포함됩니다. 코덱의 첫 번째 버전인 0.1.0은 7년 2016월 XNUMX일에 게시되었습니다.

AV1의 탄생

2015년 초에 Google은 다음 작업을 진행했습니다. VP10Xiph(Mozilla 소유)가 작업 중이었습니다. 달라, Cisco는 자체 무료 비디오 코덱을 만들었습니다. 토르.

그때 엠펙 LA 처음으로 발표된 연간 한도 HEVC (H.265) 그리고 H.8보다 264배 높은 수수료가 부과되었지만 곧 규칙이 다시 변경되었습니다.

연간 한도 없음,
콘텐츠 수수료(수익의 0,5%) 및
단위 요금은 H.10보다 약 264배 높습니다.

오픈미디어연맹 는 장비 제조업체(Intel, AMD, ARM, Nvidia, Cisco), 콘텐츠 제공업체(Google, Netflix, Amazon), 브라우저 제작자(Google, Mozilla) 등 다양한 분야의 회사에 의해 만들어졌습니다.

두 회사는 로열티 없는 비디오 코덱이라는 공통 목표를 가지고 있었습니다. 그런 다음 나타납니다 AV1 훨씬 간단한 특허 라이센스로. Timothy B. Terryberry는 현재 AV1 개념과 라이선스 모델의 기원이 된 놀라운 프레젠테이션을 제공했습니다.

브라우저를 통해 AV1 코덱을 분석할 수 있다는 사실을 알면 놀랄 것입니다. aomanalyzer.org).

범용 코덱

범용 비디오 코덱의 기본 메커니즘을 살펴보겠습니다. 이러한 개념의 대부분은 유용하며 다음과 같은 최신 코덱에서 사용됩니다. VP9, AV1 и HEVC. 설명된 많은 것들이 단순화될 것임을 경고합니다. 때로는 H.264와 같은 실제 사례를 사용하여 기술을 시연하기도 합니다.

1단계 - 이미지 분할

첫 번째 단계는 프레임을 여러 섹션, 하위 섹션 및 그 이상으로 나누는 것입니다.

무엇을 위해? 많은 이유가 있습니다. 이미지를 분할할 때 작은 움직이는 부분에 대한 작은 섹션을 사용하여 모션 벡터를 보다 정확하게 예측할 수 있습니다. 정적 배경의 경우 더 큰 섹션으로 제한할 수 있습니다.

코덱은 일반적으로 이러한 섹션을 섹션(또는 청크), 매크로블록(또는 코딩 트리 블록) 및 여러 하위 섹션으로 구성합니다. 이러한 파티션의 최대 크기는 다양합니다. HEVC는 이를 64x64로 설정하고 AVC는 16x16을 사용하며 하위 파티션은 최대 4x4 크기까지 분할할 수 있습니다.

지난 글에서 봤던 프레임 종류를 기억하시나요?! 블록에도 동일하게 적용할 수 있으므로 I-조각, B-블록, P-매크로블록 등을 가질 수 있습니다.

연습하고 싶은 분들은 이미지가 어떻게 섹션과 하위 섹션으로 나뉘는지 살펴보세요. 이렇게 하려면 이전 기사에서 이미 언급한 것을 사용할 수 있습니다. 인텔 비디오 프로 분석기 (유료이지만 처음 10프레임으로 제한되는 무료 평가판 버전). 여기에서 분석된 섹션 VP9:

2단계 - 예측

섹션이 있으면 이에 대한 점성술 예측을 할 수 있습니다. 을 위한 INTER 예측 양도해야 함 모션 벡터 나머지는 INTRA 예측을 위해 전송됩니다. 예측 방향 그리고 나머지.

3단계 - 변신

잔여 블록(예측 섹션 → 실제 섹션)이 있으면 전체 품질을 유지하면서 어떤 픽셀을 폐기할 수 있는지 알 수 있도록 변환할 수 있습니다. 정확한 동작을 제공하는 몇 가지 변환이 있습니다.

다른 방법도 있지만 좀 더 자세히 살펴보겠습니다. 이산 코사인 변환 (DCT -부터 이산 코사인 변환). DCT의 주요 기능:

• 픽셀 블록을 동일한 크기의 주파수 계수 블록으로 변환합니다.
• 공간 중복성을 제거하는 데 도움이 되는 전력을 응축합니다.
• 가역성을 제공합니다.

2년 2017월 14일 신트라 R.J. (Cintra, RJ) 및 Bayer F.M. (Bayer FM)은 XNUMX개의 추가만 필요한 이미지 압축을 위한 DCT와 유사한 변환에 대한 기사를 게시했습니다.

각 포인트의 이점을 이해하지 못하더라도 걱정하지 마십시오. 이제 구체적인 예를 들어 실제 가치를 살펴보겠습니다.

이 8x8 픽셀 블록을 살펴보겠습니다.

이 블록은 다음과 같은 8 x 8 픽셀 이미지로 렌더링됩니다.

이 픽셀 블록에 DCT를 적용하고 8x8 계수 블록을 얻습니다.

그리고 이 계수 블록을 렌더링하면 다음 이미지를 얻게 됩니다.

보시다시피 원본 이미지와는 다릅니다. 첫 번째 계수가 다른 계수와 매우 다르다는 것을 알 수 있습니다. 이 첫 번째 계수는 평균과 같은 입력 배열의 모든 샘플을 나타내는 DC 계수로 알려져 있습니다.

이 계수 블록에는 흥미로운 속성이 있습니다. 즉, 고주파 성분을 저주파 성분과 분리합니다.

이미지에서는 대부분의 전력이 낮은 주파수에 집중되어 있으므로 이미지를 주파수 성분으로 변환하고 높은 주파수 계수를 버리면 화질을 크게 저하시키지 않고 이미지를 설명하는 데 필요한 데이터 양을 줄일 수 있습니다.

주파수는 신호가 얼마나 빨리 변하는지를 나타냅니다.

DCT를 사용하여 원본 이미지를 해당 주파수(계수 블록)로 변환한 다음 가장 중요하지 않은 계수의 일부를 삭제하여 테스트 사례에서 얻은 지식을 적용해 보겠습니다.

먼저 이를 주파수 영역으로 변환합니다.

다음으로 계수의 일부(67%), 주로 오른쪽 아래 부분을 버립니다.

마지막으로, 이 버려진 계수 블록에서 이미지를 재구성하고(이것은 반전 가능해야 함을 기억하십시오) 원본과 비교합니다.

원본 이미지와 유사하지만 원본과는 많은 차이점이 있음을 알 수 있습니다. 우리는 67,1875%를 버렸지만 여전히 원본과 유사한 것을 얻었습니다. 더 나은 품질의 이미지를 얻기 위해 계수를 더 신중하게 폐기하는 것이 가능했지만 이는 다음 주제입니다.

각 계수는 모든 픽셀을 사용하여 생성됩니다.

중요: 각 계수는 하나의 픽셀에 직접 매핑되지 않지만 모든 픽셀의 가중치 합계입니다. 이 놀라운 그래프는 각 지수에 고유한 가중치를 사용하여 첫 번째 및 두 번째 계수가 계산되는 방법을 보여줍니다.

DCT를 기반으로 한 간단한 이미지 형성을 살펴봄으로써 DCT를 시각화해 볼 수도 있습니다. 예를 들어, 다음은 각 계수 가중치를 사용하여 생성된 기호 A입니다.

4단계 - 양자화

이전 단계에서 일부 계수를 처리한 후 마지막 단계(변환)에서 특수한 형태의 양자화를 수행합니다. 이 단계에서는 정보를 잃어도 괜찮습니다. 또는 더 간단하게는 계수를 양자화하여 압축을 달성합니다.

계수 블록을 어떻게 양자화할 수 있나요? 가장 간단한 방법 중 하나는 균일 양자화입니다. 블록을 가져올 때 이를 하나의 값(10)으로 나누고 결과를 반올림합니다.

이 계수 블록을 뒤집을 수 있나요? 예, 나눈 값과 동일한 값을 곱하면 가능합니다.

이 접근 방식은 각 계수의 중요성을 고려하지 않기 때문에 최선이 아닙니다. 단일 값 대신 양자화기 행렬을 사용할 수 있으며, 이 행렬은 오른쪽 하단의 대부분과 왼쪽 상단의 소수를 양자화하여 DCT 특성을 활용할 수 있습니다.

5단계 - 엔트로피 코딩

데이터(이미지 블록, 조각, 프레임)를 양자화한 후에도 여전히 손실 없이 압축할 수 있습니다. 데이터를 압축하는 알고리즘 방법에는 여러 가지가 있습니다. 우리는 그 중 일부를 간략하게 살펴볼 것입니다. 더 깊은 이해를 위해 압축 이해: 현대 개발자를 위한 데이터 압축("압축 이해: 현대 개발자를 위한 데이터 압축").

VLC를 사용한 비디오 인코딩

문자 스트림이 있다고 가정해 보겠습니다. a, e, r и t. 각 문자가 스트림에 나타나는 빈도에 대한 확률(0~1 범위)이 이 표에 표시됩니다.

	a	e	r	t
확률	0,3	0,3	0,2	0,2

가능성이 가장 높은 코드에는 고유한 이진 코드(작은 코드 선호)를 할당하고 가능성이 낮은 코드에는 큰 코드를 할당할 수 있습니다.

	a	e	r	t
확률	0,3	0,3	0,2	0,2
바이너리 코드	0	10	110	1110

각 문자에 대해 8비트를 소비하게 된다고 가정하고 스트림을 압축합니다. 압축하지 않으면 문자당 24비트가 필요합니다. 각 문자를 해당 코드로 바꾸면 비용이 절감됩니다!

첫 번째 단계는 문자를 인코딩하는 것입니다. e, 이는 10과 같고 두 번째 문자는 a, 추가됩니다(수학적 방식이 아님): [10][0], 마지막으로 세 번째 문자 t, 이는 최종 압축 비트스트림을 [10][0][1110] 또는 1001110, 이는 7비트만 필요합니다(원본보다 3,4배 적은 공간).

각 코드는 접두사가 포함된 고유한 코드여야 합니다. 허프만 알고리즘 이 번호를 찾는 데 도움이 될 것입니다. 이 방법에 결함이 있는 것은 아니지만 이러한 압축 알고리즘 방법을 여전히 제공하는 비디오 코덱이 있습니다.

인코더와 디코더 모두 해당 이진 코드가 포함된 기호 테이블에 액세스할 수 있어야 합니다. 따라서 테이블을 입력으로 보내는 것도 필요합니다.

산술 코딩

문자 스트림이 있다고 가정해 보겠습니다. a, e, r, s и t, 그 확률은 이 표에 나와 있습니다.

	a	e	r	s	t
확률	0,3	0,3	0,15	0,05	0,2

이 테이블을 사용하여 가능한 모든 문자를 포함하는 범위를 가장 큰 숫자로 정렬하여 구성합니다.

이제 세 문자의 스트림을 인코딩해 보겠습니다. 먹다.

먼저 첫 번째 문자를 선택하세요. e, 이는 0,3에서 0,6(포함하지 않음)의 하위 범위에 있습니다. 우리는 이 하위 범위를 취하여 이전과 동일한 비율로 다시 나눕니다. 단, 이 새로운 범위에 대해서입니다.

계속해서 스트림을 코딩해 보겠습니다. 먹다. 이제 두 번째 캐릭터를 선택하세요. a, 이는 0,3에서 0,39 사이의 새로운 하위 범위에 있고 마지막 문자를 가져옵니다. t 동일한 과정을 다시 반복하면 0,354에서 0,372까지의 최종 하위 범위를 얻게 됩니다.

마지막 하위 범위에서 0,354에서 0,372 사이의 숫자를 선택하면 됩니다. 0,36을 선택하겠습니다. 하지만 이 하위 범위에서 다른 숫자를 선택할 수도 있습니다. 이 번호를 통해서만 원래 스트림을 복원할 수 있습니다. 이는 마치 스트림을 인코딩하기 위해 범위 내에 선을 그리는 것과 같습니다.

역연산(즉, 디코딩)은 마찬가지로 간단합니다. 숫자 0,36과 초기 범위를 사용하여 동일한 프로세스를 실행할 수 있습니다. 그러나 이제 이 번호를 사용하여 이 번호를 사용하여 인코딩된 스트림을 식별합니다.

첫 번째 범위에서는 숫자가 슬라이스에 해당하므로 이것이 첫 번째 문자라는 것을 알 수 있습니다. 이제 이전과 동일한 프로세스를 수행하여 이 하위 범위를 다시 나눕니다. 여기서 0,36이 기호에 해당함을 알 수 있습니다. a, 그리고 이 과정을 반복한 후에 우리는 마지막 문자에 도달했습니다. t (원래 인코딩된 스트림을 형성함) 먹다).

인코더와 디코더 모두 기호 확률 테이블이 있어야 하므로 이를 입력 데이터에도 함께 보내야 합니다.

꽤 우아하지 않나요? 이 해결책을 생각해낸 사람은 정말 똑똑했습니다. 일부 비디오 코덱은 이 기술을 사용합니다(또는 적어도 옵션으로 제공).

아이디어는 양자화된 비트 스트림을 무손실 압축하는 것입니다. 확실히 이 기사에는 수많은 세부 정보, 이유, 장단점 등이 누락되어 있습니다. 하지만 개발자라면 더 많은 것을 알아야 합니다. 새로운 코덱은 다음과 같은 다른 엔트로피 인코딩 알고리즘을 사용하려고 합니다. YEARS.

6단계 - 비트스트림 형식

이 모든 작업을 수행한 후에는 수행된 단계의 맥락에서 압축된 프레임의 압축을 풀어야 합니다. 디코더는 인코더가 내린 결정을 명시적으로 알려야 합니다. 디코더에는 비트 깊이, 색 공간, 해상도, 예측 정보(모션 벡터, 방향성 INTER 예측), 프로필, 레벨, 프레임 속도, 프레임 유형, 프레임 번호 등 필요한 모든 정보가 제공되어야 합니다.

비트스트림을 간단히 살펴보겠습니다. H.264. 첫 번째 단계는 최소한의 H.264 비트스트림을 생성하는 것입니다(FFmpeg는 기본적으로 다음과 같은 모든 인코딩 옵션을 추가합니다). 세이날 — 그것이 무엇인지 조금 더 알아 보겠습니다.) 우리는 자체 저장소와 FFmpeg를 사용하여 이를 수행할 수 있습니다.

./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264

이 명령은 원시 비트스트림을 생성합니다. H.264 하나의 프레임, 64×64 해상도, 색 공간 포함 YUV420. 이 경우 다음 이미지가 프레임으로 사용됩니다.

H.264 비트스트림

표준 AVC (H.264)는 정보가 매크로프레임(네트워크 의미에서)으로 전송될 것인지 결정합니다. 날 (이것은 네트워크 추상화 수준입니다). NAL의 주요 목표는 "웹 친화적인" 비디오 프레젠테이션을 제공하는 것입니다. 이 표준은 TV(스트림 기반), 인터넷(패킷 기반)에서 작동해야 합니다.

NAL 요소의 경계를 정의하는 동기화 마커가 있습니다. 각 동기화 토큰에는 값이 포함됩니다. 0x00 0x00 0x01, 첫 번째 항목을 제외하고는 다음과 같습니다. 0x00 0x00 0x00 0x01. 우리가 발사한다면 헥스 덤프 생성된 H.264 비트스트림의 경우 파일 시작 부분에서 최소 XNUMX개의 NAL 패턴을 식별합니다.

언급한 바와 같이 디코더는 이미지 데이터뿐만 아니라 비디오, 프레임, 색상, 사용된 매개변수 등의 세부 사항도 알아야 합니다. 각 NAL의 첫 번째 바이트는 카테고리와 유형을 정의합니다.

NAL 유형 식별자	기술
0	Неизвестный 팁
1	IDR이 없는 인코딩된 이미지 조각
2	코딩된 슬라이스 데이터 섹션 A
3	코딩된 슬라이스 데이터 섹션 B
4	코딩된 슬라이스 데이터 섹션 C
5	IDR 이미지의 인코딩된 IDR 조각
6	SEI 확장에 대한 추가 정보
7	SPS 시퀀스 매개변수 세트
8	PPS 이미지 매개변수 세트
9	접근 구분자
10	시퀀스 종료
11	스레드 끝
...	...

일반적으로 비트스트림의 첫 번째 NAL은 다음과 같습니다. PLC. 이러한 유형의 NAL은 프로필, 레벨, 해상도 등과 같은 일반적인 인코딩 변수에 대한 정보를 제공합니다.

첫 번째 동기화 마커를 건너뛰면 첫 번째 바이트를 디코딩하여 어떤 NAL 유형이 첫 번째인지 알아낼 수 있습니다.

예를 들어 동기화 토큰 다음의 첫 번째 바이트는 다음과 같습니다. 01100111, 여기서 첫 번째 비트(0)는 f 필드에 있습니다.orbidden_zero_bit. 다음 2비트(11) 필드를 알려줍니다. nal_ref_idc, 이는 이 NAL이 참조 필드인지 아닌지를 나타냅니다. 그리고 나머지 5비트(00111) 필드를 알려줍니다. nal_unit_type, 이 경우 SPS 블록입니다(7) NAL.

두 번째 바이트(진=01100100, 마녀=0 X 64, 12월=100) SPS NAL의 필드는 다음과 같습니다. 프로필_idc, 인코더가 사용한 프로필을 보여줍니다. 이 경우 제한된 하이 프로파일이 사용되었습니다(즉, 양방향 B 세그먼트 지원이 없는 하이 프로파일).

비트스트림 사양을 보면 H.264 SPS NAL의 경우 매개변수 이름, 카테고리 및 설명에 대한 많은 값을 찾을 수 있습니다. 예를 들어 필드를 살펴보겠습니다. pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.

매개변수 이름	범주	기술
pic_width_in_mbs_minus_1	0	UE(v)
pic_height_in_map_units_minus_1	0	UE(v)

이 필드의 값으로 몇 가지 수학적 연산을 수행하면 해상도를 얻을 수 있습니다. 다음을 사용하여 1920 x 1080을 나타낼 수 있습니다. pic_width_in_mbs_minus_1 값은 119((119 + 1) * 매크로블록_크기 = 120 * 16 = 1920)입니다. 이번에도 공간을 절약하기 위해 1920을 인코딩하는 대신 119로 인코딩했습니다.

생성된 비디오를 바이너리 형식으로 계속 확인하는 경우(예: xxd -b -c 11 v/minimal_yuv420.h264), 그러면 프레임 자체인 마지막 NAL로 이동할 수 있습니다.

여기서는 처음 6바이트 값을 볼 수 있습니다. 01100101 10001000 10000100 00000000 00100001 11111111. 첫 번째 바이트는 NAL 유형을 나타내는 것으로 알려져 있으므로 이 경우 (00101)는 IDR 조각(5)이며, 이를 더 자세히 탐색할 수 있습니다.

사양 정보를 사용하면 조각 유형(슬라이스_유형) 및 프레임 번호(프레임 번호) 다른 중요한 분야 중 하나입니다.

일부 필드의 값을 얻으려면(ue(v), me(v), se(v) 또는 te(v)), 우리는 다음을 기반으로 하는 특수 디코더를 사용하여 조각을 디코딩해야 합니다. 지수 골롬 코드. 이 방법은 특히 기본값이 많은 경우 변수 값을 인코딩하는 데 매우 효율적입니다.

의미 슬라이스_유형 и 프레임 번호 이 비디오의 7(I-조각)과 0(첫 번째 프레임)입니다.

비트스트림은 프로토콜로 생각될 수 있습니다. 비트스트림에 대해 더 알고 싶다면 사양을 참조하세요. ITU H.264. 다음은 이미지 데이터의 위치를 ​​보여주는 매크로 다이어그램입니다(YUV 압축된 형태로).

다음과 같은 다른 비트스트림을 검사할 수 있습니다. VP9, H.265 (HEVC) 또는 새로운 최고의 비트스트림 AV1. 다들 비슷해요? 아니요. 하지만 적어도 하나를 이해하면 나머지도 이해하기가 훨씬 쉽습니다.

연습하고 싶나요? H.264 비트스트림 살펴보기

단일 프레임 비디오를 생성하고 MediaInfo를 사용하여 비트스트림을 검사할 수 있습니다. H.264. 실제로 비트스트림을 분석하는 소스 코드를 보는 것조차 방해가 되지 않습니다. H.264 (AVC).

연습을 위해 Intel Video Pro Analyser를 사용할 수 있습니다(이미 프로그램이 유료라고 말했지만 10프레임으로 제한되는 무료 평가판이 있습니까?).

검토

많은 최신 코덱은 방금 연구한 것과 동일한 모델을 사용합니다. 여기서는 비디오 코덱의 블록 다이어그램을 살펴보겠습니다. 토르. 여기에는 우리가 겪은 모든 단계가 포함되어 있습니다. 이 게시물의 요점은 최소한 이 분야의 혁신과 문서에 대한 더 나은 이해를 제공하는 것입니다.

이전에는 139p 품질, 720fps로 30시간 분량의 비디오 파일을 저장하려면 0,031GB의 디스크 공간이 필요한 것으로 계산되었습니다. 이 기사에서 논의한 방법(프레임 간 및 내부 예측, 변환, 양자화, 엔트로피 코딩 등)을 사용하면 (픽셀당 367,82비트를 소비한다는 사실을 기반으로) 매우 뛰어난 비디오를 얻을 수 있습니다. 139GB의 메모리가 아닌 XNUMXMB만 차지하는 만족스러운 품질입니다.

H.265는 어떻게 H.264보다 더 나은 압축률을 달성합니까?

이제 코덱 작동 방식에 대해 더 많이 알았으므로 최신 코덱이 더 적은 비트로 더 높은 해상도를 제공할 수 있는 방법을 더 쉽게 이해할 수 있습니다.

비교해보자면 AVC и HEVC, 이는 거의 항상 더 높은 CPU 로드와 압축 비율 사이에서 선택된다는 점을 기억할 가치가 있습니다.

HEVC 다음보다 더 많은 섹션(및 하위 섹션) 옵션이 있습니다. AVC, 더 많은 내부 예측 방향, 향상된 엔트로피 코딩 등이 있습니다. 이러한 모든 개선이 이루어졌습니다. H.265 50% 이상 압축 가능 H.264.

Первая의 часть : 비디오 및 이미지 작업의 기본 사항

출처 : habr.com