애플 사파리와 구글 크롬에서 자동 재생이 변경된다는 소식을 듣고 자세한 내용을 알고 싶으셨을 것입니다. 이 글에서는 동영상 요소의 역사와 브라우저에서 자동 재생이 동영상 지원을 형성한 방식, 발생했던 문제와 해결 방법, 최상의 자동 재생 동작을 위한 개발자를 위한 권장 사항, 향후 웹에서 자동 재생에 대해 기대할 수 있는 사항에 대해 살펴봅니다.

전체 게시글을 읽고 싶지 않으시다면 요점은 다음과 같습니다. autoplay 속성을 사용하면 작동하지만 최상의 지원을 받으려면 autoplay 속성을 사용하고 play() 메서드를 사용하여 반환되는 플레이 프로미스를 활용할 수 있습니다.

배경

2007년 2월, Opera는 웹에서의 동영상 사용을 촉구하는 선언문을 발표했습니다. 이와 함께 현재 우리가 잘 알고 있고 사랑하고 있는 <video> 요소입니다. The WHATWG 는 이 사양을 빠르게 채택했으며, 다른 브라우저들도 다음 해에 지원을 도입하기 시작했습니다.

Apple은 2008년 3월 iOS와 데스크톱에서 Safari 3.1을 출시하면서 동영상 요소를 최초로 지원한 업체 중 하나입니다. 2009년 6월에는 Mozilla Firefox가 뒤를 이었습니다. 구글 크롬은 2009년 10월에 출시되었습니다. Internet Explorer는 다소 늦게 2011년 3월에 IE9을 출시하고 동영상 요소를 지원했습니다.

2011년 3월까지 자동 재생 기능을 제한한 Apple의 iOS를 제외하고 데스크톱용 Opera, IE, Firefox, Chrome, Safari에서 자동 재생을 지원했습니다. 이는 배터리 및 사용자 환경 문제, 특히 iPhone의 동영상이 항상 인라인으로 재생되지 않고 기본 플레이어로 실행되었기 때문이었습니다.

2008년부터 2016년 사이에 배터리 수명이 크게 향상되고 웹상의 동영상이 급증했습니다. 동영상의 엄청난 성장과 함께 iOS 10에서 Apple은 iPhone과 iPad에서 미디어를 자동 재생하는 기능을 도입했습니다. 하지만 동영상이 음소거되어 있거나 오디오 트랙이 없어야 한다는 단점이 있었습니다. 또한 iPhone에서는 동영상이 인라인으로 재생되도록 허용되어야 합니다. playsinline 속성입니다.

애플이 음소거 자동재생을 도입한 후 구글도 이를 따라 안드로이드용 크롬 53에 이 기능을 도입했습니다. 그 후 몇 달 동안 Google은 광고 SDK 제공업체와 함께 새로운 자동 재생 동작과 관련된 문제를 해결하기 위해 노력했습니다.

2017년 6월, Apple은 Safari 11부터 데스크톱에서도 동일한 자동 재생 동작, 즉 음소거되지 않은 자동 재생이 거부되는 기능을 포함할 것이라고 발표했습니다. 이 발표를 계기로 저희는 한 발 물러서서 자동 재생과 관련된 문제, 특히 광고와 관련된 문제가 모두 같은 곳에서 비롯된 것인지 생각해보는 것이 가장 좋다고 생각했습니다. 플레이어 기능의 근본적인 변화로서 자동 재생을 다뤄야 할 때였습니다.

2017년 9월, 구글은 구글 크롬에도 이와 유사한 변경 사항을 적용한다고 발표했습니다: 바로 통합 자동 재생입니다. Apple과 달리 Google은 한 단계 더 나아가 음소거 자동 재생을 허용하는 것 외에도 사용자가 사이트와 상호 작용했거나 미디어 참여 지수 (MEI)를 넘은 경우 자동 재생을 허용할 예정입니다. MEI는 각 웹사이트에 할당되며 사용자가 페이지와 얼마나 상호 작용하는지, 사용자가 동영상을 보거나 오디오를 듣는지 추적합니다. 이렇게 하면 YouTube나 Netflix와 같이 동영상이 핵심 기능인 사이트는 미디어 참여 지수가 높으며 음소거 해제 재생을 위해 사용자 제스처를 기다릴 필요가 없습니다. 그러나 사용자가 이전에 방문한 적이 없는 사이트는 소리와 함께 동영상을 자동 재생할 수 없습니다. 이 기능은 2018년 초에 구글 크롬 64의 일부로 출시될 예정입니다.

문제와 우리가 한 일

철저한 테스트 결과, 플레이어에 근본적으로 변경해야 할 사항은 많지 않은 것으로 나타났습니다. 주요 문제는 Video.js가 생성한 동영상 요소에 자동 재생이 추가되도록 하는 방식과 브라우저가 해당 HTML 속성 및 속성을 처리하는 방식이 일치하지 않는 데서 발생했습니다.

첫 번째 문제는 초기화하는 동안 Video.js 설정이 autoplay 을 동영상 요소의 첫 번째 속성으로 설정하고, 그 다음에 muted 그리고 playsinline 가 포함되었습니다. Chrome은 이러한 속성이 설정되면 자동 재생 검사를 다시 실행했지만 Safari와 iOS는 그렇지 않았습니다. 그래서 저희는 autoplay 속성이 설정된 후에만 muted 그리고 playsinline 가 제공되었습니다.

두 번째 문제는 HTML 속성 및 속성과 관련된 브라우저 불일치 문제였습니다. 예를 들어 다음과 같이 HTML 속성을 사용하여 자동 재생, 음소거 플레이어를 만들 수 있습니다:

<video autoplay muted playsinline>

이것은 작동했지만 다음과 같이 프로그래밍 방식으로 시도하면 작동하지 않았습니다:

video.muted = true;
video.autoplay = true;

일부 iOS 디바이스에서는 동영상이 실제로 음소거되지 않았기 때문에 작동하지 않았습니다. 대신 속성과 속성을 설정해야 했으며, 여러 기기의 단면이 다른 경우 다음 호출만으로는 작동하지 않았습니다. setAttribute. 이를 통해 다음과 같은 결과를 얻을 수 있습니다:

video.muted = true;
 // muted is a boolean attribute, so, any value turns it on, using the name of the attribute is an often used convention
video.setAttribute(‘muted’, ‘muted’);
video.autoplay = true;
video.setAttribute(‘autoplay’, ‘autoplay’);

그리고 muted 문제가 더 커졌습니다. Video.js를 사용하여 동영상이 음소거되었는지 확인할 때 가끔 잘못된 응답을 받는 경우가 있었습니다. Video.js는 속성 값을 사용하여 설정 여부를 확인하지만, 속성을 사용하여 기능이 설정된 경우 속성이 해당 값을 반영하도록 설정되지 않은 경우도 있습니다. 따라서 다음과 같은 임베드 코드를 사용합니다:

<video muted>

우리는 얻을 것입니다 false 플레이어에게 음소거 값을 물어봤을 때:

player.muted();
// -> false

그래서 내부적으로 각 설정이 속성과 프로퍼티를 모두 설정하고 각 게터가 두 가지를 모두 확인하도록 했습니다.

자동 재생의 새로운 상태

이제 이러한 변경 사항을 사용할 수 있으므로 자동 재생이 잘 작동하죠? 아니요.... 자동 재생 거부는 올바른 조건이 충족되지 않을 때 작동하는 방식(예 muted 를 Safari 11, iOS 및 Android용 Chrome에서 사용할 수 있을 뿐만 아니라 playsinline 아이폰의 경우) 자동 재생이 거부되었는지 아니면 사용자가 방금 재생을 누른 후 바로 일시정지를 했는지 감지하기 어렵습니다. 이는 광고 SDK가 고려해야 할 사항이며, 크리테오에서 다음과 같이 발견한 사항입니다. 알려진 문제 를 참조하세요. 모바일의 경우, 대부분의 광고 SDK는 이미 적절한 지원을 위해 업데이트되었지만 이 글을 작성하는 현재 광고 SDK에서 Safari 11을 공식적으로 지원하지 않습니다.

플레이 약속

최근 몇 년 동안 브라우저는 비동기 프로세스와 그 반환값을 나타내는 프로미스(Promise)를 재생 함수에서 반환하도록 업데이트되었습니다. 프로미스를 통해 재생 성공 여부를 알 수 있습니다. 프로미스가 해결되면 플레이가 성공한 것이고, 프로미스가 거부되면 플레이가 실패한 것입니다. 이전에는 동영상을 재생할 수 없는 경우와 동영상이 성공적으로 재생되기 전에 사용자(또는 다른 스크립트)가 동영상을 재생한 직후 일시 중지한 경우 두 가지 주요 이유로 프로미스가 거부되었습니다.

이제 재생 약속에 대한 새로운 거부 사유가 생겼습니다. 동영상이 음소거되거나 무음 상태가 아닌 경우 자동 재생을 거부하는 플랫폼(또는 iPhone에서 인라인 재생이 허용되는 플랫폼)을 사용하는 경우 약속이 거부됩니다.

또한 플레이 약속은 자동 재생이 거부되었는지 여부를 알 수 있는 유일한 방법(현재)이므로 브라우저 공급업체는 자동 재생이 거부되었는지 여부를 알기 위해 play() 메서드에 대한 autoplay 속성입니다.

추천

변경 사항을 적용하면 다음과 같습니다. autoplay 속성은 계속 작동하며 최선을 다해 계속 작동합니다. 그러나 play() 방법을 사용하는 것이 좋습니다.

첫째, 브라우저 공급업체 자체에서 이 기능을 사용할 것을 권장합니다. autoplay 속성에 대한 조언을 따르는 것이 좋습니다.

두 번째는 play() 메서드를 사용하면 플레이어 개발자는 약속을 들을 때 자동 재생이 성공했는지 여부를 알 수 있습니다:

player.play().then(function() {
  // play succeeded!
})
.catch(function(error) {
  // play failed
  console.error(error.message);
});

그런 다음 자동 재생이 거부되면 메시지를 올리거나 대안을 마련할 수 있습니다.

셋째, 다음과 같은 경우 play() 메서드가 플레이어에서 사용되면 플레이어는 생성된 프로미스를 저장하고 내부적으로 사용하여 자동 재생이 거부되어 발생하는 에지 케이스에 대한 처리를 더욱 개선할 수 있습니다.

요약하면, 계속 사용할 수 있습니다. autoplay 속성을 사용하면 작동하지만 최상의 지원을 받으려면 autoplay 속성을 사용하고 play() 메서드를 사용하여 반환되는 플레이 프로미스를 활용할 수 있습니다.

자동 재생의 미래

자동 재생의 미래는 어떤 면에서는 자동 재생의 죽음과도 같습니다. Apple은 전반적으로 음소거된 자동 재생만 허용하고 음소거 해제 재생 시에는 사용자 제스처를 요구한다는 상당히 엄격한 자동 재생 정책을 따르고 있습니다. 이 정책의 장점은 데스크톱과 모바일이 일관성이 있다는 것입니다. Google은 사용자가 해당 세션에서 웹사이트와 상호 작용했거나 사용자가 동영상을 보기 위해 자주 방문하는 사이트가 아닌 한 음소거된 자동 재생만 허용하는 약간 더 완화된 정책을 적용하고 있습니다. 하지만 구글의 통합 자동 재생은 자동 재생의 미래가 될 것입니다. 사용자를 돕기 위해 자동 재생에 제한을 두는 동시에 웹사이트가 대부분 그대로 작동할 수 있도록 합니다. 결국 모든 브라우저가 일관된 자동 재생 제한을 유지하기 위해 협력하여 개발자가 브라우저별 자동 재생 동작을 타겟팅하지 않아도 되기를 바랍니다. 자동 재생의 미래는 통합된 자동 재생이 되기를 바랍니다.

알려진 문제

• 자동 재생을 거부하는 플랫폼에서는 음소거 없이 자동 재생되는 자동 광고(오디오 트랙이 없는 광고)가 자동 재생됩니다. 그러나 광고가 완료되면 플레이어가 음소거되지 않았고 사용자 액션이 제공되지 않았기 때문에 콘텐츠가 다시 시작되지 않습니다. 이는 IMA 및 프리휠에 적용됩니다.
• 플레이어가 음소거된 상태에서 자동 재생이 시작되고 사용자가 광고의 음소거를 해제하면 사용자 동작이 제공되지 않고 플레이어가 더 이상 음소거되지 않으므로 콘텐츠가 다시 시작되지 않습니다.
• 광고에 오디오가 포함되어 있지만 플랫폼에서 자동 재생을 거부하는 경우(예: Safari 11), 자동 재생이 거부되면 광고에 문제가 있는 것으로 간주합니다. 광고 시간 초과 간격을 기다린 다음 플레이어가 음소거되지 않았고 사용자 액션이 제공되지 않았기 때문에 자동 재생되지 않는 콘텐츠로 다시 전환합니다.
• 자동 재생이 거부되었지만 playsinline 를 설정하면 브라이트코브 플레이어에서 큰 재생 버튼이 숨겨지고 컨트롤 바가 표시됩니다. 그러나 대부분의 경우 포스터 이미지는 여전히 표시되어야 합니다. 이는 자동 재생 거부가 작동하는 방식 때문입니다. autoplay 속성입니다.