HTTP 라이브 스트리밍 소개: Android 등의 HLS

게시 됨: 2022-03-11

비디오 스트리밍은 현대 인터넷 경험의 필수적인 부분입니다. 휴대전화, 데스크톱 컴퓨터, TV, 웨어러블 기기 등 어디에나 있습니다. 느린 모바일 연결, WiFi, 방화벽 뒤 등 모든 장치와 네트워크 유형에서 완벽하게 작동해야 합니다. Apple의 HTTP 라이브 스트리밍(HLS)은 이러한 문제를 정확히 염두에 두고 만들어졌습니다.

거의 모든 최신 장치에는 비디오를 재생할 수 있을 만큼 빠른 최신 하드웨어가 제공되므로 네트워크 속도와 안정성이 가장 큰 문제로 대두됩니다. 왜 그런 겁니까? 몇 년 전까지만 해도 비디오를 저장하고 게시하는 표준 방식은 RTP와 같은 UDP 기반 프로토콜이었습니다. 이것은 몇 가지만 나열하면 여러 면에서 문제가 있는 것으로 판명되었습니다.

  1. 콘텐츠를 스트리밍하려면 서버(데몬) 서비스가 필요합니다.
  2. 대부분의 방화벽은 http, 이메일 등과 같은 표준 포트 및 네트워크 트래픽 유형만 허용하도록 구성되어 있습니다.
  3. 청중이 전 세계인 경우 모든 주요 지역에서 실행 중인 스트리밍 데몬 서비스의 복사본이 필요합니다.

물론 이 모든 문제를 쉽게 해결할 수 있다고 생각할 수도 있습니다. http 서버에 비디오 파일(예: mp4 파일)을 저장하고 즐겨 사용하는 CDN 서비스를 사용하여 전 세계 어디에서나 이를 제공하십시오.

기존 비디오 스트리밍이 부족한 경우

이것은 효율성이 그 중 하나인 몇 가지 이유로 최상의 솔루션과는 거리가 멉니다. 원본 비디오 파일을 전체 해상도로 저장하면 시골 지역이나 연결 상태가 좋지 않은 일부 지역의 사용자가 감상하기 어려울 것입니다. 그들의 비디오 플레이어는 런타임에 재생하기에 충분한 데이터를 다운로드하는 데 어려움을 겪을 것입니다.

따라서 다운로드 한 비디오의 양이 재생할 수 있는 것과 거의 같도록 파일의 특수 버전이 필요합니다. 예를 들어, 비디오 해상도와 품질이 5초 안에 5초 분량의 비디오를 추가로 다운로드할 수 있다면 최적입니다. 그러나 5초가 걸리는 경우 3초 분량의 비디오만 다운로드하면 플레이어가 중지되고 스트림의 다음 청크가 다운로드될 때까지 기다립니다.

반면에 품질과 해상도를 더 낮추면 대역폭이 불필요하게 절약되므로 더 빠른 연결에서 사용자 경험이 저하될 뿐입니다. 그러나 세 번째 방법이 있습니다.

적응형 비트레이트 스트리밍

사용자마다 다른 버전의 비디오를 업로드할 수 있지만 플레이어를 제어하고 연결 및 장치에 가장 적합한 스트림을 계산할 수 있어야 합니다. 그런 다음 플레이어는 둘 사이를 전환해야 합니다(예: 사용자가 3G에서 WiFi로 전환하는 경우). 그럼에도 불구하고 클라이언트가 네트워크 유형을 변경하면 어떻게 될까요? 그런 다음 플레이어는 다른 비디오로 전환해야 하지만 처음부터가 아니라 비디오 중간 어딘가에서 재생을 시작해야 합니다. 그렇다면 요청할 바이트 범위를 어떻게 계산합니까?

비디오 플레이어가 네트워크 유형 및 사용 가능한 대역폭의 변경을 감지한 다음 최상의 스트림을 찾을 때까지 다른 스트림(다른 속도로 준비된 동일한 비디오) 간에 투명하게 전환할 수 있다면 멋진 일입니다.

이것이 바로 적응형 비트 전송률 스트리밍이 해결하는 것입니다.

참고: 이 HLS 자습서에서는 암호화, 동기화된 재생 및 IMSC1을 다루지 않습니다.

HLS 란 무엇입니까?

HTTP 라이브 스트리밍은 2009년 Apple에서 도입한 적응형 비트 전송률 스트리밍 프로토콜입니다. m3u8 파일을 사용하여 미디어 스트림을 설명하고 HTTP를 사용하여 서버와 클라이언트 간의 통신을 수행합니다. 모든 iOS 장치의 기본 미디어 스트리밍 프로토콜이지만 Android 및 웹 브라우저에서 사용할 수 있습니다.

HTTP 라이브 스트리밍 표지 그림

HLS 스트림의 기본 빌딩 블록은 다음과 같습니다.

  1. M3U8 재생 목록
  2. 다양한 스트림을 위한 미디어 파일

M3U8 재생 목록

기본 질문에 답하는 것으로 시작하겠습니다. M3U8 파일이란 무엇입니까 ?

M3U(또는 M3U8)는 원래 MP3 파일 모음을 구성하기 위해 만든 일반 텍스트 파일 형식입니다. 형식은 미디어 스트림을 정의하는 데 사용되는 HLS용으로 확장됩니다. HLS에는 두 가지 종류의 m3u8 파일이 있습니다.

  • 미디어 재생 목록: 스트리밍에 필요한 파일의 URL을 포함합니다(즉, 재생할 원본 비디오의 청크).
  • 마스터 재생 목록: 미디어 재생 목록에 대한 URL이 포함되며, 여기에는 다른 대역폭에 맞게 준비된 동일한 비디오의 변형이 포함됩니다.

소위 M3U8 라이브 스트림 URL은 https://s3-us-west-2.amazonaws.com/hls-playground/hls.m3u8과 같은 M3U8 파일에 대한 URL에 불과합니다.

HLS 스트림용 샘플 M3U8 파일

M3U8 파일에는 URL 목록 또는 일부 추가 메타데이터가 포함된 로컬 파일 경로가 포함되어 있습니다. 메타데이터 행은 #으로 시작합니다.

이 예는 간단한 HLS 스트림에 대한 M3U8 파일의 모양을 보여줍니다.

 #EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:0 #EXT-X-ALLOW-CACHE:YES #EXT-X-TARGETDURATION:11 #EXTINF:5.215111, 00000.ts #EXTINF:10.344822, 00001.ts #EXTINF:10.344822, 00002.ts #EXTINF:9.310344, 00003.ts #EXTINF:10.344822, 00004.ts ... #EXT-X-ENDLIST
  • 처음 네 줄은 이 M3U8 재생 목록에 대한 전역(헤더) 메타데이터입니다.
  • EXT-X-VERSION 은 M3U8 형식의 버전입니다( EXTINF 항목을 사용하려면 최소 3이어야 함).
  • EXT-X-TARGETDURATION 태그에는 각 비디오 "청크"의 최대 지속 시간이 포함됩니다. 일반적으로 이 값은 약 10초입니다.
  • 문서의 나머지 부분에는 다음과 같은 줄 쌍이 포함되어 있습니다.
 #EXTINF:10.344822, 00001.ts

"청크" 영상입니다. 이것은 정확히 10.344822초 길이인 00001.ts 청크를 나타냅니다. 클라이언트 비디오 플레이어가 해당 비디오의 특정 지점에서 비디오를 시작해야 할 때 이전에 본 청크의 지속 시간을 합산하여 요청해야 하는 .ts 파일을 쉽게 계산할 수 있습니다. 두 번째 줄은 로컬 파일 이름 또는 해당 파일의 URL일 수 있습니다.

.ts 파일이 있는 M3U8 파일은 HLS 스트림의 가장 단순한 형태인 미디어 재생 목록을 나타냅니다.

모든 브라우저에서 기본적으로 HLS 스트림을 재생할 수 있는 것은 아닙니다.

마스터 재생 목록 또는 인덱스 M3U8 파일

이전 M3U8 예제는 일련의 .ts 청크를 가리킵니다. 인코딩된 크기가 조정되고 청크로 분할되는 원본 비디오 파일에서 생성됩니다.

이는 서론에서 설명한 문제가 여전히 있음을 의미합니다. 매우 느린(또는 비정상적으로 빠른) 네트워크의 클라이언트는 어떻습니까? 아니면 화면 크기가 매우 작은 고속 네트워크의 클라이언트입니까? 반짝이는 새 전화기에서 모든 영광을 표시할 수 없다면 최대 해상도로 파일을 스트리밍하는 것은 의미가 없습니다.

HSL의 M3U8

HLS는 M3U8의 또 다른 "계층"을 도입하여 이 문제를 해결합니다. 이 M3U8 파일에는 .ts 파일에 대한 포인터가 포함되어 있지 않지만 특정 비트 전송률 및 해상도에 대해 미리 준비된 비디오 파일이 포함된 다른 M3U8 파일에 대한 포인터가 있습니다.

다음은 이러한 M3U8 파일의 예입니다.

 #EXTM3U #EXT-X-STREAM-INF:BANDWIDTH=1296,RESOLUTION=640x360 https://.../640x360_1200.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=264,RESOLUTION=416x234 https://.../416x234_200.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=464,RESOLUTION=480x270 https://.../480x270_400.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=1628,RESOLUTION=960x540 https://.../960x540_1500.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=2628,RESOLUTION=1280x720 https://.../1280x720_2500.m3u8

비디오 플레이어는 다음과 같은 줄 쌍을 선택합니다.

 #EXT-X-STREAM-INF:BANDWIDTH=1296,RESOLUTION=640x360 https://.../640x360_1200.m3u8

이를 다른 네트워크 속도와 화면 해상도에 맞게 준비된 동일한 비디오의 변형 이라고 합니다. 이 특정 M3U8 파일( 640x360_1200.m3u8 )에는 640x360픽셀로 크기가 조정되고 1296kbps 의 비트 전송률을 위해 준비된 비디오의 비디오 파일 청크가 포함되어 있습니다. 보고된 비트 전송률은 비디오의 비디오 및 오디오 스트림을 모두 고려해야 합니다.

비디오 플레이어는 일반적으로 첫 번째 스트림 변형 에서 재생을 시작합니다(이전 예에서는 640x360_1200.m3u8). 이러한 이유로 목록의 첫 번째 변형을 결정할 때는 특별한 주의를 기울여야 합니다. 다른 변형의 순서는 중요하지 않습니다.

첫 번째 .ts 파일을 다운로드하는 데 너무 오래 걸리는 경우("버퍼링" 유발, 즉 다음 청크 대기) 비디오 플레이어는 비트 전송률이 더 작은 스트림으로 전환됩니다. 물론 로드 속도가 충분히 빠르면 더 나은 품질의 버전 으로 전환할 수 있지만 디스플레이의 해상도에 맞는 경우에만 가능합니다.

인덱스 M3U8 목록의 첫 번째 스트림이 최상의 스트림이 아닌 경우 클라이언트는 올바른 변형으로 정착될 때까지 한두 주기가 필요합니다.

이제 HLS의 세 가지 레이어가 있습니다.

  1. 변종에 대한 포인터(URL)가 포함된 M3U8 파일 (마스터 재생 목록)의 색인을 생성합니다.
  2. 다양한 화면 크기 및 네트워크 속도에 대한 다양한 스트림에 대한 변형 M3U8 파일 (미디어 재생 목록) . 여기에는 .ts 파일에 대한 포인터(URL)가 포함됩니다.
  3. .ts 파일 (청크) 은 비디오의 일부가 포함된 이진 파일입니다.

여기에서 인덱스 M3U8 파일의 예를 볼 수 있습니다(다시 말하지만 브라우저/OS에 따라 다름).

클라이언트가 느리거나 빠른 네트워크에 있다는 것을 미리 알고 있는 경우가 있습니다. 이 경우 다른 첫 번째 변형이 포함된 인덱스 M3U8 파일을 제공하여 클라이언트가 올바른 변형을 선택하도록 도울 수 있습니다. 두 가지 방법이 있습니다.

  • 첫 번째는 다양한 네트워크 유형에 대해 여러 인덱스 파일을 준비하고 클라이언트가 올바른 파일을 요청할 수 있도록 미리 준비하는 것입니다. 클라이언트는 네트워크 유형을 확인한 다음 http://.../index_wifi.m3u8 또는 http://.../index_mobile.m3u8 과 같이 요청해야 합니다.
  • 또한 클라이언트가 http 요청의 일부로 네트워크 유형을 전송하는지 확인한 다음(예: Wi-Fi 또는 모바일 2G/3G/...에 연결된 경우) 각 요청에 대해 동적으로 준비된 인덱스 M3U8 파일을 가질 수 있습니다. 인덱스 M3U8 파일에만 동적 버전이 필요하며 단일 스트림(변형 M3U8 파일)은 여전히 ​​정적 파일로 저장할 수 있습니다.

HLS용 비디오 파일 준비

Apple의 HTTP 라이브 스트리밍에는 두 가지 중요한 구성 요소가 있습니다. 하나는 비디오 파일이 저장되는 방식(나중에 HTTP를 통해 제공됨)이고 다른 하나는 플레이어(스트리밍 클라이언트 앱)에 어떤 비디오 파일을 가져올지 알려주는 M3U8 인덱스 파일입니다.

동영상 파일부터 시작하겠습니다. HLS 프로토콜은 동일한 길이(일반적으로 각각 10초)의 더 작은 청크로 저장된 비디오 파일을 예상합니다. 원래 이러한 파일은 MPEG-2 TS 파일( .ts )에 저장되고 MP3, HE-AAC 또는 AC-3의 오디오와 함께 H.264 형식으로 인코딩되어야 했습니다.

HLS 비디오

즉, 30초 길이의 비디오가 각각 약 10초 길이의 3개의 더 작은 .ts 파일로 분할됩니다.

최신 버전의 HLS는 조각난 .mp4 파일도 허용합니다. 이것은 여전히 ​​​​새로운 것이고 일부 비디오 플레이어는 여전히 그것을 구현해야 하기 때문에 이 기사의 예제에서는 .ts 파일을 사용합니다.

키프레임

청크는 각 파일의 시작 부분에 키프레임으로 인코딩되어야 합니다. 각 비디오에는 프레임이 포함되어 있습니다. 프레임은 이미지이지만 비디오 형식은 완전한 이미지를 저장하지 않으므로 디스크 공간이 너무 많이 차지합니다. 이전 프레임과의 차이점만 인코딩합니다. 비디오의 중간 지점으로 이동할 때 플레이어는 초기 이미지를 표시한 다음 비디오 재생을 시작하기 위해 모든 차이점을 적용할 "시작 지점"이 필요합니다.

이것이 .ts 청크의 시작 부분에 키프레임이 있어야 하는 이유입니다. 때때로 플레이어는 청크의 중간에서 시작해야 합니다. 플레이어는 첫 번째 키프레임에서 모든 "차이점"을 추가하여 항상 현재 이미지를 계산할 수 있습니다. 단, 처음부터 9초부터 시작하면 9초의 "diffs"를 계산해야 합니다. 계산 속도를 높이려면 몇 초마다 키프레임을 만드는 것이 가장 좋습니다(최고의 cca 3초).

HLS 중단점

여러 비디오 클립을 연속적으로 재생해야 하는 상황이 있습니다. 이를 수행하는 한 가지 방법은 원본 비디오 파일을 병합한 다음 해당 파일로 HLS 스트림을 만드는 것이지만 여러 가지 이유로 문제가 됩니다. 동영상 전후에 광고를 표시하려면 어떻게 해야 합니까? 모든 사용자에 대해 그렇게 하고 싶지 않을 수도 있고 다른 사용자에 대해 다른 광고를 원할 수도 있습니다. 물론 다른 광고가 포함된 HLS 파일을 미리 준비하고 싶지는 않습니다.

이 문제를 해결하기 위해 m3u8 재생 목록에서 사용할 수 있는 #EXT-X-DISCONTINUITY 태그가 있습니다. 이 줄은 기본적으로 이 시점부터 .ts 파일이 다른 구성(예: 해상도가 변경될 수 있음)으로 생성될 수 있다는 사실에 미리 대비하도록 비디오 플레이어에 지시합니다. 플레이어는 모든 것을 다시 계산하고 다른 변형으로 전환해야 하며 이러한 "불연속" 지점에 대비해야 합니다.

HLS를 사용한 라이브 스트리밍

"비디오 스트리밍"에는 기본적으로 두 가지 종류가 있습니다. 하나는 미리 녹화되어 사용자가 원할 때 스트리밍하는 비디오를 위한 VOD (주문형 비디오 )입니다. 그리고 라이브 스트리밍 이 있습니다. HLS는 HTTP Live Streaming의 줄임말이지만 지금까지 설명한 내용은 모두 VOD를 중심으로 하였지만 HLS로 라이브 스트리밍을 하는 방법도 있습니다.

M3U8 파일에 몇 가지 변경 사항이 있습니다. 먼저 변종 M3U8 파일에 #EXT-X-MEDIA-SEQUENCE:1 태그가 있어야 합니다. 그런 다음 M3U8 파일 은 #EXT-X-ENDLIST 합니다(그렇지 않으면 항상 끝에 위치해야 함).

스트림을 녹화하는 동안 계속해서 새로운 .ts 파일을 갖게 됩니다. M3U8 재생 목록에 추가해야 하며 새 항목을 추가할 때마다 #EXT-X-MEDIA-SEQUENCE:<counter> 가 1씩 증가해야 합니다.

비디오 플레이어가 카운터를 확인합니다. 마지막으로 변경된 경우 다운로드 및 재생할 새 청크가 있는지 알 수 있습니다. 클라이언트가 새 청크가 재생될 때까지 계속 M3U8 파일을 다시 로드하므로 M3U8 파일이 캐시 없음 헤더와 함께 제공되는지 확인합니다.

VTT

HLS 스트림의 또 다른 흥미로운 기능은 웹 비디오 텍스트 트랙(VTT) 파일을 포함할 수 있다는 것입니다. VTT 파일은 다양한 용도로 사용할 수 있습니다. 예를 들어 웹 HLS 플레이어의 경우 비디오의 다양한 부분에 대한 이미지 스냅샷을 지정할 수 있습니다. 사용자가 비디오 타이머 영역(비디오 플레이어 아래) 위로 마우스를 이동하면 플레이어는 비디오의 해당 위치에서 스냅샷을 표시할 수 있습니다.

VTT 파일의 또 다른 분명한 용도는 자막입니다. HLS 스트림은 여러 언어에 대해 여러 자막을 지정할 수 있습니다.

 #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-,NAME="English",DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,LANGUAGE="en",CHARACTERISTICS="public.accessibility.transcribes-spoken-dialog, public.accessibility.describes-music-and-sound",URI="subtitles/eng/prog_index.m3u8"

그런 다음, theprog_index.m3u8 은 다음과 같습니다.

 #EXTM3U #EXT-X-TARGETDURATION:30 #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:0 #EXT-X-PLAYLIST-TYPE:VOD #EXTINF:30, 0000.webvtt #EXTINF:30, 0001.webvtt ...

실제 VTT(예: 0000.webvtt ):

 WEBVTT X-TIMESTAMP-MAP=MPEGTS:900000,LOCAL:00:00:00.000 00:00:01.000 --> 00:00:03.000 Subtitle -Unforced- (00:00:01.000) 00:00:03.000 --> 00:00:05.000 <i>...text here... -Unforced- (00:00:03.000)</i> <i>...text here...</i>

VTT 파일 외에도 Apple은 최근 HLS가 스트리밍 전송에 최적화된 새로운 자막 형식인 IMSC1을 지원한다고 발표했습니다. 가장 중요한 장점은 CSS를 사용하여 스타일을 지정할 수 있다는 것입니다.

HTTP 라이브 스트리밍 도구 및 잠재적 문제

Apple은 공식 HLS 가이드에 자세히 설명되어 있는 여러 가지 유용한 HSL 도구를 도입했습니다.

  • 라이브 스트림의 경우 Apple은 진행 중인 비디오 스트림에서 즉석에서 세그먼트 파일을 생성하기 위해 mediastreamsegmenter 라는 도구를 준비했습니다.
  • 또 다른 중요한 도구는 mediastreamvalidator 입니다. M3U8 재생 목록을 확인하고 비디오 파일을 다운로드하며 다양한 문제를 보고합니다. 예를 들어 보고된 비트 전송률이 .ts 파일에서 계산된 것과 같지 않은 경우입니다.
  • 물론, 인코딩/디코딩/mux/demux/chunk/strip/merge/join/… 비디오/오디오 파일을 인코딩/디코딩해야 하는 경우 ffmpeg가 있습니다. 특정 사용 사례에 대해 ffmpeg의 사용자 정의 버전을 컴파일할 준비를 하십시오.

비디오에서 가장 자주 발생하는 문제 중 하나는 오디오 동기화입니다. 일부 HLS 스트림의 오디오가 비디오와 동기화되지 않은 경우(예: 배우가 입을 열었지만 목소리가 몇 밀리초 빠르거나 늦음) 원본 비디오 파일이 촬영되었을 수 있습니다. 가변 프레임 속도를 사용합니다. 고정 비트 전송률로 변환해야 합니다.

가능하면 소프트웨어가 일정한 프레임 속도로 비디오를 녹화하도록 설정되어 있는지 확인하는 것이 훨씬 좋습니다.

HTTP 라이브 스트리밍 예

Google의 ExoPlayer 플레이어를 사용하여 미리 정의된 HLS를 스트리밍하는 HLS Android 애플리케이션을 준비했습니다. 비디오와 그 아래에 HLS "이벤트" 목록이 표시됩니다. 이러한 이벤트에는 다운로드된 모든 .ts 파일 또는 플레이어가 더 높거나 낮은 비트 전송률 스트림으로 전환하기로 결정할 때마다 포함됩니다.

뷰어 초기화의 주요 부분을 살펴보겠습니다. 첫 번째 단계에서는 장치의 현재 연결 유형을 검색하고 해당 정보를 사용하여 검색할 m3u8 파일을 결정합니다.

 String m3u8File = "hls.m3u8"; ConnectivityManager connectivity = (ConnectivityManager) this.getSystemService(Context.CONNECTIVITY_SERVICE); NetworkInfo activeNetwork = connectivity.getActiveNetworkInfo(); if (activeNetwork != null && activeNetwork.isConnectedOrConnecting()) { int type = activeNetwork.getType(); int subType = activeNetwork.getSubtype(); if (type == ConnectivityManager.TYPE_MOBILE && subType == TelephonyManager.NETWORK_TYPE_GPRS) { m3u8File = "hls_gprs.m3u8"; } } String m3u8URL = "https://s3-us-west-2.amazonaws.com/hls-playground/" + m3u8File;

꼭 필요한 것은 아닙니다. HLS 플레이어는 몇 청크 후에 항상 올바른 HLS 변형으로 조정되지만 처음 5-20초 동안 사용자는 스트림의 이상적인 변형을 시청하지 않을 수 있습니다.

m3u8 파일의 첫 번째 변종은 뷰어가 시작하는 변종임을 기억하십시오. 우리는 클라이언트 측에서 연결 유형을 감지할 수 있기 때문에 이 연결 유형에 대해 미리 준비된 m3u8 파일을 요청하여 초기 플레이어가 변형 간에 전환하는 것을 최소한 방지할 수 있습니다.

다음 단계에서는 HLS 플레이어를 초기화하고 시작합니다.

 Handler mainHandler = new Handler(); DefaultBandwidthMeter bandwidthMeter = new DefaultBandwidthMeter.Builder() .setEventListener(mainHandler, bandwidthMeterEventListener) .build(); TrackSelection.Factory videoTrackSelectionFactory = new AdaptiveTrackSelection.Factory(bandwidthMeter); TrackSelector trackSelector = new DefaultTrackSelector(videoTrackSelectionFactory); LoadControl loadControl = new DefaultLoadControl(); SimpleExoPlayer player = ExoPlayerFactory.newSimpleInstance(this, trackSelector, loadControl);

그런 다음 플레이어를 준비하고 이 네트워크 연결 유형에 적합한 m3u8을 제공합니다.

 DataSource.Factory dataSourceFactory = new DefaultDataSourceFactory(this, Util.getUserAgent(this, "example-hls-app"), bandwidthMeter); HlsMediaSource videoSource = new HlsMediaSource(Uri.parse(m3u8URL), dataSourceFactory, 5, mainHandler, eventListener); player.prepare(videoSource);

결과는 다음과 같습니다.

Android의 HLS 스트리밍 예

HLS 브라우저 호환성, 향후 개발

iOS의 비디오 스트리밍 앱에 대한 Apple의 요구 사항은 비디오가 10분보다 길거나 5MB보다 큰 경우 HLS 를 사용해야 한다는 요구 사항입니다. 그 자체로 HLS가 계속 존재한다는 보장입니다. HLS와 MPEG-DASH에 대한 우려가 있었고 어느 ​​것이 웹 브라우저 분야의 승자가 될 것입니다. HLS는 모든 최신 브라우저에서 구현되지 않습니다. 예를 들어 Android에서는 4.0 미만 버전에서는 전혀 작동하지 않습니다. 4.1에서 4.4까지는 부분적으로만 작동합니다(예: 오디오가 누락되었거나 비디오가 누락되었지만 오디오는 작동함).

그러나 이 "전투"는 최근에 약간 더 단순해졌습니다. Apple은 새로운 HLS 프로토콜이 조각난 mp4 파일( fMP4 )을 허용할 것이라고 발표했습니다. 이전에는 HLS와 MPEG-DASH를 모두 지원하려면 비디오를 두 번 인코딩해야 했습니다. 이제 동일한 비디오 파일을 재사용하고 메타데이터 파일(HLS의 경우 .m3u8 및 MPEG-DASH의 경우 .mpd )만 다시 패키징할 수 있습니다.

또 다른 최근 발표는 고효율 비디오 코덱(HEVC)에 대한 지원입니다. 사용하는 경우 조각난 mp4 파일로 패키징해야 합니다. 그리고 그것은 아마도 HLS의 미래가 fMP4 라는 것을 의미합니다.

브라우저 세계의 현재 상황은 <video> 태그의 일부 브라우저 구현만 기본적으로 HLS를 재생한다는 것입니다. 그러나 HLS 호환성을 제공하는 오픈 소스 및 상용 솔루션이 있습니다. 대부분은 Flash fallback을 사용하여 HLS를 제공하지만 JavaScript로 완전히 작성된 구현이 몇 개 있습니다.

마무리

이 문서는 특히 HTTP 라이브 스트리밍에 중점을 두고 있지만 개념적으로는 ABS(Adaptive Bitrate Streaming) 작동 방식에 대한 설명으로도 읽을 수 있습니다. 결론적으로 HLS는 비디오 스트리밍의 수많은 중요한 문제를 해결하는 기술이라고 말할 수 있습니다.

  • 비디오 파일의 저장을 단순화합니다
  • CDN
  • 다른 클라이언트 대역폭을 처리하고 스트림 간 전환을 처리하는 클라이언트 플레이어
  • 이 문서에서 다루지 않은 자막, 암호화, 동기화된 재생 및 기타 기능

HLS를 사용하든 MPEG-DASH를 사용하든 두 프로토콜은 유사한 기능을 제공해야 하며 HLS에 단편화된 mp4(fMP4)가 도입되어 동일한 비디오 파일을 사용할 수 있습니다. 즉, 대부분의 경우 두 프로토콜의 기본 사항을 이해해야 합니다. 운 좋게도, 그들은 같은 방향으로 움직이는 것처럼 보이므로 마스터하기가 더 쉽습니다.