오디오 및 비디오 압축: H264 코드 스트림 계층 구조 및 NALU 자세한 설명

서문:

인코딩이 필요한 이유는 무엇입니까? 예를 들어, 현재 화면은 1280*720입니다. 그러면 1초 동안의 비디오 데이터는 1280*720(픽셀) * 24(사진) / 8(1바이트, 8비트)입니다. ) / 1024(결과: KB) / 1024(결과: MB) = 2.64MB

1초의 데이터에는 2.64MB의 데이터가 있습니다. 1분에 100MB 이상이 됩니다. 이것은 실제로 사용자에게 재앙입니다. 따라서 이제 데이터 크기를 줄이면서 더 낮은 비트 전송률(bps)에서도 선명한 비디오를 제공하기 위한 압축 방법이 필요합니다.

H264: H264/AVC는 널리 사용되는 인코딩 방법입니다. 여기에서 이해를 도와드리겠습니다. 큰 것부터 작은 순서는 시퀀스, 이미지, NALU, 슬라이스, 매크로블록, 하위 매크로블록, 블록 및 픽셀입니다.

문제 배경:

캡슐화 형식을 이야기하는 과정에서 H.264 NALU 유닛을 TS, FLV, RTP로 패키징하는 방법을 설명하는 장이 있고, 반대로, 이러한 캡슐화 형식에서 각 NALU 단위를 구문 분석하는 방법. NALU는 인코더의 출력 데이터와 디코더의 입력 데이터이므로 캡슐화하고 전송할 때 일반적으로 NALU를 다루고 NALU 내부에 무엇이 있는지 거의 신경 쓰지 않습니다. 인코딩 및 디코딩하는 경우에도 x264 인코딩 라이브러리를 초기화한 다음 YUV 데이터를 입력하면 일련의 압축 알고리즘 후에 NALU를 출력하거나 x264 디코딩 라이브러리에 NALU를 입력하고 YUV 데이터를 출력합니다.

이 글에서는 NALU가 전송할 수 있는 데이터, NALU의 유형과 구조, H264 코드 스트림 수준에 대해 미리 살펴보겠습니다. 마지막으로 분석을 통해 네이키드 코드 스트림 메모리 검증을 분석합니다. 도구를 사용하여 관심 있는 장을 읽을 수 있습니다.

NALU 구조:

네이키드 스트림(형식 캡슐화 없음)이라고도 하는 H.264의 기본 스트림은 그림에 표시된 대로 일련의 NALU 모음입니다. 아래 :

메모장 16진수 형식으로 열고 h264 네이키드 스트림 파일 콘텐츠를 annexb 형식으로 저장합니다.

NALU 구조는 비디오 코딩 계층(VCL)을 포함하여 두 개의 계층으로 나누어집니다. NAL(Network Adaptation Layer):

비디오 코딩 계층(VCL, Video Coding Layer): 효율적인 비디오 콘텐츠 표현을 담당하며 매크로 블록 및 슬라이스 처리를 포함합니다. 이 수준에서 출력되는 데이터는 SODB입니다.

네트워크 적응 계층(NAL, Network Abstraction Layer): 네트워크에서 요구하는 적절한 방식으로 데이터를 패킷으로 전송합니다. 먼저 데이터를 보고합니다. VCL에서 생성된 SODB는 바이트 정렬되어 RBSP를 구성합니다. 마지막으로 RBSP 데이터 앞에 NAL 헤더를 추가하여 NALU 단위를 구성합니다.

계층화 목적:

목적: VCL은 압축, 양자화 및 기타 처리를 포함한 비디오 신호 처리만 담당하는 반면 NAL은 인코딩된 데이터의 네트워크 전송을 해결합니다. VCL 및 NAL의 처리는 서로 다른 플랫폼에서 처리되므로 서로 다른 네트워크 환경으로 인해 VCL 비트 스트림의 재구성 및 레코딩이 줄어들 수 있습니다.

NLAU 구조:

실제로 NALU가 전달하는 데이터는 RBSP(Raw Byte Sequence Playload)가 아니라 EBSP(Extent Byte Sequence Payload)입니다. EBSP와 RBSP의 차이점은 위조 방지 시작 코드 바이트(0x03)입니다. H.264 사양에서는 인코더가 내뿜는 데이터가 각 NALU에 시작 코드(0x00 00 01 또는 0x00 00 00 01)를 추가해야 한다고 규정하고 있기 때문에 이는 RBSP의 시작 및 끝 위치를 나타내는 데 사용됩니다. NALU이면 RBSP 데이터에는 이러한 종류의 바이트 시퀀스가 ​​포함될 수 있습니다. 구문 분석 오류를 방지하기 위해 RBSP 데이터 스트림에서 0x00 00 01을 만나면 0x03이 0x01 앞에 추가됩니다. NALU의 EBSP에서 제거되어 RBSP가 되는데, 이를 For shelling 작업이라고 합니다.

원래 바이트 시퀀스 로드 RBSP는 Raw Byte Sequence Playload입니다. VCL에 의해 출력된 원래 데이터 비트 스트림 SODB는 String Of Data Bits이고 그 길이가 반드시 8비트의 정수 배수일 필요는 없기 때문입니다. 정수 단어 섹션을 구성하려면 SODB의 마지막 바이트를 채워 RBSP를 형성해야 하는 경우가 많으므로 SODB에서 RBSP까지의 개략도는 다음과 같습니다.

채우기 방법은 분할하는 것입니다. VCL의 출력 데이터는 8비트로, 마지막 비트는 8비트 미만입니다. 바이트의 첫 번째 비트는 1로 설정되고 다음 기본 비트는 0으로 설정됩니다.

자세한 내용은 아래를 참조하세요. 구체적인 채우기 구문:

원본 문서의 설명:

제가 이해한 주요 의미는 다음과 같습니다.

H.264 사양에서는 인코더에 의해 유출된 데이터는 각 NALU에 시작 코드(0x00 00 01 또는 0x00 00 00 01)를 추가해야 합니다. 이는 NALU의 시작 및 끝 위치를 나타냅니다.

따라서 H.264 인코더가 출력하는 코드 스트림의 각 프레임 시작 부분에 있는 3~4바이트의 시작 코드는 0x00 00 01 또는 0x00 00 00 01입니다.

위에서 NALU의 구조와 각 레이어의 출력 데이터 처리 방법을 분석했지만 NALU의 RBSP 데이터의 이진 표현이 무엇을 의미하는지 명확하지 않습니다. 아래에서는 NALU의 유형을 분석해 보겠습니다.

1. NALU 헤더

헤더 정보 프로토콜은 위와 같습니다.

예:

그 중 NALU의 RBSP는 실제 비디오 압축 데이터를 전달할 수 있을 뿐만 아니라 인코더 구성 정보도 전송할 수 있습니다. 그 중 슬라이스는 비디오 압축 데이터를 전송할 수 있습니다.

그러면 NLAU가 비디오 압축 데이터를 전송할 때 인코더가 DP(데이터 분할) 메커니즘을 켜지 않으면 슬라이스는 NALU이고 NALU도 슬라이스입니다.

그렇지 않은 경우 슬라이스는 세 개의 NALU, 즉 DPA, DPB 및 DPC로 구성되며 해당 nal_unit_type 유형은 2, 3 및 4입니다.

일반적으로 우리가 보는 NLAU 유형은 SPS, PPS, SEI, IDR 슬라이스 및 비IDR입니다.

이상에서는 NALU의 계층화된 처리 유형, 구조, 데이터 소스 및 이유를 NALU 관점에서 살펴보았습니다. NLAU의 주요 목적은 비디오 데이터 압축 결과를 전송하는 것입니다. 그럼 데이터 자체에 대한 이해를 바탕으로 H.264 코드 스트림의 계층적 구조를 살펴보겠습니다.

H.264 계층 구조:

실제로 H.264가 비디오 데이터를 어떻게 처리하는지 이해하려면 먼저 비디오의 형성 과정을 이해해야 합니다. 실제로 여러 개의 연속된 관련 이미지를 연속적으로 재생하여 비디오를 구성할 수 있습니다. 이는 주로 인간 시각 시스템의 지속 효과를 활용합니다. 연속된 사진을 초당 25장의 속도로 재생할 때 인간의 눈은 기본적으로 연속적이라는 것입니다. 이것이 만화의 원리입니다. 이미지의 인접한 영역이나 일정 시간 내에 연속된 이미지의 동일한 위치는 픽셀, 밝기 및 색온도의 차이가 상대적으로 작으므로 비디오 압축의 본질은 이러한 종류의 공간을 용이하게 하는 것입니다. 인코딩의 경우 일정 기간 동안 첫 번째 이미지의 YUV 값을 선택한 다음 동시에 이미지의 YUV 값과의 차이만 기록하면 됩니다. 녹화를 하면 렌즈가 완전히 전환되면 전환 후 첫 번째 이미지를 기본 이미지로 선택하는데, 현재 영상 압축의 기본 원리를 설명하는 글이 나중에 나와 있습니다.

이를 통해 다음 개념이 도출될 수 있습니다.

따라서 비디오 스트림 분석의 대상은 다음 그림으로 설명할 수 있습니다.

data NALU의 계층적 관계를 NLAU 관점에서 분석해 보면 아래와 같습니다.

여기서 비디오 프레임은 하나의 슬라이스 또는 여러 개의 슬라이스로 나누어지며, 여기서 슬라이스 데이터는 주로 NLAU를 통해 전송되고, 슬라이스는 데이터는 다음을 통해 전송됩니다:

A Slice = Silce Slice Data

사진 프레임과 NALU 간의 관계:

사진 프레임이 전달된 후 H.264 인코더를 통해 여러 개의 슬라이스로 인코딩되며, 이러한 슬라이스를 운반하는 캐리어는 NALU와 슬라이스 간의 관계를 살펴볼 수 있습니다.

인용: /p/9522c4a7818d

슬라이스 유형:

슬라이스 설정의 목적은 비트 오류의 확산과 전송을 제한하는 것입니다. , 이미지 프레임 그들의 인코딩 슬라이스는 서로 독립적이므로 이미지 중 하나의 특정 슬라이스에 문제가 있어 디코딩이 흐려지는 것으로 가정되지만 영향의 범위는 이것으로 제한됩니다. 슬라이스. 이것이 우리가 비디오를 볼 때 일반적으로 화면이 부분적으로 흐릿하고 녹색 화면이 나타나는 이유입니다.

슬라이스 데이터는 매크로블록을 하나씩 전송합니다. 매크로블록의 데이터는 각 픽셀의 YUV 압축 데이터를 전달합니다. 이미지는 일반적으로 연구를 위해 16 16, 16 8 및 기타 형식의 매크로 블록으로 나뉩니다. 우리의 디코딩 프로세스는 이러한 픽셀 배열을 복원하는 프로세스이기도 합니다. 각 픽셀의 밝기와 색도를 알면 완전한 이미지를 렌더링할 수 있습니다.

방금 매크로블록에 대해 언급했습니다. 그러면 매크로블록이란 무엇입니까?

매크로블록은 비디오 정보의 주요 전달자입니다. 코딩된 이미지는 일반적으로 각 픽셀의 밝기와 색차 정보를 포함하는 여러 매크로블록으로 나뉩니다. 비디오 디코딩의 주요 임무는 코드 스트림에서 매크로블록의 픽셀 배열을 얻는 효율적인 방법을 제공하는 것입니다.

매크로 블록 = 16*16 밝기 픽셀, 8×8Cb, 8×8Cr 컬러 픽셀 블록. (YCbCr은 YUV 계열에 속합니다. YCbCr에서 Y는 밝기 성분, Cb는 청색 채도 성분, Cr은 적색 채도 성분을 나타냅니다.)

그 중 유형은 매크로블록 MB:

매크로블록 구조:

H.264 코드 스트림 예제 분석:

여기서는 H.264 NLAU 데이터를 분석합니다. VCL NALU 데이터 및 VCL용 NALU.

H.264 코드 스트림의 NLAU 단위:

4. 데이터 분할 메커니즘이 없으므로 하나의 NALU는 하나의 슬라이스를 전달하고 하나의 슬라이스는 비디오 프레임입니다. >

4. NALU의 비VCL 데이터 SPS, PPS, SEI의 각 필드의 구체적인 의미는 다음 기사에 맡기겠습니다. 이 정보는 디코더가 동영상을 재생하는 데 매우 중요합니다.

비디오의 GOP 시퀀스, 비디오 프레임 정보 및 슬라이스 구성을 살펴보았습니다. /p>

H.264의 계층 구조:

요약:

이 기사는 주로 비디오 스트림 개체 수준에 대한 일반적인 연구 및 분석에 대해 설명합니다. 그런 다음 이러한 비디오 데이터가 NALU를 통해 전송될 때 NALU의 유형 및 계층 관계, NALU 데이터 출력의 다양한 수준이 달라집니다. 마지막으로 위의 계층적 관계를 검증하기 위해 비디오 분석 도구를 사용하여 H.264 베어 코드 스트림을 분석했습니다.

따라서 H.264 데이터를 분석할 때 현재 분석의 수준과 프레임워크를 이해해야 합니다. 각 수준에서 우리가 관심을 갖는 데이터 처리 개체가 다르기 때문에 이것이 매우 중요합니다.

일반적으로 H.264 분석 도구는 유료이며 모든 사람이 배우고 사용할 수 있는 무료 및 맞춤형 버전도 있습니다. 나는 몇 가지를 추천합니다: Elecard StreamEye, CodecVisa, VideoEye, H264Analyzer, H264Visa 등. 때때로 당신이 관심 있는 정보의 분석을 완료하기 위해 그것들을 교차 사용할 필요가 있습니다. 이것들은 모두 내 Git에 있고 누구나 얻을 수 있습니다. 그리고 그것들을 사용하세요.

원문 인용

25fps i-frame 간격 50. 분석 소프트웨어를 사용하여 50프레임마다 i-frame이 있는지 확인하고 sps, pps, sei를 보냅니다

p>

sps, pps, sei, I 프레임을 묶어서 전송합니다