웹에서 비디오 재생: 비디오 전송 모범 사례(2부)

이전 게시물에서 HTTP 아카이브의 데이터를 사용하여 오늘 웹상의 비디오 트렌드를 조사했습니다. 많은 웹사이트가 모바일 과 데스크톱에서 동일한 비디오 콘텐츠를 제공하며 많은 비디오 스트림이 3G 속도 연결에서 재생하기에는 너무 높은 비트 전송률로 전달되고 있음을 발견했습니다. 또한 웹사이트가 자동으로 모바일 장치에 비디오를 다운로드하여 재생되지 않을 수도 있는 비디오에 대해 고객의 데이터 요금제, 배터리 수명을 손상시킬 수 있음을 발견했습니다.

핵심 : 이 게시물에서는 고객에게 비디오의 속도와 전달을 최적화하는 기술을 살펴보고 비디오 자산을 전달하는 데 도움이 되는 9가지 모범 사례 목록을 제공합니다.

비디오 재생 지표

현재 사용 중인 3가지 주요 동영상 재생 측정항목이 있습니다.

1. 비디오 시작 시간
2. 비디오 지연
3. 비디오 품질

동영상 파일이 크기 때문에 동영상을 최대한 작게 최적화하면 동영상 전송 속도가 빨라지고, 동영상 시작 속도가 빨라지고, 스톨 횟수가 줄어들고, 전달되는 동영상 품질의 영향이 최소화됩니다. 물론 시작 속도와 지연의 균형을 세 번째 품질 측정 기준과 균형을 맞춰야 합니다(높은 품질의 비디오는 일반적으로 더 많은 데이터를 사용함).

비디오 시작

사용자가 비디오에서 재생을 누르면 비디오를 빨리 볼 수 있기를 기대합니다. Conviva(비디오 메트릭 분석의 선두 주자)에 따르면 2018년 1분기에 사용자가 재생을 누른 후 비디오의 14%가 재생을 시작하지 않았습니다(즉, 24억 개의 비디오 재생).

2.3%의 동영상(4억 동영상 요청)은 사용자가 재생 버튼을 누른 후 재생에 실패했습니다. 11.54%(2B 재생)는 재생을 누른 후 사용자가 포기했습니다. 이러한 문제를 일으킬 수 있는 원인을 분석해 보겠습니다.

비디오 재생 실패

동영상 재생 실패는 전체 동영상 재생의 2.3%를 차지했습니다. 무엇이 이것으로 이어질 수 있습니까? HTTP 아카이브 데이터에서 모든 비디오 요청의 0.3%가 4xx 또는 5xx HTTP 응답으로 이어지는 것을 확인하므로 일부 비율은 잘못된 URL 또는 서버 구성 오류에 실패합니다. HTTP 아카이브 데이터에서 관찰되지 않는 또 다른 잠재적인 문제는 지리적 위치에 의해 차단된 비디오입니다(시청자의 위치 및 해당 언어로 비디오를 표시하기 위한 공급자의 라이선스에 따라 차단됨).

비디오 재생 포기

Conviva 보고서에 따르면 모든 동영상 재생의 11.5% 가 재생되지만 고객은 동영상 재생이 시작되기 전에 재생을 포기했습니다. 여기서 문제는 비디오가 고객에게 충분히 빨리 전달되지 않고 고객이 포기한다는 것입니다. 모바일 웹에서 오랜 지연이 웹페이지 이탈을 유발한다는 연구들이 많이 있으며, 동영상 재생에서도 동일한 효과가 나타나는 것으로 보인다.

Akamai의 연구에 따르면 시청자는 2초 동안 기다리지만 이후 1초마다 시청자의 5.8%가 동영상을 포기합니다.

그렇다면 비디오 재생 문제의 원인은 무엇입니까? 일반적으로 파일이 크면 다운로드하는 데 시간이 오래 걸리므로 재생이 지연됩니다. 동영상 재생 속도를 높일 수 있는 몇 가지 방법을 살펴보겠습니다. 시작 시 중단된 비디오의 수를 줄이려면 이러한 파일을 최대한 '축소'하여 빠르게 다운로드(및 재생 시작)해야 합니다.

MP4: 비디오 사전 로드

웹에서 빠른 재생을 보장하기 위해 한 가지 옵션은 비디오를 미리 장치에 미리 로드하는 것입니다. 이렇게 하면 고객이 '재생'을 클릭하면 이미 비디오가 다운로드되어 재생이 빨라집니다. HTML은 auto , metadata 및 none 의 3가지 가능한 옵션이 있는 preload 속성을 제공합니다.

preload = auto

비디오가 preload="auto" 로 전달되면 브라우저는 전체 비디오 파일을 다운로드하여 로컬에 저장합니다. 비디오를 장치에서 로컬로 사용할 수 있고 네트워크 간섭이 없어 시작 속도가 느려지므로 비디오 시작 시 성능이 크게 향상됩니다.

그러나 preload="auto" 는 비디오를 볼 가능성이 높은 경우에만 사용해야 합니다. 비디오가 단순히 웹페이지에 있고 매번 다운로드되는 경우 모바일 사용자에게 큰 데이터 패널티가 추가될 뿐만 아니라 전체 비디오를 모든 사용자에게 전달하기 위한 서버/CDN 비용이 증가합니다.

이 웹사이트에는 여러 비디오가 있는 "비디오 갤러리" 섹션이 있습니다. 이 섹션의 각 비디오에는 사전 로드가 auto 로 설정되어 있으며 WebPageTest 폭포에서 다운로드를 녹색 수평선으로 시각화할 수 있습니다.

"비디오 갤러리"라는 섹션이 있으며 웹 사이트의 이 작은 섹션에 대한 파일이 페이지 다운로드의 1460만(83%)을 차지합니다. 많은 동영상 중 하나가 재생될 확률은 매우 낮으므로 preload="auto" 를 사용하면 사이트에 대한 많은 데이터 트래픽만 생성됩니다.

이 경우 이러한 비디오 중 하나만 볼 가능성은 거의 없지만 모든 비디오가 완전히 다운로드되어 모바일 사이트에 14.8MB의 콘텐츠가 추가됩니다(페이지 콘텐츠의 83%). 재생 가능성이 높은 동영상의 경우(페이지 조회수의 90%가 동영상 재생으로 이어짐) 전체 동영상을 미리 로드하는 것은 매우 좋은 생각입니다. 그러나 재생 가능성이 낮은 비디오의 경우 preload="auto" 는 서버와 고객의 모바일(및 데스크톱) 장치를 통해 추가 콘텐츠 톤수만 발생시킵니다.

preload="metadata"

preload="metadata" 속성을 사용하면 비디오의 초기 세그먼트가 다운로드됩니다. 이를 통해 플레이어는 비디오 창의 크기를 알 수 있으며 즉시 재생을 위해 두 번째 또는 두 번째 비디오를 다운로드할 수 있습니다. 브라우저는 단순히 비디오 콘텐츠의 206(부분 요청)을 만듭니다. 소량의 비디오 데이터를 장치에 저장하면 전송되는 데이터 양에 큰 영향을 미치지 않으면서 비디오 시작 시간이 단축됩니다.

Chrome에서 속성을 선택하지 않으면 메타데이터가 기본 선택입니다.

참고 : 비디오가 큰 경우 다운로드할 비디오의 양이 여전히 많을 수 있습니다.

예를 들어, 동영상이 preload="metadata" 로 설정된 모바일 웹사이트에서 동영상에 대한 요청이 하나만 표시됩니다.

그리고 요청은 부분 다운로드이지만 전체 비디오가 1080p, 길이 150초 및 97MB이기 때문에 여전히 2.7MB의 비디오가 다운로드됩니다(다음 섹션에서 비디오 크기 최적화에 대해 설명함).

따라서 사용자가 비디오를 볼 가능성이 상당히 높거나 비디오가 작은 경우에만 preload="metadata" 를 계속 사용하는 것이 좋습니다.

preload="none"

페이지가 로드될 때 비디오 파일이 다운로드되지 않으므로 가장 경제적인 비디오 다운로드 옵션입니다. 이렇게 하면 재생이 지연될 수 있지만 초기 페이지 로드가 빨라집니다. 한 페이지에 많은 비디오가 있는 사이트의 경우 비디오 창에 포스터를 추가하고 비디오가 끝날 때까지 비디오를 다운로드하지 않는 것이 좋습니다. 최종 사용자가 명시적으로 요청한 경우. 웹사이트에 삽입된 모든 YouTube 동영상은 재생 버튼을 누를 때까지 동영상 콘텐츠를 다운로드하지 않으며 기본적으로 preload="none" 처럼 작동합니다.

사전 로드 모범 사례 : 비디오를 시청할 가능성이 높은 경우 에만 preload="auto" 를 사용하십시오. 일반적으로 preload="metadata" 를 사용하면 데이터 사용량과 시작 시간의 균형이 잘 맞지만 과도한 데이터 사용량이 있는지 모니터링해야 합니다.

MP4 비디오 재생 팁

이제 비디오가 시작되었으므로 비디오 재생이 지연되지 않고 계속 재생되도록 최적화할 수 있는 방법은 무엇입니까? 다시 말하지만, 트릭은 비디오를 가능한 한 작게 만드는 것입니다.

비디오 다운로드 크기를 최적화하는 몇 가지 트릭을 살펴보겠습니다. 비디오 크기를 줄이기 위해 최적화할 수 있는 비디오의 여러 차원이 있습니다.

오디오

비디오 파일은 여러 "스트림"으로 분할됩니다. 가장 일반적인 것은 비디오 스트림입니다. 두 번째로 가장 일반적인 스트림은 비디오와 동기화되는 오디오 트랙입니다. 일부 비디오 재생 응용 프로그램에서는 오디오 스트림이 별도로 제공됩니다. 이를 통해 다양한 언어를 원활하게 전달할 수 있습니다.

동영상이 자동으로 재생되는 경우(예: 반복되는 GIF 또는 배경 동영상) 동영상에서 오디오 스트림을 제거하면 파일 크기를 빠르고 쉽게 줄일 수 있습니다. 배경 동영상의 한 예에서 전체 파일은 5.3MB였지만 오디오 트랙(듣지 않음)은 거의 300KB(파일의 5%)였습니다. 오디오를 간단하게 제거하면 파일이 낭비되지 않고 빠르게 전달됩니다. 바이트.

HTTP 아카이브에서 찾은 MP4 파일의 42%에는 오디오 스트림이 없습니다.

모범 사례 : 자동으로 재생되는 비디오에서 오디오 트랙을 제거합니다.

비디오 인코딩

비디오를 인코딩할 때 비디오 품질(프레임당 픽셀 수 또는 초당 프레임 수)을 줄이는 옵션이 있습니다. 고품질 비디오를 웹에 적합하도록 줄이는 것은 간단하며 일반적으로 최종 사용자에게 전달되는 품질에 영향을 미치지 않습니다. 이 기사는 비디오에 사용할 수 있는 모든 다양한 압축 기술에 대해 심도 있게 논의하기에 충분하지 않습니다. x264 및 x265 인코더에는 CRF (Constant Rate F Actor )라는 용어가 있습니다. 23-28의 CRF를 사용하면 일반적으로 우수한 압축/품질 트레이드 오프를 제공하며 비디오 압축 영역으로의 훌륭한 첫 시작입니다.

비디오 크기

비디오 크기는 길이, 너비 및 높이와 같은 다양한 차원의 영향을 받을 수 있습니다(여기에 오디오도 포함할 수 있음).

비디오 길이

비디오 길이는 일반적으로 웹 개발자가 조정할 수 있는 기능이 아닙니다. 동영상이 3분 동안 재생되면 3분 동안 재생됩니다. 비디오가 예외적으로 긴 경우 preload="none" 또는 비디오 스트리밍과 같은 도구를 사용하면 초기에 더 적은 양의 데이터를 다운로드하여 페이지 로드 시간을 줄일 수 있습니다.

비디오 크기

HTTP 아카이브에서 찾은 모든 비디오의 18%는 모바일과 데스크톱에서 동일합니다. 반응형 웹 디자인 작업을 해본 사람은 화면이 작을수록 이미지 크기가 훨씬 작기 때문에 다양한 뷰포트에 맞게 이미지를 최적화하면 로드 시간을 크게 줄일 수 있다는 것을 알고 있습니다.

동영상도 마찬가지입니다. 30MB 2560×1226 배경 비디오가 있는 웹사이트는 모바일에서 비디오를 다운로드하는 데 어려움을 겪을 것입니다(데스크톱에서도 마찬가지일 것입니다!). 비디오 크기를 조정하면 파일 크기가 크게 줄어들고 3~4개의 다른 배경 비디오를 제공할 수도 있습니다.

이제 불행히도 브라우저는 HTML의 비디오에 대한 미디어 쿼리를 지원하지 않습니다. 즉, 다음과 같이 작동하지 않습니다.

 <video preload="auto" autoplay muted controls source src="large.mp4" </video>

따라서 원하는 비디오를 다양한 화면 크기로 전달하기 위해 작은 JS 래퍼를 만들어야 합니다. 그러나 우리가 거기에 가기 전에...

비디오를 다운로드하지만 보기에서 숨기기

초기 반응형 웹에 대한 또 다른 후퇴는 전체 크기 이미지를 다운로드하지만 모바일 장치에서는 숨기는 것입니다. 고객은 큰 이미지를 다운로드하는 데 지연이 발생하고(모바일 데이터 요금제에 영향을 미치고 배터리가 추가로 소모되는 등) 실제로 이미지를 보는 이점이 없습니다. 이것은 모바일의 비디오에서 매우 자주 발생합니다. 따라서 스크립트를 작성할 때 더 작은 화면이 처음부터 나타나지 않을 비디오를 요청하지 않도록 할 수 있습니다.

망막 품질 비디오

기기 화면 밀도에 따라 동영상이 다를 수 있습니다. 이로 인해 모바일 고객에게 비디오를 다운로드하는 데 시간이 추가될 수 있습니다. 더 작은 화면 장치 또는 제한된 네트워크 대역폭을 가진 장치에서 레티나 비디오를 방지하여 이러한 장치의 표준 품질 비디오로 돌아가지 않도록 할 수 있습니다. Network Information API와 같은 도구는 네트워크 처리량을 제공하고 고객에게 제공할 비디오 품질을 결정하는 데 도움이 됩니다.

장치 크기 및 네트워크 품질에 따라 다양한 비디오 유형 다운로드

우리는 더 작은 화면으로 영화 전달을 최적화하는 몇 가지 방법을 다루었고 또한 비디오 태그가 비디오 유형 중에서 선택할 수 없다는 점에 주목했습니다. 따라서 다음은 화면 너비를 사용하는 빠른 JS 스니펫입니다.

• 500px 미만의 화면에서는 비디오를 제공하지 않습니다.
• 화면 500-1400에 작은 비디오를 제공합니다.
• 다른 모든 장치에 더 큰 크기의 비디오를 제공합니다.

 <html><body> <div> </div> <div></div> <script> //get screen width and pixel ratio var width = screen.width; var dpr = window.devicePixelRatio; //initialise 2 videos — //“small” is 960 pixels wide (2.6 MB), large is 1920 pixels wide (10 MB) var smallVideo="https://res.cloudinary.com/dougsillars/video/upload/w_960/v1534228645/30s4kbbb_oblsgc.mp4"; var bigVideo = "https://res.cloudinary.com/dougsillars/video/upload/w_1920/v1534228645/30s4kbbb_oblsgc.mp4"; //TODO add logic on adding retina videos if (width<500){ console.log("this is a very small screen, no video will be requested"); } else if (width< 1400){ console.log("let's call this mobile sized"); var videoTag = "\<video preload=\"auto\" width=\"100%\" autoplay muted controls src=\"" +smallVideo +"\"/\>"; console.log(videoTag); document.getElementById('video').innerHTML = videoTag; document.getElementById('text').innerHTML = "This is a small video."; } else{ var videoTag = "\<video preload=\"auto\" width=\"100%\" autoplay muted controls src=\"" +bigVideo +"\"/\>"; document.getElementById('video').innerHTML = videoTag; document.getElementById('text').innerHTML = "This is a big video."; } </script> </html></body>

이 스크립트는 사용자 화면을 세 가지 옵션으로 나눕니다.

1. 500픽셀 미만에서는 비디오가 표시되지 않습니다.
2. 500에서 1400 사이에 더 작은 비디오가 있습니다.
3. 1400픽셀 이상의 와이드 스크린의 경우 더 큰 비디오가 있습니다.

우리 페이지에는 두 가지 크기의 반응형 비디오가 있습니다. 하나는 모바일용이고 다른 하나는 데스크톱 크기 화면용입니다. 모바일 사용자는 뛰어난 비디오 품질을 얻을 수 있지만 파일은 데스크톱용 10MB 비디오에 비해 2.6MB에 불과합니다.

애니메이션 GIF

애니메이션 GIF는 큰 파일입니다. aGIF와 비디오 파일 모두 너비 및 높이 치수를 통해 데이터를 압축하는 반면 비디오 파일만 압축(종종 더 큰) 시간 축을 갖습니다. aGIF는 본질적으로 정적 GIF 이미지를 빠르게 "뒤집기"합니다. 이러한 압축 부족으로 인해 상당한 양의 데이터가 추가됩니다. 고맙게도 GIF를 루핑 비디오로 교체할 수 있어 각 요청에 대해 MB의 데이터를 잠재적으로 절약할 수 있습니다.

 <video loop autoplay muted playsinline src="pseudoGif.mp4">

Safari에는 더 멋진 접근 방식이 있습니다. 다음과 같이 사진 태그에 반복되는 mp4를 배치할 수 있습니다.

 <picture> <source type="video/mp4" loop autoplay> <source type="image/webp"> <src="animated.gif"> </picture>

이 경우 Safari는 애니메이션 GIF를 재생하는 반면 Chrome(및 WebP를 지원하는 기타 브라우저)은 애니메이션 GIF로 대체하여 애니메이션 WebP를 재생합니다. Colin Bendell의 훌륭한 게시물에서 이 접근 방식에 대해 자세히 읽을 수 있습니다.

타사 비디오

웹사이트에 비디오를 추가하는 가장 쉬운 방법 중 하나는 비디오 공유 서비스에서 코드를 복사/붙여넣기하여 사이트에 넣는 것입니다. 그러나 사이트에 제3자를 추가하는 것과 마찬가지로 페이지에 추가되는 콘텐츠의 종류와 페이지 로드에 미치는 영향에 대해 주의를 기울여야 합니다. 이러한 "단순히 HTML에 붙여넣기" 위젯 중 다수는 100KB의 JavaScript를 추가합니다. 다른 사람들은 전체 영화를 다운로드할 것이고( preload="auto" 라고 생각하세요), 어떤 사람들은 둘 다 할 것입니다.

타사 비디오 모범 사례 : 신뢰하되 확인하십시오. 추가된 콘텐츠의 양과 페이지 로드 시간에 미치는 영향을 확인합니다. 또한 동작이 변경될 수 있으므로 분석을 통해 정기적으로 추적하십시오.

스트리밍 시작

비디오 스트림이 요청되면 서버는 사용 가능한 모든 스트림(크기 및 비트 전송률 정보 포함)을 나열하는 매니페스트 파일을 플레이어에 제공합니다. HLS 스트리밍에서 플레이어는 일반적으로 목록의 첫 번째 스트림을 선택하여 재생을 시작합니다. 따라서 매니페스트 파일의 첫 번째 위치에 있는 스트림은 모바일과 데스크톱 모두에서 비디오 시작에 최적화되어야 합니다(또는 대체 매니페스트 파일을 모바일과 데스크톱에 전달해야 함).

대부분의 경우 시작은 재생을 시작하기 위해 낮은 품질의 스트림을 사용하여 최적화됩니다. 플레이어가 몇 개의 세그먼트를 다운로드하면 사용 가능한 처리량에 대해 더 잘 알고 나중 세그먼트에 대해 더 높은 품질의 스트림을 선택할 수 있습니다. 사용자는 이것을 보았을 것입니다. 비디오의 처음 몇 초는 매우 픽셀화되어 보이지만 비디오를 재생하고 몇 초 후에는 선명해집니다.

HTTP 아카이브에서 모바일 장치로 전달된 1,065개의 매니페스트 파일을 조사한 결과, 비디오의 59%가 1.2MBPS 미만의 초기 비트 전송률을 가지며 1.6MBPS 3G 데이터 전송률에서 큰 지연 없이 스트리밍을 시작할 가능성이 있음을 발견했습니다. 11%는 1.2에서 1.6MBPS 사이의 비트 전송률을 사용하여 3G에서 시작 속도가 느려질 수 있고 30%는 1.6MBPS를 초과하는 비트 전송률을 가지며 3G 연결에서 이 비트 전송률로 재생할 수 없습니다. 이 데이터에 따르면 모든 비디오의 ~41%가 모바일에서 초기 비트 전송률을 유지할 수 없는 것으로 보이며 시작 지연이 추가되고 재생 중 지연 수가 증가할 수 있습니다.

스트리밍 시작 모범 사례 : 매니페스트 파일의 초기 비트 전송률이 대부분의 고객에게 적합한 것인지 확인하십시오. 플레이어가 시작하는 동안 스트림을 변경해야 하는 경우 재생이 지연되고 비디오 조회수를 잃게 됩니다.

그렇다면 비디오의 비트 전송률이 사용 가능한 처리량에 근접(또는 초과)되면 어떻게 됩니까? 재생 준비가 완료된 비디오 세그먼트 없이 몇 초 동안 다운로드한 후 플레이어는 다운로드를 중지하고 더 낮은 품질의 비트 전송률 비디오를 선택한 다음 프로세스를 다시 시작합니다. 비디오 세그먼트를 다운로드한 다음 중단하는 작업은 추가 시작 지연으로 이어져 비디오 중단으로 이어집니다.

다른 초기 비트 전송률로 비디오 매니페스트를 빌드하여 이를 시각화할 수 있습니다. 최저(215KBPS), 중간(600KBPS), 최고 비트 전송률(2.6MBPS)의 3가지 시나리오를 테스트합니다.

가장 낮은 화질의 동영상부터 재생이 시작되면 11초부터 재생이 시작됩니다. 몇 초 후 플레이어는 더 높은 품질의 스트림을 요청하기 시작하고 영상이 선명해집니다.

가장 높은 비트 전송률(1.6MBPS의 3G 연결에서 테스트)로 시작할 때 플레이어는 재생할 수 없다는 것을 빠르게 깨닫고 가장 낮은 비트 전송률 비디오(215KBPS)로 전환합니다. 비디오는 17초부터 재생을 시작합니다. 6초의 딜레이가 있으며, 영상 품질은 1차 테스트에서 전달한 저화질과 동일합니다.

중간 품질의 비디오를 사용하면 약간의 절충이 허용되며 비디오는 13초(2초 더 느림)에서 재생을 시작하지만 처음부터 고품질이며 픽셀화된 비디오에서 더 높은 품질의 비디오로 이동하지 않습니다.

비디오 시작을 위한 모범 사례 : 가장 빠른 재생을 위해 가장 낮은 품질의 스트림부터 시작하십시오. 더 긴 비디오의 경우 시작 시 '중간 품질' 스트림을 사용하여 시작 시 선명한 비디오를 제공하는 것을 고려할 수 있습니다(약간 더 긴 지연 포함).

WebPageTest 결과: 초기 비디오 스트림은 낮음, 중간 및 높음입니다(위에서 아래로). 비디오는 가장 낮은 품질의 비디오로 가장 빠르게 시작됩니다. 17초의 고품질 시작 비디오는 11초의 저화질 시작과 동일한 품질이라는 점에 유의하는 것이 중요합니다.

스트리밍: 계속 재생

비디오 플레이어가 재생을 위한 최적의 비디오 스트림을 결정할 수 있고 스트림이 사용 가능한 네트워크 속도보다 낮은 경우 비디오는 문제 없이 재생됩니다. 비디오가 최적의 방식으로 전달되도록 하는 데 도움이 되는 트릭이 있습니다. 다음 매니페스트 항목을 검사하면:

 #EXT-X-STREAM-INF:BANDWIDTH=912912,PROGRAM-ID=1,CODECS="avc1.42c01e,mp4a.40.2",RESOLUTION=640x360,SUBTITLES="subs" video/600k.m3u8

정보 라인은 이 스트림의 비트 전송률이 913KBPS이고 해상도가 640×360이라고 보고합니다. 이 줄이 가리키는 URL을 보면 600k 비디오를 참조한다는 것을 알 수 있습니다. 비디오 파일을 검사하면 비디오가 600KBPS이고 매니페스트가 비트 전송률을 과장하고 있음을 알 수 있습니다.

비디오 비트레이트 과장

• 찬성
  비트 전송률을 과장하면 플레이어가 스트림을 선택할 때 비디오가 예상보다 빨리 다운로드되고 버퍼가 예상보다 빨리 채워져 지연 가능성이 줄어듭니다.
• 범죄자
  비트 전송률을 과장하면 전달되는 비디오는 더 낮은 품질의 스트림이 됩니다. 보고된 비트레이트와 실제 비트레이트의 전체 목록을 보면 다음과 같습니다.

1.6MBPS 연결 사용자의 경우 플레이어는 913KBPS 비트 전송률을 선택하여 고객에게 600KBPS 비디오를 제공합니다. 그러나 비트 전송률이 정확하게 보고되었다면 950KBPS 비트 전송률이 사용되었으며 문제 없이 스트리밍되었을 것입니다. 여기에서 선택하면 지연이 방지되지만 소비자에게 전달되는 비디오의 품질도 떨어집니다.

모범 사례 : 비디오 비트 전송률을 약간 과장하면 재생 중단 수를 줄이는 데 유용할 수 있습니다. 그러나 값이 너무 크면 재생 품질이 저하될 수 있습니다.

브라우저에서 Neilsen 비디오를 테스트하고 앞뒤로 점프할 수 있는지 확인하십시오.

결론

이 게시물에서는 웹사이트에 표시하는 비디오를 최적화하는 여러 가지 방법을 살펴보았습니다. 이 게시물에 설명된 모범 사례를 따르면 다음과 같습니다.

1. preload="auto"
   고객이 이 동영상을 시청할 가능성이 높은 경우에만 사용하세요.
2. preload="metadata"
   Chrome의 기본값이지만 여전히 대용량 비디오 파일 다운로드로 이어질 수 있습니다. 주의해서 사용하십시오.
3. 무성 비디오 (루핑 GIF 또는 배경 비디오)
   오디오 채널 제거
4. 비디오 크기
   데스크탑을 통해 모바일에 다양한 크기의 비디오를 제공하는 것을 고려하십시오. 비디오는 더 작아지고 더 빨리 다운로드되며 사용자는 차이를 느끼지 못할 것입니다(서버 부하도 낮아집니다!)
5. 비디오 압축
   비디오를 압축하여 전달하는 것을 잊지 마십시오.
6. 동영상 '숨기기' 금지
   비디오가 표시되지 않으면 다운로드하지 마십시오.
7. 정기적으로 타사 비디오 감사
8. 스트리밍
   빠른 시작을 위해 낮은 품질의 스트림으로 시작하십시오. (장시간 재생 비디오의 경우 시작 시 더 나은 품질을 위해 중간 비트 전송률을 고려하십시오)
9. 스트리밍
   지연을 방지하기 위해 비트 전송률에 대해 보수적인 것은 괜찮지만 너무 지나치면 스트림이 더 낮은 품질의 비디오를 제공합니다.

귀하의 페이지에 있는 비디오는 최적의 전달을 위해 간소화되었으며 귀하의 고객은 귀하가 제공하는 비디오에 만족할 뿐만 아니라 전반적으로 더 빠른 페이지 로드 시간을 즐길 수 있습니다.