본문으로 이동

H.264/MPEG-4 AVC

위키백과, 우리 모두의 백과사전.
고급 비디오 코딩(Advanced Video Coding)/ H.264 / MPEG-4 Part 10
Advanced video coding for generic audiovisual services
상태시행 중
시작 연도2003년(23년 전)(2003)
최초 출판일2004년 8월 17일 (2004-08-17)
마지막 버전15.0
2024년 8월 13일 (2024-08-13)
조직ITU-T, ISO, IEC
위원회SG16 (VCEG), MPEG
기초가 되는 표준H.261, H.262 (일명 MPEG-2 Video), H.263, ISO/IEC 14496-2 (일명 MPEG-4 Part 2)
관련 표준H.265 (일명 HEVC), H.266 (일명 VVC)
분야영상 압축
라이선스MPEG LA[1]
웹사이트www.itu.int/rec/T-REC-H.264
지각적 품질 점수가 포함된 H.264 인코더의 비디오 코딩 계층 블록도

고급 비디오 코딩(Advanced Video Coding, AVC) 또는 H.264 또는 MPEG-4 Part 10은 블록 지향적이고 움직임 보상을 기반으로 하는 영상 압축 표준이다.[2] 2024년 12월 기준 비디오 산업 개발자의 79%가 사용하고 있으며, 비디오 콘텐츠의 녹화, 압축 및 배포에 가장 흔히 사용되는 형식이다.[3] 최대 8K UHD 해상도를 지원한다.[4][5]

H.264/AVC 프로젝트의 의도는 구현이 불가능하거나 지나치게 비용이 많이 들 정도로 설계 복잡성을 높이지 않으면서도, 이전 표준들(MPEG-2, H.263, MPEG-4 파트 2)보다 상당히 낮은 비트레이트(절반 이하)에서 우수한 비디오 품질을 제공할 수 있는 표준을 만드는 것이었다. 이는 복잡성이 감소된 정수 이산 코사인 변환(정수 DCT),[6] 가변 블록 크기 분할, 다중 사진 사진 간 예측 등의 기능을 통해 달성되었다. 추가적인 목표는 저비트레이트 및 고비트레이트, 저해상도 및 고해상도 비디오, 방송, DVD 저장, RTP/IP 패킷 네트워크, ITU-T 멀티미디어 텔레포니 시스템 등 다양한 네트워크와 시스템의 광범위한 응용 분야에 적용될 수 있도록 충분한 유연성을 제공하는 것이었다. H.264 표준은 여러 가지 프로파일로 구성된 "표준 제품군"으로 볼 수 있는데, 그 중 "High 프로파일"이 가장 널리 사용된다. 특정 디코더는 최소한 하나 이상의 프로파일을 디코딩하지만, 반드시 모든 프로파일을 디코딩할 필요는 없다. 표준은 인코딩된 데이터의 형식과 데이터를 디코딩하는 방법을 설명하지만 인코딩 알고리즘을 지정하지는 않는다. 이는 인코더 설계자가 스스로 선택할 수 있는 몫으로 남겨두었으며, 이에 따라 매우 다양한 인코딩 체계가 개발되었다. H.264는 일반적으로 손실 압축에 사용되지만, 손실 코딩된 사진 내에 진정한 비손실 압축 영역을 생성하거나 전체 인코딩이 비손실인 드문 사례를 지원하는 것도 가능하다.

H.264는 ITU-T 제16 연구 그룹의 영상 부호화 전문가 그룹(VCEG)과 ISO/IEC JTC 1의 Moving Picture Experts Group(MPEG)에 의해 표준화되었다. 이 프로젝트 파트너십 노력은 Joint Video Team (JVT)으로 알려져 있다. ITU-T H.264 표준과 ISO/IEC MPEG-4 AVC 표준(공식적으로 ISO/IEC 14496-10 – MPEG-4 파트 10, Advanced Video Coding)은 기술적으로 동일한 내용을 갖도록 공동으로 유지 관리된다. 표준의 첫 번째 버전에 대한 최종 초안 작업은 2003년 5월에 완료되었으며, 이후 판본에서 기능의 다양한 확장이 추가되었다. 동일한 조직에서 개발한 고효율 비디오 코딩(HEVC, 일명 H.265 및 MPEG-H 파트 2)은 H.264/MPEG-4 AVC의 후속 표준이지만, 이전 표준들도 여전히 흔히 사용되고 있다.

H.264는 아마도 블루레이 디스크에서 가장 흔히 사용되는 비디오 인코딩 형식으로 가장 잘 알려져 있을 것이다. 또한 넷플릭스, 훌루, 프라임 비디오, 비메오, 유튜브(최근에는 VP9 및 AV1으로 전환 중), 아이튠즈 스토어와 같은 스트리밍 인터넷 소스, 어도비 플래시 플레이어 및 마이크로소프트 실버라이트와 같은 웹 소프트웨어, 그리고 지상파(ATSC, ISDB-T, DVB-T 또는 DVB-T2), 케이블(DVB-C), 위성(DVB-S 및 DVB-S2) 시스템을 통한 다양한 HDTV 방송에서도 널리 사용되어 왔다.

H.264는 다양한 당사자가 보유한 특허에 의해 제한된다. H.264에 필수적인 대부분의(전부는 아님) 특허를 포함하는 라이선스는 이전에 MPEG LA에서 관리하던 특허 풀에 의해 관리된다. Via Licensing Corp은 2023년 4월에 MPEG LA를 인수하여 Via Licensing Alliance라는 새로운 특허 풀 관리 회사를 설립했다.[7] 특허를 받은 H.264 기술의 상업적 사용은 Via 및 기타 특허 소유자에게 로열티를 지불해야 한다. MPEG LA는 최종 사용자에게 무료인 스트리밍 인터넷 비디오에 대해 H.264 기술의 무료 사용을 허용했으며, 시스코는 자사의 오픈 소스 H.264 인코더인 OpenH264의 바이너리 사용자들을 대신하여 MPEG LA에 로열티를 지불했다.

명칭

[편집]

H.264라는 이름은 ITU-T 명명 규칙을 따르는데, 여기서 권고안(Recommendation)은 해당 시리즈에 해당하는 문자와 시리즈 내의 권고 번호가 부여된다. H.264는 "H-시리즈 권고: 시청각 및 멀티미디어 시스템"의 일부이다. H.264는 더 세부적으로 "H.200-H.499: 시청각 서비스의 인프라" 및 "H.260-H.279: 동영상 부호화"로 분류된다.[8] MPEG-4 AVC라는 이름은 ISO/IEC MPEG의 명명 규칙과 관련이 있는데, 이 표준은 MPEG-4로 알려진 표준 모음인 ISO/IEC 14496의 파트 10이다. 이 표준은 ITU-T에서 H.26L이라 불리는 VCEG 프로젝트로 초기 개발 작업이 진행된 후, VCEG와 MPEG의 파트너십을 통해 공동으로 개발되었다. 따라서 공통의 유산을 강조하기 위해 H.264/AVC, AVC/H.264, H.264/MPEG-4 AVC 또는 MPEG-4/H.264 AVC와 같은 명칭으로 표준을 지칭하는 것이 일반적이다. 때때로 이를 개발한 Joint Video Team (JVT) 조직을 지칭하여 "JVT 코덱"이라고 부르기도 한다. (이러한 파트너십과 다중 명명은 드문 일이 아니다. 예를 들어 MPEG-2로 알려진 영상 압축 표준 역시 MPEG와 ITU-T 간의 파트너십에서 탄생했으며, MPEG-2 비디오는 ITU-T 커뮤니티에서 H.262로 알려져 있다.[9]) 일부 소프트웨어 프로그램(VLC 미디어 플레이어 등)은 내부적으로 이 표준을 AVC1으로 식별한다.

역사

[편집]

전체 역사

[편집]

1998년 초, 영상 부호화 전문가 그룹(VCEG – ITU-T SG16 Q.6)은 광범위한 응용 분야에 대해 기존의 다른 비디오 코딩 표준과 비교하여 코딩 효율을 두 배로 높이는(즉, 주어진 충실도 수준에 필요한 비트레이트를 절반으로 줄이는) 것을 목표로 하는 H.26L이라는 프로젝트에 대한 제안 요청을 공고했다. VCEG 의장은 게리 설리번(마이크로소프트, 전 PictureTel, 미국)이 맡았다. 이 새로운 표준에 대한 첫 번째 초안 설계는 1999년 8월에 채택되었다. 2000년에는 토마스 비간트(독일 Heinrich Hertz Institute)가 VCEG 공동 의장이 되었다.

2001년 12월, VCEG와 Moving Picture Experts Group(MPEG – ISO/IEC JTC 1/SC 29/WG 11)은 비디오 코딩 표준을 확정하기 위한 헌장과 함께 Joint Video Team (JVT)을 결성했다.[10] 사양에 대한 공식 승인은 2003년 3월에 이루어졌다. JVT는 게리 설리번, 토마스 비간트, 아자이 루트라(모토로라, 미국: 이후 Arris, 미국)가 의장을 맡았다. 2004년 7월에는 충실도 범위 확장(Fidelity Range Extensions, FRExt) 프로젝트가 완료되었다. 2005년 1월부터 2007년 11월까지 JVT는 계층적 비디오 부호화(SVC)라고 불리는 부속서(G)를 통해 H.264/AVC를 확장하는 작업을 진행했다. JVT 관리팀은 옌스 라이너 옴(독일 아헨 공과대학교)에 의해 확장되었다. 2006년 7월부터 2009년 11월까지 JVT는 3차원 텔레비전 및 제한된 범위의 자유 시점 텔레비전을 향한 H.264/AVC의 확장인 다시점 비디오 부호화(MVC) 작업을 수행했다. 이 작업에는 표준의 두 가지 새로운 프로파일인 Multiview High 프로파일과 Stereo High 프로파일의 개발이 포함되었다.

표준 개발 과정 전반에 걸쳐 부가적인 향상 정보(Supplemental Enhancement Information, SEI)를 포함하기 위한 추가 메시지가 개발되었다. SEI 메시지에는 비디오 사진의 타이밍을 나타내거나 코딩된 비디오의 다양한 속성 또는 비디오가 사용되거나 향상될 수 있는 방법을 설명하는 다양한 유형의 데이터가 포함될 수 있다. 임의의 사용자 정의 데이터를 포함할 수 있는 SEI 메시지도 정의되어 있다. SEI 메시지는 핵심 디코딩 프로세스에 영향을 미치지는 않지만, 비디오를 사후 처리하거나 표시하는 데 권장되는 방법을 나타낼 수 있다. 비디오 콘텐츠의 해석을 위한 색 공간 표시와 같은 비디오 콘텐츠의 다른 상위 레벨 속성은 비디오 사용성 정보(VUI)로 전달된다. 하이 다이내믹 레인지 및 넓은 색 영역 비디오를 위한 새로운 색 공간이 개발됨에 따라 이를 나타내기 위한 추가 VUI 식별자가 추가되었다.

충실도 범위 확장 및 전문가용 프로파일

[편집]

H.264/AVC 첫 번째 버전의 표준화는 2003년 5월에 완료되었다. 원래 표준을 확장하기 위한 첫 번째 프로젝트에서 JVT는 충실도 범위 확장(FRExt)이라 불리는 것을 개발했다. 이러한 확장은 샘플 비트 깊이 정밀도 향상과 Y′CBCR 4:2:2(일명 YUV 4:2:2) 및 4:4:4로 알려진 샘플링 구조를 포함한 고해상도 색상 정보를 지원함으로써 더 높은 품질의 비디오 코딩을 가능하게 했다. 4×4 및 8×8 변환 간의 적응형 전환 기능이 있는 8×8 정수 이산 코사인 변환(정수 DCT), 인코더가 지정한 지각 기반 양자화 가중치 행렬, 효율적인 사진 간 비손실 코딩, 추가 색 공간 지원 등 여러 다른 기능도 FRExt 프로젝트에 포함되었다. FRExt 프로젝트의 설계 작업은 2004년 7월에 완료되었고, 초안 작업은 2004년 9월에 완료되었다.

그 후 주로 전문가용 응용 분야를 대상으로 하는 5개의 새로운 프로파일(아래 버전 7 참조)이 개발되었는데, 여기에는 확장 영역 색 공간 지원 추가, 추가 종횡비 표시기 정의, 두 가지 추가 유형의 "부가적인 향상 정보"(사후 필터 힌트 및 톤 매핑) 정의, 그리고 업계 피드백에 따라 다르게 설계되었어야 한다고 판단된 이전 FRExt 프로파일 중 하나(High 4:4:4 프로파일)의 폐지가 포함되었다.

계층적 비디오 부호화

[편집]

표준에 추가된 다음 주요 기능은 계층적 비디오 부호화(SVC)였다. H.264/AVC의 부속서 G에 규정된 SVC는 표준을 준수하는 하위 비트스트림 계층을 포함하는 비트스트림의 구성을 허용하며, 여기에는 SVC를 지원하지 않는 H.264/AVC 코덱으로 디코딩할 수 있는 "기본 계층"으로 알려진 비트스트림도 포함된다. 시간적 비트스트림 가변성(즉, 메인 비트스트림보다 시간적 샘플링 속도가 작은 하위 비트스트림의 존재)을 위해, 하위 비트스트림을 유도할 때 메인 비트스트림에서 완전한 액세스 유닛이 제거된다. 이 경우 비트스트림의 상위 레벨 구문 및 인터 예측 참조 사진은 그에 따라 구성된다. 반면, 공간적 및 품질 비트스트림 가변성(즉, 메인 비트스트림보다 공간 해상도/품질이 낮은 하위 비트스트림의 존재)을 위해, 하위 비트스트림을 유도할 때 비트스트림에서 NAL(네트워크 추상화 계층)이 제거된다. 이 경우 효율적인 코딩을 위해 일반적으로 계층 간 예측(즉, 낮은 공간 해상도/품질 신호의 데이터로부터 높은 공간 해상도/품질 신호를 예측하는 것)이 사용된다. 계층적 비디오 부호화 확장은 2007년 11월에 완료되었다.

다시점 비디오 부호화

[편집]

표준에 추가된 다음 주요 기능은 다시점 비디오 부호화(MVC)였다. H.264/AVC의 부속서 H에 규정된 MVC는 비디오 장면의 둘 이상의 시점을 나타내는 비트스트림의 구성을 가능하게 한다. 이 기능의 중요한 예는 입체 3D 비디오 코딩이다. MVC 작업에서 두 가지 프로파일이 개발되었다. Multiview High 프로파일은 임의의 수의 시점을 지원하며, Stereo High 프로파일은 2-시점 입체 비디오를 위해 특별히 설계되었다. 다시점 비디오 부호화 확장은 2009년 11월에 완료되었다.

3D-AVC 및 MFC 입체 코딩

[편집]

이후 깊이 지도와 텍스처의 공동 코딩을 포함하는 3D 비디오 코딩(3D-AVC로 명명), 다해상도 프레임 호환(MFC) 입체 및 3D-MFC 코딩, 다양한 추가 기능 조합, 더 큰 프레임 크기 및 프레임 레이트를 포함하는 추가 확장이 개발되었다.

버전

[편집]

H.264/AVC 표준의 버전에는 다음과 같이 완료된 개정, 정오표 및 수정안이 포함된다(날짜는 ITU-T의 최종 승인 날짜이며, ISO/IEC의 최종 "국제 표준" 승인 날짜는 대부분의 경우 다소 늦다). 각 버전은 텍스트에 통합된 바로 아래 버전과 비교한 변경 사항을 나타낸다.

  • 버전 1 (에디션 1): (2003년 5월 30일) Baseline, Main, Extended 프로파일을 포함하여 처음으로 승인된 H.264/AVC 버전.[11]
  • 버전 2 (에디션 1.1): (2004년 5월 7일) 다양한 사소한 수정 사항을 포함하는 정오표.[12]
  • 버전 3 (에디션 2): (2005년 3월 1일) 충실도 범위 확장(FRExt)을 설정하는 첫 번째 수정안을 포함하는 주요 추가 사항. 이 버전에서는 High, High 10, High 4:2:2, High 4:4:4 프로파일이 추가되었다.[13] 몇 년 후, High 프로파일은 표준에서 가장 흔히 사용되는 프로파일이 되었다.
  • 버전 4 (에디션 2.1): (2005년 9월 13일) 다양한 사소한 수정 사항과 3개의 종횡비 표시기를 추가한 정오표.[14]
  • 버전 5 (에디션 2.2): (2006년 6월 13일) 이전 High 4:4:4 프로파일의 제거로 구성된 수정안(ISO/IEC에서는 정오표로 처리됨).[15]
  • 버전 6 (에디션 2.2): (2006년 6월 13일) 확장 영역 색 공간 지원과 같은 사소한 확장으로 구성된 수정안(ISO/IEC에서는 위에서 언급한 종횡비 표시기와 묶음 처리됨).[15]
  • 버전 7 (에디션 2.3): (2007년 4월 6일) High 4:4:4 Predictive 프로파일과 4개의 Intra-전용 프로파일(High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra, CAVLC 4:4:4 Intra) 추가를 포함하는 수정안.[16]
  • 버전 8 (에디션 3): (2007년 11월 22일) Scalable Baseline, Scalable High, Scalable High Intra 프로파일을 포함하는 계층적 비디오 부호화(SVC) 수정안을 포함하는 H.264/AVC의 주요 추가 사항.[17]
  • 버전 9 (에디션 3.1): (2009년 1월 13일) 사소한 수정 사항을 포함하는 정오표.[18]
  • 버전 10 (에디션 4): (2009년 3월 16일) 이전에 지정된 다양한 프로파일에서 지원되는 공통 기능 하위 집합만을 가진 새로운 프로파일(Constrained Baseline 프로파일)의 정의를 포함하는 수정안.[19]
  • 버전 11 (에디션 4): (2009년 3월 16일) Multiview High 프로파일을 포함한 다시점 비디오 부호화(MVC) 확장 수정안을 포함하는 H.264/AVC의 주요 추가 사항.[19]
  • 버전 12 (에디션 5): (2010년 3월 9일) 인터레이스 코딩 도구를 지원하는 2-시점 비디오 코딩을 위한 새로운 MVC 프로파일(Stereo High 프로파일) 정의 및 프레임 패킹 배열 SEI 메시지로 명칭된 추가 부가적인 향상 정보(SEI) 메시지를 규정하는 수정안.[20]
  • 버전 13 (에디션 5): (2010년 3월 9일) 사소한 수정 사항을 포함하는 정오표.[20]
  • 버전 14 (에디션 6): (2011년 6월 29일) 초당 최대 매크로블록 수 측면에서 더 높은 처리 속도를 지원하는 새로운 레벨(레벨 5.2)과 이전에 지정된 High 프로파일의 프레임 코딩 도구만 지원하는 새로운 프로파일(Progressive High 프로파일)을 규정하는 수정안.[21]
  • 버전 15 (에디션 6): (2011년 6월 29일) 사소한 수정 사항을 포함하는 정오표.[21]
  • 버전 16 (에디션 7): (2012년 1월 13일) 주로 실시간 통신 응용 분야를 대상으로 하는 세 가지 새로운 프로파일(Constrained High, Scalable Constrained Baseline, Scalable Constrained High 프로파일)의 정의를 포함하는 수정안.[22]
  • 버전 17 (에디션 8): (2013년 4월 13일) 추가 SEI 메시지 표시기가 포함된 수정안.[23]
  • 버전 18 (에디션 8): (2013년 4월 13일) Multiview Depth High 프로파일을 포함하여 3D 입체 비디오를 위한 깊이 지도 데이터 코딩을 규정하는 수정안.[23]
  • 버전 19 (에디션 8): (2013년 4월 13일) 다시점 비디오의 하위 비트스트림 추출 프로세스 오류를 수정하기 위한 정오표.[23]
  • 버전 20 (에디션 8): (2013년 4월 13일) 추가적인 색 공간 식별자(UHDTV를 위한 ITU-R 권고 BT.2020 지원 포함)와 톤 매핑 정보 SEI 메시지의 추가 모델 유형을 규정하는 수정안.[23]
  • 버전 21 (에디션 9): (2014년 2월 13일) Enhanced Multiview Depth High 프로파일을 규정하는 수정안.[24]
  • 버전 22 (에디션 9): (2014년 2월 13일) 3D 입체 비디오를 위한 다해상도 프레임 호환(MFC) 향상, MFC High 프로파일 및 사소한 수정을 규정하는 수정안.[24]
  • 버전 23 (에디션 10): (2016년 2월 13일) 깊이 지도를 포함하는 MFC 입체 비디오, MFC Depth High 프로파일, 마스터링 디스플레이 컬러 볼륨 SEI 메시지 및 추가적인 색상 관련 VUI 코드포인트 식별자를 규정하는 수정안.[25]
  • 버전 24 (에디션 11): (2016년 10월 14일) 더 큰 사진 크기를 지원하는 추가적인 디코더 능력 레벨(레벨 6, 6.1, 6.2), 그린 메타데이터 SEI 메시지, 대체 깊이 정보 SEI 메시지 및 추가적인 색상 관련 VUI 코드포인트 식별자를 규정하는 수정안.[26]
  • 버전 25 (에디션 12): (2017년 4월 13일) Progressive High 10 프로파일, 하이브리드 로그 감마(HLG), 추가적인 색상 관련 VUI 코드포인트 및 SEI 메시지를 규정하는 수정안.[27]
  • 버전 26 (에디션 13): (2019년 6월 13일) 주변 시청 환경, 콘텐츠 광도 정보, 콘텐츠 색 부피, 정거도법 투영, 큐브맵 투영, 구체 회전, 영역별 패킹, 전방위 뷰포트, SEI 매니페스트 및 SEI 접두사에 대한 추가 SEI 메시지를 규정하는 수정안.[28]
  • 버전 27 (에디션 14): (2021년 8월 22일) 주석 영역 및 셔터 간격 정보에 대한 추가 SEI 메시지와 기타 사소한 수정 및 명확화를 규정하는 수정안.[29]
  • 버전 28 (에디션 15): (2024년 8월 13일) 신경망 사후 필터 특성, 신경망 사후 필터 활성화 및 위상 표시를 위한 추가 SEI 메시지, 추가 색상 유형 식별자 및 기타 사소한 수정 및 명확화를 규정하는 수정안.[30]

응용 분야

[편집]

H.264 비디오 형식은 저비트레이트 인터넷 스트리밍 응용 분야부터 HDTV 방송 및 거의 비손실 코딩이 적용되는 디지털 시네마 응용 분야에 이르기까지 모든 형태의 디지털 압축 비디오를 아우르는 매우 넓은 응용 범위를 가지고 있다. H.264를 사용하면 MPEG-2 Part 2에 비해 50% 이상의 비트레이트 절감이 가능한 것으로 보고된다. 예를 들어, H.264는 현재 MPEG-2 구현이 약 3.5 Mbit/s에서 작동하는 것과 동일한 디지털 위성 TV 품질을 절반 이하인 단 1.5 Mbit/s의 비트레이트로 제공하는 것으로 보고되었다.[31] 소니는 9 Mbit/s AVC 녹화 모드가 약 18–25 Mbit/s를 사용하는 HDV 형식의 이미지 품질과 동등하다고 주장한다.[32]

H.264/AVC의 호환성과 원활한 채택을 보장하기 위해 많은 표준화 기구에서 비디오 관련 표준을 수정하거나 추가하여 사용자가 H.264/AVC를 사용할 수 있도록 했다. 블루레이 디스크 형식과 현재 중단된 HD DVD 형식 모두 H.264/AVC High 프로파일을 세 가지 필수 영상 압축 형식 중 하나로 포함하고 있다. 디지털 비디오 방송 프로젝트(DVB)는 2004년 말에 방송 TV용으로 H.264/AVC 사용을 승인했다.

미국의 Advanced Television Systems Committee(ATSC) 표준화 기구는 2008년 7월에 방송 TV용 H.264/AVC 사용을 승인했으나, 아직 미국 내 고정 ATSC 방송에는 사용되지 않고 있다.[33][34] 또한 H.264의 AVC 및 SVC 부분을 사용하여 최신 ATSC-M/H(모바일/핸드헬드) 표준과 함께 사용하도록 승인되었다.[35]

폐쇄회로 TV 및 비디오 감시 시장은 많은 제품에 이 기술을 포함시켰다.

많은 일반적인 DSLR은 기본 녹화 형식으로 QuickTime MOV 컨테이너에 담긴 H.264 비디오를 사용한다.

파생 형식

[편집]

AVCHD는 소니와 파나소닉이 설계한 고화질 녹화 형식으로, H.264를 사용한다(H.264를 준수하면서 추가적인 응용 분야별 기능과 제약 사항을 추가함).

AVC-Intra는 파나소닉이 개발한 인트라 프레임 전용 압축 형식이다.

XAVC는 소니가 설계한 녹화 형식으로, 해당 비디오 표준에서 지원하는 가장 높은 레벨인 H.264/MPEG-4 AVC의 레벨 5.2를 사용한다.[36][37] XAVC는 최대 60 fps로 4K 해상도(4096 × 2160 및 3840 × 2160)를 지원할 수 있다.[36][37] 소니는 XAVC를 지원하는 카메라에 소니 PMW-F55 및 소니 PMW-F5라는 두 가지 CineAlta 카메라가 포함된다고 발표했다.[38] 소니 PMW-F55는 300 Mbit/s에서 30 fps의 4K 해상도 XAVC와 100 Mbit/s에서 30 fps의 2K 해상도를 기록할 수 있다.[39] XAVC는 600 Mbit/s에서 4:2:2 크로마 샘플링으로 60 fps의 4K 해상도를 기록할 수 있다.[40][41]

설계

[편집]

기능

[편집]
H.264의 블록도

H.264/AVC/MPEG-4 Part 10은 이전 표준보다 훨씬 더 효율적으로 비디오를 압축하고 다양한 네트워크 환경에 적용할 수 있는 유연성을 제공하는 여러 가지 새로운 기능을 포함하고 있다. 특히 주요 기능은 다음과 같다:

  • 다음과 같은 기능을 포함한 다중 사진 사진 간 예측:
    • 과거 표준보다 훨씬 유연한 방식으로 이전에 인코딩된 사진을 참조로 사용하며, 경우에 따라 최대 16개의 참조 프레임(인터레이스 인코딩의 경우 32개의 참조 필드)을 사용할 수 있도록 허용한다. 비IDR 프레임을 지원하는 프로파일에서 대부분의 레벨은 최대 해상도에서 최소 4~5개의 참조 프레임을 허용할 수 있는 충분한 버퍼링이 가능해야 한다고 규정하고 있다. 이는 제한이 일반적으로 1개이거나, 전통적인 "B 사진"(B-프레임)의 경우 2개였던 이전 표준들과 대조된다.
    • 16×16만큼 크고 4×4만큼 작은 블록 크기를 가진 가변 블록 크기 움직임 보상(VBSMC)을 통해 움직이는 영역의 정밀한 분할이 가능하다. 지원되는 루마 예측 블록 크기에는 16×16, 16×8, 8×16, 8×8, 8×4, 4×8, 4×4가 포함되며, 이 중 상당수가 하나의 매크로블록 내에서 함께 사용될 수 있다. 크로마 예측 블록 크기는 크로마 서브샘플링을 사용할 때 그에 따라 더 작아진다.
    • 16개의 4×4 분할로 구성된 B 매크로블록의 경우 최대 32개까지, 매크로블록당 여러 개의 움직임 벡터(분할당 1~2개)를 사용할 수 있는 기능. 각 8×8 이상의 분할 영역에 대한 움직임 벡터는 서로 다른 참조 사진을 가리킬 수 있다.
    • B-프레임에서 I-매크로블록을 포함한 모든 매크로블록 유형을 사용할 수 있는 기능으로, B-프레임 사용 시 훨씬 더 효율적인 인코딩이 가능하다. 이 기능은 MPEG-4 ASP에서 눈에 띄게 제외되었던 부분이다.
    • 더 날카로운 서브픽셀 움직임 보상을 위해, 반픽셀 루마 샘플 예측을 유도하기 위한 6-탭 필터링. 1/4 픽셀 움직임은 처리 전력을 아끼기 위해 반픽셀 값의 선형 보간을 통해 유도된다.
    • 움직이는 영역의 변위를 정밀하게 묘사할 수 있는 1/4 픽셀 정밀도 움직임 보상. 크로마의 경우 해상도가 일반적으로 수직 및 수평 모두 절반으로 줄어들므로(4:2:0), 크로마의 움직임 보상은 1/8 크로마 픽셀 그리드 단위를 사용한다.
    • 인코더가 움직임 보상을 수행할 때 스케일링 및 오프셋 사용을 지정할 수 있는 가중치 예측 기능으로, 페이드-투-블랙, 페이드-인, 크로스-페이드 전환과 같은 특수한 경우에 성능면에서 상당한 이점을 제공한다. 여기에는 B-프레임에 대한 암시적 가중치 예측과 P-프레임에 대한 명시적 가중치 예측이 포함된다.
    • MPEG-2 파트 2에서 발견되는 "DC" 전용 예측이나 H.263v2 및 MPEG-4 파트 2의 변환 계수 예측 대신, "인트라" 코딩을 위한 인접 블록 가장자리로부터의 공간적 예측. 여기에는 16×16, 8×8, 4×4의 루마 예측 블록 크기가 포함된다(각 매크로블록 내에서는 한 가지 유형만 사용 가능).
  • 정수 이산 코사인 변환(정수 DCT),[5][42][43] 즉 변환이 표준 DCT의 정수 근사치인 일종의 이산 코사인 변환(DCT).[42] 복잡성을 줄이기 위해 선택 가능한 블록 크기[6]와 정확히 일치하는 정수 계산을 사용하며 다음과 같은 사항을 포함한다:
    • 정확히 일치하는 정수 4×4 공간 블록 변환을 통해, 이전 코덱 설계에서 흔히 발견되던 "링잉 현상"이 거의 없이 잔차 신호를 정밀하게 배치할 수 있다. 이전 표준에서 사용된 표준 DCT와 유사하지만, 더 작은 블록 크기와 간단한 정수 처리를 사용한다. 이전 표준(H.261 및 MPEG-2 등)에서 표현된 코사인 기반 공식 및 허용 오차와 달리 정수 처리는 정확히 지정된 디코딩 결과를 제공한다.
    • 정확히 일치하는 정수 8×8 공간 블록 변환을 통해, 상관관계가 높은 영역을 4×4 변환보다 더 효율적으로 압축할 수 있다. 이 설계는 표준 DCT를 기반으로 하지만 단순화되어 정확히 지정된 디코딩을 제공하도록 만들어졌다.
    • 정수 변환 연산을 위해 4×4 및 8×8 변환 블록 크기 간의 적응형 인코더 선택.
    • 매끄러운 영역에서 더 많은 압축을 얻기 위해 크로마 DC 계수(특수한 경우 루마 포함)에 적용되는 1차 공간 변환의 "DC" 계수에 수행되는 2차 아다마르 변환.
  • 다음을 포함한 비손실 매크로블록 코딩 기능:
    • 비디오 데이터 샘플을 직접 나타내는 비손실 "PCM 매크로블록" 표현 모드,[44] 특정 영역의 완벽한 표현을 허용하고 각 매크로블록에 대한 코딩된 데이터 양에 엄격한 제한을 둘 수 있게 한다.
    • 일반적으로 PCM 모드보다 실질적으로 적은 비트를 사용하면서 특정 영역의 완벽한 표현을 허용하는 향상된 비손실 매크로블록 표현 모드.
  • 다음을 포함한 유연한 인터레이스 스캔 비디오 코딩 기능:
    • 프레임으로 코딩된 사진에 매크로블록 쌍 구조를 사용하는 매크로블록 적응형 프레임-필드(MBAFF) 코딩으로, 필드 모드에서 16×16 매크로블록을 허용한다(프레임으로 코딩된 사진에서의 필드 모드 처리가 16×8 반 매크로블록 처리를 초래하는 MPEG-2와 대조됨).
    • 인코딩을 위해 두 필드가 결합된 완전한 프레임이나 개별 단일 필드 중 자유롭게 선택된 사진 혼합을 허용하는 사진 적응형 프레임-필드 코딩(PAFF 또는 PicAFF).
  • 다음을 포함한 양자화 설계:
    • 인코더에 의한 더 쉬운 비트레이트 관리와 단순화된 역양자화 스케일링을 위한 로그 단계 크기 제어.
    • 지각 기반 양자화 최적화를 위해 인코더가 선택한 주파수 맞춤형 양자화 스케일링 행렬.
  • 다른 DCT 기반 이미지 압축 기구에서 흔히 발생하는 블록 아티팩트를 방지하는 데 도움을 주어 시각적 외관과 압축 효율을 향상시키는 인-루프 디블로킹 필터.
  • 다음을 포함한 엔트로피 부호화 설계:
    • CABAC(Context-adaptive binary arithmetic coding), 주어진 문맥에서 구문 요소의 확률을 파악하여 비디오 스트림의 구문 요소를 비손실로 압축하는 알고리즘. CABAC은 CAVLC보다 데이터를 더 효율적으로 압축하지만 디코딩에 훨씬 더 많은 처리가 필요하다.
    • 양자화된 변환 계수 값의 코딩을 위한 CABAC의 저복잡도 대안인 CAVLC(Context-adaptive variable-length coding). CABAC보다 복잡도는 낮지만, CAVLC는 다른 이전 설계에서 계수를 코딩하는 데 일반적으로 사용되는 방법보다 더 정교하고 효율적이다.
    • CABAC 또는 CAVLC에 의해 코딩되지 않는 많은 구문 요소에 사용되는 공통적이고 단순하며 고도로 구조화된 가변 길이 부호화(VLC) 기술로, 지수 골롬 부호화(Exp-Golomb)라고 한다.
  • 다음을 포함한 손실 복원력 기능:
    • 동일한 비디오 구문이 많은 네트워크 환경에서 사용될 수 있도록 하는 Network Abstraction Layer(NAL) 정의. H.264의 매우 근본적인 설계 개념 중 하나는 자립형 패킷을 생성하여 MPEG-4의 헤더 확장 코드(HEC)와 같은 헤더 중복을 제거하는 것이다.[45] 이는 미디어 스트림에서 둘 이상의 슬라이스와 관련된 정보를 분리함으로써 달성되었다. 상위 레벨 매개변수의 조합을 매개변수 세트라고 한다.[45] H.264 사양에는 시퀀스 매개변수 세트(SPS)와 사진 매개변수 세트(PPS)의 두 가지 유형의 매개변수 세트가 포함된다. 활성 시퀀스 매개변수 세트는 코딩된 비디오 시퀀스 전반에 걸쳐 변경되지 않고 유지되며, 활성 사진 매개변수 세트는 코딩된 사진 내에서 변경되지 않고 유지된다. 시퀀스 및 사진 매개변수 세트 구조에는 사진 크기, 채택된 선택적 코딩 모드 및 매크로블록-슬라이스 그룹 맵과 같은 정보가 포함된다.[45]
    • 임의 슬라이스 정렬(ASO) 및 슬라이스 그룹으로도 알려진 유연한 매크로블록 순서(FMO)는 사진의 근본 영역(매크로블록) 표현 순서를 재구성하는 기술이다. 일반적으로 오류/손실 견고성 기능으로 간주되지만, FMO 및 ASO는 다른 목적으로도 사용될 수 있다.
    • 데이터 파티셔닝(DP), 더 중요한 구문 요소와 덜 중요한 구문 요소를 서로 다른 데이터 패킷으로 분리하는 기능을 제공하여 차등 오류 보호(UEP)의 적용 및 기타 유형의 오류/손실 견고성 향상을 가능하게 한다.
    • 중복 슬라이스(RS), 기본 표현이 손상되거나 손실된 경우 사용할 수 있도록 인코더가 사진 영역의 추가 표현(일반적으로 더 낮은 충실도)을 보낼 수 있게 하는 오류/손실 견고성 기능.
    • 프레임 번호 매기기, 다른 사진들 사이에 선택적으로 추가 사진을 포함시켜 시간적 가변성을 가능하게 하고, 네트워크 패킷 손실이나 채널 오류로 인해 발생할 수 있는 전체 사진 손실의 탐지 및 은닉을 가능하게 하는 기능.
    • SP 및 SI 슬라이스라고 불리는 스위칭 슬라이스, 비디오 스트림 비트레이트 전환 및 "트릭 모드" 작동과 같은 목적으로 인코더가 디코더에 진행 중인 비디오 스트림으로 뛰어들도록 지시할 수 있게 한다. 디코더가 SP/SI 기능을 사용하여 비디오 스트림 중간으로 뛰어들 때, 스위치 이전의 참조로 다른 사진을 사용하거나 사진을 전혀 사용하지 않았음에도 불구하고 비디오 스트림의 해당 위치에서 디코딩된 사진과 정확히 일치하는 결과를 얻을 수 있다.
    • 비트스트림으로의 랜덤 액세스와 바이트 동기를 잃을 수 있는 시스템에서의 바이트 정렬 복구를 허용하는 코딩된 데이터의 특수 비트 시퀀스인 시작 코드가 우발적으로 에뮬레이션되는 것을 방지하기 위한 간단한 자동 프로세스.
    • 부가적인 향상 정보(SEI) 및 비디오 사용성 정보(VUI)는 비디오 콘텐츠에 사용된 색 공간 또는 인코딩에 적용되는 다양한 제약 조건을 나타내는 것과 같은 다양한 목적으로 비트스트림에 삽입될 수 있는 추가 정보이다. SEI 메시지는 임의의 사용자 정의 메타데이터 페이로드 또는 표준에 정의된 구문 및 의미를 가진 다른 메시지를 포함할 수 있다.
    • 알파 합성과 같은 목적으로 사용될 수 있는 보조 사진.
    • 단색(4:0:0), 4:2:0, 4:2:2, 4:4:4 크로마 샘플링 지원(선택된 프로파일에 따라 다름).
    • 샘플당 8비트에서 14비트 범위의 샘플 비트 깊이 정밀도 지원(선택된 프로파일에 따라 다름).
    • 개별 색상 평면을 자체 슬라이스 구조, 매크로블록 모드, 움직임 벡터 등을 가진 별개의 사진으로 인코딩할 수 있는 기능으로, 인코더가 단순한 병렬화 구조로 설계될 수 있게 한다(4:4:4 지원 3개 프로파일에서만 지원).
    • 사진 순서 카운트(Picture order count), 사진의 순서와 디코딩된 사진의 샘플 값을 타이밍 정보로부터 분리하여 유지하는 기능으로, 디코딩된 사진 콘텐츠에 영향을 주지 않고 시스템에서 타이밍 정보를 별도로 운반하고 제어/변경할 수 있게 한다.

이러한 기술들은 다른 여러 기술과 함께 H.264가 광범위한 응용 환경의 다양한 상황에서 이전의 어떤 표준보다 훨씬 더 우수한 성능을 발휘하도록 돕는다. H.264는 종종 MPEG-2 비디오보다 훨씬 나은 성능을 보여주며, 특히 고비트레이트 및 고해상도 비디오 콘텐츠에서 일반적으로 절반 이하의 비트레이트로 동일한 품질을 얻을 수 있다.[46]

다른 ISO/IEC MPEG 비디오 표준과 마찬가지로, H.264/AVC는 무료로 다운로드할 수 있는 참조 소프트웨어 구현을 가지고 있다.[47] 이것의 주요 목적은 그 자체로 유용한 응용 프로그램이 되기보다는 H.264/AVC 기능의 예를 제공하는 것이다. 일부 하드웨어 참조 설계 작업도 Moving Picture Experts Group에서 진행되었다. 위에 언급된 측면들은 H.264의 모든 프로파일에 있는 기능들을 포함한다. 코덱에 대한 프로파일은 의도된 응용 분야의 특정 사양 세트를 충족하기 위해 식별된 해당 코덱의 기능 세트이다. 이는 나열된 많은 기능이 일부 프로파일에서는 지원되지 않음을 의미한다. H.264/AVC의 다양한 프로파일은 다음 섹션에서 설명한다.

프로파일

[편집]

표준은 특정 응용 분야 계층을 대상으로 하는 프로파일이라 불리는 여러 가지 기능 세트를 정의한다. 이들은 프로파일 코드(profile_idc)와 때때로 인코더에 적용되는 추가 제약 조건 세트를 사용하여 선언된다. 프로파일 코드와 표시된 제약 조건은 디코더가 해당 특정 비트스트림을 디코딩하기 위한 요구 사항을 인식할 수 있게 한다. (그리고 많은 시스템 환경에서는 하나 또는 두 개의 프로파일만 사용이 허용되므로 해당 환경의 디코더는 덜 일반적으로 사용되는 프로파일을 인식하는 것에 신경 쓸 필요가 없다.) 지금까지 가장 흔히 사용되는 프로파일은 High 프로파일이다.

가변적이지 않은 2D 비디오 응용 분야를 위한 프로파일은 다음과 같다:

Constrained Baseline 프로파일 (CBP, 66 및 제약 조건 세트 1)
주로 저비용 응용 분야를 위한 것으로, 화상 회의 및 모바일 응용 분야에서 가장 일반적으로 사용된다. Baseline, Main, High 프로파일 간에 공통적으로 존재하는 기능들의 하위 집합에 해당한다.
Baseline 프로파일 (BP, 66)
주로 추가적인 데이터 손실 견고성이 필요한 저비용 응용 분야를 위한 것이며, 일부 화상 회의 및 모바일 응용 분야에서 사용된다. 이 프로파일은 Constrained Baseline 프로파일에서 지원되는 모든 기능과 손실 견고성을 위해(또는 저지연 다지점 비디오 스트림 합성 등 다른 목적으로) 사용될 수 있는 세 가지 추가 기능을 포함한다. 이 프로파일의 중요성은 2009년 Constrained Baseline 프로파일이 정의된 이후 다소 줄어들었다. 모든 Constrained Baseline 프로파일 비트스트림은 동일한 프로파일 식별자 코드 값을 공유하므로 Baseline 프로파일 비트스트림으로도 간주된다.
Extended 프로파일 (XP, 88)
스트리밍 비디오 프로파일로 의도된 것으로, 상대적으로 높은 압축 능력과 데이터 손실 및 서버 스트림 스위칭에 대한 견고성을 위한 몇 가지 추가 기술을 갖추고 있다.
Main 프로파일 (MP, 77)
이 프로파일은 DVB 표준에 정의된 대로 MPEG-4 형식을 사용하는 표준 정의 디지털 TV 방송에 사용된다.[48] 그러나 2004년 해당 응용 분야를 위해 High 프로파일이 개발되면서 이 프로파일의 중요성이 희박해져 고화질 텔레비전 방송에는 사용되지 않는다.
High 프로파일 (HiP, 100)
특히 고화질 텔레비전 응용 분야를 위한 방송 및 디스크 저장 응용 분야의 기본 프로파일이다(예를 들어, 이는 블루레이 디스크 저장 형식과 DVB HDTV 방송 서비스에서 채택한 프로파일이다).
Progressive High 프로파일 (PHiP, 100 및 제약 조건 세트 4)
High 프로파일과 유사하지만 필드 코딩 기능을 지원하지 않는다.
Constrained High 프로파일 (100 및 제약 조건 세트 4와 5)
Progressive High 프로파일과 유사하지만 B(양방향 예측) 슬라이스를 지원하지 않는다.
High 10 프로파일 (Hi10P, 110)
일반적인 주류 소비자 제품 능력을 넘어서는 이 프로파일은 High 프로파일 위에 구축되어 디코딩된 사진 정밀도를 샘플당 최대 10비트까지 지원한다.
High 4|2|2 프로파일 (Hi422P, 122)
주로 인터레이스 비디오를 사용하는 전문가용 응용 분야를 대상으로 하며, High 10 프로파일 위에 구축되어 샘플당 최대 10비트의 디코딩된 사진 정밀도를 사용하면서 4:2:2 크로마 샘플링 형식을 추가로 지원한다.
High 4|4|4 Predictive 프로파일 (Hi444PP, 244)
이 프로파일은 High 4:2:2 프로파일 위에 구축되어 최대 4:4:4 크로마 샘플링, 샘플당 최대 14비트를 지원하며, 추가적으로 효율적인 비손실 영역 코딩과 각 사진을 세 개의 별도 색상 평면으로 코딩하는 기능을 지원한다.

캠코더, 편집 및 전문가용 응용 분야를 위해, 표준은 다른 해당 프로파일의 단순한 하위 집합으로 정의된 4개의 추가 인트라 프레임 전용 프로파일을 포함한다. 이들은 주로 전문가용(예: 카메라 및 편집 시스템) 응용 분야를 위한 것이다:

High 10 Intra 프로파일 (110 및 제약 조건 세트 3)
모든 인트라 사용으로 제한된 High 10 프로파일.
High 4|2|2 Intra 프로파일 (122 및 제약 조건 세트 3)
모든 인트라 사용으로 제한된 High 4:2:2 프로파일.
High 4|4|4 Intra 프로파일 (244 및 제약 조건 세트 3)
모든 인트라 사용으로 제한된 High 4:4:4 프로파일.
CAVLC 4|4|4 Intra 프로파일 (44)
모든 인트라 사용 및 CAVLC 엔트로피 코딩으로 제한된 High 4:4:4 프로파일(즉, CABAC을 지원하지 않음).

계층적 비디오 부호화(SVC) 확장의 결과로, 표준은 기본 계층을 위한 H.264/AVC 프로파일(가변 프로파일 이름의 두 번째 단어로 식별됨)과 가변 확장을 달성하는 도구의 조합으로 정의된 5개의 추가 가변 프로파일을 포함한다:

Scalable Baseline 프로파일 (83)
주로 화상 회의, 모바일 및 감시 응용 분야를 대상으로 하며, 기본 계층(비트스트림의 하위 집합)이 준수해야 하는 Constrained Baseline 프로파일 위에 구축된다. 가변성 도구의 경우 사용 가능한 도구의 하위 집합이 활성화된다.
Scalable Constrained Baseline 프로파일 (83 및 제약 조건 세트 5)
주로 실시간 통신 응용 분야를 위한 Scalable Baseline 프로파일의 하위 집합.
Scalable High 프로파일 (86)
주로 방송 및 스트리밍 응용 분야를 대상으로 하며, 기본 계층이 준수해야 하는 H.264/AVC High 프로파일 위에 구축된다.
Scalable Constrained High 프로파일 (86 및 제약 조건 세트 5)
주로 실시간 통신 응용 분야를 위한 Scalable High 프로파일의 하위 집합.
Scalable High Intra 프로파일 (86 및 제약 조건 세트 3)
주로 프로덕션 응용 분야를 대상으로 하며, 모든 인트라 사용으로 제한된 Scalable High 프로파일이다.

다시점 비디오 부호화(MVC) 확장의 결과로, 표준은 두 가지 다시점 프로파일을 포함한다:

Stereo High 프로파일 (128)
이 프로파일은 2-시점 입체 3D 비디오를 대상으로 하며 High 프로파일의 도구와 MVC 확장의 시점 간 예측 기능을 결합한다.
Multiview High 프로파일 (118)
이 프로파일은 사진 간(시간적) 예측과 MVC 시점 간 예측을 모두 사용하여 둘 이상의 시점을 지원하지만, 필드 사진 및 매크로블록 적응형 프레임-필드 코딩은 지원하지 않는다.

다해상도 프레임 호환(MFC) 확장은 두 가지 프로파일을 추가했다:

MFC High 프로파일 (134)
2계층 해상도 향상을 통한 입체 코딩용 프로파일.
MFC Depth High 프로파일 (135)

3D-AVC 확장은 두 가지 프로파일을 추가했다:

Multiview Depth High 프로파일 (138)
이 프로파일은 3D 비디오 콘텐츠의 압축을 개선하기 위해 깊이 지도와 비디오 텍스처 정보의 공동 코딩을 지원한다.
Enhanced Multiview Depth High 프로파일 (139)
깊이 정보와 결합된 다시점 코딩을 위한 향상된 프로파일.

특정 프로파일의 기능 지원

[편집]
기능 CBP BP XP MP ProHiP HiP Hi10P Hi422P Hi444PP
비트 깊이 (샘플당) 8888888~108~108~14
크로마 형식 4:2:0

 		4:2:0

 		4:2:0

 		4:2:0

 		4:2:0

 		4:2:0

 		4:2:0

 		4:2:0/
4:2:2
 		4:2:0/
4:2:2/
4:4:4
유연한 매크로블록 순서 (FMO) 아니요예예아니요아니요아니요아니요아니요아니요
임의 슬라이스 정렬 (ASO) 아니요예예아니요아니요아니요아니요아니요아니요
중복 슬라이스 (RS) 아니요예예아니요아니요아니요아니요아니요아니요
데이터 파티셔닝 아니요아니요예아니요아니요아니요아니요아니요아니요
SI 및 SP 슬라이스 아니요아니요예아니요아니요아니요아니요아니요아니요
인터레이스 코딩 (PicAFF, MBAFF) 아니요아니요예예아니요예예예예
B 슬라이스 아니요아니요예예예예예예예
CABAC 엔트로피 부호화 아니요아니요아니요예예예예예예
8×8 vs. 4×4 변환 적응성 아니요아니요아니요아니요예예예예예
양자화 스케일링 행렬 아니요아니요아니요아니요예예예예예
별도의 CB 및 CR QP 제어 아니요아니요아니요아니요예예예예예
별도 색상 평면 코딩 아니요아니요아니요아니요아니요아니요아니요아니요예
예측 비손실 코딩 아니요아니요아니요아니요아니요아니요아니요아니요예

레벨

[편집]

표준에서 사용되는 "레벨"은 프로파일에 대해 요구되는 디코더 성능의 정도를 나타내는 지정된 제약 조건 세트이다. 예를 들어, 프로파일 내의 지원 레벨은 디코더가 사용할 수 있는 최대 사진 해상도, 프레임 레이트 및 비트레이트를 규정한다. 특정 레벨을 준수하는 디코더는 해당 레벨 및 모든 하위 레벨에 대해 인코딩된 모든 비트스트림을 디코딩할 수 있어야 한다.

최대 속성값이 포함된 레벨[27]
레벨
 최대
디코딩 속도
(매크로블록/s)		 최대
프레임 크기
(매크로블록)		 비디오 코딩 계층(VCL)을 위한
최대 비디오 비트레이트
(Constrained Baseline,
Baseline, Extended
및 Main 프로파일)
(kbits/s)		 최고 프레임 레이트에서의
고해상도 사례
(최대 저장 프레임)
추가 세부 정보 토글
1 1,485 99 64
128×96@30.9 (8)
176×144@15.0 (4)
1b 1,485 99 128
128×96@30.9 (8)
176×144@15.0 (4)
1.1 3,000 396 192
176×144@30.3 (9)
320×240@10.0 (3)
352×288@7.5 (2)
1.2 6,000 396 384
320×240@20.0 (7)
352×288@15.2 (6)
1.3 11,880 396 768
320×240@36.0 (7)
352×288@30.0 (6)
2 11,880 396 2,000
320×240@36.0 (7)
352×288@30.0 (6)
2.1 19,800 792 4,000
352×480@30.0 (7)
352×576@25.0 (6)
2.2 20,250 1,620 4,000
352×480@30.7 (12)
352×576@25.6 (10)
720×480@15.0 (6)
720×576@12.5 (5)
3 40,500 1,620 10,000
352×480@61.4 (12)
352×576@51.1 (10)
720×480@30.0 (6)
720×576@25.0 (5)
3.1 108,000 3,600 14,000
720×480@80.0 (13)
720×576@66.7 (11)
1,280×720@30.0 (5)
3.2 216,000 5,120 20,000
1,280×720@60.0 (5)
1,280×1,024@42.2 (4)
4 245,760 8,192 20,000
1,280×720@68.3 (9)
1,920×1,080@30.1 (4)
2,048×1,024@30.0 (4)
4.1 245,760 8,192 50,000
1,280×720@68.3 (9)
1,920×1,080@30.1 (4)
2,048×1,024@30.0 (4)
4.2 522,240 8,704 50,000
1,280×720@145.1 (9)
1,920×1,080@64.0 (4)
2,048×1,080@60.0 (4)
5 589,824 22,080 135,000
1,920×1,080@72.3 (13)
2,048×1,024@72.0 (13)
2,048×1,080@67.8 (12)
2,560×1,920@30.7 (5)
3,672×1,536@26.7 (5)
5.1 983,040 36,864 240,000
1,920×1,080@120.5 (16)
2,560×1,920@51.2 (9)
3,840×2,160@31.7 (5)
4,096×2,048@30.0 (5)
4,096×2,160@28.5 (5)
4,096×2,304@26.7 (5)
5.2 2,073,600 36,864 240,000
1,920×1,080@172.0 (16)
2,560×1,920@108.0 (9)
3,840×2,160@66.8 (5)
4,096×2,048@63.3 (5)
4,096×2,160@60.0 (5)
4,096×2,304@56.3 (5)
6 4,177,920 139,264 240,000
3,840×2,160@128.9 (16)
7,680×4,320@32.2 (5)
8,192×4,320@30.2 (5)
6.1 8,355,840 139,264 480,000
3,840×2,160@257.9 (16)
7,680×4,320@64.5 (5)
8,192×4,320@60.4 (5)
6.2 16,711,680 139,264 800,000
3,840×2,160@300.0 (16)
7,680×4,320@128.9 (5)
8,192×4,320@120.9 (5)

High 프로파일의 최대 비트레이트는 Constrained Baseline, Baseline, Extended 및 Main 프로파일의 1.25배이며, Hi10P는 3배, Hi422P/Hi444PP는 4배이다.

루마 샘플 수는 매크로블록 수의 16×16=256배이다(초당 루마 샘플 수는 초당 매크로블록 수의 256배이다).

디코딩된 사진 버퍼링

[편집]

이전에 인코딩된 사진은 다른 사진의 샘플 값 예측을 제공하기 위해 H.264/AVC 인코더에 의해 사용된다. 이를 통해 인코더는 주어진 사진을 인코딩하는 최선의 방법에 대해 효율적인 결정을 내릴 수 있다. 디코더에서 이러한 사진은 가상 디코딩된 사진 버퍼(DPB)에 저장된다. 위 표의 오른쪽 열에 괄호로 표시된 프레임 단위(또는 필드 쌍)의 최대 DPB 용량은 다음과 같이 계산할 수 있다:

DpbCapacity = min(floor(MaxDpbMbs / (PicWidthInMbs * FrameHeightInMbs)), 16)

여기서 MaxDpbMbs는 아래 표에 레벨 번호의 함수로 제공되는 상수 값이며, PicWidthInMbs 및 FrameHeightInMbs는 매크로블록 단위로 표현된 코딩된 비디오 데이터의 사진 너비와 프레임 높이이다(정수 값으로 올림하고 해당되는 경우 크로핑 및 매크로블록 페어링을 고려함). 이 공식은 2017년판 표준의 섹션 A.3.1.h 및 A.3.2.f에 명시되어 있다.[27]

레벨 1 1b 1.1 1.2 1.3 2 2.1 2.2 3 3.1 3.2 4 4.1 4.2 5 5.1 5.2 6 6.1 6.2
MaxDpbMbs 396 396 900 2,376 2,376 2,376 4,752 8,100 8,100 18,000 20,480 32,768 32,768 34,816 110,400 184,320 184,320 696,320 696,320 696,320

예를 들어, 너비가 1,920 샘플(PicWidthInMbs = 120)이고 높이가 1,080 샘플(FrameHeightInMbs = 68)인 HDTV 사진의 경우, 레벨 4 디코더의 최대 DPB 저장 용량은 floor(32768/(120*68)) = 4 프레임(또는 8 필드)이다. 따라서 위 표의 레벨 4 행 오른쪽 열, 프레임 크기 1920×1080 옆에 괄호로 4가 표시되어 있다.

현재 디코딩 중인 사진은 DPB 충만도 계산에 포함되지 않는다(인코더가 다른 사진을 디코딩하기 위한 참조용으로 저장하거나 지연된 출력 타이밍을 위해 저장하도록 지시하지 않는 한). 따라서 디코더는 실제로 위에서 계산된 DPB의 최대 용량보다 최소 한 프레임 이상을 처리할 수 있는 충분한 메모리를 보유해야 한다.

구현

[편집]
AVC (H.264) 비디오 코덱과 Opus 오디오 형식을 사용하는 유튜브 비디오 통계 스크린샷

2009년, WHATWG HTML5 작업 그룹은 특허에 얽매이지 않는 것으로 여겨지는 자유 비디오 형식인 Ogg 테오라 지지자들과 특허 기술을 포함하는 H.264 지지자들로 나뉘었다. 2009년 7월 말까지 구글과 애플은 H.264를 지원하고, 모질라와 오페라는 Ogg 테오라를 지원한다고 알려졌다(현재 구글, 모질라, 오페라 모두 WebM과 함께 테오라 및 VP8을 지원함).[49] 마이크로소프트는 인터넷 익스플로러 9 출시와 함께 H.264를 사용하여 인코딩된 HTML 5 비디오 지원을 추가했다. 2010년 11월 가트너 심포지엄/ITXpo에서 마이크로소프트 CEO 스티브 발머는 "HTML 5인가 실버라이트인가?"라는 질문에 "보편적인 무언가를 하고 싶다면 세상이 HTML5로 가고 있다는 데 의문의 여지가 없다"라고 답했다.[50] 2011년 1월, 구글은 오픈 형식만 사용하기 위해 자사의 크롬 브라우저에서 H.264 지원을 철회하고 테오라와 WebM/VP8을 모두 지원할 것이라고 발표했다.[51]

2012년 3월 18일, 모질라는 H.264로 인코딩된 비디오의 보급과 해당 장치에서 흔히 사용되는 전용 H.264 디코더 하드웨어 사용 시의 전력 효율성 증대를 이유로 모바일 장치용 파이어폭스에서 H.264를 지원한다고 발표했다.[52] 2013년 2월 20일, 모질라는 윈도우 7 이상에서 H.264 디코딩을 위한 파이어폭스 지원을 구현했다. 이 기능은 윈도우에 내장된 디코딩 라이브러리에 의존한다.[53] 2015년 1월 13일에 출시된 파이어폭스 35.0은 OS X 10.6 이상에서 H.264를 지원한다.[54]

2013년 10월 30일, 시스코 시스템즈의 로완 트롤로프는 시스코가 OpenH264라 불리는 H.264 비디오 코덱의 바이너리와 소스 코드를 모두 단순화된 BSD 라이선스 하에 공개하고, 시스코의 사전 컴파일된 바이너리를 사용하는 모든 소프트웨어 프로젝트에 대해 MPEG LA에 모든 사용 로열티를 지불하여 시스코의 OpenH264 바이너리를 무료로 사용할 수 있게 하겠다고 발표했다. 그러나 바이너리 대신 시스코의 소스 코드를 사용하는 소프트웨어 프로젝트는 MPEG LA에 로열티를 지불할 법적 책임이 있다. 대상 CPU 아키텍처는 x86 및 ARM이며, 대상 운영 체제는 리눅스, 윈도우 XP 이상, 맥 OS X, 안드로이드를 포함한다. iOS는 응용 프로그램이 인터넷에서 바이너리 모듈을 가져와 설치하는 것을 허용하지 않기 때문에 이 목록에서 눈에 띄게 제외되었다.[55][56][57] 또한 2013년 10월 30일, 모질라의 브런던 아이크는 플랫폼 코덱을 사용할 수 없는 경우 파이어폭스에 H.264 지원을 추가하기 위해 향후 버전의 파이어폭스에서 시스코의 바이너리를 사용할 것이라고 썼다.[58] 시스코는 2013년 12월 9일에 OpenH264 소스 코드를 공개했다.[59]

2013년 시스코 소프트웨어 출시 당시 iOS는 지원되지 않았지만, 애플은 하드웨어 기반 H.264/AVC 비디오 인코딩 및 디코딩에 대한 직접 접근을 제공하기 위해 iOS 8(2014년 9월 출시)과 함께 비디오 툴박스 프레임워크를 업데이트했다.[56]

소프트웨어 인코더

[편집]
AVC 소프트웨어 구현
기능 QuickTime Nero OpenH264 X264 Main-
Concept		 Elecard  TSE  Pro-
Coder		 Avivo Elemental  IPP 
B 슬라이스 예예예예예예예예아니요예예
다중 참조 프레임 예예예예예예예예아니요예예
인터레이스 코딩 (PicAFF, MBAFF) 아니요MBAFFMBAFFMBAFF예예아니요예MBAFF예아니요
CABAC 엔트로피 부호화 예예예예예예예예아니요예예
8×8 vs. 4×4 변환 적응성 아니요예예예예예예예아니요예예
양자화 스케일링 행렬 아니요아니요예예예아니요아니요아니요아니요아니요아니요
별도의 CB 및 CR QP 제어 아니요아니요예예예예아니요아니요아니요아니요아니요
확장 크로마 형식 아니요아니요아니요4:0:0[60]
4:2:0
4:2:2[61]
4:4:4[62]  		4:2:24:2:24:2:2아니요아니요4:2:0
4:2:2		아니요
최대 샘플 깊이 (bit) 88810[63]1088881012
예측 비손실 코딩 아니요아니요아니요예[64]아니요아니요아니요아니요아니요아니요아니요

하드웨어

[편집]

H.264 인코딩 및 디코딩은 특정 산술 연산을 위해 상당한 계산 능력을 필요로 하기 때문에, 범용 CPU에서 실행되는 소프트웨어 구현은 일반적으로 전력 효율이 낮다. 그러나 2016년경 이후의 6코어 또는 8코어 소비자급 CPU와 2020년 1월 기준 쿼드코어 범용 x86 CPU는 실시간 SD 및 HD 인코딩을 수행하기에 충분한 계산 능력을 갖추고 있다. 압축 효율은 하드웨어 또는 소프트웨어 구현 사용 여부가 아니라 비디오 알고리즘 구현에 달려 있다. 따라서 하드웨어 기반 구현과 소프트웨어 기반 구현의 차이는 전력 효율성, 유연성 및 비용에 더 가깝다. 전력 효율성을 개선하고 하드웨어 폼 팩터를 줄이기 위해 전체 인코딩 또는 디코딩 프로세스나 CPU 제어 환경 내에서의 가속 지원을 위해 특수 목적 하드웨어가 사용될 수 있다.

CPU 기반 솔루션은 인코딩이 여러 형식, 여러 비트레이트 및 해상도(멀티 스크린 비디오)로 동시에 수행되어야 하거나 컨테이너 형식 지원, 고급 통합 광고 기능 등에 대한 추가 기능이 필요할 때 훨씬 더 유연한 것으로 알려져 있다. CPU 기반 소프트웨어 솔루션은 일반적으로 동일한 CPU 내에서 여러 개의 동시 인코딩 세션을 로드 밸런싱하는 것을 훨씬 쉽게 만든다.

2011년 CES(Consumer Electronics Show)에서 소개된 2세대 인텔 "샌디브리지" Core i3/i5/i7 프로세서는 인텔 퀵 싱크 비디오로 알려진 온칩 하드웨어 풀 HD H.264 인코더를 제공한다.[65][66]

하드웨어 H.264 인코더는 ASIC 또는 FPGA일 수 있다.

H.264 인코더 기능이 있는 ASIC 인코더는 많은 다양한 반도체 회사에서 구할 수 있지만, ASIC에 사용되는 핵심 설계는 일반적으로 칩스앤미디어, Allegro DVT, On2(전 Hantro, 구글에 인수됨), 이미지네이션 테크놀로지, NGCodec 등 소수의 회사로부터 라이선스를 받는다. 일부 회사는 FPGA와 ASIC 제품군을 모두 제공한다.[67]

텍사스 인스투르먼트는 30 fps에서 1080p DSP H.264 BP 인코딩을 수행하는 ARM + DSP 코어 라인을 제조한다.[68] 이는 일반 CPU의 소프트웨어보다 더 효율적이면서 코덱(고도로 최적화된 DSP 코드로 구현됨)에 대한 유연성을 허용한다.

라이선스

[편집]

소프트웨어 알고리즘에 대한 특허가 유지되는 국가에서는 H.264/AVC를 사용하는 제품의 공급업체와 상업적 사용자가 자사 제품이 사용하는 특허 기술에 대해 특허 라이선스 로열티를 지불할 것으로 기대된다.[69] 이는 Baseline 프로파일에도 적용된다.[70]

Via-LA로 알려진 민간 조직은 이 표준에 적용되는 특허 라이선스와 MPEG-4 Part 2 비디오, HEVC 및 MPEG-DASH와 같은 다른 특허 풀을 관리한다. 특허 보유자에는 후지쯔, 파나소닉, 소니, 미쓰비시, 애플, 컬럼비아 대학교, KAIST, 돌비, 구글, JVC 켄우드, LG전자, 마이크로소프트, NTT 도코모, 필립스, 삼성, 샤프, 도시바 및 ZTE가 포함된다.[71] 다만 풀 내 특허의 대다수는 파나소닉(1,197개), Godo Kaisha IP Bridge(1,130개) 및 LG전자(990개)가 보유하고 있다.[72]

2010년 8월 26일, MPEG-LA는 최종 사용자에게 무료인 H.264 인코딩 인터넷 비디오에 대해 로열티를 부과하지 않겠다고 발표했다.[73] H.264 비디오를 디코딩 및 인코딩하는 제품에 대한 로열티와 무료 텔레비전 및 유료 채널 운영자에 대한 로열티 등 다른 모든 로열티는 그대로 유지된다.[74] 라이선스 조건은 5년 단위로 업데이트된다.[75]

표준의 첫 번째 버전은 2003년 5월에 완료되었고 가장 널리 사용되는 프로파일(High 프로파일)은 2004년 6월에 완료되었으므로 관련 특허 중 일부는 현재 만료되었다.[72] 그러나 전 세계 여러 관할권에서는 다른 특허들이 여전히 유효하며, MPEG LA H.264 풀에 있는 미국 특허 중 하나(2016년 부여, 2001년 우선권)는 최소 2030년 11월까지 유효하다.[76]

2005년, 퀄컴은 미국 지방법원에 브로드컴이 H.264 영상 압축 표준을 준수하는 제품을 제작함으로써 자사의 특허 2건을 침해했다고 주장하며 소송을 제기했다.[77] 2007년 지방법원은 퀄컴이 2003년 5월 H.264 표준 발표 전 JVT에 해당 특허를 공개하지 않았기 때문에 특허를 집행할 수 없다고 판결했다.[77] 2008년 12월, 미국 연방 순회 항소법원은 특허를 집행할 수 없다는 지방법원의 명령을 확인했으나, 집행 불가능의 범위를 H.264 준수 제품으로 제한하라는 지침과 함께 지방법원으로 사건을 환송했다.[77]

2023년 10월, 노키아는 미국, 영국 및 기타 지역에서 H.264/H.265 특허 침해로 HP와 아마존을 고소했다.[78]

같이 보기

[편집]

각주

[편집]
  1. ↑ 《MPEG-4, Advanced Video Coding (Part 10) (H.264)》 (Full draft). Sustainability of Digital Formats. Washington, D.C.: Library of Congress. 2011년 12월 5일. 2021년 12월 1일에 확인함.
  2. ↑ “H.264 : Advanced video coding for generic audiovisual services”. 《www.itu.int》. 2019년 10월 31일에 원본 문서에서 보존된 문서. 2019년 11월 22일에 확인함.
  3. ↑ “Video Developer Report 2024/2025” (PDF). 《Bitmovin》. December 2024.
  4. ↑ “Delivering 8K using AVC/H.264” (미국 영어). 《Mystery Box》. 2021년 3월 25일에 원본 문서에서 보존된 문서. 2017년 8월 23일에 확인함.
  5. 1 2 Wang, Hanli; Kwong, S.; Kok, C. (2006). 《Efficient prediction algorithm of integer DCT coefficients for H.264/AVC optimization》. 《IEEE Transactions on Circuits and Systems for Video Technology》 16. 547–552쪽. Bibcode:2006ITCSV..16..547W. doi:10.1109/TCSVT.2006.871390. S2CID 2060937.
  6. 1 2 Thomson, Gavin; Shah, Athar (2017). “Introducing HEIF and HEVC” (PDF). Apple Inc. 2019년 8월 5일에 확인함.
  7. ↑ Ozer, Jan (2023년 5월 8일), 《Via LA's Heath Hoglund Talks MPEG LA/Via Licensing Patent Pool Merger》, StreamingMedia.com
  8. ↑ “ITU-T Recommendations” (미국 영어). 《ITU》. 2022년 11월 1일에 확인함.
  9. ↑ “H.262 : Information technology — Generic coding of moving pictures and associated audio information: Video”. 2007년 4월 15일에 확인함.
  10. ↑ Joint Video Team, ITU-T Web site.
  11. ↑ “ITU-T Recommendation H.264 (05/2003)”. ITU. 2003년 5월 30일. 2013년 4월 18일에 확인함.
  12. ↑ “ITU-T Recommendation H.264 (05/2003) Cor. 1 (05/2004)”. ITU. 2004년 5월 7일. 2013년 4월 18일에 확인함.
  13. ↑ “ITU-T Recommendation H.264 (03/2005)”. ITU. 2005년 3월 1일. 2013년 4월 18일에 확인함.
  14. ↑ “ITU-T Recommendation H.264 (2005) Cor. 1 (09/2005)”. ITU. 2005년 9월 13일. 2013년 4월 18일에 확인함.
  15. 1 2 “ITU-T Recommendation H.264 (2005) Amd. 1 (06/2006)”. ITU. 2006년 6월 13일. 2013년 4월 18일에 확인함.
  16. ↑ “ITU-T Recommendation H.264 (2005) Amd. 2 (04/2007)”. ITU. 2007년 4월 6일. 2013년 4월 18일에 확인함.
  17. ↑ “ITU-T Recommendation H.264 (11/2007)”. ITU. 2007년 11월 22일. 2013년 4월 18일에 확인함.
  18. ↑ “ITU-T Recommendation H.264 (2007) Cor. 1 (01/2009)”. ITU. 2009년 1월 13일. 2013년 4월 18일에 확인함.
  19. 1 2 “ITU-T Recommendation H.264 (03/2009)”. ITU. 2009년 3월 16일. 2013년 4월 18일에 확인함.
  20. 1 2 “ITU-T Recommendation H.264 (03/2010)”. ITU. 2010년 3월 9일. 2013년 4월 18일에 확인함.
  21. 1 2 “ITU-T Recommendation H.264 (06/2011)”. ITU. 2011년 6월 29일. 2013년 4월 18일에 확인함.
  22. ↑ “ITU-T Recommendation H.264 (01/2012)”. ITU. 2012년 1월 13일. 2013년 4월 18일에 확인함.
  23. 1 2 3 4 “ITU-T Recommendation H.264 (04/2013)”. ITU. 2013년 6월 12일. 2013년 6월 16일에 확인함.
  24. 1 2 “ITU-T Recommendation H.264 (02/2014)”. ITU. 2014년 11월 28일. 2016년 2월 28일에 확인함.
  25. ↑ “ITU-T Recommendation H.264 (02/2016)”. ITU. 2016년 2월 13일. 2017년 6월 14일에 확인함.
  26. ↑ “ITU-T Recommendation H.264 (10/2016)”. ITU. 2016년 10월 14일. 2017년 6월 14일에 확인함.
  27. 1 2 3 “ITU-T Recommendation H.264 (04/2017)”. ITU. 2017년 4월 13일. See Tables A-1, A-6 and A-7 for the tabulated level-dependent capabilities. 2017년 6월 14일에 확인함.
  28. ↑ “H.264: Advanced video coding for generic audiovisual services - Version 26 (Edition 13)”. 《www.itu.int》. 2019년 6월 13일. 2021년 11월 4일에 원본 문서에서 보존된 문서. 2021년 11월 3일에 확인함.
  29. ↑ “H.264: Advanced video coding for generic audiovisual services - Version 27 (Edition 14)”. 《www.itu.int》. 2021년 8월 22일. 2021년 11월 4일에 원본 문서에서 보존된 문서. 2021년 11월 3일에 확인함.
  30. ↑ “H.264: Advanced video coding for generic audiovisual services - Version 28 (Edition 15)”. 《www.itu.int》. 2024년 8월 13일. 2025년 2월 12일에 확인함.
  31. ↑ Wenger 외 (February 2005). 《RFC 3984 : RTP Payload Format for H.264 Video》. 《Ietf Datatracker》. 2쪽. doi:10.17487/RFC3984.
  32. ↑ “Which recording mode is equivalent to the image quality of the High Definition Video (HDV) format?”. 《Sony eSupport》. November 9, 2017에 원본 문서에서 보존된 문서. December 8, 2018에 확인함.
  33. ↑ “ATSC Standard A/72 Part 1: Video System Characteristics of AVC in the ATSC Digital Television System” (PDF). August 7, 2011에 원본 문서 (PDF)에서 보존된 문서. July 30, 2011에 확인함.
  34. ↑ “ATSC Standard A/72 Part 2: AVC Video Transport Subsystem Characteristics” (PDF). August 7, 2011에 원본 문서 (PDF)에서 보존된 문서. July 30, 2011에 확인함.
  35. ↑ “ATSC Standard A/153 Part 7: AVC and SVC Video System Characteristics” (PDF). July 26, 2011에 원본 문서 (PDF)에서 보존된 문서. July 30, 2011에 확인함.
  36. 1 2 “Sony introduces new XAVC recording format to accelerate 4K development in the professional and consumer markets”. Sony. 2012년 10월 30일. 2012년 11월 1일에 확인함.
  37. 1 2 “Sony introduces new XAVC recording format to accelerate 4K development in the professional and consumer markets” (PDF). Sony. 2012년 10월 30일. 2023년 3월 23일에 원본 문서 (PDF)에서 보존된 문서. 2012년 11월 1일에 확인함.
  38. ↑ Steve Dent (2012년 10월 30일). “Sony goes Red-hunting with PMW-F55 and PMW-F5 pro CineAlta 4K Super 35mm sensor camcorders”. Engadget. 2012년 11월 5일에 확인함.
  39. ↑ “F55 CineAlta 4K the future, ahead of schedule” (PDF). Sony. October 30, 2012. November 19, 2012에 원본 문서 (PDF)에서 보존된 문서. November 1, 2012에 확인함.
  40. ↑ “Ultra-fast "SxS PRO+" memory cards transform 4K video capture”. Sony. March 8, 2013에 원본 문서에서 보존된 문서. November 5, 2012에 확인함.
  41. ↑ “Ultra-fast "SxS PRO+" memory cards transform 4K video capture” (PDF). Sony. April 2, 2015에 원본 문서 (PDF)에서 보존된 문서. November 5, 2012에 확인함.
  42. 1 2 Stanković, Radomir S.; Astola, Jaakko T. (2012). 《Reminiscences of the Early Work in DCT: Interview with K.R. Rao》 (PDF). 《Reprints from the Early Days of Information Sciences》 60. 17쪽. 2019년 10월 13일에 확인함.
  43. ↑ Kwon, Soon-young; Lee, Joo-kyong; Chung, Ki-dong (2005). 〈Half-Pixel Correction for MPEG-2/H.264 Transcoding〉. 《Image Analysis and Processing – ICIAP 2005》. Lecture Notes in Computer Science 3617. Springer Berlin Heidelberg. 576–583쪽. doi:10.1007/11553595_71. ISBN 978-3-540-28869-5.
  44. ↑ “The H.264/AVC Advanced Video Coding Standard: Overview and Introduction to the Fidelity Range Extensions” (PDF). 2011년 7월 30일에 확인함.
  45. 1 2 3 RFC 3984, p.3
  46. ↑ Apple Inc. (1999년 3월 26일). “H.264 FAQ”. Apple. 2010년 3월 7일에 원본 문서에서 보존된 문서. 2010년 5월 17일에 확인함.
  47. ↑ Karsten Suehring. “H.264/AVC JM Reference Software Download”. Iphome.hhi.de. 2010년 5월 17일에 확인함.
  48. ↑ “TS 101 154 – V1.9.1 – Digital Video Broadcasting (DVB); Specification for the use of Video and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream” (PDF). 2010년 5월 17일에 확인함.
  49. ↑ “Decoding the HTML 5 video codec debate”. 《Ars Technica》. 2009년 7월 6일. 2011년 1월 12일에 확인함.
  50. ↑ “Steve Ballmer, CEO Microsoft, interviewed at Gartner Symposium/ITxpo Orlando 2010”. Gartnervideo. November 2010. 2021년 10월 30일에 원본 문서에서 보존된 문서. 2011년 1월 12일에 확인함.
  51. ↑ “HTML Video Codec Support in Chrome”. 2011년 1월 11일. 2011년 1월 12일에 확인함.
  52. ↑ “Video, Mobile, and the Open Web”. 2012년 3월 18일. 2012년 3월 20일에 확인함.
  53. ↑ by-default-metro-ui-for-windows-8-more-firefox-development-highlights/ “WebRTC enabled, H.264/MP3 support in Win 7 on by default, Metro UI for Windows 8 + more – Firefox Development Highlights” |url= 값 확인 필요 (도움말). 《hacks.mozilla.org》. mozilla. 2013년 2월 20일. 2013년 3월 15일에 확인함.
  54. ↑ “Firefox — Notes (35.0)”. 《Mozilla》.
  55. ↑ “Open-Sourced H.264 Removes Barriers to WebRTC”. 2013년 10월 30일. 2015년 7월 6일에 원본 문서에서 보존된 문서. 2013년 11월 1일에 확인함.
  56. 1 2 “Cisco OpenH264 project FAQ”. 2021년 9월 26일에 확인함.
  57. ↑ “OpenH264 Simplified BSD License”. 《GitHub》. 2013년 10월 27일. 2013년 11월 21일에 확인함.
  58. ↑ “Video Interoperability on the Web Gets a Boost From Cisco's H.264 Codec”. 2013년 10월 30일. 2013년 11월 1일에 확인함.
  59. ↑ “Updated README · cisco/openh264@59dae50”. 《GitHub》.
  60. ↑ "x264 4:0:0 (monochrome) encoding support", Retrieved 2019-06-05.
  61. ↑ "x264 4:2:2 encoding support", Retrieved 2019-06-05.
  62. ↑ "x264 4:4:4 encoding support", Retrieved 2019-06-05.
  63. ↑ "x264 support for 9 and 10-bit encoding", Retrieved 2011-06-22.
  64. ↑ "x264 replace High 4:4:4 profile lossless with High 4:4:4 Predictive", Retrieved 2011-06-22.
  65. ↑ “Quick Reference Guide to generation Intel Core Processor Built-in Visuals”. Intel Software Network. 2010년 10월 1일. 2011년 1월 19일에 확인함.
  66. ↑ “Intel Quick Sync Video”. www.intel.com. 2010년 10월 1일. 2011년 1월 19일에 확인함.
  67. ↑ “Design-reuse.com”. Design-reuse.com. 1990년 1월 1일. 2010년 5월 17일에 확인함.
  68. ↑ “Category:DM6467 - Texas Instruments Embedded Processors Wiki”. Processors.wiki.ti.com. 2011년 7월 12일. 2011년 7월 17일에 원본 문서에서 보존된 문서. 2011년 7월 30일에 확인함.
  69. ↑ “Briefing portfolio” (PDF). 《www.mpegla.com》. 2016년 11월 28일에 원본 문서 (PDF)에서 보존된 문서. 2016년 12월 1일에 확인함.
  70. ↑ “OMS Video, A Project of Sun's Open Media Commons Initiative”. May 11, 2010에 원본 문서에서 보존된 문서. August 26, 2008에 확인함.
  71. ↑ “Licensors Included in the AVC/H.264 Patent Portfolio License”. 《MPEG LA》. 2021년 10월 11일에 원본 문서에서 보존된 문서. 2019년 6월 18일에 확인함.
  72. 1 2 “AVC/H.264 – Patent List”. 《Via Licensing Alliance》. 2024년 4월 28일에 확인함.
  73. ↑ “MPEG LA's AVC License Will Not Charge Royalties for Internet Video that is Free to End Users through Life of License” (PDF). MPEG LA. 2010년 8월 26일. 2013년 11월 7일에 원본 문서 (PDF)에서 보존된 문서. 2010년 8월 26일에 확인함.
  74. ↑ Hachman, Mark (2010년 8월 26일). “MPEG LA Cuts Royalties from Free Web Video, Forever”. pcmag.com. 2010년 8월 26일에 확인함.
  75. ↑ “AVC FAQ”. MPEG LA. 2002년 8월 1일. 2010년 5월 7일에 원본 문서에서 보존된 문서. 2010년 5월 17일에 확인함.
  76. ↑ “United States Patent 9,356,620 Baese, et al.”. 2022년 8월 1일에 확인함. 2001년 9월 14일의 가장 빠른 우선권 날짜를 가진 특허로, 2,998일의 기간 연장이 적용되었다.
  77. 1 2 3 참조: Qualcomm Inc. v. Broadcom Corp., No. 2007-1545, 2008-1162 (Fed. Cir. December 1, 2008). 일반 언론 기사는 signonsandiego.com의 "Qualcomm loses its patent-rights case" 및 "Qualcomm's patent case goes to jury", 그리고 bloomberg.com의 "Broadcom Wins First Trial in Qualcomm Patent Dispute" 참조
  78. ↑ “nokia h264”.

외부 링크

[편집]
원본 주소 "https://ko.wikipedia.org/w/index.php?title=H.264/MPEG-4_AVC&oldid=41380817"