인터 하이에서 100개의 동시 라이브 스트림 진행

라이브 생방송의 미드롤 광고

스포츠 커뮤니케이션즈는 인터넷 스포츠 미디어 '스포츠 불'(약칭 '스포부')을 운영하는 회사입니다. 60개 이상의 미디어 매체와 파트너십을 맺고 있으며 40개 이상의 스포츠를 다루고 있습니다. 야구, 축구 등 팬층이 두터운 스포츠뿐만 아니라 지금은 비인기 종목이지만 팬층 확대를 원하는 스포츠에 대한 상세한 정보도 다루고 있어 이용자 수가 빠르게 증가하고 있습니다. 이벤트 기간에는 시청자와 방문자 수가 급격히 증가해 2018년 하계 고교 야구 대회에서는 일간 활성 사용자 수(DAU)가 300만 명을 돌파하기도 했습니다. 고교 야구와 마찬가지로 여름의 주요 콘텐츠는 고등학교 간 체육대회입니다. 이 회사의 이사 쿠마가이 유스케는 "아마추어 스포츠는 타겟층이 매우 넓습니다. 지역 사회에 깊이 뿌리내리고 있으며, 현 세대부터 그 세대의 부모와 조부모까지 모든 연령대의 사람들이 즐길 수 있습니다. 사실 우리 회사 직원의 절반 정도만이 프로 스포츠를 시청하는 습관을 가지고 있습니다. 그럼에도 불구하고 모두가 아마추어 스포츠에 매력을 느낍니다. 그들에게는 신비한 매력이 있고, 학창 시절 동아리 활동을 했던 많은 일본인의 원초적인 경험일지도 모릅니다. 모든 종류의 스포츠에 대한 정보를 보급하기 위해 노력하고 있는 스포부와 스포부의 팬들에게 일본 최고의 고교팀을 가리는 이 토너먼트는 중요한 이벤트입니다.

인터하이를 생중계하고 싶다는 생각에 동영상 플랫폼을 도입하기로 결정했습니다. 창업 이후 여러 영상 콘텐츠를 배포해왔고, 시청자들의 반응도 좋았습니다. 하지만 콘텐츠 관리자의 부담이 컸고, 직원 수가 적은 스타트업 기업이 동영상에 전념하기에는 어려움이 있었습니다. 라이브 방송의 경우 그 부담은 더욱 커져 상근 인력이 필요한 상황입니다. 이러한 문제를 해결할 수 있는 시스템으로 브라이트코브 비디오 클라우드가 가장 적합했습니다.

개발 부서의 매니저인 쿠마가이 타이키 씨는 "프리롤 및 미드롤 광고가 포함된 라이브 스트리밍을 안정적으로 운영할 수 있는 솔루션은 브라이트코브 비디오 클라우드가 유일했습니다. 운영에 IT 지식이 필요하지 않다는 점도 매력적이었고, 현재 시스템으로도 Inter-High.tv와 BIG6.tv(도쿄 빅6 야구 리그)의 라이브 스트리밍을 달성할 수 있다는 확신이 들었습니다.

고점 기간 동안 700회 라이브 방송 달성

브라이트코브는 2018년에 도입되었습니다. 당시 직원 수는 10명 정도였습니다. 이들은 하계 인터하이를 대비해 테스트를 진행했고, 실제로 경기를 촬영할 현지 파트너사와 수차례 미팅을 가졌습니다. 그런 다음 영상을 촬영하고 브라이트코브 비디오 클라우드로 가져와 배포하는 프로세스를 구축했습니다. 전용 계정을 발급하고 현지에서 직접 비디오 플랫폼에 접속하여 비디오를 전송하도록 하여 비디오를 업로드, 다운로드, 재업로드할 필요가 없도록 하기로 결정했습니다. 이러한 방식으로 최소한의 관리 작업으로 시청자에게 경기를 실시간으로 전달할 수 있었습니다.

우리는 곧 5G 시대에 접어들 것입니다. 동영상에 대한 수요는 계속 증가할 것입니다. 플랫폼을 미리 준비하고 전송 프로세스를 간소화한 것이 우리 비즈니스에 큰 도움이 되었다고 생각합니다.

유스케 쿠마가이

이사, Undo Tsushinsha Co.

배포는 대규모로 이루어졌습니다. 하루에 100개 이상의 동영상이 시청자에게 전달되었습니다. 또한 여러 종목에 대한 라이브 방송이 동시에 진행되어 이 기간 동안 700개의 경기가 생중계되었습니다. 결국 다양한 길이의 약 12,000개의 동영상이 편집되어 동영상 콘텐츠로 게시되었습니다.

"이제 비디오 플랫폼에서 모든 작업을 완료할 수 있게 되어 필요한 총 인력이 약 30% 감소한 것 같습니다. 브라이트코브 비디오 클라우드가 없었다면 이 정도 규모의 배포를 달성할 수 없었을 것이라고 확신합니다."(타이키 쿠마가이).

'열정적인 사용자'가 즐길 수 있는 콘텐츠

아마추어 스포츠에는 '헤비 유저'가 많다고 합니다. 그들은 오랜 시간 동안 머무르며 동영상을 자세히 시청합니다. 또한 반복적으로 사이트를 방문하는 사용자도 많습니다. 노출 수는 메이저 스포츠만큼 많지는 않지만 스포츠에 대한 열정을 가진 사용자가 분명히 존재합니다. 이러한 사용자들이 사이트를 더욱 즐길 수 있는 콘텐츠를 제공하기 위해 노력하고 있습니다.

쿠마가이 유스케는 "스포츠를 '보고', '즐기고', '지원하는' 존재가 되는 것이 목표입니다."라고 말합니다. 현재는 동영상을 활용한 '시청'에 집중하고 있지만, '플레이'를 통한 경험 창출도 지원하려고 합니다."라고 말합니다.

앞으로는 지원해주는 존재가 되고자 합니다. 더 나은 정보 전달을 지원하고 수익화 방법을 컨설팅하는 한편, 콘텐츠에 관심이 있는 시청자를 육성하고 개발하는 데 보다 직접적으로 관여하는 것이 목표입니다. 이를 통해 우수한 동영상 콘텐츠의 매력과 이를 통해 창출되는 광고 수익을 모든 종류의 스포츠 단체에 전달할 수 있을 것입니다.

"우리는 곧 5G 시대에 진입할 것입니다. 통신 속도가 빨라지고 대용량의 데이터를 빠른 속도로 주고받을 수 있게 되면 동영상에 대한 수요는 계속 늘어날 것입니다. 미리 플랫폼을 준비하고 배포 프로세스를 간소화한 것이 비즈니스에 큰 도움이 된 것 같습니다."라고 그는 말합니다.

엔드투엔드 암호화 트랜스코딩 파이프라인 설정하기

많은 Zencoder 고객에게 트랜스코딩 과정에서 콘텐츠의 보안을 유지하는 것은 최우선 과제입니다. 이제 젠코더는 암호화된 입력을 지원하므로 고객은 데이터가 젠코더를 통과할 때 절대로 일반 데이터에 저장되지 않도록 할 수 있습니다. 간단히 말해, Zencoder는 암호화된 입력을 받아 트랜스코딩을 위해 암호를 해독한 다음 출력 동영상을 저장 위치에 쓰기 전에 다시 암호화할 수 있습니다. 이 워크플로우의 중요한 점은 입력과 출력이 모두 보호된다는 것입니다. 권한이 없는 사용자가 이러한 암호화된 파일에 액세스할 수 있는 경우, 암호화를 위해 사용된 키와 IV 쌍이 없으면 파일을 볼 수 없습니다. 이 프로세스가 어떻게 진행되는지 살펴보겠습니다. 시작하기 전에 먼저 암호화된 입력이 필요합니다. 이 예제에서는 OpenSSL을 사용하여 로컬에서 파일을 암호화한 다음 트랜스코딩 작업을 만들기 전에 S3에 업로드하겠습니다.

$ openssl aes-256-cbc -k zencoderisawesome -in trailer_test.mp4 -out trailer_test.mp4.enc -p

그리고 -k 플래그는 우리가 사용하려는 비밀이며, 이 경우 "zencoderisawesome"입니다. 이 경우 -p 플래그는 나중에 암호 해독에 필요한 키를 출력하도록 OpenSSL에 지시합니다. 저희의 경우 출력은 다음과 같습니다:

salt=9E7E90A964768A2F
key=DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66
iv =375FDBBB213C062D544FCB5A6ACBA44E

이제 파일이 암호화되었으므로 이전처럼 파일을 재생할 수 없습니다. 이제 젠코더가 액세스할 수 있도록 파일을 S3 또는 FTP 서버에 업로드해야 합니다. 여기서는 S3 업로드 인터페이스를 사용하겠습니다.S3 업로드요청을 빌드할 시간입니다. 이제 Node.js 라이브러리 를 사용하여 요청을 전송했지만, 이 예제에서와 같이 다른 도구를 사용하여 동일한 요청을 전송할 수도 있습니다. 요청 빌더. 위에서 입력에 사용한 암호화 키와 IV를 지정해야 합니다.

var zencoder = require('zencoder')();
zencoder.Job.create({
  input: "s3://zencoder-demo/trailer_test.mp4.enc",
  decryption_method: "aes-256",
  decryption_key: "DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66",
  decryption_password: "zencoderisawesome"
}, function(err, data) {
  if (err) {
    console.log("Job wasn't created");
    return console.log(err);
  }
  console.log("Woo!");
  console.log(data);
});

이 정도면 표준 h.264 출력을 만들기에 충분하지만 어떤 방식으로도 암호화되지 않습니다. 암호화된 메자닌 파일(다른 낮은 품질의 출력을 만드는 데 사용되는 매우 높은 품질의 파일)을 가져와 워터마크가 있거나 낮은 품질의 출력을 배포하는 데 사용하려는 경우에 유용할 수 있기 때문에 가끔 이 기능이 유용합니다. 하나의 메자닌 파일을 세 개의 서로 다른 서비스에 업로드한다고 가정해 보겠습니다. 한 출력물은 워터마크가 있는 암호화되지 않은 저품질 버전으로, 다른 두 출력물은 식별 워터마크가 있는 것과 없는 2개의 서로 다른 키를 사용하여 암호화하고 싶습니다. 하지만 이 요청을 생성하기 전에 사용할 두 개의 키를 생성해야 합니다. 이 새 키를 생성하기 위해 OpenSSL을 다시 사용하겠습니다:

$ openssl enc -aes-256-cbc -k supersecret -P
salt=12B83BBF81DFA5B7
key=48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08
iv =2B3CABAB503198DB32394245F54E2A34

$ openssl enc -aes-256-cbc -k anothersecret -P salt=DE2DE044EA5FEB2A key=3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D iv =169C3DE53C56E74130CDA57BA85F8255

이제 트랜스코딩 프로세스 중에 출력을 암호화할 때 이 키를 사용할 수 있습니다.

zencoder.Job.create({
  input: "s3://zencoder-demo/trailer_test.mp4.enc",
  decryption_method: "aes-256",
  decryption_key: "DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66",
  decryption_password: "zencoderisawesome",
  outputs: [
    {
      url: 's3://some-bucket/decrypted.mp4',
      quality: 3,
      width: 320,
      watermarks: [{
        url: 's3://zencoder-live/test-job-watermark.png'
      }]
    },
    {
      url: 's3://some-other-bucket/encrypted-watermarked.mp4',
      width: 720,
      watermarks: [{
        url: 's3://zencoder-live/test-job-watermark.png'
      }],
      encryption_method: "aes-256",
      encryption_key: '48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08',
      encryption_iv: '2B3CABAB503198DB32394245F54E2A34'
    },
    {
      url: 's3://some-bucket/encrypted-out.mp4',
      width: 720,
      encryption_method: "aes-256",
      encryption_key: '3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D',
      encryption_iv: '169C3DE53C56E74130CDA57BA85F8255'
    }
  ]
}, function(err, data) {
  if (err) {
    console.log("Job wasn't created…");
    return console.log(err);
  }
  console.log("Woo!");
  console.log(data);
});

하나의 출력물에서 암호화를 생략하고 다른 두 개의 출력물을 따로 암호화하는 것은 엉뚱한 것처럼 보일 수 있지만 사용 사례를 생각해 보세요. 저화질 출력은 샘플로 사용할 수 있습니다(이를 위해 더 짧은 클립을 만들 수도 있습니다). 고화질 버전에는 동영상이 업로드되는 사람을 식별하는 워터마크가 있으므로 해당 사람에게 암호를 해독하고 시청할 수 있는 키를 제공하면 해당 동영상이 통제 범위를 벗어난 곳에서 발견될 경우 누가 복사한 것인지 알 수 있습니다. 세 번째, 워터마크가 없는 사본은 저희가 관리하는 버킷에 다시 업로드되어 나중에 배포에 사용할 수 있습니다. 이렇게 암호화된 파일을 로컬에 확보한 후에는 원래 파일을 암호화할 때 사용한 것과 유사한 프로세스를 사용하여 암호를 해독할 수 있습니다. 워터마크가 있는 파일의 암호화를 해제하려면 다음과 같이 하세요: $ openssl enc -aes-256-cbc -d -K 48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08 -iv 2B3CABAB503198DB32394245F54E2A34 -in encrypted-watermarked.mp4 -out decrypted-watermarked.mp4 워터마크 없이 파일 암호화를 해제하려면 다음과 같이 하세요: $ openssl enc -aes-256-cbc -d -K 3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D -iv 169C3DE53C56E74130CDA57BA85F8255 -in encrypted-out.mp4 -out decrypted-out.mp4 이제 끝났습니다! 이제 엔드투엔드 암호화된 인코딩 파이프라인이 완성되었습니다. 이 예제에서 사용된 암호화된 파일은 해당 위치에서 사용할 수 있으며 실제로 이러한 자격 증명을 사용하여 암호화되었으므로 테스트 파일로 자유롭게 사용할 수 있습니다. 참고 사항디지털 권한 관리 또는 DRM과 혼동해서는 안 됩니다. 적절한 DRM 솔루션은 특정 디바이스 및 사용자까지 훨씬 더 세분화된 콘텐츠 액세스 권한과 같은 사항을 처리합니다. 암호화된 파일은 암호화 키와 연결된 비밀번호를 통해서만 볼 수 있지만, 이는 유일한 기준입니다.

플레이북: 스포츠 동영상 전략을 만드는 방법

스포츠의 가치는 경기, 리그, 팀, 선수 그 이상입니다. 기본적으로 스포츠는 순간으로 구성되어 있습니다. 그리고 사람들은 단순히 순간을 기억하는 것이 아니라 어디에 있었는지, 누구와 함께 있었는지, 심지어 무엇을 먹었는지도 기억합니다. 스포츠는 감정에 따라 성장하고 번성합니다. 기쁨, 절망, 부러움 등 스포츠는 1초, 100분의 1초, 또는 10년이 지난 후에도 다양한 감정을 불러일으킵니다.

퍼블리셔는 비디오의 맥락에서 스포츠를 생각할 때 시청자의 참여를 유도하고 뉴스의 즉흥성, 내러티브 영화의 극적인 흐름, 그리고 매 경기와 시즌이 지나면서 쌓이는 데이터의 보고를 융합한 경험을 만들 수 있는 기회를 포착해야 합니다.

스포츠의 4가지 S

퍼블리셔가 동영상으로 시청자 참여를 높일 수 있는 기회는 크게 네 가지로 분류할 수 있습니다.

  • 통계 및 점수
  • 소셜 및 공유
  • 자발성
  • 스토리

통계 및 점수

통계와 점수는 스포츠를 기록, 측정, 분석, 추적하는 방법입니다. 필연적으로 누군가 또는 일부 팀은 'W'를, 적어도 한 사람 또는 팀은 'L'을 받게 되며, 가끔씩 동점/무승부도 발생합니다.

동영상은 모든 유형의 실시간 통계에 대한 컨텍스트를 제공할 수 있습니다.

스포츠 경기에서는 '큰' 플레이를 보여주는 것이 일반적이지만, 득점하지 않은 순간도 경기, 팀 또는 선수의 흐름을 파악하는 데 효과적입니다.

  • 위약금(또는 논란의 여지가 있거나 부재중 전화)
  • 사소해 보이는 순간(예: 릴레이 교환 중 망설임, 선수 교체)
  • 전략(예: 축구, 배구의 세트 플레이)
  • 성능(예: 플레이어 스플릿 또는 투구 속도 변화)

어떤 사람들에게는 스포츠 자체가 게임뿐만 아니라 계절, 직업, 도시, 우정을 아우르는 더 큰 열정을 위한 수단일 뿐입니다.

판타지 스포츠 게임은 야구와 축구가 가장 인기 있지만, 축구, 농구, 자동차 경주, 골프 등의 판타지 게임도 어렵지 않게 찾아볼 수 있습니다.

판타지 스포츠 시즌과 개별 경기 중에 비디오를 사용하여 최근 게임 또는 진행 중인 게임에서 수집한 실시간 데이터를 보강하여 터치다운, 골, 삼진, 큰 야드 이득 등 모든 유형의 판타지 스포츠 '득점'을 강조 표시할 수 있습니다.

하지만 판타지 스포츠 참가자들은 실시간 데이터 스트림을 수동적으로 바라보며 시간을 보내기도 합니다. 퍼블리셔는 비디오 하이라이트를 집계, 통합 및 연재하여 판타지 팀과 선수에 대한 비디오 스토리, 즉 통계와 스코어의 가상 '시즐 릴'로 구성함으로써 이러한 데이터 중심 경험을 린백 비디오 경험으로 확장할 수 있습니다.

동영상을 실시간 또는 최근 데이터와 동기화하는 것보다 더 매력적인 것은 팀 및 선수 통계를 조사할 때 동영상을 활용하여 추가적인 컨텍스트를 만들 수 있다는 점입니다. 퍼블리셔는 소비자가 단순히 통계를 보는 것뿐만 아니라 동영상을 통해 조사할 수 있도록 함으로써 매력적인 경험을 만들 수 있습니다.

소셜 및 공유

스포츠는 일반적으로 참여, 참석, 관람을 위한 사교 활동입니다.

동영상은 게임 자체를 시청하는 것 이상으로 중요한 역할을 할 수 있습니다.

개인 네트워크(이메일 또는 문자)나 소셜 네트워크(Facebook 또는 Twitter)를 통해 전달되는 스포츠는 그 순간을 넘어 재생 가치를 높여줍니다.

소셜 미디어를 통해 퍼블리셔는 동영상을 사용할 수 있습니다:

  • 특정 순간(득점, '거의' 득점, 열광하는 팬 또는 좌절하는 코치)에 대한 대화를 시작하세요.
  • 시청자가 특정 순간에 대한 대화를 시작하거나, 자신만의 순간 시리즈를 '리믹스'하거나, 자신만의 스포츠센터 스타일 요약본을 만들 수 있습니다.
  • 스폰서 콘텐츠 테마로 새로운 수익 창출 기회 만들기

스포츠 클럽과 리그에서 동영상을 사용할 수 있습니다:

  • 시즌 티켓 보유자 또는 참석자를 유도하기 위해 경기장 변경 사항 공지(예: 식사 옵션, 관람석 및 스위트룸 전망, 특별 경기 당일 이벤트 또는 경품 미리보기)
  • 사용자 제작 콘텐츠를 활용하여 팬층을 강화하고 해당 고객을 동원하여 오래 지속되는 브랜드 가치를 구축하세요(예: 간판, 응원, '홈' 팬, 테일게이트 파티 및 음식의 '최고의' 사례).

자발성

퍼블리셔는 데스크톱, 모바일, 커넥티드 TV에 이르기까지 모든 비디오 경험이 시청자의 콘텐츠 검색 욕구에 맞게 조정되어야 합니다. 스포츠 콘텐츠에는 고유한 특성이 있습니다:

  • 라이브, 시간 이동 및 사전 녹화 모두 소비됨
  • 리그, 팀, 선수, 팬의 관점에서 바라본 리그, 팀, 선수, 팬의 관점
  • 데이터와 불가분의 관계

이러한 모든 측면을 통해 퍼블리셔는 검색과 프로모션을 최적화하여 참여도와 수익 창출을 높일 수 있습니다.

동영상 소비의 린백 모드에서 퍼블리셔는 콘텐츠가 자연스럽게 느껴지도록 해야 합니다. 예를 들어 시청자는 마이클 펠프스가 100분의 1초라는 아주 근소한 차이로 금메달을 획득한 리플레이를 시청하는 것부터 시작할 수 있습니다. 비디오의 '박빙의 승부'라는 개념에 착안하여 비디오 경험은 유사한 콘텐츠의 동적 재생 목록을 자동으로 프로그래밍할 수 있습니다: 켄터키를 상대로 한 크리스티안 렛트너의 역전 점퍼, 탈라데가에서 0.0002초 차이로 승리한 지미 존슨, 우승컵을 차지하기 위한 블랙호크스의 마지막 순간 랠리 등 다양한 콘텐츠를 자동으로 프로그래밍할 수 있습니다.

스토리

동영상은 6초 또는 6시간 동안 이야기를 전달할 수 있습니다. 스포츠 콘텐츠에 중점을 둔 퍼블리셔에게 모든 동영상은 리그, 팀, 선수, 코치 또는 팬에 대한 이야기 등 스토리를 전달합니다. 하지만 스포츠 스토리는 다양한 요소를 포괄할 수 있기 때문에 전통적인 리그의 틀을 뛰어넘어 확장될 수 있습니다.

GoPro로 무장하면 낚시꾼이 950파운드 청새치와 씨름하는 모습, 등반가가 엘 캐피탄을 등반하는 모습, 지오캐싱을 즐기는 모습, 도시 탐험가가 파리의 자갈밭을 헤집고 다니는 모습을 볼 수 있습니다.

퍼블리셔는 소비자의 감성에 호소할 수 있는 특별한 기회를 갖게 됩니다. 뉴스 콘텐츠는 일시적이며 즉각성과 역사적 아카이브로서의 가치를 모두 얻을 수 있지만, 스포츠의 한 순간은 같은 수준의 드라마로 몇 번이고 반복해서 시청할 수 있습니다.

스포츠는 사람들이 참가자로서 또는 팬으로서 열정을 쏟을 수 있게 해주며, 비디오는 승패나 무승부를 가릴 때마다 경험을 고조시키는 중요한 역할을 합니다.

럭셈버거 워트가 투르 드 프랑스에서 활약하는 방법

룩셈부르크의 인구와 성공적인 투르 드 프랑스 참가자를 비교해 보면 사이클링이 이 작은 나라의 국민 스포츠가 된 이유를 바로 이해할 수 있습니다. 100년 전 첫 번째 '그랑 부클'이 시작된 이래 룩셈부르크 사이클링의 거장 15명이 투르 드 프랑스에서 70번의 스테이지 우승을 달성했습니다. 이미 5명의 룩셈부르크 선수가 세계에서 가장 유명한 자전거 레이스에서 우승했으며, 3주간의 시련 끝에 옐로 저지를 입고 집으로 돌아갈 수 있었습니다. 그러니 요즘 룩셈부르크의 가장 중요한 일간지 중 하나인 룩셈부르크 워트에서도 사이클링이 가장 핫한 주제 중 하나인 것은 당연한 일입니다.

자체 기자 및 사진작가 팀이 상주하는 룩셈부르크 맥아즙의 뉴스 포털인 wort.lu는 독자들에게 매일 업데이트되는 비디오 보도를 제공합니다. 소규모 팀이 브라이트코브를 사용하여 사이트의 전체 비디오 콘텐츠를 직접 관리하며, 온라인 비디오, 1~5분 분량의 짧은 비디오 리포트, 긴 비디오 인터뷰 등의 다양한 형식을 제공합니다. 사이클링 팬들은 투어 기간 동안 wort.lu에서 투어 실시간 티커를 통해 최신 정보를 확인할 수 있으며, 매일 저녁 웹사이트에서 주최사인 아모리 스포츠 기구(ASO)의 공식 동영상 요약본을 볼 수 있습니다. 매일 85,000부씩 발행되는 이 신문은 룩셈부르크의 사이클리스트들이 이번 투어 기념일에도 다시 한 번 레이스의 선두에 서기를 기원합니다.

이 언론사가 2012년에 브라이트코브를 도입하기로 결정한 주요 요인 중 하나는 룩셈부르크가 유럽에서 모바일 사용률이 가장 높다는 점입니다. 이동 중에도 뉴스를 접하는 사람들이 점점 더 많아지고 있는 이 나라에서는 다양한 플랫폼에서 안정적이고 고품질의 비디오를 전송하는 것이 필수적입니다. wort.lu 개발팀은 비디오 클라우드 SDK를 사용하여 2주 만에 wort.lu 사이트를 위한 모바일 애플리케이션을 개발할 수 있었습니다. 원활한 구현은 광범위한 문서와 지원팀과의 협업을 기반으로 이루어졌습니다.

현지화는 또한 투르 드 프랑스 보도와 전체 편집 콘텐츠를 독일어, 프랑스어, 영어, 포르투갈어로 제공하기 때문에 DMEXCO 2012의 출판 의사 결정권자들이 브라이트코브에 주목했습니다. 즉, 편집 팀은 브라이트코브를 사용하여 자막과 같은 비디오 콘텐츠의 라벨 또는 기타 표준 텍스트를 여러 언어로 자동화할 수 있습니다.

룩셈부르크 워트의 편집장 마크 틸(Marc Thill)은 비디오 부문에서 wort.lu의 전략적 방향이 분명합니다. "온라인 및 인쇄 편집팀은 서서히 함께 성장하고 있으며, 이를 위해 향후 증가할 비디오 수요와 함께 성장할 수 있는 Brightcove와 같은 솔루션이 필요했습니다. 특히 인터넷 뉴스 포털 wort.lu의 트래픽 생성에 관한 한, 매년 열리는 투르 드 프랑스 보도는 전통적으로 사이클링에 열광하는 우리 독자들에게 한 해의 고정적인 하이라이트입니다."

이 출판사는 룩셈부르크 뉴스 시장에서 wort.lu의 선도적인 위치를 유지하고 확장하기 위해서는 이러한 주요 스포츠 이벤트를 넘어 인터넷 지배력 경쟁이 치열해지는 상황에서 디지털 서비스도 매일 그 가치를 입증해야 한다는 사실을 잘 알고 있습니다. 마크 틸은 브라이트코브를 통해 이 언론사는 필요한 기술적 조건을 충족하게 되었다고 말합니다. wort.lu 뉴스룸 팀은 이제 많은 기술적 노력 없이도 매일 다양한 모바일 및 온라인 사용자 그룹에 온라인 비디오 콘텐츠를 동적으로 안정적으로 전송할 수 있습니다. 또한 브라이트코브를 사용하여 새로운 범위의 비디오 광고 옵션을 제공함으로써 온라인 부문에서 긴밀한 협력을 원하는 wort.lu 광고 파트너의 꾸준히 증가하는 수요에 대응할 수 있게 되었습니다. 동영상 시장에서 성공적인 수익 창출을 위해 중요한 분석 기능은 브라이트코브 패키지에 포함되어 있습니다.

MPEG-DASH: 상호 운용성, 엔드투엔드 전송을 위한 표준 만들기

미디어 업계에서 일하신다면 MPEG-DASH라는 용어를 꽤 많이 들어보셨을 것입니다. MPEG-DASH는 코덱, 프로토콜, 시스템 또는 포맷이 아닙니다. 그 대신 HTTP를 통한 비디오의 상호 운용성, 즉 엔드투엔드 전송을 위한 표준입니다.

MPEG-DASH의 주요 목표 중 하나이자 퍼블리셔가 누릴 수 있는 핵심 혜택은 기존 인프라에서 개방형 표준을 사용하여 라이브 및 사전 녹화된 프리미엄 동영상 경험을 제공하는 데 드는 비용과 노력을 줄일 수 있다는 점입니다. 오늘날의 프리미엄 동영상 경험에는 일반적으로 광고, 보안(예: DRM), 적응형 비트레이트 재생, 캡션, 다국어 지원 등의 요구 사항이 포함됩니다. 파편화된 디바이스 환경에서 라이브 및 사전 녹화된 콘텐츠에 이러한 요구 사항을 적용하면 퍼블리셔의 인코딩, 패키징, 스토리지 및 전송 워크플로우가 복잡해집니다(비용).

업계 플레이어들은 MPEG-DASH를 통해 사실상 비디오 전송을 위한 세 가지 프로토콜(Apple의 HTTP 라이브 스트리밍, Adobe의 HTTP 동적 스트리밍, Microsoft의 스무스 스트리밍)을 논리적으로 '진화'시켜 복합적인 표준으로 만들기 위해 노력하고 있습니다. 이것은 말이 됩니다. 이 세 가지 프로토콜은 모두 HTTP 네트워크를 통해 적응형 비트레이트 재생을 위한 효율적이고 안전한 콘텐츠 전송이라는 측면에서 매우 유사합니다. 하지만 서로 호환되지는 않습니다.

오늘날 대부분의 퍼블리셔는 데스크톱, 모바일, 커넥티드 TV, 게임 콘솔 등 다양한 디바이스를 지원하면서 콘텐츠의 보편화를 위해 노력하고 있습니다. 따라서 퍼블리셔가 적응형 비트레이트 스트리밍을 지원하려면 여러 포맷, 프로토콜, 콘텐츠 보호 옵션을 지원하여 여러 디바이스와 플랫폼에서 폭넓게 지원하거나 디바이스와 플랫폼 공간을 표준화하여 제한해야 합니다.

어느 쪽도 매력적이지 않습니다. 콘텐츠 제작(여러 형식과 언어를 위한 인코딩, 여러 콘텐츠 보호 체계를 위한 패키징), 중복 스토리지, 여러 콘텐츠 전송 프로토콜, 서로 다른 기능을 가진 여러 플레이어, 일관되지 않은 광고 형식 등 모두가 비효율적으로 운영되고 있습니다.

MPEG-DASH의 목표는 퍼블리셔가 동영상 워크플로우를 효율적으로 관리하고 모든 플랫폼과 디바이스에 제공할 수 있도록 동영상 워크플로우를 간소화하는 것입니다.

MPEG-DASH가 만병통치약인가요?

MPEG-DASH는 구현 세부 사항을 정의하지 않으며, 대신 다음과 같은 작업과 결정을 업계 전반에 맡깁니다.

  • 엔드투엔드 DRM
  • 코덱
  • 파일 형식 및 이전 버전과의 호환성
  • 로열티 고려 사항 및 현재와 미래의 IP를 둘러싼 문제

퍼블리셔가 마이그레이션을 서두를 경우, 에코시스템 내 개별 공급업체의 지원이 제한적이거나 일관되지 않고 에코시스템 내 공급업체 간의 상호 운용성이 부족하기 때문에 기술 및 워크플로 결정에 영향을 받을 가능성이 여전히 존재합니다. 그런 다음 퍼블리셔는 콘텐츠 전송, 광고, 분석, 인코딩, DRM 패키징 및 라이선스 관리, 재생 등 스택의 모든 부분을 통합하여 엔드투엔드 워크플로우를 진정으로 해결해야 합니다.

사실 HTML5 '표준'에서 보았던 파편화는 MPEG-DASH에서 직면하게 될 문제를 예고하는 것일 수 있습니다.

Apple의 장점은 무엇인가요?

또한 애플이 HLS에 엄청난 노력을 기울여 사실상 표준으로 끌어올린 상황에서 왜 MPEG-DASH를 홍보하는지도 명확하지 않습니다. 많은 시스템과 회사가 이 프로토콜을 중심으로 구축되어 있으며, 제 생각에는 Apple이 HLS의 이점을 포기하고 대신 다른 대안의 표준화를 추진하도록 설득하는 것은 힘든 싸움이 될 것 같습니다.

역사는 반복되는가... 아니면 반복되는가?

새로운 표준이나 프로세스의 실행 가능성을 평가할 때는 과거와 비교하는 렌즈를 통해 고려하는 것이 도움이 됩니다.

기업들이 상품을 운송하던 방식을 생각해 보세요. 1950년대 이전에는 쉽고 효율적인 운송 방법이 없었습니다. 하지만 50년대 중반에 복합운송과 컨테이너라는 개념이 도입되었습니다. 선박, 철도 또는 트럭으로 상품을 표준 형식으로 운송할 수 있게 되면서 현대적인 공급망이 탄생했습니다. 프로세스의 표준화에 동의하는 것이 중요한 첫 단계였습니다. MPEG-DASH도 이와 유사한 '바다의 변화'를 이루기 위해 노력하고 있지만, 구현 세부 사항을 피하기 때문에 궁극적으로 파편화가 발생할 위험이 큽니다.
다음은 우리가 직면할 수 있는 문제입니다.

  • MPEG-DASH 구현이 이전 버전과 호환되지 않는 경우, MPEG-DASH와 HLS를 모두 지원해야 합니다. HLS(또는 HDS와 Smooth)가 이전 버전과의 호환성을 비효율적으로 만드는 경로를 계속 사용한다면 퍼블리셔는 MPEG-DASH와 HLS, 스무드 스트리밍과 HDS를 모두 고려해야 합니다.
  • 클라이언트 측 플레이어(데스크톱, 모바일, 커넥티드 TV, 게임 콘솔)가 MPEG-DASH를 광범위하게 지원하지 못하면 퍼블리셔는 여전히 플레이어 파편화에 직면하게 됩니다. 플레이어 조각화는 업스트림에서 발생하며, 이는 재생부터 전송, 패키징, 인코딩에 이르는 전체 콘텐츠 워크플로우가 MPEG-DASH 워크플로우와 중복된다는 것을 의미합니다. 많은 퍼블리셔에게 도입 비용은 점진적인 이득에 비해 가치가 없을 수 있습니다.

브라이트코브의 견해

퍼블리셔는 이미 여러 형식과 관련 전송 프로토콜을 지원해야 하는 운영상의 복잡성에 직면해 있습니다. 여러 형식의 콘텐츠 수집, 크로스 플랫폼 재생 및 크로스 플랫폼 DRM에 필요한 여러 렌더링과 형식의 트랜스코딩 및 패키징, 데스크톱, 모바일 웹, 모바일 앱 및 커넥티드 TV를 위한 적응형 비트레이트 스트리밍 등 워크플로우의 모든 단계에서 필요한 마찰과 노력을 줄이기 위해 지속적으로 기능을 개선해 나갈 것입니다.

표준화라는 개념은 지지하지만, 엔드투엔드 MPEG-DASH 시나리오를 위해 다른 모든 지원을 포기할 수 있는 단계는 아직 아닙니다. MPEG-DASH는 동영상 생태계의 폭과 깊이를 모두 고려하지 않기 때문에 조기 도입 시 특정 벤더에 종속되거나 폐쇄될 수 있으며, 이는 고객에게 해가 될 수 있습니다.

궁극적으로, 저희는 MPEG-DASH와 생태계 내 공급업체가 신속하게 역량을 강화하여 공급업체에 종속되거나 표준의 불완전한 구현을 초래하는 독점적인 구현을 강요하는 대신 퍼블리셔에게 더 많은 유연성을 제공하기를 희망합니다. 그 동안 저희는 MPEG-DASH 생태계 내에서 디지털 역할을 수행하기 위해 소매를 걷어붙이고 키워드에 집중하고 있습니다.

성능과 안정성을 개선한 VIDEO.JS 4.0

Video.js 4.0은 2013년에 출시되었으며 Github에서 다운로드할 수 있고 브라이트코브의 CDN에서 무료로 호스팅됩니다. 참고로 Video.js는 2012년 브라이트코브가 인수한 Zencoder 팀이 만든 오픈 소스 HTML5 동영상 플레이어입니다.

Video.js는 오픈 소스 동영상 플레이어 기술 시장을 뒤흔들며 불과 몇 년 만에 엄청난 채택률과 시장 점유율을 기록했습니다. 몽블랑, 돌체 앤 가바나, 디젤, 일리, 애플비, 마텔, 켈로그, 레 에코스, 미 해군, 애트나, 트랜스아메리카, 워싱턴 주립대 등 수만 개의 조직에서 무료 Video.js 플레이어를 사용하고 있습니다.

버전 4.0은 이전 버전 중 가장 많은 커뮤니티의 협업을 받았으며, 이는 자바스크립트 커뮤니티의 성장, HTML5 비디오의 인기 증가, Video.js 사용의 증가를 반영합니다. 2012년부터 2013년까지 Video.js를 사용하는 사이트의 수는 두 배 이상 증가했으며, 매달 CDN 호스팅 버전에만 2억 건 이상의 조회 수가 발생하고 있습니다.

Video.js 4.0에는 많은 새로운 기능이 있습니다.

  • 고급 모드에서 Google 클로저 컴파일러를 사용하여 18% 크기 감소를 통한 성능 향상
  • 트래비스CI, 번입, 브라우저스택을 사용한 자동화된 크로스 브라우저/기기 테스트 스위트를 통해 안정성을 높입니다.
  • Video.js 확장을 위한 새로운 플러그인 인터페이스 및 플러그인 목록
  • 글꼴 아이콘을 사용하는 새로운 기본 스킨 디자인으로 사용자 지정 기능 강화
  • 반응형 디자인 및 망막 디스플레이 지원
  • ARIA 지원 개선을 통한 접근성 향상
  • Apache 2.0 라이선스로 이전
  • Grunt를 포함한 100% 자바스크립트 개발 도구 세트

2013년은 성능, 멀티플랫폼 안정성, 플러그인 및 스킨을 통한 사용자 정의 기능이 더욱 개선되는 등 Video.js에 있어 흥미로운 한 해가 될 것입니다. 커뮤니티 회원들은 이미 재생 목록, 분석 및 광고와 같이 요청이 많았던 기능에 대한 플러그인 작업을 시작했습니다.

트래픽을 유도하는 7가지 동영상 SEO 모범 사례

동영상 SEO를 개선하고 사이트로 더 많은 트래픽을 유도하고 싶으신가요? 다음은 도움이 될 수 있는 7가지 간단한 팁입니다.

1. 사람들을 위한 동영상 제목 및 설명 작성

Google은 '사람을 위한 글쓰기'를 중요하게 생각하며 동영상 제목과 설명에 키워드를 채우는 것을 꺼립니다. 키워드를 채우는 것이 아니라 시청자의 관심을 끌고 관련성이 있는 제목과 설명을 작성해야 합니다.

2. 동영상 사이트 맵이 있는 경우 태그 추가

동영상에 태그를 추가하는 것은 브라이트코브 온라인 동영상 플랫폼 내에서 콘텐츠를 구성하는 좋은 방법이며 SEO에도 도움이 될 수 있지만, 검색 엔진에 해당 태그를 노출하는 동영상 사이트 맵이 있는 경우에만 가능합니다. 간단한 동영상 사이트 맵을 만들 수 있는 개발 리소스가 있다면 투자할 만한 가치가 있습니다.

3. 스키마 마크업 사용

스키마는 웹마스터가 주요 검색 제공업체가 인식하는 방식으로 페이지를 마크업하는 데 사용할 수 있는 HTML 태그 모음입니다. 검색 엔진은 이러한 스키마 태그를 사용하여 검색 결과 표시를 개선함으로써 사람들이 올바른 웹 페이지를 더 쉽게 찾을 수 있도록 합니다. 항목 범위 속성을 사용하여 검색 엔진에서 콘텐츠를 동영상으로 식별하면 SEO 결과가 향상됩니다. 스키마에는 itemscope 속성을 사용하는 방법에 대한 설명과 HTML 태그를 사용하여 동영상을 식별하는 일반적인 지침이 나와 있습니다.

4. 고품질 썸네일 이미지 선택

미리보기 이미지의 편집 품질이 이미지 품질보다 우선합니다. 다시 말해, 콘텐츠의 매력적인 미리보기 이미지를 선택하면 사용자 클릭을 늘릴 수 있습니다. 사용자 참여도가 높을수록 SEO 결과에 영향을 미칩니다. 또한 이미지 미리보기 이미지가 일반적인 동영상 아이콘이나 "동영상을 보려면 여기를 클릭하세요" 텍스트 링크보다 항상 더 나은 트래픽 결과를 얻을 수 있다는 점도 주목할 가치가 있습니다.

5. 동영상 결과를 반환하는 인기 검색어 통합하기

동영상 제목과 설명을 '키워드화'해서는 안 되지만, 특정 단어는 검색 엔진에서 검색될 가능성을 높여줍니다. '동영상', '쇼', '방법', '리뷰', '정보' 등의 단어는 모두 콘텐츠가 동영상 미리보기 이미지 결과를 표시할 가능성을 높여주는 인기 용어입니다. 부자연스럽지 않게 제목이나 설명에 이러한 단어를 포함할 수 있다면(예: "알로프트 브루클린의 비디오 투어") 차이를 만들 수 있습니다.

6. 웹사이트 최적화

사이트가 최적화되지 않았다면 아무리 완벽한 동영상 SEO도 소용이 없습니다. 동영상 설정을 조정하기 전에 항상 웹사이트의 SEO가 최적화되어 있는지 확인하는 것이 좋습니다.

7. 페이지 상단에 동영상 배치

동영상이 있는 경우 페이지 상단에 배치합니다. 이렇게 하면 검색 엔진이 동영상 콘텐츠라는 것을 이해할 수 있습니다. 이 작은 변화로 어떤 결과를 얻을 수 있는지 놀랍습니다.

다이나믹 매니페스트와 HLS 재생 목록의 유연성

수년 동안 인터넷 스트리밍의 기본 모델에는 서버 기반 독점 기술인 RTMP 또는 프로그레시브 다운로드의 두 가지가 있었습니다. 서버 기반 스트리밍은 필요에 따라 전환할 수 있는 다중 비트레이트 스트림을 전송할 수 있지만 고가의 소프트웨어 라이선스가 필요합니다. 프로그레시브 다운로드는 Apache를 통해 수행할 수 있지만 비트레이트 전환 시 재생을 중지해야 합니다.

HLS 및 스무스 스트리밍과 같은 HTTP 기반 스트리밍 프로토콜의 등장으로 Apache와 같은 상용 서버 기술을 사용하는 표준 HTTP 연결을 통해 스트리밍 전송이 가능해졌고, 원활한 비트레이트 전환이 일반화되었으며, CDN을 통한 전송은 근본적으로 모든 파일을 HTTP로 전송하는 것과 동일하기 때문에 간단해졌습니다. HTTP 스트리밍은 고품질 스트리밍의 비용과 복잡성을 크게 줄이면서 스트리밍 미디어 전송에 혁명을 가져왔습니다.

동영상 플랫폼을 설계할 때 고려해야 할 사항은 무수히 많습니다. 하지만 가장 중요하면서도 흔히 간과되는 결정 중 하나는 HTTP 기반 매니페스트 파일을 처리하는 방법입니다.

정적 매니페스트 파일

실제 세계에서는 비디오를 구매할 때 포장을 살펴보고 상자를 들고 계산대로 가서 계산원에게 돈을 지불하고 집에 가서 플레이어에 삽입합니다.

대부분의 동영상 플랫폼은 매우 유사한 구조로 되어 있습니다. 기본적으로 메타데이터 그룹(상자)은 재생 가능한 미디어 항목(동영상)과 연결되어 있습니다. 대부분의 동영상 플랫폼은 메타데이터를 단일 MP4 동영상에 연결하는 단일 URL 개념으로 시작합니다. 동영상 플랫폼이 복잡해지면 여러 비트레이트, 해상도 또는 미리보기나 특수 기능과 같은 주요 항목과 관련된 다른 미디어를 나타내는 메타데이터에 연결된 여러 URL이 있을 수 있습니다.

물리적 모델을 HLS와 같은 HTTP 기반 스트리밍 프로토콜을 포함하는 온라인 스트리밍 세계로 확장하려고 하면 상황이 더 복잡해집니다. HLS는 매니페스트라고 하는 텍스트 파일로 서로 연결된 비디오 파일의 여러 조각을 기반으로 합니다. HLS를 구현할 때 가장 간단한 방법은 매니페스트 또는 m3u8 파일로 연결되는 URL을 추가하는 것입니다. 이 방법은 매우 쉽고 기본적으로 기존 모델에 적합하다는 장점이 있습니다.

단점은 HLS가 정적 미디어 항목과 다르다는 점입니다. 예를 들어 MP4는 DVD의 비디오 트랙과 매우 유사하며, 단일 해상도와 비트레이트의 단일 비디오입니다. HLS 매니페스트는 대부분 여러 비트레이트, 해상도, 수천 개의 조각난 비디오 조각으로 구성됩니다. HLS는 MP4보다 훨씬 더 많은 용량을 처리할 수 있는데 왜 똑같이 취급해야 할까요?

HLS 재생 목록

HLS 재생 목록에는 스트림의 기본 요소를 설명하는 일부 메타데이터와 동영상 조각에 대한 정렬된 링크 세트가 포함되어 있습니다. 각 조각 또는 비디오 세그먼트를 다운로드하여 순서대로 재생하면 사용자는 하나의 연속 비디오처럼 보이는 것을 시청할 수 있습니다.

  • EXTM3U
  • #EXT-X-재생목록-유형:VOD
  • #EXT-X-TARGETDURATION:10
  • #EXTINF:10,
  • file-0001.ts
  • #EXTINF:10,
  • file-0002.ts
  • #EXTINF:10,
  • file-0003.ts
  • #EXTINF:10,
  • file-0003.ts
  • #EXT-X-ENDLIST

위는 기본 m3u8 재생 목록입니다. 4개의 동영상 세그먼트로 연결됩니다. 이 데이터를 프로그래밍 방식으로 생성하려면 첫 번째 항목의 파일 이름, 세그먼트의 목표 지속 시간(이 경우 10초), 총 세그먼트 수만 있으면 됩니다.

HLS 매니페스트

HLS 매니페스트는 재생 목록에 대한 정렬되지 않은 일련의 링크입니다. 재생 목록이 여러 개 있는 이유는 다양한 비트레이트 제공과 백업 재생 목록 제공이라는 두 가지입니다. 다음은 각 .m3u8이 다른 HLS 재생목록에 대한 상대 링크인 일반적인 재생목록입니다.

  • #EXTM3U
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2040000
  • file-2040k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1540000
  • file-1540k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1040000
  • file-1040k.m3u8
  • #EXT-X-스트림-정보:프로그램-ID=1,대역폭=640000
  • file-640k.m3u8
  • #EXT-X-스트림-정보:프로그램-ID=1,대역폭=440000
  • file-440k.m3u8
  • #EXT-X-스트림-정보:프로그램-ID=1,대역폭=240000
  • file-240k.m3u8
  • #EXT-X-스트림-정보:프로그램-ID=1,대역폭=64000
  • file-64k.m3u8

재생 목록은 네트워크 상태에 관계없이 원활한 재생을 제공하기 위해 다양한 비트레이트와 해상도로 구성됩니다. 매니페스트를 생성하는 데 필요한 것은 각 재생 목록의 비트레이트와 상대 경로뿐입니다.

빈칸 채우기

온라인 동영상 플랫폼이 인코딩된 각 동영상 자산에 대해 캡처해야 하는 중요한 정보는 동영상 코덱, 오디오 코덱, 컨테이너, 총 비트레이트 등 여러 가지가 있습니다. 단일 동영상 항목에 대해 저장되는 데이터는 시청자에게 의미 있고(설명, 평점, 출연자), 플랫폼에 의미 있고(재생 시간, 조회수, 참여도), 애플리케이션에 의미 있는(포맷, 해상도, 비트레이트) 데이터여야 합니다. 이 데이터를 통해 시청자는 시청할 콘텐츠를 결정하고, 시스템은 프로그래밍 방법을 결정하고, 애플리케이션은 재생 방법을 결정할 수 있습니다.

재생 목록, 매니페스트 및 각 재생 목록에 대한 코덱 정보를 프로그래밍 방식으로 생성하는 데 필요한 데이터를 캡처하면 요청마다 매니페스트와 재생 목록이 생성되는 시스템을 갖출 수 있습니다.

예 - 첫 번째 재생 목록

HLS 사양은 매니페스트에서 가장 먼저 오는 재생 목록이 재생할 첫 번째 항목으로 선택되도록 결정합니다. 이전 섹션의 예시에서는 목록의 첫 번째 항목도 최고 음질의 트랙이었습니다. 인터넷 연결이 빠르고 안정적인 사용자에게는 괜찮지만 연결 속도가 느린 사용자에게는 재생이 시작되는 데 시간이 걸립니다.

디바이스의 인터넷 연결 상태가 양호한지 확인한 다음 그에 따라 재생 목록을 사용자 지정하는 것이 좋습니다. 다행히도 동적 매니페스트 생성을 사용하면 시스템이 바로 이러한 작업을 수행할 수 있도록 설정되어 있습니다.

이 연습에서는 비트레이트의 정렬된 배열로 매니페스트 요청이 이루어진다고 가정합니다. 예를 들어 [2040,1540,1040,640,440,240,64]를 요청하면 이전 섹션의 재생 목록과 동일한 재생 목록이 반환됩니다. iOS에서는 사용자가 Wi-Fi를 사용 중인지 아니면 셀룰러 연결을 사용 중인지 확인할 수 있습니다. 비트 전송률, 해상도 및 기타 매개 변수를 포함하여 각 재생 목록에 대한 데이터가 캡처되었으므로 앱은 매니페스트의 순서를 지능적으로 결정할 수 있습니다.

예를 들어, 사용자가 와이파이를 사용하는 경우 800~1200kbps, 셀룰러 연결을 사용하는 경우 200~600kbps 사이에서 시작하는 것이 가장 좋다고 판단할 수 있습니다. 사용자가 와이파이를 사용하는 경우 앱은 다음과 같은 배열을 요청합니다: [1040,2040,1540,640,440,240,64]. 앱이 셀룰러 연결만 감지했다면 [440,2040,1540,1040,640,240,64]를 요청할 것입니다.

예시 - 레거시 디바이스

Android에서 동영상 지원은 다소 까다로운 편입니다. 수년 동안 공식 Android 문서는 특정 모델이 1080p를 처리할 수 있음에도 불구하고 640×480 기준 h.264 mp4 비디오 사용만 지원했습니다. HLS의 경우 지원은 훨씬 더 세분화되어 있고 이해하기 어렵습니다.

다행히도 Android는 소수의 대표 기기가 주도하고 있습니다. 동적 매니페스트를 통해 앱은 시작하기에 가장 좋은 재생 목록을 타겟팅할 수 있을 뿐만 아니라 호환되지 않는 것으로 판단되는 재생 목록은 제외할 수 있습니다.

미디어 항목은 해상도 및 코덱 정보와 같은 데이터도 캡처하기 때문에 특정 디바이스를 대상으로 지원할 수 있습니다. 앱이 모든 렌더링을 전송하도록 결정할 수 있습니다: [2040,1540,1040,640,440,240,64]. 또는 720p까지만 지원하는 구형 디바이스에서는 가장 높은 렌더링을 제거할 수 있습니다: [1540,1040,640,440,240,64]. 또한 모바일 디바이스 외에도 앱이 커넥티드 TV인 경우 가장 낮은 화질의 렌더링이 제거될 수 있습니다: [2040,1540,1040,640].

동적 또는 정적

정적 매니페스트 모델을 선택하는 것도 괜찮습니다. 유연성은 다소 떨어지지만 단순성이라는 장점이 있습니다. 특히 사용자 제작 콘텐츠 세계에서 많은 사용 사례는 동적 생성과 관련된 복잡성을 필요로 하지 않지만, 동적 매니페스트 생성은 과감하게 도전하려는 사람들에게 많은 가능성을 열어줍니다.

매니페스트를 처리하는 방법은 동영상 플랫폼의 장기적인 유연성에 큰 영향을 미치므로 상주 압축 전문가와 논의해야 할 사항입니다.

파일피커를 사용하여 동영상 업로드 및 인코딩하기

동영상 업로드 방법은 신규 고객으로부터 가장 많이 받는 질문 중 하나입니다. 개발자의 경우 파일 업로드를 구현하는 것은 몇 번 해본 적이 있는 작업이지만 항상 번거로운 작업입니다.

파일 선택기 입력

파일피커(현재 파일스택)를 사용하면 파일을 쉽게 업로드할 수 있습니다. 정말 쉽습니다. 로컬 파일에만 국한되지 않고 Dropbox와 Google부터 웹캠에서 직접 동영상을 녹화하는 것까지 다양한 소스를 지원합니다. 가장 좋은 점은 프런트엔드를 벗어나지 않고도 이 모든 작업을 수행할 수 있다는 것입니다.

다른 작업을 하기 전에 먼저 Filepicker 계정에 가입해야 합니다. 계정을 만든 후 대시보드에 앱이 없는 경우 새 앱을 만듭니다. 표시되는 API 키를 메모해 두세요. 나중에 사용할 것이니까요. Filepicker는 시작하기에 충분한 S3 버킷을 제공하지만 잠시 시간을 내어 업로드를 위한 대상 S3 버킷을 설정하세요.

기본 HTML5 템플릿으로 같은 페이지에서 시작하겠습니다. 간단하게 만들기 위해 jQuery를 사용할 예정이므로 상용구와 함께 파일 선택기 라이브러리를 포함하겠습니다.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>Zencoder Dropzone</title>

    <!-- jQuery Include -->
    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>

    <!-- Filepicker.io Include -->
    <script type="text/javascript" src="//api.filepicker.io/v1/filepicker.js"></script>
</head>

<body>
    <div id="content">
        <h1>Upload all the things!</h1>
    </div>
</body>
</html>

이제 Filepicker JavaScript API를 사용하여 사용자가 파일을 선택하여 S3 버킷에 저장할 수 있도록 할 수 있습니다. 또한 사용자가 클릭할 수 있도록 본문의 링크와 연결해야 합니다. Filepicker JavaScript include 아래에 추가하세요. 먼저 업로드 링크를 추가해 보겠습니다. 이미 크고 눈에 잘 띄는 h1 태그에 링크를 추가해 보겠습니다.

<h1><a href="#" id="upload-link">Upload all the things!</a></h1>

이제 이 링크를 사용하여 다음을 트리거하려고 합니다. filepicker.pickAndStore 를 클릭합니다. 여기서 앞서 메모해둔 API 키를 사용합니다. 이 스니펫을 페이지 헤드의 파일 선택기 JavaScript 포함 아래에 배치합니다.

<script type="text/javascript">
    $(function() {
      filepicker.setKey('The_Key_From_Your_Dashboard');

      $('a').click(function(e) {
        e.preventDefault(); // This keeps the normal link behavior from happening

        filepicker.pickAndStore({},{location: 's3'},function(fpfiles){
            console.log(JSON.stringify(fpfiles));
        });
      });
    });
</script>

HTML을 제공하기 위해 일종의 웹 서버를 사용해야 하며, 그렇지 않으면 외부 JavaScript 파일을 로드할 수 없습니다. http-server와 같은 것을 사용할 수도 있지만, GitHub 리포지토리에 정적 파일을 제공하는 기본 Node 애플리케이션이 있습니다.

아무 파일이나 선택하고(비교적 작은 파일을 선택하는 것이 좋습니다) 업로드합니다. 현재 업로드에 성공하면 파일에 대한 fpfiles 객체를 콘솔에 추가할 수 있으므로 파일을 업로드한 후 콘솔을 살펴보세요. 모든 것이 계획대로 진행되었다면 새로 업로드한 파일에 대한 정보가 포함된 개체가 있을 것입니다.

방금 컴퓨터에서 간단한 HTML 마크업을 포함하여 27줄의 코드만 있는 파일을 업로드했습니다. 하지만 파일을 업로드하고 그대로 두는 것만으로는 유용하지 않으므로 사용자가 동영상을 업로드하고 인코딩할 수 있도록 만들어 보겠습니다.

젠코더 추가

먼저 업로더가 동영상 파일만 허용하도록 변경해 보겠습니다. 파일 선택기를 사용하면 모방 유형별로 제한할 수 있으므로 저와 같은 경우 다음과 같이 시도해보고 싶을 수 있습니다. {mimetype: 'video/*'}. 이 방법은 Chrome에서도 잘 작동하지만 Safari 사용자는 업로드할 수 있는 파일의 하위 집합이 훨씬 작아집니다. 동영상의 경우 확장자로 제한하는 것이 훨씬 더 안정적이므로 이 방법을 사용하겠습니다.

$('a').click(function(e) {
  e.preventDefault(); // This keeps the normal link behavior from happening
  var acceptedExtensions = ['3g2','3gp','3gp2','3gpp','3gpp2','aac','ac3','eac3','ec3','f4a','f4b','f4v','flv','highwinds','m4a','m4b','m4r','m4v','mkv','mov','mp3','mp4','oga','ogg','ogv','ogx','ts','webm','wma','wmv'];
  filepicker.pickAndStore({extensions: acceptedExtensions},{location: 's3'},function(fpfiles){
      console.log(JSON.stringify(fpfiles));
  });
});

이 허용 파일 세트를 제한하거나 더 추가할 수 있지만, 저는 쉬운 방법을 택하여 Zencoder 형식 문서에 있는 유효한 출력 형식 목록을 사용했습니다. 여기에는 일부 오디오 파일이 포함되어 있지만, Zencoder는 오디오 전용 인코딩을 지원하므로 그대로 두어도 됩니다. 이제 링크를 클릭하고 로컬 파일을 찾아보면 목록에서 확장자를 가진 파일만 선택할 수 있다는 것을 알 수 있습니다. 허용되지 않는 파일을 드래그 앤 드롭하려고 하면 오류가 발생합니다.

이제 젠코더가 지원할 수 있는 파일만 업로드할 것이므로 업로드가 성공하면 해당 파일이 인코딩을 위해 젠코더로 전송되도록 만들어 보겠습니다. 그러기 전에 Zencoder API 키를 설정해야 합니다. 파일 선택기 키 바로 아래에 이 키를 포함하면 됩니다.

filepicker.setKey('The_Key_From_Your_Dashboard');
var zenKey = 'Zencoder_API_Key';

이제 jQuery의 $.ajax 를 클릭하여 업로드가 성공하면 Zencoder에 API 요청을 전송합니다.

filepicker.pickAndStore({extensions: acceptedExtensions},{location: 's3'},function(fpfiles){
  // This is the simplest Zencoder API call you can make. This will output an h.264 mp4 with AAC audio and
  // save it to Zencoder's temporary storage on S3.
  var request = {
    "input": fpfiles[0].url
  }
  // Let's use $.ajax instead of $.post so we can specify custom headers.
  $.ajax({
      url: 'https://app.zencoder.com/api/v2/jobs',
      type: 'POST',
      data: JSON.stringify(request),
      headers: { "Zencoder-Api-Key": zenKey },
      dataType: 'json',
      success: function(data) {
        $('body').append('Job created! <a href="https://app.zencoder.com/jobs/'+ data.id +'">View Job</a>')
      },
      error: function(data) {
        console.log(data);
      }
  });
});

이제 페이지를 새로고침하고 동영상을 업로드합니다. 모든 것이 계획대로 진행되었다면 새로 만든 작업에 대한 링크가 포함된 성공 메시지가 표시될 것입니다.

47줄의 코드만 입력하면 동영상을 업로드하고 인코딩을 위해 전송할 수 있는 웹 페이지를 만들 수 있습니다.

참고 및 경고

젠코더 API 키를 자바스크립트 내부에 일반 텍스트로 넣는 것은 좋지 않습니다. 다시 한 번 강조합니다: 다른 사람이 액세스할 수 있는 코드에 사용하지 마세요. 다른 사람이 API 키를 가져가서 원하는 모든 동영상을 인코딩하는 것을 막을 수는 없습니다.

훨씬 더 좋은 방법은 설명한 대로 Filepicker를 사용하되 실제로는 API 키가 노출되지 않는 백엔드에서 Zencoder API 호출을 하는 것입니다.

한 단계 더 발전하기

드래그 앤 드롭은 정말 멋지므로 전체 페이지에 Filepicker의 makeDropPane. 사용자는 어떤 작업을 수행하기 전에 API 키를 입력해야 하며 코드에 저장되지 않으므로 데모 를 온라인에 올려도 안전합니다.

이 버전은 API 키의 유효성을 검사하고, 최근 Zencoder 작업 내역을 포함하며, 요청 템플릿을 수정할 수 있습니다. 이러한 모든 설정은 브라우저의 로컬 저장소에 저장되므로 새로 고침 시 모든 설정이 손실되지 않습니다.