HLS 매니페스트와 비디오 연결하기

이 글은 HTTP 라이브 스트리밍(HLS)에 초점을 맞추고 있지만 기본 개념은 다른 HTTP 기반 스트리밍 프로토콜에도 유효합니다. HLS 프로토콜에 대한 자세한 설명은 이 글의 범위를 벗어나지만, 공개된 표준을 비롯한 다양한 정보를 온라인에서 확인할 수 있습니다: HTTP 라이브 스트리밍.

연결과 기존 방식

콘텐츠는 곧 가치이므로, 동영상 세계에서 더 많은 가치를 창출하는 한 가지 방법은 하나의 동영상을 촬영하고 다른 동영상과 혼합하여 새로운 콘텐츠를 만드는 것입니다. 이러한 작업은 여러 동영상을 연결하거나 여러 동영상을 이어 붙이는 기능을 통해 이루어지는 경우가 많은데, 이는 편집의 기본 형태입니다. 여기에 편집 목록을 통한 클립 생성 기능을 추가하면 비선형 편집기의 가장 기본적인 두 가지 기능을 사용할 수 있습니다.

연결은 유망해 보이지만 인프라와 운영 모두에 부담을 줄 수 있습니다. 소셜 비디오 포털을 상상해 보세요. 대상 디바이스에 따라 동영상당 몇 개에서 수십 개의 출력 형식이 있을 수 있습니다. 라이브러리의 가치를 확장하기 위해 여러 비디오를 연결하기로 결정하면 스토리지 비용과 자산 관리의 복잡성이 크게 증가하게 됩니다. 새로운 비디오 조합이 생성될 때마다 일련의 고정 자산이 생성되어 저장해야 합니다.

HTTP 라이브 스트리밍과 매니페스트 파일

매니페스트 기반 HTTP 기반 스트리밍 프로토콜의 도입으로 동적 시청 환경을 만들기 위한 완전히 새로운 패러다임이 만들어졌습니다. 기존에는 하나의 콘텐츠에서 여러 클립 조합을 전송할 수 있는 유일한 옵션은 편집, 즉 고정 자산 생성을 통한 것이었습니다. 재생 가능한 항목이 더 이상 비디오 파일이 아니라 단순한 텍스트 파일이기 때문에 HLS와 같은 기술을 사용하면 비디오를 편집하는 것은 워드 프로세서에서 문서를 편집하는 것과 동일합니다.

동영상 플랫폼의 경우, HLS m3u8 매니페스트 파일을 처리하는 방법에는 두 가지가 있습니다. 가장 간단하게는 m3u8 파일을 재생 가능한 개별 에셋으로 취급할 수 있습니다. 이 모델에서는 m3u8이 세그먼트화된 TS 파일과 함께 오리진 서버에 저장되어 디바이스에 전달됩니다. 결과는 간단하고 빠르게 구현할 수 있지만, m3u8 파일은 수동 프로세스를 통해서만 변경할 수 있습니다.

대신 매니페스트를 동적으로 생성되는 것으로 취급함으로써 시청자에게 사실상 무한한 클립 조합을 제공할 수 있습니다. 이 모델에서 m3u8은 즉석에서 생성되므로 서버에 저장되지 않고 요청이 있을 때마다 생성되어 전달됩니다.

동적 매니페스트 생성

매니페스트 파일이란 무엇인가요? 가장 기본적으로 매니페스트 파일은 일부 메타데이터와 동영상 세그먼트에 대한 링크의 조합입니다.

  • 예시 동영상 A
  • #EXTM3U
  • #EXT-X-MEDIA-SEQUENCE:0
  • #EXT-X-TARGETDURATION:10
  • #EXTINF:10,
  • Exemplary_A_segment-01.ts
  • #EXTINF:10,
  • Exemplary_A_segment-02.ts

위의 m3u8에는 각각 10초 길이의 동영상 세그먼트가 두 개 있으므로 총 동영상 길이는 20초입니다. 그런데 정말 훌륭한 동영상인 예시 동영상 A는 길이가 20초입니다. 이제 우리도 있다고 가정해 봅시다:

  • 예시 동영상 B
  • #EXTM3U
  • #EXT-X-MEDIA-SEQUENCE:0
  • #EXT-X-TARGETDURATION:10
  • #EXTINF:10,
  • Exemplary_B_segment-01.ts
  • #EXTINF:10,
  • Exemplary_B_segment-02.ts

또한 특정 시청자가 비디오 B를 먼저 실행하고 비디오 A를 두 번째로 실행하여 두 비디오를 조합하여 시청하는 것을 좋아할 것이라는 사실을 알고 있다고 가정해 보겠습니다:

  • 멋진 비디오
  • #EXTM3U
  • #EXT-X-MEDIA-SEQUENCE:0
  • #EXT-X-TARGETDURATION:10
  • #EXTINF:10,
  • Exemplary_B_segment-01.ts
  • #EXTINF:10,
  • Exemplary_B_segment-02.ts
  • #EXT-X-DISCONTINUITY
  • #EXTINF:10,
  • Exemplary_A_segment-01.ts
  • #EXTINF:10,
  • Exemplary_A_segment-02.ts

이제 원본에 저장해야 하는 영구 에셋을 만들지 않고, 새 에셋을 만들기 위해 편집기를 사용하지 않고도 즉시 비디오 B로 시작하여 비디오 A로 이어지는 새로운 비디오를 생성했습니다. 이 비디오는 마치 하나의 비디오인 것처럼 원활하게 재생됩니다.

m3u8에 작은 기능이 추가된 것을 눈치채셨을 겁니다:

EXT-X-불연속성

이 태그를 m3u8에 넣으면 플레이어가 다음 동영상 세그먼트가 이전 동영상과 다른 해상도 또는 다른 오디오 프로필을 가질 것으로 예상합니다. 동영상이 모두 동일한 해상도, 코덱 및 프로필로 인코딩된 경우 이 태그를 생략할 수 있습니다.

새 모델 확장

즉석에서 맞춤형 재생 경험을 제공할 수 있는 비디오 플랫폼을 만들기 위해서는 m3u8 매니페스트를 고정 자산이 아니라 요청에 따라 생성해야 하는 것으로 취급해야 합니다. 즉, 백엔드는 비디오의 모든 세그먼트의 위치, 항목당 총 세그먼트 수, 각 세그먼트의 길이를 알고 있어야 합니다.

이 작업을 더 간단하게 할 수 있는 방법이 있습니다. 예를 들어, 파일 이름을 일관되게 지정하면 모든 세그먼트에 대해 기본 파일 이름만 알면 되고 세그먼트 반복은 프로그래밍 방식으로 처리할 수 있습니다. 최종 세그먼트를 제외한 모든 세그먼트의 목표 길이가 같다고 가정할 수 있으므로 최종 세그먼트의 길이만 저장하면 됩니다. 따라서 여러 개의 동영상 세그먼트가 있는 단일 동영상 파일의 경우 기본 경로, 기본 파일 이름, 세그먼트 수, 평균 세그먼트 길이, 마지막 세그먼트 길이만 저장하면 됩니다.

긴 형식의 타이틀도 장면의 조합으로 간주하거나 더 나아가 장면을 샷의 조합으로 간주하면 동적 매니페스트 생성을 통해 얻을 수 있는 엄청난 양의 파워가 있습니다. 초기에 계획하고 구축하면 운영 또는 인프라 비용의 추가 증가 없이도 전송 플랫폼 아키텍처의 유연성을 크게 향상시킬 수 있습니다.

아비드 기술이 맞춤형 교육 기능을 만든 방법

브라이트코브 고객이 브라이트코브 기술을 어떻게 활용하고 구현을 통해 측정 가능한 이점을 실현하고 있는지 살펴보는 것은 언제나 흥미로운 일입니다. 우리의 세계와 그들의 세계가 본질적으로 연결되어 있기 때문에 Avid Technology가 브라이트코브를 어떻게 사용하는지 자세히 알아보는 것은 특히 재미있었습니다. 우리는 고객이 온라인 비디오 콘텐츠를 전달하고 관리하도록 지원하지만, Avid는 비디오 개발 과정에서 사용되는 크리에이티브 툴인 경우가 많습니다.

매사추세츠에 본사를 둔 또 다른 회사인 Avid는 비디오 및 오디오 제작 기술, 특히 디지털 비선형 편집 시스템, 관리 및 배포 서비스를 전문으로 합니다. 할리우드부터 매디슨 애비뉴에 이르기까지 다양한 크리에이티브 전문가들이 시각적 스토리텔링의 필요를 충족하기 위해 Avid의 제품군에 의존하고 있습니다. Avid는 1987년 설립 이래 기술 혁신을 통해 두 번의 오스카상, 그래미상, 14개의 에미상 등 수백 개의 상을 수상했습니다. 이 회사는 확실히 "비디오 크레딧"을 보유하고 있습니다.

그렇다면 Avid가 브라이트코브를 선택한 이유는 무엇일까요? Avid는 비디오 개발 분야의 전문가이지만, 비디오 배포 모범 사례를 위해 외부 전문가를 찾고 있었습니다. 고객 사례 연구에서는 Avid와 Brightcove의 관계에 대해 자세히 설명하지만, 이 포스팅을 통해 간략한 개요를 소개하고자 합니다.

Avid가 온라인 비디오에 발을 들여놓은 것은 2010년 봄, 비디오를 포함한 라이브 웹캐스팅 옵션을 조사하기 시작하면서부터입니다. 결국 Avid는 대화형 경험을 위해 채팅과 비디오를 모두 통합한 DIY 플래시 기반 웹캐스팅 솔루션을 개발했습니다. 이러한 노하우를 바탕으로 추가적인 온디맨드 시청 기능을 제공하고 향후 교육용 비디오 기능을 추가하는 데 도움이 될 온라인 비디오 플랫폼을 연구하기 시작했습니다.

2012년 3월, Avid는 온라인 동영상 플랫폼으로 브라이트코브를 선택했습니다. 그 이후로 Avid는 웹사이트 도움말 서비스에 동영상을 통합하여 사용자가 Avid 소프트웨어 내에서 작업하다가 궁금한 점이 생겼을 때 튜토리얼 동영상 콘텐츠로 안내하고 있습니다. 현재 Avid 팀은 비디오 콘텐츠 마케팅 자산을 모바일 기기에 최적화할 뿐만 아니라 쉽게 구성 및 관리할 수 있도록 비디오 클라우드에 마이그레이션하는 작업을 진행 중입니다. 향후 Avid는 브라이트코브를 활용하여 동영상 중심의 SEO를 개선하고 웹사이트에 사용자 제작 콘텐츠를 추가할 계획입니다.

온라인 동영상으로 고객 참여를 유도하는 PUMA

콘텐츠 마케팅 생태계에서 온라인 동영상이 브랜드가 고객과 지속적인 관계를 구축하는 데 어떤 역할을 하는지에 대해 자세히 설명한 적이 있습니다. 세계에서 가장 잘 알려진 신발 및 의류 브랜드 중 하나인 PUMA는 비디오의 힘과 고객과의 참여를 높이는 데 비디오가 어떻게 도움이 되는지 잘 이해하는 마케터의 좋은 예입니다.

PUMA는 전 세계에서 다양한 동영상 콘텐츠를 제작하고 게시하여 제품을 홍보하는 동시에 고객과 함께 여행을 떠날 수 있도록 합니다. PUMA는 최첨단 제품으로 유명하지만, 회사가 제품을 배치하는 맥락과 브랜드가 묘사하는 라이프스타일을 통해 브랜드가 진정으로 살아납니다. PUMA는 비디오를 고객 참여의 기회이자 고객에 맞는 멀티스크린 경험으로 안내하는 방법으로 활용하고 있습니다.

이 전략은 2012 런던 올림픽에서 크게 활용되었는데, 푸마는 라이브 비디오 콘텐츠를 통해 고객이 직접 또는 원격으로 소통할 수 있는 브랜드 환경을 조성하고 푸마가 후원하는 자메이카 육상 선수 우사인 볼트와 그의 100미터 및 200미터에서의 멋진 퍼포먼스에 맞춰 이벤트와 콘텐츠를 제공했습니다.

브라이트코브는 최근 PUMA의 디지털 전략 책임자인 제이 바스나이트(Jay Basnight)를 만나 회사의 비디오 전략과 비디오가 참여도를 높이는 데 미치는 영향에 대해 자세히 알아보았습니다. Jay는 비디오의 중요성과 PUMA가 성공을 측정하는 방법, 그리고 브라이트코브 비디오 플랫폼을 사용하여 전 세계에서 비디오 활동을 지원하는 방법에 대해 자세히 설명합니다.

브라이트코브와 함께 세일즈포스 벌크 API 및 에이펙스 코드 사용

브라이트코브에서는 고객 정보를 관리하기 위해 Salesforce를 사용합니다. 영업, 계정 관리, 지원 및 재무 팀에서도 영업 리드에게 연락하고, 지원 사례를 추적하고, 사용 보고서를 생성하는 등 다양한 활동에 Salesforce를 사용합니다. 고객 데이터를 적시에 안정적으로 Salesforce에 계속 푸시하는 것이 비즈니스에 중요합니다.

저희 제품의 데이터 모델은 사용자와 계정 간의 다대다 관계를 지원합니다. 계정 개체는 대규모 조직 내의 조직 또는 부서를 나타내며, 사용자 개체는 하나 또는 여러 조직에서 근무하는 개인을 나타냅니다. Salesforce에서는 기본 제공 연락처 개체를 사용자 지정하여 Brightcove 서비스의 각 사용자를 나타내며, 계정을 나타내는 사용자 지정 개체인 BCAccount를 정의합니다(그림 1 참조).

그림 1

그림 1. 브라이트코브 서비스 및 Salesforce의 데이터 모델

몇 년 전에 Salesforce SOAP API와 쿼츠를 사용하여 데이터 동기화 기능을 구축했는데, 이 구현에서 몇 가지 문제점을 발견했습니다. 크게 두 가지 어려움이 있었습니다:

  • 채팅이 너무 많아서 속도가 느립니다. 시간당 700개의 개체만 Salesforce에 동기화할 수 있습니다.
  • 데이터 모델을 변경하려면 많은 노력이 필요합니다. 개체에 새 필드를 추가하려면 Salesforce에서 새 WSDL 파일을 내보내고 WSDL 파일에서 Java 클래스를 생성해야 합니다.

이러한 어려움을 고려하여 Salesforce 벌크 API와 Apex 코드를 사용하여 새로운 동기화 시스템을 구축하기로 결정했습니다. 새로운 구현은 RedLine이라는 데이터 푸시 엔진과 RedLine에서 푸시된 대량 데이터를 처리하기 위한 일련의 Salesforce Apex 클래스로 구성됩니다.

그림 2

그림 2. 새로운 데이터 동기화

RedLine은 경량 루비 웹 서버인 Sinatra를 사용하여 다른 브라이트코브 서비스와는 독립적인 독립형 서비스로 구축되었습니다. RedLine은 루퍼스 스케줄러를 사용하여 RESTful API를 통해 Brightcove에서 생성, 업데이트, 삭제된 개체를 주기적으로 쿼리합니다. 그런 다음 RedLine은 JSON 응답을 CSV로 변환하여 Salesforce에 일괄 요청으로 보냅니다. Salesforce는 대량 요청당 10,000개의 개체로 제한되어 있는데, 저희의 사용량에는 충분했습니다. 대량 요청은 Salesforce에서 비동기적으로 처리되기 때문에, 브라이트코브 서비스나 RedLine 모두 데이터를 Salesforce로 전송한 후 기다릴 필요가 없습니다.

사용자 및 계정 개체를 Salesforce 개체에 맞게 조정하는 등 대량 요청을 처리하기 위해 몇 가지 Apex 클래스를 작성한 다음, Apex 클래스를 Salesforce에 배포하고 데이터가 대량 요청으로 도착하면 이러한 클래스를 실행하도록 Apex 배치 작업을 예약했습니다. 이러한 방식으로, Brightcove 서비스에는 Salesforce 데이터 모델에 대한 코드가 존재하지 않으며, Salesforce Apex 코드만 Salesforce 데이터 모델을 처리하면 됩니다. Salesforce는 대량 요청과 Apex 배치 작업 모두를 위한 모니터링 도구 세트를 제공합니다.

대량 요청을 처리하는 동안 오류가 발생하면 Salesforce 웹 UI에서 쉽게 확인할 수 있습니다. 또한 대량 요청이 예상된 주기로 도착하는지 확인하기 위해 주기적으로 실행되고, 요청이 한동안 도착하지 않으면 알림을 보내는 Apex 클래스를 배포했습니다.

새로운 동기화 시스템에서 사용자 또는 계정 개체의 새 필드를 변경하려면 Salesforce 사용자 지정 개체에 새 필드를 추가한 다음 Brightcove 서비스 API의 JSON 응답에 새 필드를 노출하기만 하면 됩니다. RedLine은 일괄 요청 시 JSON의 새 필드를 CSV의 새 열로 변환할 수 있을 만큼 스마트하기 때문에 개체 형식 변경을 위해 RedLine을 변경하거나 다시 시작할 필요가 없습니다.

계정 개체에는 네 가지 변경 사항이 있었고 사용자 개체에는 한 가지 변경 사항이 있었는데, 이러한 변경 사항으로 인해 RedLine 코드를 한 줄도 변경할 필요가 없었습니다. 이전 SOAP API 기반 동기화 시스템의 경우 사용자 또는 계정 개체에 대한 새 필드를 동기화하는 데 1~2주가 걸리곤 했습니다.

이 새로운 동기화 애플리케이션을 8개월 동안 프로덕션 환경에서 실행한 결과, 몇 번의 데이터 버스트 변경을 원활하게 처리하는 것을 확인했습니다. 최근 배포 중에 900개의 계정이 일괄 변경되었는데, 모든 계정이 1분 이내에 Salesforce에 동기화되었습니다(대부분의 시간은 Salesforce에서 실행 중인 Apex 클래스에서 소요됨). 이전 동기화 시스템에서는 같은 양의 개체를 동기화하는 데 1시간 이상 걸리곤 했습니다.

동영상 트랜스코딩에 GOOGLE 컴퓨트 엔진 사용

클라우드 컴퓨팅 업계에 종사하는 사람들에게 2012년 Google I/O에서 가장 흥미로운 소식은 글래스를 착용한 스카이다이버도, 새로운 태블릿도 아니었습니다. 가장 큰 뉴스는 현재 아마존 웹 서비스(AWS)가 주도하고 있는 클라우드 서비스형 인프라 영역에 구글이 뛰어든다는 것이었습니다. 특히 구글은 Amazon EC2와 경쟁하기 위해 구글 컴퓨트 엔진이라는 새로운 서비스를 출시했습니다.

이것은 흥미로운 일입니다. 세상에는 강력하고 성능이 뛰어나며 잘 설계된 또 하나의 클라우드 가상 머신 서비스가 필요합니다. 오랫동안 독주체제를 유지해 온 Rackspace와 다른 업체들에게 사과의 말씀을 드리자면, EC2는 단연 선두주자입니다. 구글이 이 분야를 계속 고수한다면 강력한 경쟁자가 될 수 있는 전문성과 규모를 갖춘 것은 분명합니다.

현재 상황은 어떤가요? 초기 보고는 긍정적입니다. 구글 컴퓨트 엔진(GCE)은 잘 설계되고, 잘 실행되며, 구글이 수년간 사용해 온 인프라를 기반으로 합니다. 특히 디스크 I/O, 부팅 시간, 일관성 등 그동안 EC2의 강점이 아니었던 성능이 우수합니다. 그렇다면 클라우드 비디오 트랜스코딩에 GCE가 얼마나 적합할까요? 더 많은 테스트가 필요하다는 점을 인정하면서 몇 가지 예비 결과가 있습니다. 다음은 GCE와 EC2 모두에서 Zencoder 소프트웨어를 사용한 비디오 트랜스코딩 및 파일 전송에 대한 몇 가지 기본 테스트입니다.

원시 트랜스코딩 속도

젠코더는 성능을 최우선으로 생각하기 때문에 가능한 가장 빠른 서버를 사용합니다. EC2에서는 두 가지 크기의 고속 듀얼 CPU 머신인 클러스터 컴퓨트 인스턴스를 사용합니다: 4XL과 8XL. 이를 현재 가장 빠른 GCE 인스턴스 유형인 단일 CPU 8코어 서버와 비교했습니다.

서버CPU
GCE 8코어인텔 제온(샌디 브리지 - 아마도 E5-2670) - 8코어 @ 2.60GHz
EC2 cc1.4xlarge듀얼 인텔 제온 X5570 - 8코어 @ 2.93GHz/코어
EC2 cc2.8xlarge듀얼 인텔 제온 E5-2670 - 16코어 @ 2.60GHz/코어

이 테스트는 640×360 및 1280×720 해상도의 H.264 소스 비디오를 사용하여 수행되었으며, 동일한 단일 패스 출력 트랜스코딩 설정(H.264 기준 프로파일, AAC, 원패스 일정 품질 트랜스코딩 등)을 사용하여 Zencoder로 인코딩했습니다.

구글 컴퓨트 엔진과 아마존 EC2

서버해상도동시 인코딩시간(초)천 명당 비용
EC2 cc1.4xlarge640×360615.87$0.96
EC2 cc2.8xlarge640×36069.93$1.10
GCE 8코어640×360621.05$1.13
GCE 8코어640×36016.01$1.94
EC2 cc1.4xlarge640×36015.96$2.15
EC2 cc1.4xlarge1280×720648.58$2.92
EC2 cc2.8xlarge640×36014.99$3.33
EC2 cc2.8xlarge1280×720630.74$3.42
GCE 8코어1280×720668.15$3.66
EC2 cc1.4xlarge1280×720112.89$4.65
GCE 8코어1280×720116.01$5.16
EC2 cc2.8xlarge1280×720110.92$7.28

기본 젠코더 설정을 사용하면 두 가지 유형의 EC2 인스턴스 모두 GCE보다 빠릅니다. 경제성은 조금 더 비슷하며 4XL EC2 인스턴스와 GCE 사이에 명확한 승자는 없습니다. 따라서 GCE는 원시 속도보다 비용이 더 우선시되는 트랜스코딩에 적합한 옵션이지만, AWS 고객은 예약 인스턴스 및 스팟 인스턴스를 사용하여 비용을 추가로 절감할 수 있습니다. 6개의 동시 트랜스코딩으로 부하가 걸렸을 때 16코어 EC2 인스턴스가 GCE 8코어 인스턴스보다 약 2배 더 빠르다는 것을 확인했습니다.

클럭 속도는 비슷하지만 코어 수가 절반이라는 점을 감안하면 예상할 수 있는 결과입니다. 하지만 구글이 비슷한 16코어 머신을 추가한다면 비슷한 수준의 트랜스코딩 속도를 낼 수 있습니다.

전송 속도

클라우드에서 동영상을 트랜스코딩할 때 네트워크 I/O는 CPU만큼이나 중요합니다. 특히 비트레이트가 높은 콘텐츠를 다루는 고객(방송사, 스튜디오, 크리에이티브 업체)에게는 더욱 그렇습니다. 그렇다면 GCE 전송 속도는 EC2와 비교해 어떤 차이가 있을까요? 이를 테스트하기 위해 네 가지 벤치마크 세트를 실행했습니다:

  • Amazon S3에서 Amazon EC2로
  • Amazon S3에서 Google 컴퓨팅 엔진으로
  • Google 클라우드 스토리지에서 Amazon EC2로
  • 구글 클라우드 스토리지에서 구글 컴퓨팅 엔진으로

Google 클라우드 스토리지(GCS)와 Amazon S3에 저장된 동일한 1GB 동영상 파일을 테스트했습니다. 전송은 10개의 HTTP 연결을 사용하여 수행되었습니다(Zencoder는 전송 속도를 최적화하기 위해 기본적으로 이 작업을 수행하며, HTTP를 통한 대용량 파일 전송 속도를 크게 높일 수 있습니다).

GCE와 EC2 전송 속도 비교

 전송 속도(Mbps)서버 대역폭
S3에서 GCE로470.961Gbps
S3 ~ EC2 c1.xlarge644.291Gbps
S3 ~ EC2 cc2.8xlarge1458.3210Gbps
GCS에서 GCE로202.601Gbps
GCS에서 EC2 c1.xlarge로 전환378.281Gbps
GCS에서 EC2 cc2.8xlarge로 전환641.3410Gbps

흥미롭습니다. 아마존에서 아마존으로의 전송이 빠를 것으로 예상했는데 실제로는 빨랐습니다. 하지만 구글과 구글 간 전송도 빠를 것으로 예상했지만 그렇지 않았습니다. 실제로 GCS는 S3보다 느리고, GCE 전송은 EC2보다 느린 것으로 나타나, 컴퓨팅에 Google을 사용하더라도 스토리지에는 S3를 사용하는 것이 더 나을 수 있습니다. 전송 속도는 GCS에서 GCE로 전송하는 것보다 S3에서 GCE로 전송하는 것이 2.3배 더 빨랐습니다.

더 필요한 테스트

이 결과는 예비적인 결과라고 생각하세요. 더 많은 변수를 고려하기 위해 추가 테스트가 필요합니다.

  • 인스턴스 간 차이. 이는 특히 네트워크 상태와 인스턴스 가변성에 따라 크게 달라질 수 있는 파일 전송의 경우 더욱 그렇습니다.
  • 추가 애플리케이션. 이 벤치마크는 CPU 기반 벤치마크인 트랜스코딩만 다룹니다. 다른 애플리케이션은 디스크, 메모리 등에 의해 제한되며 이러한 테스트는 트랜스코딩 이외의 다른 항목에 대해서는 언급하지 않습니다.
  • 확장성. 확장성은 비디오 트랜스코딩에 클라우드를 사용하는 모든 사용자에게 매우 중요한 요소입니다. 수만 대 이상의 서버를 사용하는 엄청난 규모에서 GCE가 EC2와 어떻게 비교되는지 확인하려면 더 많은 테스트가 필요합니다. 사용자는 어느 시점에서 용량 문제에 직면하나요? 성능 문제? 설계상의 한계? 불안정성?

클라우드 인프라의 미래

이 초기 테스트에서는 EC2가 승리했지만, 저희는 Google Compute Engine에 대해 기대가 큽니다. 고성능 트랜스코딩의 진정한 경쟁자가 되려면 더 빠른 CPU를 갖춘 더 큰 인스턴스를 추가해야 합니다. 하지만 새로운 인스턴스 유형을 추가하는 것은 쉽습니다. 구글이 이를 방해하는 것은 아무것도 없습니다. 어려운 것은 강력하고 성능이 뛰어나며 기능이 완벽하고 확장 가능한 클라우드 플랫폼을 구축하는 것인데, Google은 이미 성공한 것으로 보입니다. Google이 장기적으로 이 제품과 개발자에 전념한다면 클라우드 가상화 세계는 이제 막 두 번째 합법적인 플레이어를 얻었을지도 모릅니다.

웹, 모바일 및 커넥티드 TV를 위한 자막 서비스

선택 캡션은 접근성과 유용성을 위해 좋은 일이며, 인터넷 동영상이 성숙 단계로 나아가는 또 하나의 이정표입니다. 안타깝게도 선택 캡션은 "켜기"만 하면 되는 하나의 기술이나 동영상 "기능"이 아닙니다. 여러 가지 형식, 표준 및 접근 방식이 있습니다.

자막은 다른 디지털 동영상과 마찬가지로 다소 복잡하며, 특히 멀티스크린 퍼블리셔에게는 어려운 작업입니다. 그렇다면 지금 웹, 모바일 및 커넥티드 TV용으로 동영상을 퍼블리시하려면 선택 자막에 대해 무엇을 알아야 할까요?

이 게시물에서는 선택 자막의 작동 방식, 알아야 할 형식, 모든 화면에서 선택 자막을 활성화하는 방법 등 기본 사항을 간략하게 설명합니다.

선택 자막 작동 방식

가장 먼저 이해해야 할 것은 선택 자막이 전달, 저장 및 읽히는 방식입니다. 오늘날에는 크게 두 가지 접근 방식이 있습니다.

  • 동영상에 임베드. CEA-608, CEA-708, DVB-T, DVB-S, WST. 이러한 캡션 형식은 비디오 파일에 데이터 트랙으로 직접 작성되거나 비디오 스트림 자체에 임베드됩니다. 방송 텔레비전은 iOS와 마찬가지로 이 방식을 사용합니다.
  • 별도의 파일로 저장됩니다. DFXP, SAMI, SMPTE-TT, TTML, EBU-TT(XML), WebVTT, SRT(텍스트), SCC, EBU-STL(바이너리). 이러한 형식은 캡션 정보를 동영상 자체에 삽입하지 않고 동영상과 함께 플레이어에게 전달합니다. 이 접근 방식은 일반적으로 브라우저 기반 동영상 재생에서 사용됩니다.

자막과 선택 자막의 차이점

자막은 어떻게 되나요? 자막도 선택 캡션과 같은 것일까요? 세 가지 주요 차이점이 있는 것으로 밝혀졌습니다.

  • 목표. 자막은 청각 장애인이 동영상을 이용할 수 있도록 하는 접근성 기능으로, 누가 말하고 있는지 또는 어떤 소리가 나는지에 대한 단서(예: "문이 두드려지고 있습니다")를 포함할 수 있습니다. 자막은 국제화 기능으로, 구어를 이해하지 못하는 사람들도 동영상을 이용할 수 있도록 합니다. 즉, 음소거 상태로 동영상을 시청할 때는 캡션을 사용하고, 모르는 언어로 된 동영상을 시청할 때는 자막을 사용하는 것입니다. 참고: 북미에서는 이러한 구분이 적용되지만, 전 세계 대부분의 국가에서는 선택 캡션과 자막을 구분하지 않습니다.

  • 스토리지. 지금까지 캡션은 동영상 내에 삽입하고 자막은 외부에 저장해 왔습니다(아래 CEA-608 참조). 캡션은 항상 동영상과 함께 제공되어야 하고 청각 장애인을 위한 100% 접근성이 법으로 의무화되어 있기 때문에 개념적으로 합리적입니다. 자막은 경우에 따라 필요하지만, 독일에서 방송되는 독일어 동영상에는 독일어 자막을 포함할 필요가 없지만 프랑스에서 방송되는 동일한 동영상에는 자막을 포함해야 합니다.

  • 재생. 자막은 동영상과 함께 전달되어 TV 또는 기타 소비자 디바이스에서 해석/표시되므로 시청자는 언제든지 TV 자체에서 자막을 켜고 끌 수 있지만 언어를 선택할 수 있는 옵션이 거의 없습니다. 번역 목적으로 자막을 추가하는 경우 일반적으로 하드 자막(아래 참조)이므로 비활성화할 수 없습니다. 그러나 DVD/블루레이/VOD 비디오를 볼 때는 재생 장치에서 자막 표시 여부와 자막 언어를 제어합니다.

형식 및 표준

자막 및 자막에는 수십 가지 형식과 표준이 있습니다. 다음은 인터넷 동영상에 가장 중요한 포맷을 요약한 것입니다.

  • CEA-608. 라인 21이라고도 하는 CEA-608 캡션은 미국과 캐나다의 아날로그 TV에서 사용하는 NTSC 표준입니다. 라인 21 캡션은 방송 재생 장치에서 비디오 스트림의 숨겨진 영역에 직접 인코딩됩니다. 프로그램 상단에 흰색 막대와 점이 있는 것을 본 적이 있다면 이것이 바로 21번 라인 캡션입니다.
  • SCC. 이 파일에는 시나리오스트 선택 자막 형식의 캡션이 포함되어 있습니다. 여기에는 해당 인코딩된 캡션 데이터와 함께 CEA-608 데이터의 표현으로 SMTPE 타임코드가 포함되어 있습니다.
  • CEA-708. 이는 미국과 캐나다의 ATSC 디지털 텔레비전(DTV) 스트림에 대한 선택 자막 표준입니다. 현재 비디오 스트림 외에 CEA-708 캡션을 저장할 수 있는 표준 파일 형식은 없습니다.
  • TTML. 시간 제한 텍스트 마크업 언어는 텍스트와 오디오 또는 비디오와 같은 기타 미디어의 동기화를 설명합니다. 자세한 내용은 W3C TTML 권장 사항을 참조하세요.
  • DFXP. 이것은 W3C에서 정의한 TTML의 프로파일입니다. DFXP 파일에는 캡션 데이터를 표시하는 시기와 방법을 정의하는 TTML이 포함되어 있습니다. DFXP는 배포 형식 교환 프로필의 약자입니다. DFXP와 TTML은 종종 동의어로 사용됩니다.
  • SMPTE-TT. 영화 및 텔레비전 엔지니어 협회 - 시간 제한 텍스트는 다른 캡션 형식 및 정보 항목에는 있지만 DFXP에는 없는 세 가지 확장자에 대한 지원을 추가하는 DFXP 프로필의 확장입니다: #데이터, #이미지, #정보입니다. SMPTE-TT는 FCC 세이프 하버 형식이기도 합니다. 동영상 콘텐츠 제작자가 이 형식의 캡션을 배포자에게 제공하면 접근 가능한 형식의 캡션을 제공해야 하는 의무를 충족한 것입니다. 그러나 동영상 콘텐츠 제작자와 배포자는 자유롭게 다른 형식에 합의할 수 있습니다.
  • SAMI. 동기화된 접근 가능한 미디어 교환은 HTML을 기반으로 하며 Microsoft에서 Microsoft Encarta Encyclopedia 및 Windows Media Player와 같은 제품을 위해 개발했습니다. SAMI는 여러 데스크톱 동영상 플레이어에서 지원됩니다.
  • EBU-STL. EBU 표준에서 사용하는 바이너리 형식으로, 별도의 .STL 파일에 저장됩니다.
  • EBU-TT. 이것은 TTML에 기반하여 EBU에서 지원하는 최신 형식입니다. EBU-TT는 TTML의 엄격한 하위 집합으로, EBU-TT 문서는 유효한 TTML 문서이지만 일부 TTML 문서는 EBU-TT에서 지원하지 않는 기능을 포함하고 있기 때문에 유효한 EBU-TT 문서가 아님을 의미합니다.
  • SRT. 동영상에서 캡션 또는 자막을 추출하기 위한 Windows 기반 오픈 소스 도구인 SubRip에서 만든 형식입니다. SRT는 데스크톱 동영상 플레이어에서 널리 지원됩니다.
  • WebVTT. 이것은 SRT와 유사한 텍스트 형식입니다. 웹 하이퍼텍스트 애플리케이션 기술 워킹 그룹(WHATWG)은 HTML5 동영상 선택 자막의 표준으로 WebVTT를 제안했습니다.
  • 하드 자막. 하드자막은 정의상 선택 자막이 아닙니다. 하드자막은 동영상 자체에 인코딩된 오버레이 텍스트이므로 선택 자막이나 소프트자막과 달리 켜거나 끌 수 없습니다. 가능하면 소프트 자막이나 선택 자막을 사용하는 것이 좋지만 선택 자막을 지원하지 않는 디바이스나 플레이어를 대상으로 할 때는 하드 자막을 사용하는 것이 유용할 수 있습니다.

모든 디바이스를 위한 캡션

어떤 디바이스와 플레이어가 어떤 포맷을 사용하나요?

  • HTML5. 캡션은 아직 브라우저에서 널리 지원되지 않지만 시간이 지남에 따라 변경될 것입니다. 두 가지 경쟁 표준이 있습니다: W3C에서 제안한 TTML과 WHATWG에서 제안한 WebVTT입니다. 현재 Chrome은 WebVTT를 제한적으로 지원하며, Safari, Firefox, Opera는 모두 WebVTT 지원을 위해 노력하고 있고, Internet Explorer 10은 WebVTT와 TTML을 모두 지원합니다. 브라우저에서 기본적으로 형식을 지원하기 전까지는 Video.js와 같은 HTML5 플레이어 프레임워크가 외부 파일을 파싱하여 자바스크립트를 통해 캡션을 지원할 수 있습니다(Video.js는 현재 WebVTT 캡션을 지원합니다).
  • iOS. Apple은 다른 접근 방식을 취하여 수정된 버전의 CEA-708/ATSC 레거시 인코딩을 사용하여 CEA-608 캡션을 사용합니다. 즉, HTML5와 달리 트랜스코딩 시 캡션을 추가해야 합니다. 브라이트코브 젠코더는 iOS용 HTTP 라이브 스트리밍 동영상에 캡션을 추가할 수 있습니다.
  • Android. 동영상 플레이어 지원은 여전히 단편적이고 문제가 많습니다. 캡션 지원은 OS 버전과 사용하는 플레이어에 따라 달라질 수 있습니다.
  • 기타 모바일 디바이스. 일부 기기는 자막을 전혀 지원하지 않으며, 하드 자막이 유일한 옵션일 수 있습니다.
  • Roku. 외부 SRT 파일을 통한 캡션을 지원합니다.
  • 기타 커넥티드 TV 플랫폼. 아직 자막을 지원하지 않는 플랫폼도 있습니다. 하지만 곧 지원하게 될 것입니다. 현재 시장에 출시된 모든 TV, 콘솔, 케이블 박스, 블루레이 플레이어는 인터넷 콘텐츠 스트리밍을 원하고 있으며, 향후 1년 반 동안 선택 자막은 필수 사항이 될 것입니다. 따라서 소니, 삼성, 비지오, 구글 TV 등은 결국 캡션 지원을 애플리케이션 개발 프레임워크의 일부로 포함시킬 것입니다. 안타깝게도 어떤 형식이 사용될지는 아직 명확하지 않습니다. 앞으로도 여러 플랫폼에서 호환되지 않는 다양한 포맷을 계속 지원할 가능성이 높습니다.

자막 요구 사항

선택 자막의 환경은 시간이 지남에 따라 변화하고 성숙해지겠지만 2012년 현재 일반적인 디바이스에서 선택 자막을 지원하기 위한 가장 일반적인 요구 사항은 다음과 같습니다.

  • 자막을 활성화 및 비활성화할 수 있는 플레이어 측 컨트롤이 있는 웹 플레이어입니다.
  • 캡션 데이터가 포함된 외부 파일(WebVTT, TTML 또는 SRT 등의 형식을 사용할 수 있음). 파일이 두 개 이상 필요할 수 있습니다(예: Roku용 SRT 및 HTML5용 WebVTT).
  • Zencoder와 같이 iPad/iPhone 전송용 HTTP 라이브 스트리밍을 위한 임베디드 폐쇄 자막을 지원하는 트랜스코더입니다. Zencoder는 TTML을 포함한 다양한 형식의 캡션 정보를 받아들일 수 있으므로 퍼블리셔는 웹 재생과 iOS 동영상용 Zencoder의 입력으로 단일 TTML 파일을 사용할 수 있습니다.

그 이후에는 상황이 어려워집니다. 다른 디바이스에서는 다른 입력 형식이 필요할 수 있으며, 레거시 디바이스 간 100% 호환을 위해서는 하드 자막이 필요할 수도 있습니다.

브라이트코브 젠코더 및 캡션

브라이트코브 젠코더는 두 가지 형식의 자막을 지원합니다: HLS를 사용하는 iOS 디바이스용 CEA-608 스타일 자막과 CEA-608 캡션 트랙이 포함된 MP4 파일입니다. 입력 측면에서는 MP4 파일에서 SCC, SAMI, DFXP/TTML/SMPTE-TT 및 CEA-608 캡션 트랙을 지원합니다.

지금까지는 임베디드 캡션에 집중하기로 결정했는데, 이는 이러한 형식이 트랜스코딩 시점에 동영상 파일에 추가되기 때문입니다. 따라서 iPad 또는 iPhone용 캡션을 지원하지 않으면 이러한 디바이스에 게시하는 고객은 선택 캡션을 사용할 수 없습니다. 향후에는 허용되는 캡션 형식의 범위를 확대하고 외부 캡션 파일에 대한 형식 변환(예: TTML에서 WebVTT로)과 같은 서비스를 제공할 수 있습니다.

한편, 브라이트코브 고객은 하나의 자막 파일과 적합한 HTML5 플레이어만 있으면 웹, 모바일 및 커넥티드 TV 디바이스용 자막 동영상을 제작하는 데 필요한 모든 것을 갖출 수 있습니다.

앱 클라우드: 웹 개발자의 경험 보고서

웹 개발자이자 디자이너로 13년 동안 일하면서 저는 Java부터 시작해서 PHP, 이후 Ruby에 이르기까지 새로운 기술에 쉽게 적응해 왔습니다. 오랫동안 '플래시 증기선'에 몰두하면서 빠르게 진화하는 웹 표준을 최신 상태로 유지하면서 프로토타입과 jQuery 같은 주요 UI 라이브러리를 탐구했습니다.

하지만 많은 웹 개발자와 마찬가지로 저도 모바일 애플리케이션으로의 도약을 놓쳤습니다. C++나 Objective-C 같은 저수준 언어에 대한 경험도 부족했고 배울 시간도 없었기 때문입니다. 부피가 크고 광범위하다고 생각했던 Java로 '작은' 앱을 만든다는 생각도 마찬가지로 매력적이지 않았습니다.

여러 크로스 플랫폼 개발 도구를 살펴봤지만 기대에 미치지 못하는 경우가 많았습니다:

  • 사전 구축된 템플릿으로 RSS 피드를 래핑하는 앱 '팩토리'는 영감을 받지 않은 일반적인 앱을 만들었습니다.
  • 자바스크립트나 액션스크립트를 네이티브 코드로 변환하는 프레임워크는 앱 제작 및 컴파일을 위한 복잡한 툴체인이 필요했습니다.
  • 웹 페이지를 네이티브 셸로 래핑하는 프레임워크는 프로덕션 환경에서 데이터 기반 앱을 배포하기 위한 인프라를 거의 제공하지 못했습니다.

HTML, CSS, JavaScript를 사용하여 네이티브 모바일 앱을 제작하는 프레임워크인 App Cloud를 처음 발견했을 때는 회의적이었습니다. 다른 프레임워크와 다를 게 있을까? 약속을 지킬 수 있을까요? 첫 번째 앱을 개발한 후, 저는 자신 있게 "그렇다!"라고 말할 수 있습니다. 그 이유는 다음과 같습니다.

개발자의 언어로 말하는 앱 클라우드

App Cloud는 웹 개발자의 핵심 기술에 의존합니다: 콘텐츠를 구성하는 HTML, 모양을 지정하는 CSS, 편집하는 JavaScript가 바로 그것입니다. 콘텐츠 중심의 풍부한 앱을 만들기 위해 새로운 언어를 배울 필요가 없습니다. 웹 기술은 항상 단순함에서 탁월했습니다. iOS에서 표 보기를 만드는 복잡성과 기본 HTML 목록을 만드는 간편함을 비교해 보세요.

또한 App Cloud SDK는 거의 모든 JavaScript 라이브러리를 지원하므로 수년간 웹 개발을 통해 익힌 기법을 적용할 수 있습니다.

앱 클라우드로 빠른 차선에서

저는 코딩할 때 BBEdit와 vim을 자주 전환하는데, 여전히 가장 편한 도구이기 때문입니다. App Cloud를 사용하면 익숙한 편집기를 계속 사용할 수 있습니다. 표준 웹 기술을 기반으로 하기 때문에 Chrome 개발자 도구로 코드를 디버그하고 테스트할 수도 있습니다. XCode나 Eclipse에 묶여 있는 번거로운 시스템과 달리 App Cloud는 유연성과 자유를 제공합니다.

워크샵 앱으로 빠른 반복 작업

iOS 및 Android용 App Cloud 워크샵 앱을 사용하면 개발 중에 실시간으로 테스트할 수 있습니다. 코드를 변경한 후 '새로 고침'을 클릭하기만 하면 업데이트 내용을 즉시 확인할 수 있습니다. 코딩, 새로 고침, 반복과 같은 반복적인 프로세스에 익숙한 웹 개발자에게는 이 기능이 매우 유용합니다.

데스크톱 브라우저에서 많은 테스트를 수행할 수 있지만, 실제 기기에서 앱이 어떻게 작동하는지 확인하는 것만큼 좋은 것은 없습니다. 워크샵 앱을 사용하면 이 작업을 쉽고 원활하게 수행할 수 있습니다.

디바이스별 기능 활용

App Cloud는 카메라나 사진 라이브러리와 같은 디바이스별 기능에 액세스할 수 있는 간단한 JavaScript API를 제공합니다. 예를 들어 QR 코드를 스캔하는 것만큼이나 간단합니다:

bc.device.getQRCode(
function (data) { /* handle success */ },
function (error) { bc.device.alert("Oops! " + error.errorMessage); }
);

간소화된 앱 컴파일

Android 개발자 키트와 같은 다른 도구를 사용하여 앱을 컴파일하는 것은 종종 지루하고 답답하게 느껴지는 IKEA 가구를 조립하는 것과 같은 느낌을 줍니다. App Cloud Studio를 사용하면 몇 번의 클릭만으로 클라우드에서 앱을 컴파일할 수 있습니다. 특별한 도구 없이도 몇 분 안에 앱을 다운로드하고 다양한 앱 스토어에 배포할 준비가 완료됩니다.

콘텐츠 최적화: 적을수록 좋습니다

콘텐츠 중심 앱에서는 콘텐츠 자체가 병목 현상이 발생하는 경우가 많습니다. App Cloud는 다음과 같이 성능을 최적화합니다:

  • 불필요한 데이터를 제거하고, 피드를 압축하고, 콘텐츠를 캐싱합니다. 예를 들어, 제 블로그 피드는 39KB에서 4KB로 줄어들어 90% 감소했습니다.
  • 이미지 트랜스코딩으로 파일 크기 줄이기. 이미지 하나가 425픽셀 너비 125KB에서 200픽셀 너비 8KB로 94% 감소했습니다.

이러한 최적화를 통해 사용자 참여에 중요한 로딩 시간이 크게 개선되었습니다.

배포를 넘어선 유연성

다른 도구와 달리 App Cloud Studio를 사용하면 앱을 다시 컴파일하거나 재배포할 필요 없이 배포 후 데이터, 디자인 및 설정을 수정할 수 있습니다. 이러한 유연성 덕분에 데이터 피드를 교체하고 설정을 조정하여 단일 템플릿에서 여러 개의 앱을 만들 수 있습니다.

간편한 협업

App Cloud를 사용하면 동료와 앱을 간편하게 공유할 수 있습니다. 워크샵 앱에서 바로 스크린샷을 공유하거나 URL 또는 QR 코드를 통해 템플릿을 배포할 수 있어 효율적인 협업과 테스트가 가능합니다.

포괄적인 클라우드 관리

App Cloud는 네이티브 광고 게재부터 실시간 분석에 이르기까지 앱을 관리하고 수익을 창출하는 데 필요한 모든 것을 제공합니다. 설치 수, 사용 시간 및 기타 주요 지표를 추적할 수 있습니다.

또한 App Cloud는 성능 향상 및 기능 업데이트를 무료로 제공합니다. 푸시 알림 및 인앱 구매와 같은 향후 개선 사항은 플랫폼을 더욱 강력하게 만들 것입니다.

App Cloud는 웹 개발의 간편함과 네이티브 앱의 기능을 결합하여 효율적이고 확장 가능하며 매력적인 모바일 앱을 만들고자 하는 개발자에게 필수적인 도구입니다.

완벽한 아이패드/아이폰 동영상을 위한 인코딩 설정

진지한 동영상 퍼블리셔라면 이미 iPad와 iPhone을 지원하고 있거나 지원 추가에 대해 깊이 고민해야 합니다. 일부 주요 퍼블리셔의 경우, iPad 전송이 전체 동영상 조회수의 3분의 1 이상을 차지합니다.

하지만 iOS용 인코딩은 약간 까다롭습니다. 이러한 디바이스는 여러 세대에 걸쳐 기술적으로 발전해 왔으며, iPhone 4에 이상적인 동영상 설정은 iPhone 3GS나 iPad에는 적합하지 않습니다.

다행히도 몇 가지 인코딩 프로필만 있으면 최초의 iPhone부터 iPad 2까지 모든 iOS 디바이스에 고화질 동영상을 스트리밍할 수 있으며, 차세대 모바일 하드웨어에 대비할 수도 있습니다.

일반 설정

오늘날 대부분의 동영상과 마찬가지로 iOS를 타겟팅할 때는 h.264 동영상과 AAC 오디오를 사용합니다.

On the audio side, consider using HE-AAC at <64kbps, for App Store compliance. HE-AAC sounds reasonably good at these bitrates, even for complex audio.

동영상 쪽에서는 여러 프로필을 사용하여 각 디바이스를 타겟팅합니다. iPhone 3GS 및 이전 버전에서는 h.264 기본 프로필인 레벨 3.0만 지원하지만(일부는 이보다 더 제한된 버전을 지원함), 최신 디바이스는 기본 및 고급 프로필을 지원합니다.

최상의 사용자 경험을 위해서는 HTTP 라이브 스트리밍(HLS)이 필수입니다. Apple은 App Store에서 10분 이상의 콘텐츠를 재생하는 모든 동영상 앱에 이 기능을 요구하고 있으며, iOS에서 지원하는 유일한 진정한 스트리밍 형식입니다. Android(버전 3 이상), Roku 및 기타 다양한 대상에서도 HLS를 채택하고 있습니다.

일반적인 접근 방식

해상도프로필비트 전송률@ 16:9@ 4:3오디오댓글
1024×768[email protected]2Mbps1024×5761024×76856kbps HE-AAC 
960×640[email protected]1.5Mbps960×540854×64056kbps HE-AAC 
640×432[email protected]1Mbps640×360576×43256kbps HE-AAC 
480×320[email protected]600kbps480×272426×32056kbps HE-AAC 
400×288[email protected]400kbps400×224384×28856kbps HE-AAC 
400×288[email protected]200kbps400×224384×28856kbps HE-AAC디세이트 프레임 속도
해당 없음(오디오만 해당)    56kbps HE-AAC 

이러한 권장 사항이 필요한 이유는 무엇인가요?

  • 이는 권장 사항일 뿐입니다. 다른 해상도와 비트레이트는 완벽하게 유효하며 일부 상황에서는 실제로 더 나은 해상도와 비트레이트가 더 바람직할 수 있습니다. 예를 들어 매우 복잡한 콘텐츠의 경우 더 높은 비트레이트가 필요할 수 있습니다.
  • 720p는 iPad 1과 iPhone 4에서 재생할 수 있는 최대 동영상이며, iPad 2/iPhone 4S는 최대 1080p까지 재생할 수 있습니다. 하지만 기본 디스플레이의 너비가 1024픽셀에 불과하기 때문에 720p나 1080p까지 가는 것은 중요하지 않습니다. 물론 다른 곳에서 동영상을 재사용하려는 경우가 아니라면 720p는 전체 화면 웹 재생에 적합한 해상도이며 1080p는 커넥티드 TV에 전적으로 적합합니다. 향후 출시될 iPad의 해상도는 현재 iPad의 4배에 달할 것이라는 소문이 있으므로 미래를 대비하여 720p를 추가하는 것이 좋습니다.
  • h.264 프로필이 중요합니다. iPad 1과 iPhone 4는 모두 메인 프로필을 지원합니다. 아이패드 2/아이폰 4S는 메인 프로파일보다 약간 나은 하이 프로파일을 지원하지만, 전 세계 아이패드 1 디바이스 수를 고려할 때 메인 프로파일을 사용하는 것이 좋습니다. 진정으로 최적의 디바이스 타겟팅을 위해서는 메인과 높음 모두로 인코딩하세요.
  • 이 여섯 가지 해상도와 비트레이트는 다양한 대역폭을 합리적으로 잘 커버합니다. 물론 더 많은 해상도와 프로필을 원하는 대로 추가하거나 뺄 수 있습니다.
  • 기존 iPhone/iPod Touch 사용자는 480×320 화질의 동영상(이러한 디바이스의 화면 해상도)을 포함하여 3개의 스트림을 사용할 수 있습니다. iPad 및 iPhone 4 사용자는 6개의 스트림을 모두 사용할 수 있습니다.
  • iPad의 해상도 스케일러는 꽤 좋은 편이므로 해상도를 조정한 동영상은 일반적으로 잘 보입니다.
  • 이 설정은 가능한 한 16으로 나눌 수 있는 해상도 크기를 허용합니다. 이렇게 하면 압축 효율이 더 높아집니다. 특히 고해상도에서는 효율성 향상 효과가 작지만, 저해상도에서는 차이가 나타나기 시작합니다.
  • 각 동영상에서 오디오를 동일하게 유지해야 합니다. 오디오 사양이 버전 간에 변경되면 스트림을 전환할 때 재생 중에 '펑'하는 소리와 딸깍하는 소리가 들릴 수 있습니다.

기타 설정

  • 원하는 처리 시간을 기준으로 속도를 설정합니다. 이 권장 사항에서는 기본값보다 압축률이 약간 향상되지만 여전히 상당히 빠른 속도인 속도 2를 사용하겠습니다.
  • 피크를 사용하여 각 세그먼트의 크기가 거의 같은지 확인합니다. bitrate\_cap 목표 비트 전송률의 150% 이내이지만, 길게는 buffer\_size (예: 5초 또는 5배의 bitrate\_cap).
  • 유형을 "세그먼트"로 설정하면 브라이트코브가 자동으로 적절한 키프레임 배치를 선택합니다. MP4로 인코딩하여 HLS로 별도 세그멘테이션하는 경우에는 forced\_keyframe\_rate 를 "0.2" 또는 "0.1"로 설정합니다(각각 5초 또는 10초 키프레임 간격).
  • 약간 예측할 수 없는 비트레이트를 받아들일 수 있다면, 믹스에 품질을 추가하고 다음을 변경하십시오. video\_bitrate 에 max\_video\_bitrate 를 설정하여 파일 크기에 맞게 최적화할 수 있습니다. 인코더는 필요한 경우 최대 비트 전송률을 사용하고, 더 적은 비트로 원하는 화질을 얻을 수 있는 경우 더 낮은 비트 전송률을 사용합니다.
  • 설정 max\_frame\_rate 을 30으로, 그리고 max\_audio\_sample\_rate 를 48000으로 설정합니다.
  • iOS 기기에서 하나의 h.264만 허용하는 경우 1세대 reference\_frame를 사용하므로 호환성을 극대화하려면 베이스라인 스트림에서 이 기능을 활성화하세요.

브라이트코브 비디오 클라우드와 구글 애널리틱스 통합

이 도움말에서는 Google 애널리틱스를 사용하여 동영상을 측정할 수 있는 Google 애널리틱스 연동 프로그램에 대해 소개합니다. Google 애널리틱스 통합 프로그램은 비디오 클라우드 계약을 체결하고 이미 Google 애널리틱스를 사용하고 있는 경우에 사용할 수 있습니다.