스트리밍은 대부분의 브라우저와
Developer 앱에서 사용할 수 있습니다.
-
웹 미디어 포맷 살펴보기
Safari 17에서 지원하는 최신 이미지 포맷과 비디오 기술을 소개합니다. 여러분의 웹 사이트에서 JPEG XL, AVIF, HEIC를 어떻게 사용할 수 있는지, 기존 포맷과는 어떤 점이 다른지 알아보세요. 또, Managed Media Source API가 어떻게 Media Source Extensions(MSE)보다 배터리를 덜 소모하는지 알려 드리며, 5G 환경에서 스트리밍 비디오를 더 효율적으로 관리하는 방법도 살펴보겠습니다.
리소스
- Enabling Low-Latency HTTP Live Streaming (HLS)
- HLS.js
- Safari Technology Preview
- Submit feedback
- WebKit Open Source Project
관련 비디오
WWDC23
WWDC22
WWDC21
-
다운로드
♪ ♪
'웹 미디어 포맷 살펴보기'에 오신 걸 환영합니다 전 WebKit 엔지니어인 장이브 아브나르입니다 오늘은 Safari에서 지원하는 미디어 포맷을 살펴보겠습니다 특히 이미지와 비디오를 중심으로 Safari 17에서 새롭게 선보이는 기술들을 소개해 드리겠습니다 새로운 이미지 포맷에 대한 지원이 추가됐는데요 여러분 사이트에 적절하게 쓰일 포맷을 선택하는 걸 돕고 사람들이 가장 흔히 찾는 포맷을 간단하게 소개하겠습니다 저희가 Safari 17에 탑재한 최신 기술인 MSE를 최적화하는 법도 알려 드리죠 마지막으로 Media Source Extension을 사용해 비디오에 AirPlay 지원을 추가하는 법도 보여 드리겠습니다 오랫동안 세 가지 포맷이 가장 널리 사용됐는데요 모든 브라우저에서 지원하며 쉽게 생성하고 사용할 수 있었죠 하지만 지난 십여 년 동안 기술이 엄청나게 발전하면서 새로운 포맷이 개발됐습니다 가장 널리 쓰이는 건 GIF, JPEG, PNG인데요 더 자세하게 알아보도록 하죠 제 고국에서는 '지프'라고 발음하는 GIF는 36년 전에 처음 도입된 포맷으로 단순한 애니메이션이나 밈, 소셜 미디어 콘텐츠에 적합합니다 색상 팔레트 전체는 지원하지 않고 8비트 컬러로 제한됩니다 손실이 없는 포맷이어서 파일 사이즈가 상당히 크기 때문에 큰 애니메이션에는 별로 적합하지 않습니다 다음으로는 30년 전에 도입된 JPEG가 있습니다 순차적으로 로딩된다는 점이 가장 큰 특징입니다 이미지 전체가 로딩되기 전에 일부를 볼 수 있죠 네트워크 속도가 느리던 시절에 특히 편리한 특징이었습니다 색깔이나 디테일이 많은 사진과 이미지에 가장 적합합니다 손상이 있는 포맷이고요 압축 과정에서 이미지 데이터가 일부 손실될 수 있다는 의미죠 파일이 작거나 로딩이 빠를 때 압축이 가능합니다 GIF는 제한이 너무 많아서 26년 전, PNG가 개발됐습니다 PNG는 투명도를 지원해서 이미지를 레이어로 삽입할 때 유용하게 쓰입니다 선명한 색깔이 광범위하게 쓰인 이미지나 뾰족한 스타일의 로고 WebKit 자바스크립트의 Squirrel Fish 같은 그림에 적합하죠 손실이 없고 JPEG처럼 압축이 잘되지 않아서 많은 색깔로 구성된 큰 이미지에는 적합하지 않습니다 PNG도 GIF처럼 대체용으로 쓰고 애니메이션을 지원하려 만들었지만 현업에서 실제로 쓰는 건 거의 본 적 없습니다
이 포맷들을 사용하면 모든 사용자를 아우를 수 있습니다 어떤 웹 브라우저를 쓰든 상관없죠 Safari 17은 최신 포맷 네 가지를 추가로 지원합니다 기존의 포맷과 더불어서 사용하시면 좋습니다 그게 가장 좋다고 생각해요 네 가지 포맷 모두 훌륭하고 서로 호환되지만 각각의 포맷에는 고유의 장점이 있습니다 WebP는 Safari 14과 macOS Big Sur에 추가됐습니다 최신 이미지 포맷인데요 더 발전된 압축 알고리즘을 써서 이미지를 손상하지 않으면서도 크기는 작게 유지할 수 있죠 WebP 파일은 기존의 포맷보다 크기가 작아서 웹 사이트에서 보기가 더 좋고 로딩 시간도 짧습니다 WebP로는 비디오에 버금가는 애니메이션을 만들 수 있으며 사이즈나 색상 부족 문제 때문에 GIF를 사용하는 게 부적합할 때 쓰면 좋습니다 Safari 17이 좋은 또 다른 점은 JPEG-XL이 추가됐다는 겁니다 새롭게 고안된 이미지 포맷인데요 압축 효율과 이미지의 품질을 높여 주죠 Modular Entropy Coding이라는 새로운 압축 알고리즘을 써서 압축 효율을 놀랍도록 유연하게 조정할 수 있습니다 JPEG처럼 접속이 느린 환경에서 이미지를 볼 때 적합하죠 이미지가 완전히 뜨기 전에 일부를 볼 수 있거든요 JPEG-XL의 주요 특징은 무손실 변환이 가능하다는 겁니다 기존의 JPEG에서 JPEG-XL로 변환하더라도 손실이 없고 파일 크기는 최대 60%까지 크게 줄일 수 있죠 비교적 새로운 포맷이어서 모든 기기와 브라우저에서 지원하지는 않습니다 AVIF는 AV1 비디오 코덱을 사용해 이미지 품질을 유지하면서도 뛰어난 압축 효율을 구현하는 또 다른 최신 이미지 포맷입니다 모든 브라우저에서 지원하고 Live Photo에도 적합하며 색 깊이는 12비트까지 지원합니다 지원 범위가 가장 넓으며 대체용으로 쓰면 좋습니다 AVIF 파일은 JPEG 파일보다 크기를 열 배는 줄일 수 있습니다 Safari 17에서는 HEIF로도 알려진 HEIC에 대한 지원도 추가했습니다 HEVC 비디오 코덱 압축 알고리즘으로 사이즈를 줄이는 이미지 포맷입니다 하지만 다른 플랫폼에서 널리 지원하지 않으므로 대체용으로 사용하시는 게 좋을 겁니다 HEIC는 iPhone과 iPad에서 사진을 저장할 때 쓰는 포맷이므로 저장된 사진을 변환하지 않고 바로 업로드해 사용할 수 있습니다 앱에 있는 WKWebView로 이미지를 보여 줄 때는 이 포맷을 사용하면 좋습니다 하드웨어 가속으로 빠르고 효율적으로 렌더링할 수 있기 때문이죠
JPEG-XL, AVIF, HEIC의 주요 특징 가운데 하나는 지원하는 색상과 HDR 범위가 넓다는 것입니다 색상 수십억 개를 지원하는데요 지원하는 색상이 많으면 파일의 색깔이 더 잘 보존되어 화면에서도 더 잘 보입니다
HDR은 어두운색은 더 어둡게 표현하고 밝은색은 더 밝게 표현하며 빛의 양을 정의하게 해 줍니다 이러한 특징이 합쳐지면 야외 풍경은 더 생생하게 표현되고 밝은 이미지에서는 대비 효과가 극대화되며 아름답고 복잡한 피부색도 완벽하게 렌더링할 수 있죠
여러분의 웹 사이트가 널리 쓰이는 모든 웹 브라우저를 계속 지원하길 바란다면 앞으로도 한동안은 GIF와 JPEG PNG를 제공해야 할 겁니다
하지만 새 포맷을 추가로 제공하면 사이트가 더 빨리 로딩되고 대역폭은 덜 사용하면서도 호환은 잘될 것입니다 여러분이 선택할 필요가 없습니다 어떻게 하는지 보여 드리죠 오래되거나 지원이 안 되는 브라우저에서 JPEG-XL로 이미지를 띄우면 이미지가 깨질 수도 있습니다
HTML의 사진 엘리먼트는 대체 포맷을 지정하게 해 줍니다 브라우저에서 지원하는 포맷을 선택해 주는 거죠 심지어 대체 포맷을 여러 개 제공할 수도 있습니다 최상의 결과물을 보여 줄 포맷을 우선적으로 선택하는 거죠 브라우저가 사용 가능한 포맷을 처음부터 끝까지 쭉 훑어볼 겁니다 지원이 된다면 여기서는 HEIC를 가장 먼저 사용하겠죠 적합한 포맷을 발견하지 못하거나 디코딩에 실패한다면 이미지 엘리먼트 소스의 URL이 선택될 겁니다 기기가 지원하는 포맷이 무엇이든 적합한 포맷을 제공하는 게 얼마나 쉬운지 알 수 있습니다 User-Agent 스트링을 찾거나 사용자가 어떤 브라우저를 쓸지 걱정할 필요도 없죠 여러분은 선택하지 않아도 됩니다 브라우저가 대신 해 줄 겁니다 이제 우리가 쓸 수 있는 최신 이미지 포맷에는 뭐가 있고 언제 사용하면 좋을지 알았으니 이제 비디오 얘기를 해 보죠 그중에서도 적응형 스트리밍 비디오의 세계에 빠져들어 봅시다 웹 사이트 내 비디오 삽입 기술은 놀라울 정도로 발전했습니다 인터넷 초창기 이래로 많은 진전을 이루었죠 웹 사이트 내 비디오 삽입 기술 발전 역사의 중요한 사건 몇 가지를 소개하겠습니다 인터넷 초창기에는 비디오가 많이 사용되지 않았죠 기술적인 제한 때문이었습니다 웹 사이트는 주로 텍스트와 정적인 이미지로 구성됐습니다 2000년대 초 Flash, QuickTime 등 브라우저 플러그인이 탄생했고 웹 사이트에 비디오를 추가하는 인기 있는 방법으로 떠올랐죠 그러다 2010년에 HTML5가 도입됐습니다 플러그인을 쓰지 않고 비디오를 웹 페이지에 바로 올릴 수 있는 방식이었죠 덕분에 비디오를 더욱 쉽게 웹 사이트에 올리게 됐습니다 비디오 콘텐츠가 게시되고 재생되는 방식을 더 유연하게 제어할 수 있게 되었죠 WebKit은 이런 혁명의 선두에 서 있었습니다 모바일 기기가 부상하면서 비디오 콘텐츠를 작은 화면에 게시하는 게 급격하게 중요해졌습니다 이는 새로운 기술의 발전으로 이어졌습니다 다양한 화면 사이즈와 제어 환경에 웹 사이트가 적응할 수 있게 됐죠 Apple은 HTTP Live Streaming을 2009년에 도입했습니다 적응형 비트레이트 스트리밍을 지원한다는 게 주요 특징이었죠 사용자의 인터넷 속도와 기기 사양에 맞는 최적의 비디오 품질을 전달할 수 있게 해 줬습니다 HLS 적응형 스트리밍은 비디오 콘텐츠를 작은 덩어리나 부분으로 나눕니다 보통은 2-10초 길이로 나누죠 각 부분이 인코딩되는 전송 속도도 각각 다릅니다 그리고 그 각각의 버전이 고객에게 전달되는데 M3U8 Multivariant Playlist 형태의 매니페스트 파일로 전달되죠 HLS는 가장 적합한 유형을 정말 잘 골라 줍니다 사용하기가 정말 간단해 엔드 유저에게 최고의 솔루션이죠 데스크톱의 모든 브라우저가 HLS를 지원하지는 않습니다 심지어 현재는 Safari만 지원합니다 웹 개발자들은 제어가 쉽고 유연성이 높은 포맷을 원했습니다 미디어 데이터를 선택하고 전송하는 능력이나 DRM 콘텐츠를 데스크톱에서 재생하는 능력이 뛰어난 포맷을요 그래서 2013년에 W3C가 Media Source Extension을 내놨죠 다른 브라우저들처럼 Safari 8도 그에 대한 지원을 탑재했습니다 Media Source Extension 즉, MSE는 하위 레벨 툴키트로 적응형 스트리밍을 가능케 합니다 버퍼링 및 해상도 관리에 대해 웹 페이지에 더 많은 권한과 책임을 부여해서 말이죠 전반적으로 MSE는 웹 개발자들에게 게임 체인저였습니다 웹상에서 고품질 스트리밍 경험을 구현해 현재 가장 많이 사용되는 웹 비디오 기술이 되었죠 MSE도 결점은 있습니다 버퍼 레벨 네트워크 타이밍과 접속량 미디어 포맷 선택을 관리하는 능력이 뛰어나진 않죠 이런 비효율성은 현대의 범용 컴퓨터처럼 고사양 기기에서는 크게 느껴지지 않았지만 모바일 기기의 배터리 소모는 HLS 네이티브 플레이어보다 높죠 그래서 MSE는 iPhone에서 사용되지 못했습니다 MSE를 쓰면 배터리를 아낄 수 없었으니까요 여러 사이트에서 시험해 본 결과 MSE를 사용했다면 배터리 사용 시간이 줄어들었을 겁니다
사양이 더 낮은 기기를 쓰거나 접속 환경이 좋지 않은 조건에서는 MediaSource API로 재생했을 때 HLS로 재생했을 때와 비슷한 품질을 얻기가 힘듭니다
그 이유 중 하나는 MSE가 미디어 데이터에 대한 관리의 대부분을 User-Agent에서 페이지 내에서 돌아가는 응용 프로그램에 전가하기 때문이죠 관리가 전가되면서 비효율적인 부분들이 생겨났고 페이지는 User-Agent만큼 정보를 갖고 있지도 않고 심지어 목표도 없습니다 가장 저렴한 네트워크 연결 경로를 찾겠지만 그러면 배터리 사용량은 훨씬 늘어납니다 올해는 그 결점을 해결하고자 했습니다 MSE의 유연성과 HLS의 효율성을 결합하려고 큰 노력을 기울였죠 그래서 이 새로운 기술을 소개하게 되어 정말 기쁩니다 MSE의 최대 장점과 HLS의 훌륭한 요소들을 결합했죠 Managed Media Source API를 소개합니다 Managed Media Source는 MediaSource와 관련 객체를 브라우저에서 더 많이 관리하게 합니다 덕분에 미디어 웹 사이트 운영자는 사양이 떨어지는 기기에도 미디어 스트리밍을 지원할 수 있게 됐습니다 User-Agent가 사용 가능한 메모리와 네트워크 환경에 맞춰 반응하기 때문인데요 기존 MSE와의 차이점을 살펴보도록 하겠습니다 Managed Media Source는 더 많은 미디어 데이터를 버퍼링할 타이밍을 알려 주어 배터리를 절약합니다 버퍼링하지 않을 때는 셀룰러 모뎀이 오랜 시간 동안 저전력 모드를 유지하도록 해 배터리 사용 시간을 연장합니다 시스템이 메모리를 덜 쓰는 상태에 들어가면 Managed Media Source가 알아서 사용하지 않거나 방치된 버퍼링 메모리를 제거해 페이지의 효율성을 높입니다 Managed Media Source가 버퍼링의 시작과 끝을 추적하니 버퍼링이 적게 걸리거나 많이 걸린 상태를 페이지가 더 쉽게 탐지할 수 있죠 브라우저가 여러분을 대신해 주는 겁니다
이런 점이 개선되어 Safari는 5G 모뎀에 미디어를 요청할 수 있게 됐습니다 그러면 여러분의 사이트는 눈부신 속도의 5G 네트워크를 써서 미디어 데이터를 엄청나게 빨리 로딩할 수 있죠 그러면서도 배터리 사용량에는 영향을 최소한으로 미치고요 라이브 영상을 재생해야 한다면 Managed Media Source가 이를 자동으로 탐지해 LTE나 4G로 전환해서 배터리 사용 시간을 늘릴 겁니다 운전대를 잡은 건 여전히 여러분입니다 어떤 해상도를 택할지는 여러분 손에 달렸죠 각 부분을 어떻게, 어디서 다운로드할지도 여러분 선택이죠 Managed Media Source는 힌트를 드릴 뿐이고 MSE의 더 효율적인 버전을 제공할 뿐입니다 Managed Media Source를 쓰면 대역폭과 배터리를 절약할 수 있어 사용자는 비디오를 더 오래 시청할 수 있고 iPhone뿐만 아니라 iPad나 Mac에서도 볼 수 있습니다 MSE에서 Managed Media Source로 바꾸는 건 정말 쉽습니다 여러분의 비디오 플레이어를 Managed Media Source로 바꾸는 건 쉬운 작업입니다 몇 단계만 거치면 되죠 여기 아주 단순한 HTML 페이지를 열었습니다 MSE를 시험해 볼 때 수도 없이 드나들던 페이지인데요 여기서 비디오 엘리먼트를생성하고 12초짜리 데이터를 열어 재생하죠 모든 로직은 mediasource.js라는 유틸리티 파일에서 일어납니다 한번 살펴보겠습니다 특히 runWithMSE 메서드를 보죠 RunwithMSE는 페이지가 열리면 비디오 엘리먼트를 생성한 뒤 MediaSource 객체에 연결해 HTML 바디에 추가합니다 먼저, Managed Media Source가 사용 가능한지 확인해야 합니다 Managed Media Source 객체가 정의돼 있는지 보면 간단히 확인할 수 있습니다 그게 아니면 MSE를 쓰게 되죠 MediaSource에 대한 모든 호출을 ManagedMediaSource로 교체합니다 제 생각에 더 쉬운 방법이 있는데 MediaSource를 덮어씌우는 겁니다 getMediaSource() 메서드를 정의하고 MediaSource shim을 설정합니다
이제 MediaSource가 나올 때마다 실제로는 ManagedMediaSource를 사용하게 될 겁니다 ManagedMediaSource를 MSE보다 늘 먼저 선택해야 합니다 HTML 페이지로 돌아가겠습니다
SourceBuffer를 생성합니다 이제 ManagedSourceBuffer겠네요 그런 다음 이벤트 핸들러를 두 개 추가합니다 startstreaming은 플레이어에 언제 새로운 콘텐츠를 가져와서 managed sourceBuffer에 추가할지 알려 줍니다
endstreaming으로는 플레이어가 새로운 데이터를 그만 가져와도 되는 타이밍을 알려 줍니다 User-Agent는 데이터가 충분하다고 판단하면 저전력 모드로 들어갑니다 이를 위해 쓰인 endstreaming 이벤트 핸들러는 플레이스홀더일 뿐입니다 MSE와는 다르게 sourceBuffer는 콘텐츠를 축출할 수 있는데요 데이터를 추가할 때뿐만 아니라 언제든 할 수 있죠 MSE로는 버퍼링 범위를 추정할 수 없었습니다 새 데이터가 추가될 때만 빨라졌고 재생이 멈추곤 했죠 MSE 설명서에는 주기적으로 확인할 것을 권고하고요 bufferedchange 이벤트에 이벤트 핸들러도 추가해야 합니다 어떤 데이터가 축출됐는지 확인이 필요한 곳에 말이죠
Managed Media Source 이벤트의 안내를 따르고 엘리먼트가 요청할 때만 데이터를 추가한다면 iPhone과 iPad에서도 5G를 쓸 수 있고 사용자들은 더 높은 해상도 더 짧은 리버퍼링 시간 최장의 배터리 사용 시간으로 비디오를 즐길 수 있습니다 이제 여러분은 Safari 17에서 ManagedMediaSource를 사용해 적응형 스트리밍을 다룰 준비가 되셨습니다 여러분이 관심 있는 건 Apple 기기일 테니 HLS를 쓰는 게 더 맞기는 합니다 여러분의 사용자들이 계속하고 싶어 하는 게 하나 있죠 좋아하는 TV 프로그램을 AirPlay로 보는 겁니다 네이티브 HLS를 쓰는 가장 큰 장점이 바로 AirPlay를 자동으로 지원한다는 겁니다 AirPlay를 사용하면 폰에서 재생되는 비디오를 그저 소파에 앉아 큰 기기로 보낼 수 있습니다 AirPlay에 URL을 보내야 하는데 MSE에는 존재하지 않죠 이는 우리가 해결하고 싶은 문제였습니다 아까 적합한 이미지 포맷을 선택하는 법을 얘기하면서 이미지 엘리먼트로 대안 포맷을 어떻게 추가하는지 알려 드렸죠 비디오를 추가하는 메커니즘도 똑같습니다 HTTP Live Streaming playlist를 비디오의 자식 엘리먼트에 추가하기만 하면 되죠 사용자가 콘텐츠를 AirPlay로 틀면 Safari가 그걸 Managed Media Source에서 바꿔 AirPlay 기기에서 HLS 스트림으로 재생합니다 Safari가 AirPlay 아이콘을 비디오 플레이어에 자동으로 띄워 사용자가 비디오를 AirPlay로 볼 수 있게 해 주죠 너무 복잡해 보인다면 HLS.js 같은 프레임워크를 사용하셔도 됩니다 그러면 Managed Media Source를 가능할 때 자동으로 지원하죠 궂은일은 우리가 다 해 드리겠습니다 HLS.js를 사용해 비디오를 다루는 건 상당히 쉽고 모든 웹 브라우저에서 쓸 수 있죠 HLS를 지원하지 않는 브라우저도요 먼저, 늘 하듯이 HTML 파일에서 비디오 엘리먼트를 생성하세요 브라우저가 HLS를 원래 지원하는지부터 확인합시다 지원이 된다면 비디오 소스 속성을 매니페스트 URL로 설정할 수 있죠 지원하지 않는다면 HLS.js를 돌릴 수 있는지 확인해야죠 가능하다면 HLS.js 라이브러리의 인스턴스를 새로 만들어 'my-video'라는 ID를 비디오 엘리먼트에 추가해 주세요 HLS playlist 파일을 로딩합니다 이 경우에는 my-video.m3u8입니다 이게 다입니다 이렇게 하면 거의 모든 브라우저로 HLS 비디오를 재생할 수 있습니다
Managed MSE를 설계할 때 빠진 부분이 없도록 했습니다 그래야 사용자들이 예전과 비슷한 수준의 기능들을 계속 사용할 수 있으니까요 Managed MSE를 Mac, iPad iPhone에서 활성화하려면 플레이어가 AirPlay 소스의 대안을 제공해야 합니다 그게 없어도 Managed MSE에는 접근할 수 있지만 Remote Playback API에서 미디어 엘리먼트에 대해 disableRemotePlayback을 호출해 AirPlay를 비활성화해야 하죠 그게 다입니다 Managed MSE는 지난해 추가된 훌륭한 기술 전부를 지원합니다 SharePlay, 공간 음향 혹은 HDR 같은 기술이요 Managed MSE는 Safari 17 macOS, iPad OS에서 쓸 수 있으며 iPhone에서는 시험 사용 중입니다 마침내 iPhone에 적용할 수 있게 돼 기쁩니다 새로운 미디어 포맷을 시험해 보고 Managed Media Source를 써 보세요 Safari에서 여러분의 사이트를 꼭 시험해 보시길 바랍니다 또, Safari Technology Preview를 2주에 한 번 출시하는데요 최신 기능들을 시험해 볼 수 있습니다 엔드 유저가 사용하기 전에 먼저 써 보실 수 있죠 개발이 활발하게 이루어지는 여타 프로그램처럼 때때로 사소한 문제나 버그가 생기기도 합니다 그런 문제를 발견하면 bugs.webkit.org로 알려 주시면 감사하겠습니다 의견을 남겨 주시거나 제안을 해 주셔도 됩니다 항상 여러분의 목소리에 귀 기울이고 있으니까요 Safari CSS의 새로운 기능은 'CSS의 새 기능'을 참고하시고 'Safari 개발자 기능의 재발견'도 확인해 보세요 기능 플래그를 켜서 Managed Media Source를 사용하는 법을 배울 수 있습니다 시청해 주셔서 감사합니다 ♪ ♪
-
-
찾고 계신 콘텐츠가 있나요? 위에 주제를 입력하고 원하는 내용을 바로 검색해 보세요.
쿼리를 제출하는 중에 오류가 발생했습니다. 인터넷 연결을 확인하고 다시 시도해 주세요.