1. 가변 비트레이트 스트리밍 (Adaptive Bitrate Streaming)
가변 비트레이트 스트리밍은 네트워크의 상태 혹은 전송속도등을 기반으로 대역폭이 소화할 수 있는 정도의 고화질
(즉, 높은 비트레이트를 가진 소스를 이용하도록)의 부분 컨텐츠를 전송하는 방식을 이야기 한다.
대역폭이 떨어지거나 네트워크 혼잡도가 높아지면서 전송 효율이 떨어지면 낮은 부분 컨텐츠로 변경하여 전송하는 민첩함을 가지고 있기도 하다.
이같은 가변 전송을 하기 위해서는 가변 전송을 하고자 하는 컨텐츠를 다양한 비트레이트로 인코딩을 하는 과정이 선행 되어야 한다.
고화질의 원본 소스파일은 서비스 하고자 하는 비트레이트의 종류만큼 복수 개의 파일로 인코딩이 되어야 하고 가변 스트리밍을 위하여 전체 길이의 파일을 2 ~ 10초 단위의 부분 동영상으로 나누어 저장하게 된다.
예를들어 1분짜리 동영상을 3개의 비트레이트로 가변 비트레이트 스트리밍을 한다면 10초 단위로 부분 동영상을 만든다고 할 때, 총 30개의 파일(각 비트레이트 별로 10개씩)로 나누어져야 하는 것이다.
그렇다면 사용자 (End-User) 는 파일이 이렇게 쪼개져 있다는 것을 어떻게 알 수 있을까?
가변 비트레이트 스트리밍이 시작되는 시점에 사용자의 플레이어는 인코딩된 파일들의 조각 정보가 담겨 있는 메니페스트(Manifest) 파일을 받게 되고
이 파일이 담고 있는 비트레이트의 종류, 부분 파일의 식별 방법에 따라 적절한 파일을 HTTP 로 요청하여 받게된다.
2. HTTP 라이브 스트리밍(HTTP Live Streaming, HLS)
HTTP 라이브 스트리밍(HLS)는 원래 Apple에서 2009년 iOS 운영 체제(iOS 3.0)와 프로그램(QickTime X)의 일부로 구현한 비디오 전송 프로토콜이다.
HLS는 분할된 H.264 MPEG-2 TS 비디오와 M3U8 설명자 파일을 이용하여 가변 비트레이트 라이브 비디오와 주문형 비디오를 제공하는 기술이다.
HLS는 iPhone과 iPad의 사용자 수가 늘어남으로써 자연스럽게 그 수요가 늘어나게 되었다.
또한, 규격 자체의 단순함과 IETF(Internet Engineering Task Force)를 통한 표준화 작업 등을 통해 다른 업체들도 쉽게 HLS를 지원할 수 있게 했다.
그 결과로, Adobe는 Flash Media Server 4.0에서, Microsoft는 IIS Media Server 4.0에서, Wowza는 Wowza Media Server 2에서 HLS를 정식으로 지원하며,
모바일 운영체제에서 상대 진영이라 할 수 있는 Google의 Android에서도 3.0 버전인 Honeycomb부터 HLS를 지원하기 시작했다.
HLS 작동 원리는 M3U8 파일이 인덱스가 되어 클라이언트에게 특정 시각에 어떤 스트림과 어떤 세그먼트를 사용할 수 있는지를 알려준다.
디바이스는 대역폭과 CPU 제약을 고려하여 기본 매니페스트 파일에서 가장 적절한 스트림을 자동으로 선택하고 세그먼트를 다운로드하며 이를 재생 버퍼에 추가한다.
이름에서 짐작하듯 HLS는 HTTP에 데이터를 전송하므로, RTP 또는 RTMP와 같은 전통적인 스트리밍 프로토콜을 다양하게 개선할 수 있다.
대표적인 효과로는,
– 인프라 비용 절감
– CDN과 기타 HTTP 캐싱 인프라에서의 “캐시 기능”
– 프록시와 방화벽 제한을 통해 위협 저감
– 클라이언트 발견법(어댑티브 비트레이트)을 통한 실시간 최적화
– 내장 리던던시
– 간편한 HTML5 플레이어 구현
HLS 비디오는 다른 M3U8 파일을 참조하거나 각 비디오 세그먼트(.ts 세그먼트, 통상적으로 2 ~ 10초 길이)를 참조하는 인덱스 파일(.M3U8 XML 매니페스트)로 구성되어 있다.
* 이미지 출처 : https://zencoder.com/ko/hls-guide
3. HLS 를 위한 ts 파일 생성
HLS에서 사용하기 위한 ts 파일은 MPEG-2 TS 를 순서대로 저장한 파일이다. 다만 정한 시간에 따라 분할하여 저장한다.
HLS로 화면을 자연스럽게 재생하려면 각 ts 파일이 I-frame(Intra frame: 화면 전체가 압축되어 들어 있는 frame)을 포함해야 한다. 되도록이면 첫 비디오 데이터가 I-frame인 것이 좋다.
첫 화면이 I-frame 이 아니면 플레이어에서 화면이 나오지 않거나 일시적으로 뭉개진 화면이 나올 수 있다.
I-frame은 데이터 크기가 크기 때문에 ts 파일이 포함하는 데이터의 재생 시간 간격을 적절하게 선택해야 한다.
Apple이 HLS를 위해 권고하는 미디어의 규격은 다음과 같다.
Apple에서 권고하는 기기별/네트워크별 해상도와 비트레이트는 다음과 같다.
추천 값에 대한 더 자세한 내용은 “HTTP Live Streaming Overview” 문서를 참조한다.
4. HLS 암호화
HLS는 컨텐츠 보호를 위해 각각의 ts 파일을 개별적으로 암호화하는 방식을 사용한다.
암호화가 적용되면 암호화에 사용한 키(key)를 #EXT-X-KEY 지시어로 플레이어에 제공한다. 플레이어는 이 키 파일에 기록된 키를 이용하여 ts 파일을 해독하여 재생한다.
HLS이 기본적으로 사용하는 암호화 방식은 AES-128이다. 따라서 키 파일에는 16 octet의 binary key 정보가 들어 있어야 한다.
모든 ts 파일은 하나의 키를 이용하여 암호화할 수도 있고, 각 구간별로 다른 키를 이용하여 암호화할 수도 있다.
이론적으로는 각 ts 파일마다 다른 키를 사용하여 암호화할 수도 있지만, 매번 키 파일을 플레이어가 받아야 되므로 추가적인 전송 데이터가 발생한다.
* 일부출처 : http://helloworld.naver.com/helloworld/7122
* 참고문서 : Wowza Media Server – How to secure Apple HLS streaming using DRM encryption
http://www.wowza.com/forums/content.php?437-How-to-secure-Apple-HLS-streaming-using-DRM-encryption
[polldaddy rating=”7739789″]