크기 및 품질에 대한 비디오 최적화
게시 됨: 2022-03-10지난 몇 년 동안 점점 더 많은 프로젝트에서 비디오를 응용 프로그램의 필수적인 부분으로 사용하고 있습니다. 동영상은 정지 사진보다 더 매력적이며(동영상은 전환율을 두 배로 늘리고 사이트에서 보내는 시간을 늘릴 수 있음) 고객이 제품 및 서비스에 대한 세부 정보를 탐색하도록 유도할 수 있으므로 이는 좋은 방향입니다. 그러나 비디오 재생과 관련된 문제가 있는 경우 모든 것이 옆으로 이동합니다.
비디오 재생 문제 는 비디오의 크기 및 비트 전송률과 직접적인 관련이 있습니다. 크기가 크거나 비트 전송률이 높은 비디오는 다운로드하는 데 시간이 더 오래 걸리고 원활하게 재생하려면 더 빠른 속도의 네트워크가 필요합니다. 이로 인해 시작 시간이 길어지고 네트워크에서 비디오를 충분히 빠르게 제공할 수 없는 경우 비디오 재생 중에 비디오가 중단됩니다.
그래도 해결책이 있습니다! 비디오를 웹사이트에 추가하기 전에 기본 최적화를 실행하면 이러한 문제가 발생하는 것을 방지할 수 있습니다. 어떤 식으로든 파일을 더 작게 만들기만 하면 됩니다. 이제 트릭은 품질 저하 없이 파일을 작게 만드는 방법입니다.
이 기사에서는 재생을 위해 비디오를 최적화하기 위해 취할 수 있는 도구와 몇 가지 단계를 살펴보겠습니다.
실제 데이터
예를 들어 영웅 배경 비디오로 사용되는 매우 큰 비디오가 있는 웹사이트를 찾는 것은 드문 일이 아닙니다. 내 연구에서 2020년 12월 모바일 HTTPArchive에서 찾은 사이트를 조사하고 있었고 모바일과 데스크톱 모두에서 기본적으로 거대한 비디오 파일을 로드하는 사이트를 찾는 것이 어렵지 않았습니다.
물론 여기에서 보여드릴 것과 동일한 비용 절감 효과를 얻을 수 있을지는 의문입니다. 그러나 비디오를 다룰 때 염두에 두어야 할 몇 가지 유용한 포인터와 팁을 얻을 수 있을 것입니다. 사실, 주의하지 않으면 실수로 웹사이트에 매우 큰 비디오 를 배치하기가 매우 쉬워 대부분의 고객이 거의 사용할 수 없게 됩니다.
호박 패치 이야기
10월 중순이고 가족과 함께 주말 오후를 보낼 호박밭과 옥수수 미로를 찾고 있다고 상상해 보십시오. 데스크탑 컴퓨터에서 편안하게 웹에서 가까운 위치를 검색하고 완벽한 위치를 찾습니다. 웹 사이트는 페이지 상단에서 재생되는 필드의 아름다운 드론 4K 비디오 와 함께 멋지게 보입니다. URL을 선택하여 자신과 사랑하는 사람에게 보내 이동 중에도 이 옵션을 계속 탐색할 수 있습니다.
그러나 휴대폰에서 페이지를 열면 결함이 있음을 알 수 있습니다. 비디오가 휴대폰에서 필사적으로 재생을 시도하지만 불행히도 그렇게 하지 못합니다. 비디오는 계속해서 멈추고 다시 시작되어 컴퓨터에서보다 훨씬 더 혼란스럽고 짜증납니다. 결국 계속 이동하고 URL을 북마크에 추가하고 일상을 계속 진행합니다.
진흙 투성이의 즐거운 하루를 보낸 후(저는 최근에 시애틀과 영국에 살았으므로 호박 패치가 진흙 투성이입니다.) 컴퓨터로 다시 돌아왔습니다. 아마도 그 비디오에 대해 다시 생각하고 왜 재생되지 않았는지 궁금할 것입니다. 잘 당신의 전화에. 자, 무슨 일이 일어나고 있는지 진단해 봅시다.
브라우저에서 DevTools를 열어 시작할 수 있습니다. 페이지가 로드되면 네트워크 탭으로 이동하고 "미디어"로 필터링하여 모든 비디오 파일을 볼 수 있습니다.
MP4 파일이 다운로드되고 있는 것을 볼 수 있습니다. 파일은 독립 실행형 파일로 네트워크를 통해 제공되지 않습니다. 대신 스트리밍 서비스는 파일을 몇 개의 세그먼트 로 분할해야 하므로 동일한 파일에 대해 여러 개의 206
(부분 콘텐츠) 요청이 표시될 수 있습니다.
이 파일의 응답 헤더 를 보면 몇 가지 세부 정보를 찾을 수 있습니다.
accept-ranges: bytes access-control-allow-headers: x-test-header, Origin, X-Requested-With, Content-Type, Accept access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS Content-Length: 87690242 Content-Range: bytes 70025216-157715457/157715458 content-type: video/mp4 date: Fri, 22 Jan 2021 15:27:26 GMT last-modified: Mon, 24 Jun 2019 05:13:04 GMT server: Apache
이제 이 숫자 중 일부는 약간 크기 때문에 약간 무섭습니다. 사실, 파일이 너무 커서 쉼표를 추가하는 습관을 들이기 때문에 파일이 실제로 얼마나 큰지 알 수 있습니다. 이 경우 부분 다운로드는 87MB이고 전체 파일은 157,715,457바이트입니다. 예, 맞습니다. 이 비디오는 157MB이고 오늘 일찍 내 휴대전화에 로드하려고(시도했습니다)! 그것이 성공하지 못한 것은 당연합니다.
이 영상은 어때요?
조금 더 깊이 들어가 보겠습니다. 분명히 비디오는 메모리가 적고 네트워크가 느린 휴대 전화에서 원활하게 재생하기에는 너무 큽니다. 그러나 그것을 고치기 위해 무엇이 필요합니까? 문제가 정확히 무엇인지 파악하기 위해 공개 소스이며 무료이며 비디오를 최적화하는 가장 안정적인 도구 중 하나인 FFMPEG를 사용할 수 있습니다. FFMPEG에서 구성을 끝없이 조정할 수 있지만 이 기사에서 중요한 몇 가지만 만지겠습니다.
자, FFprobe라는 진단 도구부터 시작하겠습니다. FFprobe는 멀티미디어 스트림에서 정보를 수집하고 비디오 인코딩 방법 및 재생 방법에 대한 세부 정보를 제공합니다. FFMPEG 패키지의 일부이며 실제로 사용하기 쉽습니다.
더 좋은 점은 동영상이 이미 온라인에 있는 경우 바로 이동할 수 있는 ffprobe의 온라인 버전이 있다는 것입니다. 따라서 양식에 URL을 입력하고 그 대가로 비디오에 대한 세부 정보(예: 비디오 크기, 비트 전송률 및 상당한 양의 메타데이터)를 가져오도록 하겠습니다.
호박 농장에서 MP4 URL을 추가하면 즉시 문제 중 하나가 표시됩니다. ffprobe의 show_format
응답은 요약을 반환합니다. 분명히 2개의 스트림이 있고 길이는 62초입니다(모든 것이 의심되지 않을 만큼 충분히 정상으로 들립니다). 그러나 크기와 비트 전송률 에 도달하면 비디오가 어디에서 실패하는지 즉시 알 수 있습니다.
위에서 언급했듯이 이러한 큰 숫자에 쉼표를 추가하는 데 익숙해지는 것이 좋습니다. 실제로 필드 위를 비행하는 드론 영상은 157MB이고 비트 전송률은 초당 20MB입니다! 즉, 비디오가 원활하게 재생되려면 네트워크에서 20MBPS보다 빠른 속도로 비디오를 스트리밍 할 수 있어야 합니다.
이상적인 재생 비트 전송률은 얼마입니까?
지연을 방지하려면 적절한 속도로 비디오를 스트리밍 해야 합니다. 여기서 비트 전송률이 중요해집니다. 비트 전송률은 비디오의 재생 속도입니다. 브라우저가 비디오를 원활하게 재생하려면 비디오가 재생되는 것보다 더 빨리 다운로드되어야 합니다. 즉, 네트워크 속도가 20MBPS를 초과하는 경우에만 비디오가 원활하게 재생됩니다. 네트워크 속도를 생각할 때 WebPageTest의 트래픽 프로필에 의존하는 경향이 있습니다.
위의 개요에서 알 수 있듯이 비디오는 "네이티브 연결" 및 초고속 광 케이블 FIOS 연결에서 잘 재생 될 수 있습니다 (20MBPS는 정확히 필요한 속도이므로 다른 것은 다운로드할 필요가 없습니다. 배경). 그러나 다른 모든 연결의 다운링크 속도는 20MBPS보다 훨씬 낮습니다 . 비디오가 이러한 속도로 로드되는 경우 플레이어는 다운로드할 수 있는 것보다 더 빨리 비디오를 사용하려고 시도하고 비디오는 영구적으로 중단됩니다.
비디오의 비트 전송률은 고객이 사용할 수 있는 최소 네트워크 속도를 설정합니다. 일반적으로 비디오의 비트 전송률은 네트워크에서 사용 가능한 처리량의 약 80%여야 합니다 . 따라서 20MBPS 비디오가 비디오를 원활하게 재생하려면 실제로 24MBPS 네트워크 처리량이 필요합니다. 느린 연결을 사용하는 모든 사람은 매우 좋지 않은 경험을 하게 되며 비디오를 전혀 볼 수 없을 것입니다. 더 구체적으로 말하자면, 이는 우리가 4G에서 부드럽고 매끄럽게 플레이하려면 비트레이트가 7.2MBPS 미만 으로 유지되어야 함을 의미합니다.
이 비디오의 비트 전송률을 낮출 수 있습니까?
네! 이 비디오의 비트 전송률을 줄이는 데 사용할 수 있는 몇 가지 구성을 살펴보겠습니다. 하지만 먼저 FFprobe에서 얻은 데이터를 살펴보겠습니다. 상당히 눈에 띄는 한 가지는 비디오의 초당 프레임 r_frame_rate
값입니다. 값은 60000/1001입니다. 이는 비디오의 프레임 속도가 초당 60프레임임을 의미합니다. 그러나 웹의 일반적인 프레임 속도는 25–30이므로 가장 먼저 할 수 있는 일은 더 낮은 비트 전송률로 비디오를 다시 인코딩하는 것 입니다.
명심해야 할 또 다른 사항은 Constant Rate Factor 입니다. FFMPEG에서 주요 품질/크기 벤치마크는 0
(압축 없음)에서 50
(높은 압축) 사이의 값을 갖는 CRF(Constant Rate Factor) 압축입니다. FFMPEG에서 CRF의 기본값은 23
입니다(CRF 매개변수를 생략하면 비디오가 해당 값을 사용합니다). 내 개인적인 경험에 따르면 23-28의 값은 여전히 고품질 비디오 를 생성하고 웹에서 보기 좋고 파일 크기가 크게 줄어듭니다.
30fps와 23
의 CRF에서 시작하겠습니다. 터미널 명령은 다음과 같습니다.
ffmpeg -i input.mp4 -vcodec h264 -acodec aac -crf 23 -strict -2 :v fps=fps=30 output.mp4
짜잔! 그 결과 이미 48% 개선된 81.5MB 비디오가 생성됩니다. 그러나 비디오는 10MBPS 비트 전송률로 여전히 매우 큽니다. CRF를 28로 설정하면 파일은 35.4MB로 떨어지고 비트 전송률은 4.5MBPS로 4G 연결에서 잘 재생될 가능성이 훨씬 높습니다.
원본 동영상보다 5배 향상된 기능 입니다. 이 비디오를 더 쉽게 액세스할 수 있도록 비디오 크기를 조정하여 더 작게 만들 수 있습니다. 이는 아래 스트리밍 섹션에서 논의할 내용입니다.
배고픈 피자 이야기
당신이 로스 앤젤레스에 있다고 상상해보십시오. 아마도 해외에서 방문하여 전화로 로밍하고 물론 피자 한 조각을 먹을 생각을하고있을 것입니다. 휴대전화에서 놀라운 피자 가게를 발견하고 그곳으로 가기로 결정합니다. 페이지에서 몇 가지 비디오와 영웅 이미지를 보았을 수도 있지만 실제로 모든 피자 가게가 비슷해 보이기 때문에 비디오를 보는 데 방해가 되지 않았습니다. 호텔로 돌아가기 전에 머리를 잡고 한두 조각을 먹습니다.
그날 밤, 당신은 당신이 상상했던 것보다 훨씬 더 많은 데이터를 사용했다는(그리고 당신이 원래 계획했던 것보다 확실히 더 많이!) 당신의 이동통신사로부터 문자를 받았습니다. 몇 대의 택시와 피자 웹사이트 - 피자 웹사이트는 또 얼마나 비쌌나요?
피자 웹사이트를 WebPageTest에 띄우고 모바일 연결에서 확인합니다.
44MB의 비디오 . 이것은 어디서 오는 거니? 그 외에도 소스와 폭포를 조금 더 자세히 살펴보면 실제로 두 개의 동영상이 있음을 알 수 있습니다! 다행히도(또는 불행히도?) 둘 다 완전히 다운로드되지 않았습니다.
동영상 | 크기 |
---|---|
동영상 1 다운로드됨 | 11.8MB(총 121MB 중) |
동영상 2 다운로드됨 | 31.1MB(총 139MB 중) |
이것은 몇 가지 우려와 몇 가지 질문을 제기합니다.
첫째, 자동 재생이 되지 않을 때 왜 그렇게 많은 비디오가 다운로드 되었습니까? 우리는 아직 아무 것도 클릭하지 않았지만 이미 거의 40MB의 데이터를 사용했습니다. 답은 언제나 그렇듯이 출처에 있습니다. 글쎄, "소스보기", 즉.
<video class="video-js vjs-big-play-centered" controls preload="auto" width="1050" height="591" poster="assets/home_poster.jpg" data-setup='{"fluid": true}'>
<source src="assets/home_1.mp4" type='video/mp4'> <source src="assets/home.webm" type='video/webm'>
<p class="vjs-no-js">To view this video please enable JavaScript, and consider upgrading to a web browser that <a href="https://videojs.com/html5-video-support/" target="_blank">supports HTML5 video</a></p> </video>
박쥐에서 우리는 적어도 두 가지 문제를 봅니다.
- 사전 로드 = "자동"
preload="auto"
를 설정하면 고객이 "재생"을 눌렀는지 여부에 관계없이 브라우저의 기본 설정을 무시하고 비디오 다운로드를 시행 합니다. 기본preload
속성은metadata
이며 몇 100KB가 다운로드되었을 것입니다. 분명히, 이 비디오를 보지 않을 사이트 방문자에게는 훨씬 더 나은 결과입니다. - 비디오 주문
여러 버전의 비디오(이 경우: h264 .mp4 및 VP8 .webm 인코딩 비디오)가 있는 경우 브라우저는 재생 방법을 알고 있는 첫 번째 비디오 를 선택합니다. 이제 모든 최신 브라우저는 mp4를 지원하지만 대부분의 최신 브라우저는 webm도 지원합니다(CanIUse에 따르면 95.4% 글로벌 지원).
제가 즐겨 사용하는 한 가지 방법은 Javascript로 적절한 비디오 소스 라인을 삽입하는 것입니다. 그렇게 하면 특정 화면에서 비디오를 제공하지 않기로 선택하면 빈 <video> 태그만 남게 되며 비디오를 다운로드할 수 없습니다.
window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 992){ videoLocation.setAttribute("autoplay",""); }; }
window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 992){ videoLocation.setAttribute("autoplay",""); }; }
이제 이 두 비디오에 대해 ffprobe를 실행하면 크기에서 상당한 차이를 발견할 수 있습니다.
체재 | 크기 |
---|---|
MP4 | 121.2MB |
웹엠 | 11.8MB |
webm은 90% 더 작지만 모든 브라우저가 mp4를 지원하기 때문에 보기가 0 개 있습니다. 이 두 동영상은 모두 640×360 및 140초입니다. mp4에서 위에서 ffmpeg
명령을 실행하면 12.4MB 비디오가 생성되므로 개발자가 유사한 프로세스를 따라 .webm 변형도 압축하고 인코딩했을 가능성이 있습니다. 아마도 12.5MB에 대해 preload="auto"
를 갖는 것은 결국 그렇게 나쁘지 않을 것입니다.
두 번째 동영상(레스토랑 내부 드론 영상)은 Full HD(1080p)로 촬영되지만 마찬가지로 140MB에서 35MB로 압축됩니다. 따라서 FFMPEG가 있는 120s는 이 페이지 의 비디오 무게를 160MB에서 57MB로 줄일 수 있습니다. webm/mp4 순서를 바꾸면 해당 형식을 지원할 수 있는 브라우저의 95%에 대해 몇 MB를 추가로 절약할 수 있습니다.
비디오를 다양한 크기의 화면에 반응하도록 만들면 어떨까요? 반응형 동영상으로 더 작은 동영상을 만들어 봅시다!
<video> 태그는 다른 화면에 다른 비디오 파일을 제공하는 미디어 쿼리를 지원하지 않으므로 장치 화면에 맞는 크기의 비디오를 제공하는 다른 방법이 필요합니다. 이를 달성하는 가장 쉬운 방법은 비디오 스트리밍 을 사용하는 것입니다. 이렇게 하면 비디오 플레이어에 필요한 일부 Javascript 및 기타 자산이 추가되지만 비디오 절약으로 이 추가 데이터를 확실히 상쇄할 것입니다.
우리는 FFMPEG로 비디오 스트림을 생성할 수 있지만(저는 과거에 이와 같은 bash 스크립트를 사용했습니다), 이를 위해서는 우리가 사용하고자 하는 모든 크기와 설정을 알아야 합니다(앞서 언급했듯이 FFMPEG에는 많은 설정이 있습니다! ).
비디오를 더 쉽게 스트리밍할 수 있도록 비디오를 업로드하는 API(예: api.video 및 Mux)가 있으며 도구는 비디오 스트림을 생성하고 비디오를 호스팅합니다. 전체 공개를 위해 전자에서 작업하므로 비디오 처리 파이프라인을 단순화하기 위해 api.video를 사용하여 비디오를 트랜스코딩하고 호스팅합니다. 업로드 API를 사용하면 모든 비디오를 업로드할 수 있으며 이 도구는 다양한 크기와 비트 전송률(현재 240p, 360p, 480p, 720p, 1080p 및 4K)의 스트리밍 버전을 생성합니다.
비디오의 크기가 감소함에 따라 더 작은 비디오의 비트 전송률이 크게 감소합니다. 이것은 비디오가 더 작은 화면에서 더 적은 네트워크 용량을 필요로 하고 더 느린 네트워크에서 재생됨을 의미합니다.
간결함을 위해 호박 패치 비디오만 테스트합니다. 드론 비디오에서도 비슷한 결과를 얻었습니다(다른 피자 비디오는 360p에 불과하므로 작은 크기에서는 큰 이점이 없습니다).
참고 : 이 비디오는 현재 60fps의 1080p mp4 비디오이며 모든 방문자의 무게는 157MB입니다.
일부 최적화(CRF 28 및 프레임 속도를 30fps로 감소)를 통해 비디오는 35.7MB 로 감소했습니다. DevTools를 사용하여 장치를 에뮬레이션하여 다양한 크기의 화면에서 스트리밍 비디오의 비디오 재생에 사용되는 데이터의 양을 확인할 수 있습니다.
아래 표는 사용된 총 트래픽 양을 보여줍니다. HLS 비디오에는 약 1MB의 추가 오버헤드를 추가하는 JavaScript 플레이어, CSS, 글꼴 등이 있습니다. 이것은 아래 총계에 포함됩니다.
장치 | 비디오 크기(픽셀) | 비디오 크기(MB) | 비트레이트(MBPS) |
---|---|---|---|
모토 G4(세로) | 240p | 3.1MB | 0.35 |
모토 G4(가로) | 360p | 7.5MB | 0.800 |
아이폰 7/7/8 (가로) | 480p | 12.1MB | 1.40 |
아이패드(가로) | 720p | 21.2MB | 2.6 |
아이패드 프로(가로) | 1080p | 39.4MB | 4.4 |
1080p에서 스트림에 대해 약 4MB의 추가 자산이 다운로드되지만 다른 모든 크기의 경우 비디오 품질 손실 없이 상당한 데이터 절감 효과가 있습니다. 비디오 는 장치에 맞게 적절하게 크기 가 조정될 뿐만 아니라 느린 모바일 연결에 있을 가능성이 가장 높은 장치의 비트 전송률이 줄어들기 때문에 정지될 가능성이 훨씬 적습니다.
비디오 스트리밍은 프레임 속도, 비디오 크기 및 품질 문제를 처리하여 모든 크기의 화면과 속도 네트워크에서 빠른 재생을 보장합니다.
"
비디오 스트리밍의 또 다른 이점: 네트워크가 느리거나 갑자기 느려지면 플레이어는 표시되는 비디오를 조정하고 열악한 네트워크 조건에서도 장치에서 재생을 보장하여 비디오의 낮은 품질 버전을 재생할 수 있습니다. (내가 얼마 전에 출시한 작은 오픈 소스 프로젝트인 StreamOrNot으로 다양한 비디오를 테스트할 수 있습니다.
자, 약간 오버헤드가 너무 크지 않습니까? YouTube 또는 Vimeo로 동일한 작업을 훨씬 더 빠르게 수행할 수 없었습니까? 분명히 할 수 있지만 비디오 플레이어 iframe 내에 로드된 스크립트의 오버헤드는 말할 것도 없고 비디오에서 브랜딩이나 광고를 완전히 제거할 수는 없습니다. 또한 때때로 제품 페이지에서 비디오를 배경 비디오로 사용하고 외부 브랜딩을 전혀 피하고 싶을 수도 있습니다.
결론
우리는 카메라의 이미지를 웹에 직접 배포하지 않지만 품질과 웹 성능의 균형을 맞추기 위해 이미지를 압축하고 크기를 조정합니다. 비디오 파일에 대해서도 동일한 작업을 수행해야 합니다. 더 작은 비디오는 더 빨리 재생되기 시작 하고 덜 자주 멈추므로 웹 사이트의 사용자 경험이 향상됩니다.
이 기사에서는 품질과 프레임 속도를 낮추는 등 비디오를 최적화하는 몇 가지 간단한 단계를 거쳤습니다. 또한 비디오 스트리밍을 통해 웹용으로 더 반응이 빠른 비디오 경험을 구축할 수 있는 방법을 살펴보았습니다. 즉, 장치 화면에 적합한 크기의 비디오를 자동으로 제공합니다.
읽어 주셔서 감사합니다. 더 자세히 알아보려면 여기, Smashing Magazine 및 내 블로그에서 비디오 모범 사례 에 대해 더 읽어 보세요.
- 웹에서 비디오 재생: 비디오의 현재 상태(1부)
- 웹에서 비디오 재생: 비디오 전송 모범 사례(2부)
- 모바일 웹에서 동영상 숨기기