고급 비디오 코딩 - Advanced Video Coding

고급 비디오 코딩
일반 시청각 서비스를위한 고급 비디오 코딩
상태 힘에서
연도 시작 2003 년
최신 버전 2019 년 6 월
조직 ITU-T ( SG16 ), ISO , IEC
위원회 VCEG , MPEG
기본 표준 H.261 , H.262 (일명 MPEG-2 비디오 ), H.263 , MPEG-1
관련 표준 H.265 (일명 HEVC), H.266 (일명 VVC)
도메인 비디오 압축
웹 사이트 https://www.itu.int/rec/T-REC-H.264

고급형 비디오 코딩 ( AVC 라고도 함), H.264 또는 MPEG-4 파트 10, 고급 비디오 코딩 ( MPEG-4 AVC를 ), A는 비디오 압축 표준 블록 지향에 기초하여 움직임 보상 정수 DCT가 코딩. [1] 2019 년 9 월 현재 비디오 산업 개발자의 91 %가 사용하는 비디오 콘텐츠의 녹화, 압축 및 배포에 가장 일반적으로 사용되는 형식입니다 . [2] [3] [4] 8K UHD를 포함한 최대 해상도를 지원합니다 . [5] [6]

H.264 / AVC 프로젝트의 의도는 이전 표준보다 훨씬 낮은 비트 전송률 (즉, MPEG-2 , H.263 또는 MPEG-의 절반 이하의 비트 전송률) 에서 우수한 비디오 품질을 제공 할 수있는 표준을 만드는 것이 었습니다. 4 Part 2 ), 구현하는 데 비실용적이거나 과도하게 비용이 많이 드는 설계의 복잡성을 크게 증가시키지 않습니다. 이것은 정수 같은 감소 된 복잡도의 기능을 달성하고 이산 코사인 변환 (DCT의 정수), [6] [7] [8] 가변 블록 크기의 분할 및 멀티 프레임 간 예측. 추가 목표는 저 / 고 비트 전송률, 저 / 고해상도 비디오, 방송 , DVD 스토리지, RTP /를 포함하여 다양한 네트워크 및 시스템의 다양한 애플리케이션에 표준을 적용 할 수있는 충분한 유연성을 제공하는 것이 었습니다. IP의 패킷 네트워크, ITU-T의 멀티미디어 텔레포니시스템. H.264 표준은 "높은 프로필"이 가장 일반적으로 사용되는 형식이지만 여러 가지 프로필로 구성된 "표준 제품군"으로 볼 수 있습니다. 특정 디코더 디코딩 적어도 하나의, 그러나 반드시 모든 프로필. 이 표준은 인코딩 된 데이터의 형식과 데이터가 디코딩되는 방식을 설명하지만 비디오 인코딩을위한 알고리즘을 지정하지는 않습니다. 이는 인코더 설계자가 스스로 선택할 수있는 문제로 열려 있으며 다양한 인코딩 체계가 있습니다. 개발했다. H.264는 일반적으로 손실 압축 에 사용되지만 손실 코딩 된 그림 내에서 진정으로 무손실 코딩 된 영역 을 생성 하거나 전체 인코딩이 무손실 인 드문 사용 사례를 지원할 수도 있습니다.

H.264는 표준화 된 ITU-T 전문가 그룹 비디오 코딩 의 (VCEG) 연구 그룹 (16) 과 함께 ISO / IEC JTC1은 사진 전문가 그룹 이동 (MPEG)을. 프로젝트 파트너십 노력을 JVT (Joint Video Team)라고합니다. ITU-T H.264 표준과 ISO / IEC MPEG-4 AVC 표준은 (공식적으로는 ISO / IEC 14496-10 - MPEG-4 파트 10, 코딩 고급 비디오) 공동 그들이 동일한 기술 내용이 너무 유지됩니다. 표준의 첫 번째 버전에 대한 최종 초안 작업은 2003 년 5 월에 완료되었으며 그 기능의 다양한 확장이 후속 버전에 추가되었습니다. 고효율 비디오 코딩(HEVC), 일명 H.265 및 MPEG-H Part 2는 동일한 조직에서 개발 한 H.264 / MPEG-4 AVC의 후속 버전이지만 이전 표준은 여전히 ​​일반적으로 사용됩니다.

H.264는 Blu-ray 디스크 에서 가장 일반적으로 사용되는 비디오 인코딩 형식으로 가장 잘 알려져 있습니다. 또한 Netflix , Hulu , Prime Video , Vimeo , YouTubeiTunes Store의 비디오 , Adobe Flash PlayerMicrosoft Silverlight같은 웹 소프트웨어 , 지상파를 통한 다양한 HDTV 방송 같은 스트리밍 인터넷 소스 ( ATSC , ISDB-T , DVB-T 또는 DVB-T2 ), 케이블 ( DVB-C ) 및 위성 ( DVB-SDVB-S2 ) 시스템.

H.264는에 의해 보호되는 특허 다양한자가 소유. H.264에 필수적인 대부분의 (전부는 아님) 특허를 포괄하는 라이센스는 MPEG LA에서 관리 하는 특허 풀에서 관리합니다 . [9]

특허받은 H.264 기술을 상업적으로 사용하려면 MPEG LA 및 기타 특허 소유자에게 로열티를 지불해야합니다. MPEG LA는 최종 사용자에게 무료로 인터넷 비디오 스트리밍을위한 H.264 기술의 자유로운 사용을 허용하고 있으며, 시스코 시스템즈는 자사에 대한 바이너리의 사용자를 대신하여 MPEG LA에 로열티를 지불하는 오픈 소스 H.264 인코더.

명명

H.264 이름은 ITU-T 명명 규칙을 따릅니다. 여기서 표준은 VCEG 비디오 코딩 표준 의 H.26x 라인의 구성원입니다 . MPEG-4 AVC 이름은 ISO / IEC MPEG 의 명명 규칙과 관련이 있습니다.여기에서 표준은 MPEG-4로 알려진 표준 모음 인 ISO / IEC 14496의 10 부입니다. 이 표준은 H.26L이라는 VCEG 프로젝트로 ITU-T에서 초기 개발 작업을 한 후 VCEG와 MPEG의 파트너십으로 공동 개발되었습니다. 따라서 공통 유산을 강조하기 위해 H.264 / AVC, AVC / H.264, H.264 / MPEG-4 AVC 또는 MPEG-4 / H.264 AVC와 같은 이름으로 표준을 참조하는 것이 일반적입니다. 때때로이를 개발 한 JVT (Joint Video Team) 조직과 관련하여 "JVT 코덱"이라고도합니다. (이러한 파트너십 및 다중 이름 지정은 드문 일이 아닙니다. 예를 들어 MPEG-2로 알려진 비디오 압축 표준은 MPEG 와 ITU-T 간의 파트너십에서 발생했습니다 . MPEG-2 비디오는 ITU-T 커뮤니티에서 H로 알려져 있습니다. .262. [10]) 일부 소프트웨어 프로그램 (예 : VLC 미디어 플레이어 )은 내부적으로이 표준을 AVC1로 식별합니다.

역사

전반적인 역사

1998 년 초, Video Coding Experts Group (VCEG – ITU-T SG16 Q.6)은 H.26L이라는 프로젝트에 대한 제안 요청을 발표했습니다. 다양한 애플리케이션에 대한 기존의 다른 비디오 코딩 표준과 비교하여 주어진 충실도 수준). VCEGGary Sullivan ( Microsoft , 이전 PictureTel , US) 이 의장을 맡았습니다 . 이 새로운 표준에 대한 첫 번째 초안 설계는 1999 년 8 월에 채택되었습니다. 2000 년에 Thomas Wiegand ( 독일 Heinrich Hertz Institute )가 VCEG 공동 의장이되었습니다.

2001 년 12 월 VCEG와 동영상 전문가 그룹 ( MPEGISO / IEC JTC 1 / SC 29 / WG 11)은 비디오 코딩 표준을 완성하기위한 헌장과 함께 JVT (Joint Video Team)를 구성했습니다. [11] 사양의 공식 승인은 2003 년 3 월에 이루어졌습니다. JVT는 Gary Sullivan , Thomas Wiegand 및 Ajay Luthra ( 미국 Motorola , 나중에 Arris , 미국) 가 의장을 맡았습니다 . 2004 년 7 월에 FRExt (Fidelity Range Extensions) 프로젝트가 마무리되었습니다. 2005 년 1 월부터 2007 년 11 월까지 JVT는 SVC ( Scalable Video Coding )라는 부록 (G)에 의한 확장 성을 향한 H.264 / AVC의 확장 작업을 진행했습니다 . JVT 관리 팀은Jens-Rainer Ohm ( RWTH Aachen University , 독일). 2006 년 7 월부터 2009 년 11 월까지 JVT는 H.264 / AVC를 3D TV 및 제한 범위 자유 시점 TV 로 확장 한 MVC ( Multiview Video Coding) 작업을 수행했습니다 . 그 작업에는 표준의 두 가지 새로운 프로필 인 Multiview High Profile과 Stereo High Profile의 개발이 포함되었습니다.

표준을 개발하는 동안 SEI (보조 향상 정보)를 포함하기위한 추가 메시지가 개발되었습니다. SEI 메시지에는 비디오 사진의 타이밍을 나타내거나 코딩 된 비디오의 다양한 속성 또는 사용 또는 향상 방법을 설명하는 다양한 유형의 데이터가 포함될 수 있습니다. 임의의 사용자 정의 데이터를 포함 할 수있는 SEI 메시지도 정의됩니다. SEI 메시지는 핵심 디코딩 프로세스에 영향을주지 않지만 비디오가 후 처리 또는 표시되도록 권장되는 방식을 나타낼 수 있습니다. 비디오 콘텐츠의 일부 다른 상위 수준 속성은 비디오 콘텐츠 해석을위한 색상 공간 표시와 같은 비디오 사용성 정보 (VUI)로 전달됩니다 . HDR 과 같은 새로운 색 공간이 개발됨에 따라그리고 넓은 색 영역 비디오 추가 VUI 식별자를 표시하기 위해 추가되었습니다.

충실도 범위 확장 및 전문 프로필

H.264 / AVC의 첫 번째 버전의 표준화는 2003 년 5 월에 완료되었습니다. 원래 표준을 확장하기위한 첫 번째 프로젝트에서 JVT는 FExt (Fidelity Range Extensions)라고하는 것을 개발했습니다. 이러한 확장은 Y'C B C R 4 : 2 : 2 (일명 YUV 4 : 2 : 2 ) 및 4 : 로 알려진 샘플링 구조를 포함하여 향상된 샘플 비트 심도 정밀도와 고해상도 색상 정보를 지원하여 고품질 비디오 코딩을 가능하게합니다 . 4 : 4. FRExt 프로젝트에는 8x8 정수 이산 코사인 변환 추가와 같은 몇 가지 다른 기능도 포함되었습니다.(정수 DCT) 4x4 및 8x8 변환 간 적응 전환, 인코더 지정 지각 기반 양자화 가중치 매트릭스, 효율적인 그림 간 무손실 코딩 및 추가 색상 공간 지원. FRExt 프로젝트에 대한 설계 작업은 2004 년 7 월에 완료되었으며, 이에 대한 초안 작업은 2004 년 9 월에 완료되었습니다.

그런 다음 주로 전문 응용 프로그램을위한 5 개의 다른 새로운 프로필 (아래 버전 7 참조)이 개발되어 확장 된 색 영역 지원을 추가하고 추가 종횡비 표시기를 정의하고 두 가지 추가 유형의 "추가 향상 정보"(필터 후 힌트 및 톤)를 정의합니다. 매핑)하고, 이전에 FRExt 프로파일 (하이 4 비하 하나의 4 : 4 : 4 프로파일)이 산업 피드백 [ 의해? ] 표시는 다르게 설계되어야합니다.

확장 가능한 비디오 코딩

표준에 추가 된 다음 주요 기능은 SVC ( Scalable Video Coding )입니다. H.264 / AVC의 Annex G에 지정된 SVC는 H.264 / AVC에 의해 디코딩 될 수있는 "기본 계층"으로 알려진 비트 스트림을 포함하여 표준을 준수하는 하위 비트 스트림의 계층 을 포함하는 비트 스트림의 구성을 허용합니다 . SVC를 지원하지 않는 264 / AVC 코덱 . 시간적 비트 스트림 확장 성 (즉, 메인 비트 스트림보다 시간적 샘플링 속도가 더 작은 서브 비트 스트림의 존재)을 위해 완전한 액세스 단위하위 비트 스트림을 파생 할 때 비트 스트림에서 제거됩니다. 이 경우 비트 스트림의 고수준 신택스와 인터 예측 참조 픽처가 그에 따라 구성됩니다. 반면에 공간 및 품질 비트 스트림 확장 성 (즉, 메인 비트 스트림보다 공간 해상도 / 품질이 낮은 서브 비트 스트림의 존재)을 위해 서브 비트 스트림을 유도 할 때 NAL ( Network Abstraction Layer )이 비트 스트림에서 제거됩니다. . 이 경우, 계층 간 예측 (즉, 낮은 공간 해상도 / 품질 신호의 데이터로부터 높은 공간 해상도 / 품질 신호의 예측)은 일반적으로 효율적인 코딩을 위해 사용된다. 하는 스케일 러블 비디오 코딩 확장은 2007 년 11 월에 완료되었습니다.

멀티 뷰 비디오 코딩

표준에 추가 된 다음 주요 기능은 MVC ( Multiview Video Coding )입니다. H.264 / AVC의 Annex H에 지정된 MVC는 비디오 장면의 둘 이상의 뷰를 나타내는 비트 스트림을 구성 할 수 있습니다. 이 기능의 중요한 예는 입체 3D 비디오 코딩입니다. MVC 작업에서는 두 가지 프로필이 개발되었습니다. Multiview High 프로필은 임의의 수의보기를 지원하고 Stereo High 프로필은 2 개보기 입체 비디오를 위해 특별히 설계되었습니다. Multiview Video Coding 확장은 2009 년 11 월에 완료되었습니다.

3D-AVC 및 MFC 입체 코딩

심도 맵 및 텍스처 의 공동 코딩 (3D-AVC라고 함), 다중 해상도 프레임 호환 (MFC) 입체 및 3D-MFC 코딩, 다양한 추가 기능 조합 및 더 높은 프레임 을 포함한 3D 비디오 코딩을 포함한 추가 확장이 나중에 개발되었습니다. 크기 및 프레임 속도.

버전

H.264 / AVC 표준의 버전에는 다음과 같은 완료된 개정, 정정 및 수정이 포함됩니다 (날짜는 ITU-T의 최종 승인 날짜 인 반면 ISO / IEC의 최종 "국제 표준"승인 날짜는 다소 다르며 대부분의 경우 약간 늦습니다.) 사례). 각 버전은 텍스트에 통합 된 다음 하위 버전과 관련된 변경 사항을 나타냅니다.

  • 버전 1 (Edition 1) : (2003 년 5 월 30 일) Baseline, Main 및 Extended 프로필을 포함하는 H.264 / AVC의 최초 승인 버전. [12]
  • 버전 2 (1.1 판) : (2004 년 5 월 7 일) 정오표에는 다양한 사소한 수정 사항이 포함되어 있습니다. [13]
  • 버전 3 (Edition 2) : (2005 년 3 월 1 일) 첫 번째 수정안이 포함 된 주요 추가 사항으로 FRExt (Fidelity Range Extensions)를 설정합니다. 이 버전에는 High, High 10, High 4 : 2 : 2 및 High 4 : 4 : 4 프로필이 추가되었습니다. [14] 몇 년 후 High profile은 가장 일반적으로 사용되는 표준 프로필이되었습니다.
  • 버전 4 (2.1 판) : (2005 년 9 월 13 일) 정오표는 다양한 사소한 수정 사항을 포함하고 세 가지 종횡비 표시기를 추가합니다. [15]
  • 버전 5 (Edition 2.2) : (2006 년 6 월 13 일) 이전 High 4 : 4 : 4 프로필의 제거로 구성된 개정안 (ISO / IEC에서 정정으로 처리됨). [16]
  • 버전 6 (2.2 판) : (2006 년 6 월 13 일) 확장 된 색 영역 지원과 같은 사소한 확장으로 구성된 수정안 (위에 언급 된 ISO / IEC의 종횡비 표시기와 함께 번들로 제공됨). [16]
  • 버전 7 (버전 2.3) : (2007 년 4 월 6 일) High 4 : 4 : 4 예측 프로파일과 4 개의 Intra 전용 프로파일 (High 10 Intra, High 4 : 2 : 2 Intra, High 4 : 4)이 추가 된 수정안 : 4 Intra 및 CAVLC 4 : 4 : 4 Intra). [17]
  • 버전 8 (Edition 3) : (2007 년 11 월 22 일 ) Scalable Baseline, Scalable High 및 Scalable High Intra 프로필을 포함하는 SVC ( Scalable Video Coding)에 대한 수정 사항이 포함 된 H.264 / AVC에 대한 주요 추가 . [18]
  • 버전 9 (버전 3.1) : (2009 년 1 월 13 일) 사소한 수정이 포함 된 정오표. [19]
  • 버전 10 (Edition 4) : (2009 년 3 월 16 일) 이전에 지정된 다양한 프로필에서 지원되는 공통 기능 하위 집합 만있는 새 프로필 (제한된 기준 프로필)의 정의를 포함하는 수정. [20]
  • 버전 11 (Edition 4) : (2009 년 3 월 16 일) Multiview High 프로필을 포함하여 MVC ( Multiview Video Coding ) 확장에 대한 수정 사항이 포함 된 H.264 / AVC의 주요 추가 사항 입니다. [20]
  • 버전 12 (Edition 5) : (2010 년 3 월 9 일) 인터레이스 코딩 도구를 지원하고 추가 SEI (보조 향상 정보) 메시지를 지정하는 2- 뷰 비디오 코딩을위한 새로운 MVC 프로파일 (스테레오 하이 프로파일)의 정의를 포함하는 수정안 프레임 패킹 배열 SEI 메시지라고합니다. [21]
  • 버전 13 (Edition 5) : (2010 년 3 월 9 일) 사소한 수정이 포함 된 정오표. [21]
  • 버전 14 (Edition 6) : (2011 년 6 월 29 일) 초당 최대 매크로 블록 측면에서 더 높은 처리 속도를 지원하는 새로운 수준 (레벨 5.2) 및 프레임 코딩 도구 만 지원하는 새 프로필 (Progressive High 프로필)을 지정하는 수정안 이전에 지정된 High 프로필의. [22]
  • 버전 15 (Edition 6) : (2011 년 6 월 29 일) 사소한 수정이 포함 된 정오표. [22]
  • 버전 16 (Edition 7) : (2012 년 1 월 13 일) 주로 실시간 통신 애플리케이션을위한 세 가지 새로운 프로필의 정의를 포함하는 수정안 : 제한 높음, 확장 가능 제한 기준선 및 확장 가능 제한 높음 프로필. [23]
  • 버전 17 (Edition 8) : (2013 년 4 월 13 일) 추가 SEI 메시지 표시기가 포함 된 수정. [24]
  • 버전 18 (Edition 8) : (2013 년 4 월 13 일) Multiview Depth High 프로필을 포함한 3D 입체 비디오에 대한 깊이 맵 데이터의 코딩을 지정하기위한 수정. [24]
  • 버전 19 (Edition 8) : (2013 년 4 월 13 일) Corrigendum은 멀티 뷰 비디오에 대한 하위 비트 스트림 추출 프로세스의 오류를 수정했습니다. [24]
  • 버전 20 (Edition 8) : (2013 년 4 월 13 일) 톤 매핑 정보 SEI 메시지에 추가 색상 공간 식별자 ( UTU-R Recommendation BT.2020 for UHDTV 지원 포함 ) 및 추가 모델 유형을 지정하기위한 수정. [24]
  • 버전 21 (버전 9) : (2014 년 2 월 13 일) Enhanced Multiview Depth High 프로필을 지정하기위한 수정. [25]
  • 버전 22 (에디션 9) : (2014 년 2 월 13 일) 3D 입체 비디오, MFC 하이 프로파일 및 사소한 수정에 대한 다중 해상도 프레임 호환 (MFC) 향상을 지정하기위한 수정. [25]
  • 버전 23 (버전 10) : (2016 년 2 월 13 일) 깊이 맵, MFC 깊이 높음 프로필, 마스터 링 디스플레이 색상 볼륨 SEI 메시지 및 추가 색상 관련 VUI 코드 포인트 식별자가있는 MFC 입체 비디오를 지정하기위한 수정. [26]
  • 버전 24 (버전 11) : (2016 년 10 월 14 일) 더 큰 화면 크기 (레벨 6, 6.1 및 6.2), 녹색 메타 데이터 SEI 메시지, 대체 깊이 정보 SEI 메시지 및 추가를 지원하는 디코더 기능의 추가 수준을 지정하기위한 수정 색상 관련 VUI 코드 포인트 식별자. [27]
  • 버전 25 (Edition 12) : (2017 년 4 월 13 일) Progressive High 10 프로필, HLG ( Hybrid Log-Gamma ), 추가 색상 관련 VUI 코드 포인트 및 SEI 메시지를 지정하기위한 수정. [28]
  • 버전 26 (13 판) : (2019 년 6 월 13 일) 주변보기 환경, 콘텐츠 조명 수준 정보, 콘텐츠 색상 볼륨, 정방형 투영, 큐브 맵 투영, 구 회전, 영역 별 패킹, 전 방향 뷰포트에 대한 추가 SEI 메시지를 지정하기위한 수정안 SEI 매니페스트 및 SEI 접두사. [29]

특허 보유자

다음 조직은 MPEG LA의 H.264 / AVC 특허 풀 에서 하나 이상의 특허를 보유하고 있습니다.

H.264 / AVC 특허 보유자 (2020 년 11 월 기준 ) [30]
조직 [31] 활성 특허 만료 된 특허 총 특허 [30]
Panasonic Corporation 1,135 62 1,197
고도 카이 샤 IP 브릿지 1,111 19 1,130
LG 전자 875 115 990
Dolby Laboratories 754 21 775
Toshiba 357 34 391
마이크로 소프트 176 39 215
Nippon Telegraph and Telephone ( NTT Docomo 포함 ) 187 2 189
소니 116 31 147
프라운호퍼 소사이어티 125 16 141
구글 136 139
GE 비디오 압축 136 0 136
Fujitsu 92 14 106
미쓰비시 전기 54 50 104
Tagivan II LLC 77 0 77
삼성 전자 23 40 63
Maxell 51 2 53
필립스 5 39 44
Vidyo 41 2 43
Ericsson 34 0 34
한국 전자 통신 연구원 (ETRI) 32 0 32

응용

H.264 비디오 형식은 저 비트율 인터넷 스트리밍 응용 프로그램에서 HDTV 방송 및 거의 무손실 코딩으로 디지털 시네마 응용 프로그램에 이르기까지 모든 형태의 디지털 압축 비디오를 포괄하는 매우 광범위한 응용 프로그램 범위를 가지고 있습니다. H.264를 사용하면 MPEG-2 Part 2에 비해 비트 전송률이 50 % 이상 절감 되는 것으로보고됩니다. 예를 들어 H.264는 비트 전송률이 절반 미만인 현재 MPEG-2 구현과 동일한 디지털 위성 TV 품질을 제공하는 것으로보고되었으며 현재 MPEG-2 구현은 약 3.5Mbit / s에서 작동하고 H.264는 1.5에서 작동합니다. Mbit / s. [32] 9 메가 비트 / s AVC 기록 모드의 화질을 동등한 것으로 소니 항 HDV의 약 1,825 메가 비트를 사용하는 포맷 / S. [33]

H.264 / AVC의 호환성과 문제없는 채택을 보장하기 위해 많은 표준 기관이 비디오 관련 표준을 수정하거나 추가하여 이러한 표준의 사용자가 H.264 / AVC를 사용할 수 있도록합니다. 둘 다 블루 레이 디스크 형식과 지금 중단 HD DVD의 형식은 세 개의 필수 비디오 압축 형식 중 하나로서 H.264 / AVC 하이 프로파일을 포함한다. DVB (Digital Video Broadcast project )는 2004 년 말 방송 텔레비전에 H.264 / AVC 사용을 승인했습니다.

고급 텔레비전 시스템위원회 표준은 아직 미국 내에서 고정 된 ATSC 방송에 사용되지는 않지만 (ATSC) 미국 표준 단체는 2008 년 7 월 TV 방송을위한 H.264 / AVC의 사용을 승인했다. [34] [35] 그것은 또한 최신 사용하도록 승인 된 ATSC-M / H H.264의 AVC 및 SVC를 이용하여 부분 (이동 / 휴대용) 표준. [36]

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

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

파생 형식

AVCHDH.264를 사용 하는 SonyPanasonic에서 설계 한 고화질 레코딩 형식입니다 (애플리케이션 별 기능과 제약을 추가하면서 H.264를 준수 함).

AVC-IntraPanasonic 에서 개발 한 인트라 프레임 전용 압축 형식 입니다.

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

디자인

풍모

H.264의 블록 다이어그램

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

  • 다음 기능을 포함한 다중 사진 간 사진 예측 :
    • 이전 표준보다 훨씬 더 유연한 방식으로 이전에 인코딩 된 그림을 참조로 사용하여 경우에 따라 최대 16 개의 참조 프레임 (또는 인터레이스 인코딩의 경우 32 개의 참조 필드)을 사용할 수 있습니다. IDR 프레임 을 지원하는 프로필 에서 대부분의 수준은 최대 해상도에서 최소 4 개 또는 5 개의 참조 프레임을 허용 할 수 있도록 충분한 버퍼링을 사용할 수 있도록 지정합니다. 이는 제한이 일반적으로 1 인 이전 표준과는 대조적입니다. 또는 기존의 " B 픽처 "(B 프레임)의 경우 2 개.
    • 블록 크기가 최대 16x16 및 작은 4x4 인 가변 블록 크기 모션 보상 (VBSMC)으로 이동 영역을 정밀하게 분할 할 수 있습니다. 지원되는 루마 예측 블록 크기는 16x16, 16x8, 8x16 , 8x8, 8x4, 4x8 및 4x4를 ​​포함하며, 이들 중 다수는 단일 매크로 블록에서 함께 사용할 수 있습니다. 크로마 서브 샘플링 이 사용될 때 크로마 예측 블록 크기는 이에 따라 더 작습니다 .
    • 16 개의 4x4 파티션으로 구성된 B 매크로 블록의 경우 최대 32 개의 매크로 블록 (파티션 당 1 개 또는 2 개) 당 여러 모션 벡터를 사용할 수있는 기능. 각 8x8 또는 더 큰 파티션 영역에 대한 모션 벡터는 서로 다른 참조 픽처를 가리킬 수 있습니다.
    • I- 매크로 블록을 포함하여 B- 프레임 에서 모든 매크로 블록 유형을 사용할 수 있으므로 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에서 발견 된 변환 계수 예측이 아니라 "인트라" 코딩을 위해 인접 블록의 에지로부터의 공간 예측 . 여기에는 luma가 포함됩니다. 16x16, 8x8 및 4x4의 예측 블록 크기 (각 매크로 블록 내에서 하나의 유형 만 사용할 수 있음 ).
  • 정수 이산 코사인 변환 (정수 DCT), [6] [8] [43] 이산 코사인 변환 (DCT) 유형 [8] 여기서 변환은 표준 DCT의 정수 근사치입니다. [44] 선택 가능한 블록 크기 [7] 와 정확히 일치하는 정수 계산을 통해 다음을 포함하여 복잡성을 줄입니다.
    • 정확히 일치하는 정수 4x4 공간 블록 변환으로, 이전 코덱 설계에서 흔히 발견 되는 " " 이 거의없이 잔류 신호를 정밀하게 배치 할 수 있습니다. 이전 표준에서 사용 된 표준 DCT와 유사하지만 더 작은 블록 크기와 간단한 정수 처리를 사용합니다. 이전 표준 (예 : H.261 및 MPEG-2)에 표현 된 코사인 기반 공식 및 허용 오차와 달리 정수 처리는 정확히 지정된 디코딩 결과를 제공합니다.
    • 정확히 일치하는 정수 8x8 공간 블록 변환으로 상관 관계가 높은 영역을 4x4 변환보다 더 효율적으로 압축 할 수 있습니다. 이 디자인은 표준 DCT를 기반으로하지만 정확하게 지정된 디코딩을 제공하도록 단순화되고 만들어졌습니다.
    • 정수 변환 작업을위한 4x4 및 8x8 변환 블록 크기 사이의 적응 형 인코더 선택.
    • 평활 영역에서 더 많은 압축을 얻기 위해 색도 DC 계수 (및 특별한 경우 루마)에 적용되는 1 차 공간 변환의 "DC"계수에 대해 수행 된 2 차 Hadamard 변환 입니다.
  • 다음을 포함한 무손실 매크로 블록 코딩 기능 :
    • 비디오 데이터 샘플이 직접 표현되는 무손실 "PCM 매크로 블록"표현 모드로, [45] 특정 영역을 완벽하게 표현하고 각 매크로 블록에 대한 코딩 된 데이터의 양을 엄격하게 제한 할 수 있습니다.
    • 향상된 무손실 매크로 블록 표현 모드는 특정 영역을 완벽하게 표현하면서 일반적으로 PCM 모드보다 훨씬 적은 비트를 사용합니다.
  • 다음과 같은 유연한 인터레이스 스캔 비디오 코딩 기능 :
    • 프레임으로 코딩 된 사진에 매크로 블록 쌍 구조를 사용하는 매크로 블록 적응 형 프레임 필드 (MBAFF) 코딩으로 필드 모드에서 16x16 매크로 블록을 허용합니다 (MPEG-2와 비교하여 프레임으로 코딩 된 사진에서 필드 모드 처리) 결과적으로 16x8 반 매크로 블록이 처리됩니다).
    • 영상 적응 형 프레임 필드 코딩 (PAFF 또는 PicAFF)은 인코딩을 위해 두 필드가 함께 결합되거나 개별 단일 필드로 결합되는 완전한 프레임으로 코딩 된 영상의 자유롭게 선택된 혼합을 허용합니다.
  • 다음을 포함하는 양자화 설계 :
    • 인코더를 통한보다 쉬운 비트 전송률 관리 및 단순화 된 역 양자화 스케일링을위한 로그 스텝 크기 제어
    • 지각 기반 양자화 최적화를 위해 인코더에서 선택한 주파수 맞춤형 양자화 스케일링 매트릭스
  • 다른 DCT 기반 이미지 압축 기술에 공통적 인 블로킹 아티팩트를 방지하여 시각적 모양과 압축 효율성을 향상시키는 인 루프 디 블로킹 필터
  • 다음을 포함하는 엔트로피 코딩 설계 :
    • 컨텍스트 적응 이진 산술 코딩 (CABAC), 주어진 컨텍스트에서 구문 요소의 확률을 알고 비디오 스트림의 구문 요소를 무손실 압축하는 알고리즘입니다. CABAC는 CAVLC보다 더 효율적으로 데이터를 압축하지만 디코딩하려면 훨씬 더 많은 처리가 필요합니다.
    • 상황 적응 가변 길이 코딩 (CAVLC)은 양자화 된 변환 계수 값의 코딩을 위해 CABAC에 대한 복잡성이 낮은 대안입니다. CABAC보다 복잡도가 낮지 만 CAVLC는 다른 이전 설계에서 계수를 코딩하는 데 일반적으로 사용되는 방법보다 더 정교하고 효율적입니다.
    • Exponential-Golomb 코딩 (또는 Exp-Golomb) 이라고하는 CABAC 또는 CAVLC에 의해 코딩되지 않은 많은 구문 요소에 대한 일반적인 단순하고 고도로 구조화 된 가변 길이 코딩 (VLC) 기술입니다 .
  • 다음을 포함한 손실 복원 기능 :
    • 네트워크 추상화 계층 동일한 비디오 구문을 허용 (NAL) 정의는 많은 네트워크 환경에서 사용합니다. H.264의 매우 기본적인 설계 개념 중 하나는 MPEG-4의 HEC (Header Extension Code)에서와 같이 헤더 중복을 제거하기 위해 자체 포함 된 패킷을 생성하는 것입니다. [46] 이것은 미디어 스트림에서 하나 개 이상의 슬라이스에 관련된 정보를 디커플링함으로써 달성되었다. 상위 레벨 매개 변수의 조합을 매개 변수 세트라고합니다. [46]H.264 사양에는 SPS (Sequence Parameter Set) 및 PPS (Picture Parameter Set)의 두 가지 유형의 매개 변수 세트가 포함됩니다. 활성 시퀀스 매개 변수 세트는 코딩 된 비디오 시퀀스 전체에서 변경되지 않고 그대로 유지되고 활성 픽처 매개 변수 세트는 코딩 된 픽처 내에서 변경되지 않습니다. 시퀀스 및 픽처 매개 변수 세트 구조에는 픽처 크기, 사용되는 선택적 코딩 모드 및 슬라이스 그룹 맵에 대한 매크로 블록과 같은 정보가 포함됩니다. [46]
    • 슬라이스 그룹이라고도하는 FMO ( Flexible macroblock ordering ) 및 ASO (임의 슬라이스 순서 지정 )는 그림에서 기본 영역 ( 매크로 블록 ) 의 표현 순서를 재구성하는 기술입니다 . 일반적으로 오류 / 손실 견고성 기능으로 간주되는 FMO 및 ASO는 다른 용도로도 사용할 수 있습니다.
    • 데이터 파티셔닝 (DP), 더 중요하고 덜 중요한 구문 요소를 서로 다른 데이터 패킷으로 분리 할 수있는 기능을 제공하여 불평등 오류 보호 (UEP) 및 기타 유형의 오류 / 손실 견고성을 향상시킬 수 있습니다.
    • 중복 슬라이스 (RS), 인코더가 기본 표현이 손상되거나 손실 된 경우 사용할 수있는 그림 영역의 추가 표현 (일반적으로 낮은 충실도)을 보낼 수 있도록하는 오류 / 손실 견고성 기능입니다.
    • "하위 시퀀스"를 생성 할 수있는 기능인 프레임 번호 지정, 다른 그림 사이에 추가 그림을 선택적으로 포함하여 시간 확장 성을 가능하게하고 네트워크 패킷 손실 또는 채널로 인해 발생할 수있는 전체 그림의 손실을 감지하고 은폐합니다. 오류.
  • SP 및 SI 슬라이스라고하는 스위칭 슬라이스는 인코더가 디코더가 비디오 스트리밍 비트 레이트 전환 및 "트릭 모드"작동과 같은 목적으로 진행중인 비디오 스트림으로 점프하도록 지시 할 수 있도록합니다. 디코더가 SP / SI 기능을 사용하여 비디오 스트림의 중간으로 점프하면 다른 그림을 사용하거나 전혀 그림이없는 경우에도 비디오 스트림의 해당 위치에서 디코딩 된 그림과 정확히 일치 할 수 있습니다. 스위치.
  • 시작 코드 의 우발적 인 에뮬레이션을 방지하기위한 간단한 자동 프로세스입니다 . 코딩 된 데이터의 특수한 비트 시퀀스는 바이트 동기화가 손실 될 수있는 시스템에서 비트 스트림에 대한 임의 액세스 및 바이트 정렬 복구를 허용합니다.
  • SEI (Supplemental Enhancement Information) 및 VUI (Video Useability Information)는 비디오 콘텐츠에 사용 된 색 공간 또는 인코딩에 적용되는 다양한 제약을 나타내는 등 다양한 목적으로 비트 스트림에 삽입 할 수있는 추가 정보입니다. SEI 메시지에는 임의의 사용자 정의 메타 데이터 페이로드 또는 표준에 정의 된 구문 및 의미가있는 기타 메시지가 포함될 수 있습니다.
  • 알파 합성 과 같은 목적으로 사용할 수있는 보조 사진 .
  • 단색 (4 : 0 : 0), 4 : 2 : 0, 4 : 2 : 2 및 4 : 4 : 4 채도 샘플링 지원 (선택한 프로필에 따라 다름).
  • 샘플 당 8 ~ 14 비트 범위의 샘플 비트 심도 정밀도 지원 (선택한 프로필에 따라 다름).
  • 개별 색상 평면을 고유 한 슬라이스 구조, 매크로 블록 모드, 모션 벡터 등을 사용하여 별개의 그림으로 인코딩하는 기능을 통해 인코더를 간단한 병렬화 구조로 설계 할 수 있습니다 (3 개의 4 : 4 : 4 가능 프로필에서만 지원됨). .
  • 픽처 순서 카운트, 타이밍 정보로부터 분리 된 디코딩 된 픽처의 샘플 값과 픽처의 순서를 유지하는 기능으로, 디코딩 된 픽처 콘텐츠에 영향을주지 않고 시스템에 의해 타이밍 정보를 개별적으로 운반 및 제어 / 변경할 수 있습니다.

이러한 기술은 다른 여러 기술과 함께 H.264가 다양한 응용 프로그램 환경의 다양한 상황에서 이전 표준보다 훨씬 우수한 성능을 발휘하도록 도와줍니다. H.264는 MPEG-2 비디오보다 훨씬 뛰어난 성능을 발휘할 수 있습니다. 일반적으로 특히 높은 비트 전송률과 고해상도 비디오 콘텐츠에서 절반 이하의 비트 전송률로 동일한 품질을 얻을 수 있습니다. [47]

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

프로필

이 표준은 특정 응용 프로그램 클래스를 대상 으로하는 프로필 이라고하는 여러 기능 집합을 정의 합니다. 이들은 프로파일 코드 (profile_idc)를 사용하여 선언되며 때로는 인코더에 적용된 추가 제약 조건 세트를 사용합니다. 프로파일 코드와 표시된 제약을 통해 디코더는 특정 비트 스트림을 디코딩하기위한 요구 사항을 인식 할 수 있습니다. (많은 시스템 환경에서 하나 또는 두 개의 프로필 만 사용할 수 있으므로 이러한 환경의 디코더는 덜 일반적으로 사용되는 프로필을 인식하는 데 신경 쓸 필요가 없습니다.) 지금까지 가장 일반적으로 사용되는 프로필은 High Profile입니다.

확장 불가능한 2D 비디오 응용 프로그램의 프로필에는 다음이 포함됩니다.

제약 된베이스 라인 프로파일 (CBP, 제약 세트 1이있는 66)
주로 저비용 애플리케이션의 경우이 프로필은 화상 회의 및 모바일 애플리케이션에서 가장 일반적으로 사용됩니다. Baseline, Main 및 High Profile간에 공통적 인 기능의 하위 집합에 해당합니다.
기준 프로필 (BP, 66)
추가 데이터 손실 견고성이 필요한 저비용 애플리케이션의 경우 주로이 프로필이 일부 화상 회의 및 모바일 애플리케이션에 사용됩니다. 이 프로필에는 Constrained Baseline Profile에서 지원되는 모든 기능과 손실 견고성 (또는 저 지연 멀티 포인트 비디오 스트림 합성과 같은 다른 목적)에 사용할 수있는 세 가지 추가 기능이 포함됩니다. 이 프로필의 중요성은 2009 년 Constrained Baseline Profile의 정의 이후 다소 희미 해졌습니다. 모든 Constrained Baseline Profile 비트 스트림은 두 프로필이 동일한 프로필 식별자 코드 값을 공유하기 때문에 Baseline Profile 비트 스트림으로 간주됩니다.
확장 프로필 (XP, 88)
스트리밍 비디오 프로필로 의도 된이 프로필은 비교적 높은 압축 기능과 데이터 손실 및 서버 스트림 전환에 대한 견고성을위한 몇 가지 추가 트릭을 가지고 있습니다.
메인 프로필 (MP, 77)
이 프로파일은 DVB 표준에 정의 된 MPEG-4 형식을 사용하는 표준 화질 디지털 TV 방송에 사용됩니다. [49] 이 프로파일의 중요성이 높은 정보가 애플리케이션에 대한 2004 년에 개발 된 경우에 퇴색 그것은 그러나, 고화질 텔레비전 방송을 위해 사용되지 않는다.
높은 프로필 (HiP, 100)
방송 및 디스크 저장 응용 프로그램, 특히 고화질 TV 응용 프로그램의 기본 프로필입니다 (예 : Blu-ray 디스크 저장 형식 및 DVB HDTV 방송 서비스에서 채택한 프로필 ).
프로그레시브 하이 프로파일 (PHiP, 100, 제약 세트 4)
High profile과 유사하지만 필드 코딩 기능을 지원하지 않습니다.
제한된 높은 프로필 (제한 세트 4 및 5가있는 100)
프로그레시브 하이 프로파일과 유사하지만 B (이중 예측) 슬라이스를 지원하지 않습니다.
하이 10 프로파일 (Hi10P, 110)
일반적인 주류 소비자 제품 기능을 넘어서이 프로파일은 하이 프로파일을 기반으로 구축되어 디코딩 된 영상 정밀도 샘플 당 최대 10 비트를 지원합니다.
높은 4 : 2 : 2 프로필 (Hi422P, 122)
주로 인터레이스 비디오를 사용하는 전문 애플리케이션을 대상으로하는이 프로필은 High 10 Profile을 기반으로 구축되어 디코딩 된 그림 정밀도 샘플 당 최대 10 비트를 사용하면서 4 : 2 : 2 크로마 샘플링 형식을 지원합니다.
높은 4 : 4 : 4 예측 프로필 (Hi444PP, 244)
이 프로필은 High 4 : 2 : 2 프로필을 기반으로 구축되어 최대 4 : 4 : 4 크로마 샘플링, 샘플 당 최대 14 비트를 지원하고 효율적인 무손실 영역 코딩과 각 픽처의 코딩을 3 개의 개별 색상으로 추가로 지원합니다. 비행기.

캠코더, 편집 및 전문 응용 프로그램의 경우 표준에는 다른 해당 프로필의 간단한 하위 집합으로 정의되는 4 개의 추가 프레임 내 전용 프로필이 포함되어 있습니다 . 이들은 대부분 전문 (예 : 카메라 및 편집 시스템) 애플리케이션 용입니다.

High 10 Intra Profile (제한 세트 3이있는 110)
All-Intra 사용으로 제한되는 High 10 Profile.
높은 4 : 2 : 2 인트라 프로필 (제한 세트 3이있는 122)
All-Intra 사용으로 제한되는 High 4 : 2 : 2 프로필.
높은 4 : 4 : 4 인트라 프로필 (제약 세트 3이있는 244)
All-Intra 사용으로 제한된 High 4 : 4 : 4 프로필.
CAVLC 4 : 4 : 4 인트라 프로필 (44)
All-Intra 사용 및 CAVLC 엔트로피 코딩 (즉, CABAC을 지원하지 않음)으로 제한되는 High 4 : 4 : 4 프로파일.

SVC ( Scalable Video Coding ) 확장 의 결과로 표준에는 기본 계층에 대한 H.264 / AVC 프로필의 조합으로 정의되는 5 개의 추가 확장 가능한 프로필 이 포함됩니다 (확장 가능한 프로필 이름에서 두 번째 단어로 식별 됨). ) 및 확장 가능한 확장을 달성하는 도구 :

확장 가능한베이스 라인 프로필 (83)
주로 화상 회의, 모바일 및 감시 애플리케이션을 대상으로하는이 프로필은 기본 계층 (비트 스트림의 하위 집합)이 준수해야하는 제한적인 기본 프로필 위에 구축됩니다. 확장 성 도구의 경우 사용 가능한 도구의 하위 집합이 활성화됩니다.
확장 가능한 제약 된베이스 라인 프로필 (제한 세트 5가있는 83)
주로 실시간 통신 애플리케이션을위한 Scalable Baseline Profile의 하위 집합입니다.
확장 가능한 하이 프로파일 (86)
주로 브로드 캐스트 및 스트리밍 애플리케이션을 대상으로하는이 프로필은 기본 레이어가 준수해야하는 H.264 / AVC High Profile을 기반으로합니다.
확장 가능한 제한 높은 프로필 (제한 세트 5가있는 86)
주로 실시간 통신 애플리케이션을 위해 고안된 Scalable High Profile의 하위 집합입니다.
확장 가능한 High Intra Profile (제한 세트 3이있는 86)
주로 프로덕션 애플리케이션을 대상으로하는이 프로필은 올인 트라 사용으로 제한되는 확장 가능한 하이 프로필입니다.

MVC ( Multiview Video Coding ) 확장 의 결과로 표준에는 두 개의 멀티 뷰 프로필이 포함됩니다 .

스테레오 하이 프로파일 (128)
이 프로필은 2- 뷰 입체 3D 비디오를 대상 으로하며 High 프로필의 도구와 MVC 확장의 인터뷰 예측 기능을 결합합니다.
멀티 뷰 하이 프로파일 (118)
이 프로파일은 인터 픽처 (시간) 및 MVC 인터 뷰 예측을 모두 사용하는 둘 이상의 뷰를 지원하지만 필드 픽처 및 매크로 블록 적응 형 프레임 필드 코딩은 지원하지 않습니다.

MFC (Multi-resolution Frame-Compatible) 확장은 두 개의 프로필을 더 추가했습니다.

MFC 하이 프로파일 (134)
2 계층 해상도 향상으로 입체 코딩을위한 프로파일입니다.
MFC 깊이 높은 프로필 (135)

3D-AVC 확장은 두 가지 프로필을 더 추가했습니다.

멀티 뷰 깊이 하이 프로파일 (138)
이 프로파일은 3D 비디오 콘텐츠의 압축 개선을 위해 깊이 맵과 비디오 텍스처 정보의 공동 코딩을 지원합니다.
향상된 멀티 뷰 깊이 하이 프로파일 (139)
깊이 정보와 결합 된 멀티 뷰 코딩을위한 향상된 프로파일.

특정 프로필의 기능 지원

특색 CBP BP XP MP ProHiP 잘 알고 있기 Hi10P Hi422P Hi444PP
I and P slices Yes Yes Yes Yes Yes Yes Yes Yes Yes
비트 심도 (샘플 당) 8 8 8 8 8 8 8에서 10 8에서 10 8에서 14
Chroma 형식 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 슬라이스 아니 아니
Multiple reference frames Yes Yes Yes Yes Yes Yes Yes Yes Yes
In-loop deblocking filter Yes Yes Yes Yes Yes Yes Yes Yes Yes
CAVLC entropy coding Yes Yes Yes Yes Yes Yes Yes Yes Yes
CABAC 엔트로피 코딩 아니 아니 아니
4 : 0 : 0 ( 흑백 ) 아니 아니 아니 아니
8x8 대 4x4 변환 적응성 아니 아니 아니 아니
양자화 스케일링 행렬 아니 아니 아니 아니
C B 및 C R QP 제어 분리 아니 아니 아니 아니
별도의 색상 평면 코딩 아니 아니 아니 아니 아니 아니 아니 아니
무손실 예측 코딩 아니 아니 아니 아니 아니 아니 아니 아니

레벨

이 용어가 표준에서 사용됨에 따라 " 레벨 "은 프로파일에 필요한 디코더 성능의 정도를 나타내는 지정된 제약 세트입니다. 예를 들어, 프로파일 내의 지원 수준은 디코더가 사용할 수있는 최대 사진 해상도, 프레임 속도 및 비트 속도를 지정합니다. 주어진 레벨을 따르는 디코더는 해당 레벨과 모든 하위 레벨에 대해 인코딩 된 모든 비트 스트림을 디코딩 할 수 있어야합니다.

최대 속성 값을 가진 수준 [28]
수평
최대
디코딩 속도
(매크로 블록 / 초)
최대
프레임 크기
(매크로 블록)

비디오
코딩 레이어 (VCL)에 대한 최대 비디오 비트 전송률
(제한된 기준선,
기준선, 확장
및 기본 프로필)
(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)
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 Profile의 최대 비트 전송률은 Constrained Baseline, Baseline, Extended 및 Main Profile의 1.25 배입니다. Hi10P의 경우 3 회, Hi422P / Hi444PP의 경우 4 회.

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

디코딩 된 사진 버퍼링

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

DpbCapacity = 분 (층 ( MaxDpbMbs / ( PicWidthInMbs는 * FrameHeightInMbs을 )) 16)

여기서 MaxDpbMbs하면 레벨 번호의 함수로서 아래의 표에 제공되는 상수 값이며, PicWidthInMbsFrameHeightInMbs는 매크로 블록 (정수 값으로 반올림 자르기 차지 단위로 표현되는 코딩 된 비디오 데이터의 픽처 폭과 프레임의 높이이다 해당되는 경우 매크로 블록 페어링). 이 공식은 표준 2017 년판의 섹션 A.3.1.h 및 A.3.2.f에 지정되어 있습니다. [28]

수평
1
1b
1.1
1.2
1.3
2
2.1
2.2
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 인 Level 4 행의 오른쪽 열 위 표에서 괄호 안에 표시됩니다.

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

구현

2009 년 HTML5 워킹 그룹특허에 의해 방해받지 않는 것으로 여겨지는 무료 비디오 형식 인 Ogg Theora 와 특허 기술이 포함 된 H.264의 지지자로 나뉘 었습니다 . 2009 년 7 월 말에 Google과 Apple은 H.264를 지원하고 Mozilla와 Opera는 Ogg Theora를 지원한다고합니다 (현재 Google, Mozilla 및 Opera는 모두 VP8을 사용 하여 Theora 및 WebM지원함 ). [50] HTML 5 비디오 마이크로 소프트 인터넷 익스플로러 (9)의 방출에 첨가했다 지원 H.264를 사용하여 인코딩. 2010 년 11 월 Gartner Symposium / ITXpo에서 Microsoft CEO Steve Ballmer는 "HTML 5 또는 Silverlight? ""보편적 인 일을하고 싶다면 세상이 HTML5로 가고 있다는 것은 의심의 여지가 없습니다. " [51] 2011 년 1 월 Google은 Chrome 브라우저에서 H.264를 지원하고 지원한다고 발표했습니다. Theora와 WebM / VP8 모두 개방 형식 만 사용합니다. [52]

2012 년 3 월 18 일 Mozilla 는 H.264로 인코딩 된 비디오의 보급과 이러한 장치에서 일반적으로 사용되는 전용 H.264 디코더 하드웨어 사용으로 인한 전력 효율성 증가로 인해 모바일 장치의 Firefox에서 H.264에 대한 지원을 발표했습니다. [53] 2013 년 2 월 20 일, Mozilla는 Windows 7 이상에서 H.264 디코딩을위한 Firefox 지원을 구현했습니다. 이 기능은 Windows의 내장 디코딩 라이브러리에 의존합니다. [54] 2015 년 1 월 13 일에 출시 된 Firefox 35.0은 OS X 10.6 이상에서 H.264를 지원합니다. [55]

2013 년 10 월 30 일, Cisco Systems의 Rowan TrollopeCiscoSimplified BSD 라이선스에 따라 OpenH264 라는 H.264 비디오 코덱의 바이너리와 소스 코드를 모두 릴리스 하고 모든 소프트웨어 프로젝트에 대해 MPEG LA에 사용하는 모든 로열티를 지불 할 것이라고 발표 했습니다. Cisco의 사전 컴파일 된 바이너리를 사용하여 Cisco의 OpenH264 바이너리를 만듭니다.무료로 사용할 수 있습니다. 그러나 바이너리 대신 Cisco의 소스 코드를 사용하는 모든 소프트웨어 프로젝트는 MPEG LA에 대한 모든 로열티를 지불 할 법적 책임이 있습니다. 현재 타겟 CPU 아키텍처는 x86 및 ARM이고 현재 타겟 운영 체제는 Linux, Windows XP 이상, Mac OS X 및 Android입니다. iOS는 응용 프로그램이 인터넷에서 바이너리 모듈을 가져 와서 설치할 수 없도록하기 때문에이 목록에 포함되지 않았습니다. [56] [57] [58] 2013 년 10 월 30 일에, 브렌던 아이크 에서 모질라는 이 플랫폼 코덱을 사용할 수없는 경우 파이어 폭스에 H.264에 대한 지원을 추가 할 파이어 폭스의 향후 버전에서 시스코의 바이너리를 사용하는 것이라고 썼다. [59]

Cisco는 2013 년 12 월 9 일 OpenH264에 소스를 게시했습니다. [60]

소프트웨어 인코더

AVC 소프트웨어 구현
특색 QuickTime 네로 OpenH264 x264 주요
개념
Elecard TSE 프로
코더
Avivo 원소 같은 IPP
B 슬라이스 아니
여러 참조 프레임 아니
인터레이스 코딩 (PicAFF, MBAFF) 아니 MBAFF MBAFF MBAFF 아니 MBAFF 아니
CABAC 엔트로피 코딩 아니
8x8 대 4x4 변환 적응성 아니 아니
양자화 스케일링 행렬 아니 아니 아니 아니 아니 아니 아니 아니
C B 및 C R QP 제어 분리 아니 아니 아니 아니 아니 아니 아니
확장 된 크로마 형식 아니 아니 아니 4 : 0 : 0 [61]
4 : 2 : 0
4 : 2 : 2 [62]
4 : 4 : 4 [63]
4 : 2 : 2 4 : 2 : 2 4 : 2 : 2 아니 아니 4 : 2 : 0
4 : 2 : 2
아니
최대 샘플 깊이 (비트) 8 8 8 10 [64] 10 8 8 8 8 10 12
무손실 예측 코딩 아니 아니 아니 [65] 아니 아니 아니 아니 아니 아니 아니

하드웨어

H.264 인코딩 및 디코딩은 특정 유형의 산술 연산에서 상당한 컴퓨팅 성능을 필요로하기 때문에 범용 CPU에서 실행되는 소프트웨어 구현은 일반적으로 전력 효율성이 떨어집니다. 그러나 최신 [ 언제? ]쿼드 코어 범용 x86 CPU는 실시간 SD 및 HD 인코딩을 수행하기에 충분한 계산 능력을 갖추고 있습니다. 압축 효율성은 하드웨어 또는 소프트웨어 구현이 사용되는지 여부가 아니라 비디오 알고리즘 구현에 따라 다릅니다. 따라서 하드웨어 기반 구현과 소프트웨어 기반 구현의 차이는 전력 효율성, 유연성 및 비용에 있습니다. 전력 효율성을 개선하고 하드웨어 폼 팩터를 줄이기 위해 전체 인코딩 또는 디코딩 프로세스 또는 CPU 제어 환경 내에서 가속화 지원을 위해 특수 목적 하드웨어를 사용할 수 있습니다.

CPU 기반 솔루션은 특히 여러 형식, 여러 비트 전송률 및 해상도 ( 멀티 스크린 비디오 )로 인코딩을 동시에 수행해야 할 때 훨씬 더 유연하며 컨테이너 형식 지원, 고급 통합 광고 기능 등에 대한 추가 기능을 사용할 수 있습니다. . CPU 기반 소프트웨어 솔루션은 일반적으로 동일한 CPU 내에서 여러 동시 인코딩 세션의로드 밸런싱을 훨씬 쉽게 만듭니다.

2011 년 1 월 CES ( Consumer Electronics Show ) 에서 소개 된 2 세대 Intel " Sandy Bridge " Core i3 / i5 / i7 프로세서는 Intel Quick Sync Video 로 알려진 온칩 하드웨어 풀 HD H.264 인코더를 제공합니다 . [66] [67]

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

H.264 인코더 기능이있는 ASIC 인코더는 다양한 반도체 회사에서 구할 수 있지만 ASIC에 사용되는 핵심 디자인은 일반적으로 Chips & Media , Allegro DVT, On2 (이전 명칭 : Hantro, Google에서 인수) 와 같은 소수의 회사 중 하나에서 라이센스를 받았습니다 . 상상 기술 , NGCodec. 일부 회사는 FPGA와 ASIC 제품을 모두 제공합니다. [68]

Texas Instruments는 30fps에서 1080p를 인코딩하는 DSP H.264 BP를 수행하는 ARM + DSP 코어 라인을 제조합니다. [69] 일반 CPU의 소프트웨어보다 효율적이면서 (최적화 된 DSP 코드로서 구현 됨) 코덱에 대해 이러한 유연성을 허용한다.

라이센싱

소프트웨어 알고리즘에 대한 특허 가 유지 되는 국가에서 H.264 / AVC를 사용하는 제품의 공급 업체 및 상용 사용자는 해당 제품이 사용하는 특허 기술에 대해 특허 라이선스 로열티를 지불해야합니다. [70] 이베이스 라인 프로파일에 적용도. [71]

로 알려진 개인 조직 MPEG LA 는 MPEG 표준화 조직과 어떤 방식으로 제휴하지 않습니다,는이 기준에 적용되는 특허에 대한 라이센스뿐만 아니라 다른 관리하는 특허 풀 등의 MPEG-4 파트 2 비디오, HEVC 및 대한 등을, MPEG-DASH. 특허 보유자는 Fujitsu , Panasonic , Sony , Mitsubishi , Apple , Columbia University , KAIST , Dolby , Google , JVC Kenwood , LG Electronics , Microsoft , NTT Docomo , Philips를 포함합니다., Samsung , Sharp , ToshibaZTE , [72] 풀의 대부분의 특허는 Panasonic (1,197 개 특허), Godo Kaisha IP Bridge (1,130 개 특허) 및 LG 전자 (990 개 특허)가 보유하고 있습니다. [73]

2010 년 8 월 26 일 MPEG LA는 최종 사용자에게 무료로 제공되는 H.264 인코딩 인터넷 비디오에 대해 로열티가 부과되지 않는다고 발표했습니다. [74] 다른 모든 로열티는 제품에 대한 로열티로, 장소에 남아 디코딩 및 인코딩 H.264 비디오 그뿐만 아니라 무료 텔레비전 및 구독 채널 운영자에게있다. [75] 라이센스 조건은 5 년 블록으로 갱신된다. [76]

표준의 첫 번째 버전이 2003 년 5 월에 완성 된 이후 (17 년 전) 가장 많이 사용되는 프로필 (High 프로필)은 2004 년 6 월에 완료되었습니다 (십육년 전), 원래의 표준에 적용 특허의 상당수가 만료되고, [77] 은 MPEG LA H.264 풀의 미국 특허 중 하나가 지속되지만 적어도까지 2027 [78]

2005 년 Qualcomm은 Broadcom이 H.264 비디오 압축 표준을 준수하는 제품을 만들어 자사의 2 개의 특허를 침해했다고 주장하면서 미국 지방 법원에서 Broadcom을 고소했습니다. [79] 2007 년 지방 법원은 Qualcomm이 2003 년 5 월 H.264 표준이 공개되기 전에 JVT에 특허를 공개하지 않았기 때문에 해당 특허를 시행 할 수 없다고 판결했습니다. [79] 2008 년 12 월 미국 법원은 연방 순회에 대한 항소는 H.264 준수 제품에 대한 시행 불가능의 범위를 제한하라는 지침과 함께 특허를 집행 할 수 없지만 지방 법원에 재 구속하라는 지방 법원의 명령을 확인했습니다. [79]

또한보십시오

참고 문헌

  1. ^ "H.264 : 일반 시청각 서비스를위한 고급 비디오 코딩" . www.itu.int . 아카이브 2019년 10월 31일에 원래부터 . 만회 년 11 월 (22), 2019 .
  2. Ozer, Jan. "여러 화면 전달을위한 인코딩, 섹션 3, 강의 7 : H.264 소개" . Udemy . 만회 년 10 월 (10), (2016) .
  3. "Video Developer Report 2018" (PDF) . Bitmovin . 2019 년 9 월.
  4. "Video Developer Report 2019" . Bitmovin . 2019 년 9 월.
  5. ^ "AVC / H.264를 사용하여 8K 제공" . 미스터리 박스 . 만회 년 8 월 (23), 2017 .
  6. ^ a b c Wang, Hanli; Kwong, S .; Kok, C. (2006). "H.264 / AVC 최적화를위한 정수 DCT 계수의 효율적인 예측 알고리즘". 비디오 기술을위한 회로 및 시스템에 대한 IEEE 트랜잭션 . 16 (4) : 547–552. DOI : / TCSVT.2006.871390 10.1109을 . S2CID 2060937 .
  7. ^ a b 톰슨, 개빈; 샤, 아 타르 (2017). "HEIF 및 HEVC 소개" (PDF) . Apple Inc.의 만회 년 8 월 (5), 2019 년 .
  8. ^ a b c Stanković, Radomir S .; Astola, Jaakko T. (2012). "DCT의 초기 작업 회상 : KR Rao와의 인터뷰" (PDF) . 정보 과학 초기의 재판 . 60 : 17 . 만회 년 10 월 (13), 2019 년 .
  9. ^ "AVC / H.264 FAQ" . www.mpegla.com . 에서 보관 원래 2010 년 5 월 7 . 만회 년 9 월 (15), (2016) .
  10. ^ "H.262 : 정보 기술-동영상 및 관련 오디오 정보의 일반 코딩 : 비디오" . 만회 년 4 월 (15), 2007 .
  11. ^ 합동 영상 팀 , ITU-T 웹 사이트.
  12. "ITU-T Recommendation H.264 (2003 년 5 월)" . ITU. 2003 년 5 월 30 일 . 만회 년 4 월 (18), 2013 .
  13. "ITU-T Recommendation H.264 (2003 년 5 월) Cor. 1 (2004 년 5 월)" . ITU. 2004 년 5 월 7 일 . 만회 년 4 월 (18), 2013 .
  14. "ITU-T 권고 H.264 (2005 년 3 월)" . ITU. 2005 년 3 월 1 일 . 만회 년 4 월 (18), 2013 .
  15. "ITU-T Recommendation H.264 (2005) Cor. 1 (2005 년 9 월)" . ITU. 2005 년 9 월 13 일 . 만회 년 4 월 (18), 2013 .
  16. a b "ITU-T Recommendation H.264 (2005) Amd. 1 (2006/2006)" . ITU. 2006 년 6 월 13 일 . 만회 년 4 월 (18), 2013 .
  17. "ITU-T Recommendation H.264 (2005) Amd. 2 (04/2007)" . ITU. 2007 년 4 월 6 일 . 만회 년 4 월 (18), 2013 .
  18. "ITU-T Recommendation H.264 (2007 년 11 월)" . ITU. 2007 년 11 월 22 일 . 만회 년 4 월 (18), 2013 .
  19. "ITU-T Recommendation H.264 (2007) Cor. 1 (01/2009)" . ITU. 2009 년 1 월 13 일 . 만회 년 4 월 (18), 2013 .
  20. ^ a b "ITU-T 권고 H.264 (2009 년 3 월)" . ITU. 2009 년 3 월 16 일 . 만회 년 4 월 (18), 2013 .
  21. ^ a b "ITU-T 권고 H.264 (2010 년 3 월)" . ITU. 2010 년 3 월 9 일 . 만회 년 4 월 (18), 2013 .
  22. ^ a b "ITU-T 권고 H.264 (2011 년 6 월)" . ITU. 2011 년 6 월 29 일 . 만회 년 4 월 (18), 2013 .
  23. "ITU-T 권고 H.264 (2012 년 1 월)" . ITU. 2012 년 1 월 13 일 . 만회 년 4 월 (18), 2013 .
  24. ^ a b c d "ITU-T 권고 H.264 (2013 년 4 월)" . ITU. 2013 년 6 월 12 일 . 만회 년 6 월 (16), 2013 년 .
  25. ^ a b "ITU-T 권고 H.264 (2014 년 2 월)" . ITU. 2014 년 11 월 28 일 . 만회 년 2 월 (28), (2016) .
  26. "ITU-T Recommendation H.264 (2016 년 2 월)" . ITU. 2016 년 2 월 13 일 . 만회 년 6 월 (14), 2017 년 .
  27. "ITU-T Recommendation H.264 (2016 년 10 월)" . ITU. 2016 년 10 월 14 일 . 만회 년 6 월 (14), 2017 년 .
  28. ^ a b c "ITU-T 권고 H.264 (2017 년 4 월)" . ITU. 2017 년 4 월 13 일. 표로 작성된 레벨 종속 기능은 표 A-1, A-6 및 A-7을 참조하십시오 . 만회 년 6 월 (14), 2017 년 .
  29. "ITU-T Recommendation H.264 (2019 년 6 월 – 사전 게시 됨)" . ITU. 2019 년 6 월 13 일 . 검색된 년 8 월 (6), 2019 년 .
  30. ^ a b "AVC / H.264 – 특허 목록" (PDF) . MPEG LA . 검색된 년 7 월 (6), 2019 년 .
  31. ^ "AVC / H.264 사용권 허가자" . MPEG-LA. 에서 보관 원래 2015년 5월 30일에 . 만회하는 5 월 (19), 2013 .
  32. ^ 벵거; et al. "RFC 3984 : H.264 비디오 용 RTP 페이로드 형식" : 2. Cite journal requires |journal= (help)
  33. ^ "어떤 녹화 모드가 HDV (High Definition Video) 형식의 화질과 동일합니까?" . Sony eSupport . 에서 보관 원래 2017년 11월 9일에 . 검색된 년 12 월 (8), 2018 년 .
  34. ^ "ATSC 표준 A / 72 파트 1 : ATSC 디지털 텔레비전 시스템에서 AVC의 비디오 시스템 특성" (PDF) . 2011 년 8 월 7 일에 원본 (PDF) 에서 보관되었습니다 . 만회 년 7 월 (30), 2011 .
  35. ^ "ATSC 표준 A / 72 파트 2 : AVC 비디오 전송 하위 시스템 특성" (PDF) . 2011 년 8 월 7 일에 원본 (PDF) 에서 보관되었습니다 . 만회 년 7 월 (30), 2011 .
  36. ^ "ATSC 표준 A / 153 파트 7 : AVC 및 SVC 비디오 시스템 특성" (PDF) . 2011 년 7 월 26 일에 원본 (PDF) 에서 보관되었습니다 . 만회 년 7 월 (30), 2011 .
  37. ^ a b "Sony는 전문가 및 소비자 시장에서 4K 개발을 가속화하기 위해 새로운 XAVC 레코딩 형식을 도입했습니다 . " . 소니. 2012 년 10 월 30 일 . 검색된 년 11 월 (1), 2012 년 .
  38. ^ a b "Sony, 전문가 및 소비자 시장에서 4K 개발을 가속화하기 위해 새로운 XAVC 레코딩 형식 도입" (PDF) . 소니. 2012 년 10 월 30 일 . 검색된 년 11 월 (1), 2012 년 . [ 영구 데드 링크 ]
  39. Steve Dent (2012 년 10 월 30 일). "Sony는 PMW-F55 및 PMW-F5 pro CineAlta 4K Super 35mm 센서 캠코더로 레드 헌팅을 시작 합니다. " Engadget . 검색된 년 11 월 (5), 2012 년 .
  40. "F55 CineAlta 4K, 예정보다 앞선 미래" (PDF) . 소니. 2012 년 10 월 30 일. 2012 년 11 월 19 일에 원본 (PDF) 에서 보관되었습니다 . 검색된 년 11 월 (1), 2012 년 .
  41. ^ "초고속"SxS PRO + "메모리 카드는 4K 비디오 캡처를 변환합니다" . 소니. 에서 보관 원래 2013년 3월 8일에 . 검색된 년 11 월 (5), 2012 년 .
  42. ^ "초고속"SxS PRO + "메모리 카드는 4K 비디오 캡처를 변환합니다" (PDF) . 소니. 2015 년 4 월 2 일에 원본 (PDF) 에서 보관되었습니다 . 검색된 년 11 월 (5), 2012 년 .
  43. 권순영; 이주경; 정기동 (2005). "MPEG-2 / H.264 트랜스 코딩을위한 하프 픽셀 수정" . 이미지 분석 및 처리 – ICIAP 2005 . 컴퓨터 과학 강의 노트. 스프링거 베를린 하이델베르크. 3617 : 576–583. DOI : / 11553595_71 10.1007을 . ISBN 978-3-540-28869-5.
  44. Britanak, Vladimir; Yip, Patrick C .; Rao, KR (2010). 이산 코사인 및 사인 변환 : 일반 속성, 빠른 알고리즘 및 정수 근사치 . 엘스 비어 . ix, xiii, 1, 141–304 쪽. ISBN 9780080464640.
  45. ^ "H.264 / AVC 고급 비디오 코딩 표준 : Fidelity 범위 확장에 대한 개요 및 소개" (PDF) . 만회 년 7 월 (30), 2011 .
  46. ^ a b c RFC 3984 , 3 쪽
  47. Apple Inc. (1999 년 3 월 26 일). "H.264 FAQ" . 사과. 에서 보관 원래 2010년 3월 7일에 . 만회하는 5 월 (17), 2010 .
  48. Karsten Suehring. "H.264 / AVC JM 참조 소프트웨어 다운로드" . Iphome.hhi.de . 만회하는 5 월 (17), 2010 .
  49. ^ "TS 101 154 – V1.9.1 – 디지털 비디오 방송 (DVB), MPEG-2 전송 스트림에 기반한 방송 애플리케이션에서 비디오 및 오디오 코딩 사용에 대한 사양" (PDF) . 만회하는 5 월 (17), 2010 .
  50. ^ "HTML 5 비디오 코덱 토론 디코딩" . Ars Technica . 2009 년 7 월 6 일 . 만회 년 1 월 (12), 2011 .
  51. ^ "Steve Ballmer, CEO Microsoft, Gartner Symposium / ITxpo Orlando 2010에서 인터뷰" . Gartnervideo. 2010 년 11 월 . 만회 년 1 월 (12), 2011 .
  52. ^ "HTML Video Codec Support in Chrome". January 11, 2011. Retrieved January 12, 2011.
  53. ^ "Video, Mobile, and the Open Web". March 18, 2012. Retrieved March 20, 2012.
  54. ^ "WebRTC enabled, H.264/MP3 support in Win 7 on by default, Metro UI for Windows 8 + more – Firefox Development Highlights". hacks.mozilla.org. mozilla. February 20, 2013. Retrieved March 15, 2013.
  55. ^ "Firefox — Notes (35.0)". Mozilla.
  56. ^ "Open-Sourced H.264 Removes Barriers to WebRTC". October 30, 2013. Archived from the original on July 6, 2015. Retrieved November 1, 2013.
  57. ^ "Cisco OpenH264 project FAQ". October 30, 2013. Retrieved November 1, 2013.
  58. ^ "OpenH264 Simplified BSD License". October 27, 2013. Retrieved November 21, 2013.
  59. ^ "Video Interoperability on the Web Gets a Boost From Cisco's H.264 Codec". October 30, 2013. Retrieved November 1, 2013.
  60. ^ "Updated README · cisco/openh264@59dae50". GitHub.
  61. ^ "x264 4:0:0 (monochrome) encoding support", Retrieved 2019-06-05.
  62. ^ "x264 4:2:2 encoding support", Retrieved 2019-06-05.
  63. ^ "x264 4:4:4 encoding support", Retrieved 2019-06-05.
  64. ^ "x264 support for 9 and 10-bit encoding", Retrieved 2011-06-22.
  65. ^ "x264 replace High 4:4:4 profile lossless with High 4:4:4 Predictive", Retrieved 2011-06-22.
  66. ^ "Quick Reference Guide to generation Intel Core Processor Built-in Visuals". Intel Software Network. October 1, 2010. Retrieved January 19, 2011.
  67. ^ "Intel Quick Sync Video". www.intel.com. October 1, 2010. Retrieved January 19, 2011.
  68. ^ "Design-reuse.com". Design-reuse.com. January 1, 1990. Retrieved May 17, 2010.
  69. ^ "Category:DM6467 - Texas Instruments Embedded Processors Wiki". Processors.wiki.ti.com. July 12, 2011. Retrieved July 30, 2011.
  70. ^ "Briefing portfolio" (PDF). www.mpegla.com.
  71. ^ "OMS Video, A Project of Sun's Open Media Commons Initiative". Archived from the original on May 11, 2010. Retrieved August 26, 2008.
  72. ^ "Licensors Included in the AVC/H.264 Patent Portfolio License". MPEG LA. Retrieved June 18, 2019.
  73. ^ "AVC/H.264 – Patent List" (PDF). MPEG LA. Retrieved July 6, 2019.
  74. ^ "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. August 26, 2010. Retrieved August 26, 2010.
  75. ^ Hachman, Mark (August 26, 2010). "MPEG LA Cuts Royalties from Free Web Video, Forever". pcmag.com. Retrieved August 26, 2010.
  76. ^ "AVC FAQ". MPEG LA. August 1, 2002. Archived from the original on May 7, 2010. Retrieved May 17, 2010.
  77. ^ "Archived copy" (PDF). Archived from the original (PDF) on May 14, 2015. Retrieved November 20, 2018.CS1 maint: archived copy as title (link)
  78. ^ http://www.osnews.com/story/24954/US_Patent_Expiration_for_MP3_MPEG-2_H_264 has a MPEG LA patent US 7826532 that was filed in September 5, 2003 and has a 1546 day term extension. http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7826532 http://www.google.com/patents/about?id=2onYAAAAEBAJ
  79. ^ a b c See Qualcomm Inc. v. Broadcom Corp., No. 2007-1545, 2008-1162 (Fed. Cir. December 1, 2008). For articles in the popular press, see signonsandiego.com, "Qualcomm loses its patent-rights case" and "Qualcomm's patent case goes to jury"; and bloomberg.com "Broadcom Wins First Trial in Qualcomm Patent Dispute"

Further reading

External links