KR101780247B1 - 동적 적응 버퍼링 기반의 ott 데이터 처리 방법 - Google Patents
동적 적응 버퍼링 기반의 ott 데이터 처리 방법 Download PDFInfo
- Publication number
- KR101780247B1 KR101780247B1 KR1020160026673A KR20160026673A KR101780247B1 KR 101780247 B1 KR101780247 B1 KR 101780247B1 KR 1020160026673 A KR1020160026673 A KR 1020160026673A KR 20160026673 A KR20160026673 A KR 20160026673A KR 101780247 B1 KR101780247 B1 KR 101780247B1
- Authority
- KR
- South Korea
- Prior art keywords
- media
- channel
- player
- file
- data
- Prior art date
Links
- 230000003139 buffering effect Effects 0.000 title claims abstract description 102
- 238000000034 method Methods 0.000 title claims abstract description 36
- 230000003044 adaptive effect Effects 0.000 title claims abstract description 28
- 238000012545 processing Methods 0.000 title claims abstract description 17
- 238000006243 chemical reaction Methods 0.000 claims description 9
- 238000012508 change request Methods 0.000 claims description 5
- 238000003672 processing method Methods 0.000 claims description 5
- 239000000872 buffer Substances 0.000 abstract description 14
- 230000005540 biological transmission Effects 0.000 abstract description 7
- 238000010586 diagram Methods 0.000 description 18
- 230000009191 jumping Effects 0.000 description 15
- 230000008569 process Effects 0.000 description 13
- 230000004044 response Effects 0.000 description 12
- 230000008859 change Effects 0.000 description 11
- 238000012546 transfer Methods 0.000 description 10
- 238000012360 testing method Methods 0.000 description 6
- 230000000694 effects Effects 0.000 description 5
- 238000010295 mobile communication Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 4
- 238000011156 evaluation Methods 0.000 description 4
- 230000006872 improvement Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000002474 experimental method Methods 0.000 description 3
- 238000005259 measurement Methods 0.000 description 3
- 238000004904 shortening Methods 0.000 description 3
- 230000000052 comparative effect Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000004088 simulation Methods 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000000087 stabilizing effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
- H04N21/234309—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by transcoding between formats or standards, e.g. from MPEG-2 to MPEG-4 or from Quicktime to Realvideo
-
- H04L65/605—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Transfer Between Computers (AREA)
Abstract
본 발명은 HLS를 동적으로 최적화하는 영상 비트율(video bitrate)로 전송하기 위한 적응 버퍼링을 갖는 OTT 데이터 처리 기술에 관한 것이다. 본 발명에서는 클라이언트 대역폭 용량에 대한 검침을 통해 다층 비트율과 대역폭 조절기 사이의 비디오 스트림을 조정한다. 특히, 본 발명의 다중채널 동적 버퍼링 방식에서는 종래의 HLS에 버퍼를 추가 설정하고 각각의 버퍼는 현재 채널에 대한 상대적인 이전 채널과 다음 채널을 지속적으로 미리 버퍼링함으로써 미디어 채널을 전환할 때 채널재핑 지연시간을 감소시킬 수 있는 장점이 있다.
Description
본 발명은 HLS를 동적으로 최적화하는 영상 비트율(video bitrate)로 전송하기 위한 적응 버퍼링을 갖는 OTT 데이터 처리 기술에 관한 것이다. 본 발명에서는 클라이언트 대역폭 용량에 대한 검침을 통해 다층 비트율과 대역폭 조절기 사이의 비디오 스트림을 조정한다.
특히, 본 발명의 다중채널 동적 버퍼링 방식에서는 종래의 HLS에 버퍼를 추가 설정하고 각각의 버퍼는 현재 채널에 대한 상대적인 이전 채널과 다음 채널을 지속적으로 미리 버퍼링함으로써 미디어 채널을 전환할 때 채널재핑 지연시간을 감소시킬 수 있는 장점이 있다.
방송은 크게 전통적인 RF 기반의 방송과 인터넷 프로토콜 기반의 IP 방송으로 크게 구별할 수 있다.
먼저, RF 기반의 방송은 전통적으로 방송 서비스를 제공하는 기술로서, 전송 매체의 종류에 따라 위성방송, 지상파 방송, 케이블 방송으로 나뉘고 각각에 대한 규격은 DVB-S/S2, ATSC, DVB-T/T2, DVB-C, ISDB로 구분된다. 이러한 RF 기반의 방송은 송출 인프라가 구축되어 오랫동안 안정되게 디지털 방송을 송출하고 있다. 하지만 주파수 대역이 제한되어 있어 추가적인 방송서비스 및 부가서비스를 추가하기가 힘들다. 특히, 최근들어 4K UHD방송이 시작되면서 방송채널 한 개가 차지하는 주파수는 매우 커져 32Mbps까지 사용하면서 주파수가 턱없이 부족하게 되었다. 방송채널의 화질은 점점 더 고화질로 바뀌고 있는 추세이기에 주파수 부족은 점점 더 심화될 것으로 예상된다.
다음으로, 인터넷 프로토콜(IP)을 기반으로 하는 IP 방송은 인터넷을 통하여 방송 서비스를 제공하는 기술로서, 다시 멀티캐스트 기반의 IPTV(Internet Protocol Television)와 일방향 방송 기반의 OTT(Over-The-Top)로 세분될 수 있다. IPTV는 관리형 네트워크(managed network)를 사용하고, 100Mbps내의 대역폭에서 서비스가 되고 있다. OTT는 비관리형 네트워크(unmanaged network) 상에서 방송과 VOD를 서비스하고 있고 일방향 방송을 사용한다.
현재 모바일 디바이스와 PC에서 시청하는 대부분의 방송이 OTT에 해당된다. 초기에 OTT는 기존의 통신 및 방송 사업자가 아닌 제 3 사업자들이 IP 망(퍼블릭 망)을 통해 제공하는 영화나 방송프로그램 등의 프리미엄 동영상 서비스를 단말기를 통해 제공하는 것이었고 일 예가 넷플릭스(Netflix)이다. 하지만 현재는 그 분야가 확대되어 인터넷을 통해 영화나 방송프로그램 등과 같은 동영상 콘텐츠를 전달하는 서비스를 총칭하는 의미로도 사용되고 동영상 이외에 데이터, 광고, 전자상거래 등 멀티미디어 콘텐츠도 서비스 영역으로 포함하고 있다.
OTT는 채널을 무한정으로 늘릴 수 있는 장점이 있는데, OTT에서 방송 스트림을 제공하는 방식, 즉 스트리밍 전송 방식으로는 HTTP, HLS, RTP, RTSP 등이 있지만 현재는 HLS가 가장 널리 사용되고 있다.
HLS(HTTP Live Streaming)는 Apple에서 iOS 3.0과 QuickTime X를 위해 2009년에 내놓은 프로토콜이다. HLS에서는 스트리밍 데이터를 MPEG-2 트랜스포트 스트림(Transport Stream; TS)에 담아 시간 단위로 잘게 쪼개서 미디어 플레이어로 전송하고 어떤 파일을 재생해야 하는지에 관한 정보는 m3u8 파일을 통해 미디어 플레이어로 전달한다.
HLS는 iPhone과 iPad의 사용자 수가 늘어남에 따라 널리 보급되었고, 규격이 단순하고 IETF(Internet Engineering Task Force)의 표준화 작업에 의해 애플 외의 다른 업체들도 쉽게 HLS를 지원할 수 있었다. 그에 따라, 어도비(Adobe)는 Flash Media Server 4.0에서 HLS를 지원하였고 마이크로소프트는 IIS Media Server 4.0에서 HLS를 지원하였으며, 구글 안드로이드는 2.0 버전인 Honeycomb부터 HLS를 지원하기 시작하였다. 그에 따라, OTT 서비스는 iOS, 리눅스, 안드로이드, HTM5 등의 대부분의 운영체제에서 구현이 가능하게 되었다.
그런데 OTT는 일방향 방송 방식을 사용하고 비관리형 네트워크에서 동작하기 때문에 QoS를 보장할 수 없어 버퍼링이나 끊김 현상이 발생할 수 있다. 이는 안정적으로 서비스를 하는데 제약이 될 수 있기에 버퍼링 알고리즘을 최적화하여 끊김 현상이나 채널전환 속도를 향상시키는 것이 중요하다.
이에 본 발명에서는 HLS기반 적응 스트리밍 기반의 동적 버퍼링 알고리즘을 최적화하여 버퍼링 시간을 단축하고 안정적인 서비스를 할 수 있는 방안을 제시한다. 본 발명을 통해 안정적인 스트리밍 서비스를 모바일 디바이스와 PC에서 구현할 수 있다.
Inki Kim et al, "Analysis of Smart OTT based Zapping Time with Adaptive Buffering for Live Streaming." ICONI 2015, Dec. 2015
Gil Jin Yang, Byoung Wook Choi, and Jong Hun Kim, "Implementation of HTTP Live Streaming for an IP Camera using an Open Source Multimedia Converter," International Journal of Software Engineering and Its Applications Vol.8,No.6,2014 pp.39-50
Benjamin Schwarz, "A Harmonic, Viaccess-Orca and Broadpeak OTT White Paper," May 2012
Fernando M. V. Ramos, "GREEN IPTV: a resource and energy efficient network for IPTV," University of Cambridge, 2012
How-Sing Lin, "Improving the Availability of Scalable on-demand Streams by Dynamic Buffering on P2P Networks," KSII Transactions on Internet and Information Systems Vol. 4, No. 4, Aug. 2010
Hyoung-Gook Kim, "Enhanced Timing Recovery Using Active Jitter Estimation for Voice-Over IP Networks," KSII Transactions on Internet and Information Systems Vol. 6, No. 4, Apr. 2012
강민구 외, "OTT 연계형 PLC 기반의 3D 유니티 플랫폼" 2015년도 한국인터넷정보학회 추계학술발표대회 논문집 제16권2호, 2015.10
본 발명의 목적은 HLS를 동적으로 최적화하는 영상 비트율로 전송하기 위한 적응 버퍼링을 갖는 OTT 데이터 처리 기술을 제공하는 것이다.
특히, 본 발명의 목적은 종래의 HLS에 버퍼를 추가 설정하고 각각의 버퍼는 현재 채널에 대한 상대적인 이전 채널과 다음 채널을 지속적으로 버퍼링함으로써 미디어 채널을 전환할 때 채널재핑 지연시간을 감소시킬 수 있는 OTT 데이터 처리 기술을 제공하는 것이다.
상기의 목적을 달성하기 위하여 본 발명에 따른 동적 적응 버퍼링 기반의 OTT 데이터 처리 방법은, 네트워크 대역폭에 대응하는 영상의 초기 비트율을 HLS 서버로 제공하여 초기 비트율에 따라 현재 컨텐츠에 대한 미디어 파일을 스트리밍 제공받아 재생하는 제 1 단계; 해당 시점의 네트워크 대역폭에 대응하는 동적 비트율을 검출하여 HLS 서버로 제공함으로써 미디어 파일에 대해 그 검출된 동적 비트율에 따라 스트리밍 제공받는 제 2 단계; 현재 미디어 파일에 대한 다음재생 후보 미디어 데이터를 식별하는 제 3 단계; 다음재생 후보 미디어 데이터에 대한 다중 스트리밍을 HLS 서버로부터 제공받는 제 4 단계; 다중 스트리밍을 통해 제공되는 다음재생 후보 미디어 데이터에 대해 동적 버퍼링을 수행하는 제 5 단계; 미디어 파일의 변경 요구를 식별하면, 현재 미디어 파일의 재생을 종료하고 위 동적 버퍼링을 수행한 미디어 파일 데이터를 활용하여 다음재생 후보 미디어 데이터의 재생 동작으로 전환하는 제 6 단계;를 포함하여 구성된다.
본 발명에서 다음재생 후보 미디어 데이터는 OTT 방송의 편성에 따라 채널 업/다운 조작에 의해 나타날 인접 미디어 채널에서 제공되는 컨텐츠의 미디어 파일을 포함하여 구성될 수 있다.
이때, 제 1 단계는 현재 미디어 플레이어(mp_cur)를 생성 및 프리페어 설정하는 단계를 포함하여 구성되고, 제 4 단계는 현재 미디어 플레이어(mp_cur)를 생성하면서 인접 미디어 채널을 위한 하나이상의 전환 미디어 플레이어를 생성하고 다음재생 후보 미디어 데이터의 주소를 인접 미디어 채널 별로 전환 미디어 플레이어에 대해 데이터 소스 URL 설정하는 단계를 포함하여 구성되고, 제 5 단계는 전환 미디어 플레이어에 대해 프리페어 설정하고 onPreapared 호출을 감지하면 전환 미디어 플레이어를 현재 미디어 플레이어(mp_cur)에 대한 다음 미디어 플레어로 등록하며 현재 미디어 플레이어(mp_cur)를 통해 현재 미디어 채널의 방송 컨텐츠를 재생하는 단계를 포함하여 구성되고, 제 6 단계는 채널전환 입력이 식별되면 채널전환 입력에 대응하는 전환 미디어 플레이어를 동작시켜 해당 인접 미디어 채널의 컨텐츠를 재생하는 단계를 포함하여 구성될 수 있다.
이때, 인접 미디어 채널은 현재 미디어 채널에 대한 채널다운 미디어 채널과 채널업 미디어 채널을 포함하여 구성되고, 전환 미디어 플레이어는 채널다운 미디어 채널을 위한 제 1 전환 미디어 플레이어(mp_chdown) 및 채널업 미디어 채널을 위한 제 2 전환 미디어 플레이어(mp_chup)를 포함하여 구성되며, 제 6 단계에서 채널전환 입력이 채널-다운 버튼 조작이면 제 1 전환 미디어 플레이어(mp_chdown)를 동작시켜 채널다운 미디어 채널의 방송 컨텐츠를 재생하고, 제 6 단계에서 채널전환 입력이 채널-업 버튼 조작이면 제 2 전환 미디어 플레이어(mp_chup)를 동작시켜 채널업 미디어 채널의 방송 컨텐츠를 재생할 수 있다.
한편, 다음재생 후보 미디어 데이터는 OTT 방송의 편성에 따라 현재 미디어 채널에서 다음 순서로 배치된 컨텐츠의 미디어 파일, 현재 미디어 채널에서 현재 미디어 파일의 후속 TS 파일, 현재 컨텐츠 중간에 잠시 삽입될 광고 또는 PPL 영상 중의 하나 이상을 포함하여 구성될 수 있다.
이때, 제 3 단계는 현재 미디어 파일에서 현재 TS 파일의 이후에 이어지는 하나이상의 후속 TS 파일을 다음재생 후보 미디어 데이터로서 식별하는 단계를 포함하여 구성되고, 제 4 단계는 네트워크 대역폭의 허용 한도 내에서 복수의 파일 전송 세션을 설정하고 이들 복수의 파일 전송 세션을 통해 상기 후속 TS 파일을 다중 스트리밍으로 상기 HLS 서버로부터 제공받는 단계를 포함하여 구성되고, 제 5 단계는 제공받는 후속 TS 파일을 버퍼 메모리의 논리적으로 구분된 복수의 영역에 동적 버퍼링하는 단계를 포함하여 구성되고, 제 6 단계는 현재 TS 파일의 재생 완료를 감지하면 위 동적 버퍼링을 수행한 후속 TS 파일 중에서 현재 TS 파일의 다음에 해당하는 TS 파일의 재생을 시작하는 단계를 포함하여 구성된다.
이때, 제 1 단계는 제 1 미디어 플레이어(Player 0)를 생성하고 현재 컨텐츠의 미디어 파일을 재생하는 단계를 포함하여 구성되고, 제 4 단계는 제 2 미디어 플레이어(Player 1)를 생성하고 다음재생 후보 미디어 데이터의 주소를 제 2 미디어 플레이어(Player 1)에 대해 데이터 소스 URL 설정하는 단계를 포함하여 구성되고, 제 5 단계는 제 2 미디어 플레이어(Player 1)에 대해 프리페어 설정하고 onPreapared 호출을 감지하면 제 2 미디어 플레이어(Player 1)를 제 1 미디어 플레이어(Player 0)에 대한 다음 미디어 플레어로 등록하는 단계를 포함하여 구성되고, 제 6 단계는 제 1 미디어 플레이어(Player 0)에 의한 현재 컨텐츠의 재생이 완료되면 제 2 미디어 플레이어(Player 1)가 자동으로 시작되는 단계를 포함하여 구성된다.
한편, 본 발명에 따른 컴퓨터로 판독가능한 기록매체는 컴퓨터에 이상과 같은 동적 적응 버퍼링 기반의 OTT 데이터 처리 방법을 실행시키기 위한 프로그램을 기록한 것이다.
본 발명에 따르면 HLS기반 적응 스트리밍 기반의 동적 버퍼링 알고리즘을 최적화하여 버퍼링 시간을 단축함으로써 안정적인 OTT 방송 서비스를 구현할 수 있는 장점을 얻을 수 있다.
또한, 본 발명에 따르면 다중채널 동적 버퍼링을 통하여 미디어채널을 전환할 때 채널재핑 지연시간을 감소시킬 수 있는 장점도 얻을 수 있다.
[도 1]은 HLS기반 적응 스트리밍의 전체적인 동작 방식을 개념적으로 나타내는 도면.
[도 2]는 HLS에서 네트워크 대역폭 변화에 대응하여 적응 비트율 스트리밍을 구현하는 개념을 나타내는 도면.
[도 3]은 HLS의 기술적 특징을 다른 기술규격과 비교하여 나타내는 비교표.
[도 4]는 HLS에서 m3u8 파일을 사용하는 방식을 개념적으로 나타내는 도면
[도 5]는 HLS에서 m3u8 파일과 스트림 세그먼트의 대응 관계를 개념적으로 나타내는 도면.
[도 6]은 HLS에서 m3u8 파일이 시간 흐름에 따라 변화되는 예를 나타내는 도면.
[도 7]은 동적 버퍼링의 기본 개념을 나타내는 도면.
[도 8]은 동적 버퍼링에서 복수의 파일 전송 세션을 통해 하나의 컨텐츠를 스트리밍하는 개념을 나타내는 도면.
[도 9]는 단일채널 동적 버퍼링의 처리 프로세스를 나타내는 순서도.
[도 10] 및 [도 11]은 다중채널 동적 버퍼링의 처리 프로세스를 나타내는 순서도.
[도 12]는 동적 버퍼링의 성능 평가를 위한 시뮬레이션 조건을 나타내는 도면.
[도 13]은 동적 버퍼링의 성능 평가를 위해 네트워크 대역폭의 변경에 따른 채널재핑 지연시간의 테스트 결과를 나타내는 도면.
[도 14]는 동적 버퍼링의 성능 평가를 위해 영상 비트율의 변경에 따른 채널재핑 지연시간의 테스트 결과를 나타내는 도면.
[도 2]는 HLS에서 네트워크 대역폭 변화에 대응하여 적응 비트율 스트리밍을 구현하는 개념을 나타내는 도면.
[도 3]은 HLS의 기술적 특징을 다른 기술규격과 비교하여 나타내는 비교표.
[도 4]는 HLS에서 m3u8 파일을 사용하는 방식을 개념적으로 나타내는 도면
[도 5]는 HLS에서 m3u8 파일과 스트림 세그먼트의 대응 관계를 개념적으로 나타내는 도면.
[도 6]은 HLS에서 m3u8 파일이 시간 흐름에 따라 변화되는 예를 나타내는 도면.
[도 7]은 동적 버퍼링의 기본 개념을 나타내는 도면.
[도 8]은 동적 버퍼링에서 복수의 파일 전송 세션을 통해 하나의 컨텐츠를 스트리밍하는 개념을 나타내는 도면.
[도 9]는 단일채널 동적 버퍼링의 처리 프로세스를 나타내는 순서도.
[도 10] 및 [도 11]은 다중채널 동적 버퍼링의 처리 프로세스를 나타내는 순서도.
[도 12]는 동적 버퍼링의 성능 평가를 위한 시뮬레이션 조건을 나타내는 도면.
[도 13]은 동적 버퍼링의 성능 평가를 위해 네트워크 대역폭의 변경에 따른 채널재핑 지연시간의 테스트 결과를 나타내는 도면.
[도 14]는 동적 버퍼링의 성능 평가를 위해 영상 비트율의 변경에 따른 채널재핑 지연시간의 테스트 결과를 나타내는 도면.
이하에서는 도면을 참조하여 본 발명을 상세하게 설명한다.
[도 1]은 OTT에서 사용되는 HLS기반 적응 스트리밍(HLS Adaptive Streaming)의 전체적인 동작 방식을 개념적으로 나타내는 도면이다. [도 1]을 참조하면, HLS기반 적응 스트리밍은 다음의 5 단계로 이루어진다.
(1) 다중 비트율 세그먼트(multiple-bitrate segments)를 인코딩하는 단계;
(2) 영상을 스플릿하여 세그먼트 구성(segmentation)하는 단계;
(3) 각 세그먼트에 대해 HTTP-URL로 주소 매핑(making each segment addressable via a HTTP-URL)하는 단계;
(4) 사용자가 각자의 상황에 맞는 세그먼트 URL을 요청하는 단계;
(5) 그 요청에 대응하는 세그먼트들을 클라이언트 디바이스(미디어 플레이어)로 전송하여 동영상 재생이 이루어지도록 하는 단계.
HLS는 어댑티브 비트율 라이브와 VOD 비디오 전송을 구현하기 위해서 동영상 데이터를 스트림 세그먼트(stream segment), 즉 세그먼트 형식의 H.265 MPEG-2 TS 비디오로 전송한다. 스트림 세그먼트는 개념적으로는 잘게 쪼개놓은 다수의 TS 파일이다. 이때, TS는 MPEG-2 트랜스포트 스트림을 의미한다.
또한, HLS는 이들 스트림 세그먼트의 구성에 관한 정보를 m3u8 파일에 담아 제공한다. 일반적으로 m3u는 멀티미디어 플레이리스트(multimedia playlist)라고 불리는 것으로 멀티미디어 파일의 재생목록을 관리하는 파일이다. m3u8 파일은 UTF-8 로 인코딩된 m3u 파일로서, HLS에서 어떤 스트림의 어떤 세그먼트가 사용가능한지 미디어 플레이어가 식별할 수 있도록 정보를 제공하는 인덱스 파일이다. HLS에서 m3u8의 사용 방식에 대해서는 [도 4] 내지 [도 6]을 참조하여 후술한다.
미디어 플레이어는 현재 활용가능한 통신속도와 자신의 프로세싱 능력에 기초하여 매니페스트 파일에서 가장 적합한 스트림을 자동으로 선택하고, 세그먼트 파일을 다운로드 받아서 비디오 재생용 버퍼로 추가한다.
HLS 서버(200)는 [도 1]에서 미디어 오리진 서버(Media Origin Server; 220)와 HTTP 캐시 서버(HTTP Cache Server; 210)를 합친 것으로서 클라이언트 디바이스(동영상 재생장치, 미디어 플레이어; 100)로부터 HTTP 요청을 받아서 플레이어에 HTTP 응답을 제공하는 역할을 수행한다. 구체적으로는 HTTP 포맷에 따라 플레이어로부터 요청을 받고, 그 요청받은 파일을 찾아서 그대로 응답 메세지에 포함시켜 플레이어로 제공한다.
[도 2]는 HLS에서 네트워크 대역폭 변화에 대응하여 적응 비트율 스트리밍을 구현하는 개념을 나타내는 도면이다.
HLS는 사용자가 이동하는 중에 놓여지게 되는 통신망 속도를 감지하고 그에 적합한 콘텐츠를 선택하여 재생하는 적응 비트율 스트리밍을 지원한다. 적응 비트율 스트리밍을 적용하면 사용자의 통신망 환경이 변화해도 동영상 재생이 실패하지 않고 지속적으로 이루어진다.
예를 들어 사용자가 무선랜(Wi-Fi) 환경에서 라이브 방송에 대한 스트리밍 서비스를 사용하던 중에 이동통신망(예: LTE) 환경으로 이동하는 경우를 가정한다. 사용자가 무선랜 환경에서 벗어나 이동통신망 환경으로 진입하면 네트워크의 대역폭이 감소된다.
일반적인 스트리밍 서비스에서는 사용자가 이동통신망 환경으로 진입하는 순간부터 동영상 데이터를 제대로 수신하지 못하여 지속적으로 버퍼링이 발생하거나 데이터 부족으로 인해 정상적인 화면 표시가 실패하는 문제가 발생한다.
하지만, HLS 기반의 스트리밍 서비스에서는 이동통신망 환경으로의 진입이 감지되면 이동통신망 환경의 라이브 서비스로 자동 전환함으로써 재생 화면의 품질과 해상도는 저하되지만 동영상 재생이 끊어지지 않고 지속적으로 라이브 서비스를 이용할 수 있다.
[도 3]은 HLS의 기술적 특징을 다른 기술규격과 비교하여 나타내는 비교표이다.
라이브 방송 서비스에서 적응 스트리밍을 구현하기 위하여 기존에 여러 업체에서 기술 규격을 제시하였으며 대표적인 것으로는 Adobe HDS, Microsoft HSS, Apple HLS, 3GPP/MPEG DASH를 들 수 있다. 이중에서 HLS는 HTTP 프로토콜을 통해 데이터를 전송하므로 RTSP(Real-Time Streaming Protocol), RTP(Real-time Transport Protocol), RTMP(Real-Time Messaging Protocol) 등을 사용하는 다른 기술 규격에 비해 여러가지 장점을 갖는다.
HLS가 나타내는 장점으로는 인프라 비용 절감, CDN(Contents Delivery Network)과 기타 HTTP 캐싱 인프라에서의 캐시(cache) 기능, 프록시와 방화벽에서 차단당할 위험 감소, 클라이언트 추정을 통한 실시간 최적화, 포맷 자체의 높은 안정성, HTML5 플레이어 구현의 용이성 등을 들 수 있다.
이와 같은 HLS의 기술적 특징을 다른 적응비트율 동영상 서비스 기술인 3GPP/MPEG DASH와 비교하여 나타내면 [도 3]와 같다.
[도 4]는 HLS에서 m3u8 파일을 사용하는 방식을 개념적으로 나타내는 도면이다.
HLS의 m3u8 포맷을 이해하기 위해 m3u 포맷에 대해 먼저 살펴본다. m3u 포맷은 원래 오디오 스트리밍 분야에서 사용하던 기술로서 미디어 플레이어에서 연속 재생할 MP3 파일 목록을 저장하는 멀티미디어 플레이리스트 파일이다. 각 라인마다 재생 대상인 파일의 경로(path)를 기재한 매우 단순한 구조이다.
그런데 m3u 포맷은 Latin-1 문자 집합만 적을 수 있다는 한계가 있었고, 단순히 파일 목록을 나열할 뿐이므로 미디어 플레이어로서는 그 재생할 파일에 대한 정보를 m3u 파일로부터 알 수 없다는 단점이 있었다. 그에 따라 스트리밍 서비스에서 활용할 목적으로 m3u 포맷을 확장하여 m3u8 포맷을 규정하였다. m3u8 포맷에서는 UTF-8 문자 집합을 사용할 수 있고, 여러 가지 지시어를 활용하여 재생 대상인 파일에 대한 정보를 미디어 플레이어에게 제공하는 것이 가능하다.
HLS는 m3u8 파일을 사용하는데, 이때 적용되는 규칙을 간단히 살펴보면 다음과 같다.
먼저, [도 4]에 도시된 바와 같이 m3u8 파일의 첫번째 라인은 #EXTM3U로 시작해야 한다. #EXTM3U라는 지시어를 통해 해당 파일이 m3u8 포맷을 사용한다는 것을 미디어 플레이어에게 알려준다.
그리고, m3u8 파일의 모든 지시어는 라인 맨 앞을 #EXT로 시작해야 한다. #EXT로 시작하지 않으면 # 이후의 문자열을 주석으로 간주한다.
[도 4]의 좌측에는 HLS에서 사용하는 m3u8 파일의 일 예가 개시되어 있고, [도 4]의 우측에는 당해 m3u8 파일이 관리하는 스트림 세그먼트의 일 예가 개시되어 있다.
먼저, #EXT-X-TARGETDURATION 지시어는 ‘#EXT-X-TARGETDURATION: <시간: 초>’의 신택스(syntax)를 갖는 것으로서 파일 목록에 나열된 각 파일의 최대 재생 시간을 나타낸다.
#EXT-X-MEDIA-SEQUENCE 지시어는 ‘#EXT-X-MEDIA-SEQUENCE: <첫 파일의 일련번호>’의 신택스를 갖는 것으로서 미디어 플레이어가 첫번째로 재생해야하는 파일의 일련번호를 명시한다. [도 4]에서는 3개의 파일(0, 1, 2) 중에서 0 파일을 첫번재로 재생해야 함을 나타내었다.
#EXTINF 지시어는 ‘#EXTINF: <시간: 초>, <제목>’의 신택스를 갖는 것으로서 그 지시어의 다음에 명시된 콘텐츠의 재생 시간과 제목을 명시한다. [도 4]에서는 3개의 TS 파일의 제목을 제시하고 이들에 대해 재생시간이 2초라는 것을 나타내었다.
[도 5]는 HLS에서 적응 비트율 스트리밍을 지원하기 위한 m3u8 파일과 스트림 세그먼트의 대응 관계를 개념적으로 나타내는 도면이다.
적응 비트율 스트리밍을 위해 HLS에서는 동시에 여러 비트율의 TS 파일에 대한 정보를 제공할 수 있다. [도 5]를 참조하면, 전체를 대표하는 대표 인덱스 파일(main index file)이 m3u8 포맷으로 제공되고, 대표 인덱스 파일 하부에서 각각의 비트율별로 플레이리스트 파일에 해당하는 대체 인덱스 파일(alternate index file)이 m3u8 포맷으로 마련되어 있다.
[도 5]에는 3가지의 비트율에 대응하여 대체 인덱스 파일이 도시되어 있다. 또한, 대체 인덱스 파일은 각자의 비트율에 해당하는 TS 파일들, 즉 스트림 세그먼트를 가리킨다. HLS는 다른 기술규격에 비해 확장성이 높고 안정적이기는 하나, 스트림 세그먼트(TS 파일)를 먼저 만들고 스트리밍 제공하는 방식이기 때문에 RTMP나 RTSP 방식에 비해 시간지연 문제가 발생할 수 있다.
한편, 대표 인덱스 파일에서 가장 처음에 나오는 m3u8 파일의 비트율는 스트리밍 서비스에서 가장 최적의 비트율 값을 갖는다. 미디어 플레이어는 동영상 재생을 시작할 때 낮은 비트율, 예컨대 128 kbps의 데이터를 요청하는데, 그에 따라 미디어 플레이어의 네트워크 대역폭이 고화질 영상을 재생하기에 충분한 정도라 하더라도 한동안은 저화질 영상을 재생하게 된다.
[도 6]은 HLS에서 m3u8 파일이 시간 흐름에 따라 변화되는 예를 나타내는 도면이다. HLS 서비스가 시작되면 HLS 서버(200)에서 m3u8 파일은 세그먼트 파일(TS 파일)이 생길 때마다 지속적으로 변경되는데, [도 6]에 일 예를 제시하였다.
[도 6]을 참조하면, 처음에는 2, 3, 4의 일련번호를 갖는 TS 파일이 존재한다.
#EXT-X-TARGETDURATION이 2로 명시되어 있으므로 2초 후에는 5번 TS 파일이 생긴다. m3u8 파일의 뒷부분에 5번 TS 파일을 가리키는 라인을 추가할 수도 있다. 하지만 라인을 추가하여 m3u8 파일에 명시된 콘텐츠가 늘어나게 되면, 5번 TS 파일이 생기고 난 뒤에 스트리밍을 요청하는 미디어 플레이어는 콘텐츠 재생을 위해 2, 3, 4, 5의 4개 TS 파일을 요청하게 된다.
이는 초기 시작을 위한 대기 시간을 늘리고, 실제 동영상과 미디어 플레이어에서 재생하는 동영상의 시간 차이를 늘리게 된다. 그리고, 불운한 시점(unlucky timing)에서 스트리밍을 요청한 사용자는 상당히 오랜 시간동안 동영상 재생을 대기해야 하는 문제점이 있다.
그에 따라, 특정 개수의 TS 파일만을 m3u8 파일에 명시하는 것이 바람직하며, 이를 통해 각 사용자마다 유사한 수준의 적정 대기 시간을 보장할 수 있다.
이러한 점을 감안하여 HLS에서 미디어 플레이어는 동영상 재생을 위해 다음과 같이 동작한다.
먼저, m3u8 파일을 요청하고, m3u8 파일에 기록되어 있는 TS 파일들을 HLS 서버(200)에 요청하여 제공받는다. TS 파일들을 확보함에 따라 미디어 플레이어는 첫번째 TS 파일의 재생을 시작한다. [도 6]에서는 첫번째 TS 파일인 segment-000002.ts 파일을 재생한다.
미디어 플레이어는 현재 재생중인 TS 파일의 재생이 완료되면 m3u8 파일의 플레이리스트를 참조하여 다음 TS 파일을 재생하는데, 그와 동시에 HLS 서버(200)에 m3u8 파일을 요청함으로써 업데이트된 플레이리스트를 획득한다. [도 6]을 참조하면, 미디어 플레이어는 segment-000002.ts 파일의 재생이 완료되면 플레이리스트에서 그 다음 TS 파일인 segment-000003.ts 파일을 재생하면서 그동안 업데이트된 m3u8 파일을 입수한다. 업데이트된 m3u8 파일에 따르면 3, 4, 5의 일련번호를 갖는 TS 파일이 존재한다.
미디어 플레이어는 TS 파일을 연속적으로 재생하여 사용자가 마치 단일의 동영상 파일을 재생하는 것과 같이 끊김없는 화면을 제공한다. HLS 서버(200)는 각 분할된 TS 파일에 포함된 동영상 데이터가 시간적으로 겹치거나 시간 간격이 지나치게 벌어지지 않도록 TS 파일을 생성한다.
[도 7]은 본 발명에 따른 동적 버퍼링의 기본 개념을 나타내는 도면이다.
단계 (S100) ~ (S140) : 먼저, 클라이언트 디바이스(100)가 HLS 서버(200)에 비트율의 체크를 요청하고, 그에 대응하여 HLS 서버(200)는 현재 연결된 방송 서비스를 위한 비트율 체크 패킷을 클라이언트 디바이스(100)에 전송한다.
HLS 서버(200)로부터의 비트율 체크 패킷에 대응하여 클라이언트 디바이스(100)는 현재의 네트워크 대역폭을 감안하여 적절한 영상의 초기 비트율을 검출하고 그 결과를 HLS 서버(200)로 제공한다. 그에 대응하여, HLS 서버(200)는 클라이언트 디바이스(100)로부터 제공받은 해당 초기 비트율에 따라 현재 컨텐츠에 대한 미디어 파일을 스트리밍 전송한다. 클라이언트 디바이스(100)는 스트리밍 전송받은 영상 데이터를 이용하여 현재 컨텐츠를 재생한다.
단계 (S150) ~ (S170) : 네트워크 대역폭은 언제라도 변동될 수 있는데, 클라이언트 디바이스(100)는 그때그때의 네트워크 대역폭을 따른 적절한 동적 비트율을 검출하고, 그 검출된 동적 비트율을 HLS 서버(200)로 제공한다. 그에 대응하여, HLS 서버(200)는 현재 컨텐츠의 미디어 파일을 그 검출된 동적 비트율에 따라서 스트리밍 전송한다. 이를 통해, [도 2]를 참조하여 전술한 바와 같이 네트워크 대역폭의 변화에 대응하여 적응 비트율 스트리밍이 가능해진다.
단계 (S180) : 클라이언트 디바이스(100)는 현재 재생중인 미디어 파일을 체크하고 그에 대한 다음재생 후보 미디어 데이터를 확인한다. 다음재생 후보 미디어 데이터는 현재 미디어 채널에서 현재 재생중인 컨텐츠 다음에 제시될 다음 컨텐츠 영상 파일 또는 현재 컨텐츠의 후속 TS 파일을 의미할 수 있다. 또한, 다음재생 후보 미디어 데이터는 다른 미디어 채널에서 현재 제공되는 방송 컨텐츠 영상 파일을 의미할 수도 있다.
이때, 현재 미디어 채널의 다음 컨텐츠 영상 파일은 방송 편성에서 현재 컨텐츠의 다음 순서로 배치된 컨텐츠의 미디어 파일, 현재 컨텐츠 중간에 잠시 삽입될 광고 또는 PPL 영상 등을 포함한다.
또한, 현재 컨텐츠의 후속 TS 파일은 현재 컨텐츠를 구성하는 일련의 TS 파일들(스트림 세그먼트) 중에서 현재 화면 표시에 사용되고 있는 TS 파일의 이후에 배치되어 이후에 사용될 예정인 TS 파일을 의미한다.
또한, 다른 미디어 채널의 방송 컨텐츠 영상 파일은 방송 편성에서 채널 업/다운 조작에 의해 나타날 인접 미디어 채널에서 제공되는 컨텐츠의 미디어 파일을 포함한다.
단계 (S190), (S200) : 그리고 나서, 클라이언트 디바이스(100)는 다음재생 후보 미디어 데이터에 대한 다중 스트리밍을 HLS 서버(200)에 요청하고, 그에 대응하여 HLS 서버(200)는 다음재생 후보 미디어 데이터에 대한 다중 스트리밍을 클라이언트 디바이스(100)에 제공한다. 이때, HLS 서버(200)와 클라이언트 디바이스(100) 간에는 복수의 파일 전송 세션이 설정되어 있어 이들 세션을 통해 다중 스트리밍이 이루어진다.
단계 (S210) : 클라이언트 디바이스(100)는 HLS 서버(200)로부터 다중 스트리밍을 통해 제공되는 다음재생 후보 미디어 데이터에 대해 동적 버퍼링을 수행한다. 이러한 동적 버퍼링은 현재의 미디어 파일 재생 작업에 대한 백그라운드 프로세스로 수행된다.
이때, 다음재생 후보 미디어 데이터가 현재 시청중인 미디어 채널 내에서 다음 컨텐츠 영상 파일 또는 현재 컨텐츠의 후속 TS 파일인 경우에 수행되는 동적 버퍼링 작업을 본 명세서에서는 단일채널 동적 버퍼링이라고 부른다. 단일채널 동적 버퍼링에 대해서는 [도 9]를 참조하여 후술하며, 특히 다음재생 후보 미디어 데이터가 현재 컨텐츠의 후속 TS 파일인 경우에 이루어지는 처리 프로세스는 [도 8]을 참조하여 상세하게 후술한다.
또한, 다음재생 후보 미디어 데이터가 상이한 미디어 채널의 방송 컨텐츠 영상 파일인 경우에 수행되는 동적 버퍼링 작업을 본 명세서에서는 다중채널 동적 버퍼링이라고 부른다. 다중채널 동적 버퍼링에 대해서는 [도 10] 및 [도 11]을 참조하여 후술한다.
단계 (S220) : 클라이언트 디바이스(100)는 미디어 파일의 변경 요구를 식별하면 현재 미디어 파일의 재생을 종료하고 위 동적 버퍼링을 수행해둔 다음재생 후보 미디어 데이터의 재생 동작으로 전환한다.
클라이언트 디바이스(100)는 채널 업/다운 조작의 경우에는 현재 미디어 파일의 재생을 종료하고 다음재생 후보 미디어 데이터의 재생 동작을 개시함으로써 채널 전환이 이루어지도록 한다.
또한, 클라이언트 디바이스(100)는 현재 시청중인 컨텐츠의 종료 이벤트 또는 컨텐츠 임시 전환 이벤트(예: 중간광고 재생)에 의해 컨텐츠 변경의 요구를 감지하면 현재 컨텐츠에 대한 재생을 종료하고 다음재생 후보 미디어 데이터에 대한 재생을 시작한다.
또한, 클라이언트 디바이스(100)는 현재 컨텐츠에 대한 현재 TS 파일의 재생 종료(완료)를 감지하면 후속 TS 파일 중에서 현재 TS 파일의 다음에 해당하는 TS 파일의 재생을 시작한다.
전술한 바와 같이 단계 (S180) 내지 (S210)에서 다음재생 후보 미디어 데이터에 대한 동적 버퍼링을 미리 수행하였기에 다음 컨텐츠에 대한 재생을 즉시 수행할 수 있으며, 이를 통해 사용자에게 다음 컨텐츠의 재생 시작 시간이 단축되고 동일 컨텐츠 내에서도 끊김 현상이 종래에 비해 감소하여 보다 개선된 UX(User eXperience)를 제공할 수 있다.
한편, 본 명세서에서 '동적으로 버퍼링한다'는 말의 의미는 클라이언트 디바이스(100)에서 현재 시청중인 컨텐츠 이외에 그때그때의 상황에 따라서 다음에 재생할 가능성이 있는 다른 컨텐츠에 대해서도 미디어 파일의 스트리밍 및 버퍼링을 미리 해둔다는 것을 나타낸다. 또한, 하나의 컨텐츠 내에서 현재 필요한 TS 파일뿐만 아니라 향후 필요할 것으로 생각되는 TS 파일에 대해서도 스트리밍 및 버퍼링을 미리 해둔다는 것을 나타낸다.
또한, 본 명세서에서 '동시' 또는 '한꺼번에'라는 말의 의미는 물리적으로 동일한 시각을 나타내는 것은 아니고, 여러가지 일이 순차적으로 이루어지지 않고 앞의 것이 종료되기 전에 다른 것이 수행된다는 의미를 나타낸다.
[도 8]은 동적 버퍼링에서 복수의 파일 전송 세션을 통해 하나의 컨텐츠를 스트리밍하는 개념을 나타내는 도면이다.
단계 (S300), (S310) : 먼저, 클라이언트 디바이스(100)가 사용자가 컨텐츠를 시청하고 있는 해당 미디어 채널에 대한 m3u8 파일을 HLS 서버(200)로 요청하고, 그에 대응하여 HLS 서버(200)는 해당 미디어 채널에 대한 m3u8 파일을 클라이언트 디바이스(100)로 제공한다. 이때, 해당 미디어 채널에 대한 m3u8 파일을 HLS 서버(200)가 클라이언트 디바이스(100)로 제공하여 활용한다는 것은 전술한 바와 같이 HLS에서 종래에도 적용된 사항이다.
단계 (S320), (S330) : 클라이언트 디바이스(100)와 HLS 서버(200)는 m3u8 파일을 참조하면서 네트워크 대역폭에 따라 허용되는 한도 내에서 복수의 파일 전송 세션을 동시에 설정한다. 이들 파일 전송 세션은 현재 시청하는 컨텐츠의 미디어 파일에 대해서 TS 파일들을 스트리밍하기 위한 위한 것이다.
복수의 파일 전송 세션이 설정됨에 따라 복수의 TS 파일을 동시에 스트리밍할 수 있는 조건이 형성되었다.
HLS 서버(200)는 각각의 파일 전송 세션을 통해 복수의 TS 파일을 동시에 전송하는데, 이를 통해 클라이언트 디바이스(100)는 해당 컨텐츠에 대해 현재 다운로드받아야만 하는 TS 파일뿐만 아니라 향후 필요할 것으로 예상되는 TS 파일들을 미리 스트리밍받는다. [도 6]을 참조하면, 클라이언트 디바이스(100)가 4개의 파일 전송 세션을 설정하고 000002.ts 파일부터 000005.ts 파일을 한꺼번에 HLS 서버(200)로부터 스트리밍 제공받는다.
단계 (S340) : 클라이언트 디바이스(100)는 현재 시청중인 컨텐츠의 미디어 파일에 대해서 복수의 TS 파일을 동시에(병행적으로) 제공받으며, 이들을 버퍼 메모리(150)에 버퍼링한다. 즉, 동시에 제공받는 복수의 TS 파일들 중에서 현재 필요한 TS 파일은 기본 버퍼링 공간에 넣어 현재의 컨텐츠 재생에 활용하고, 향후 필요할 것으로 예상되어 미리 받아둔 TS 파일들은 동적 버퍼링 공간에 넣어 향후의 컨텐츠 재생에 활용한다.
이처럼 복수의 TS 파일들을 동적으로 버퍼링해야 하므로 버퍼 메모리(150)는 논리적으로 복수의 영역으로 구분하여 관리된다.
단계 (S350) : 클라이언트 디바이스(100)는 현재 TS 파일의 재생 완료를 감지하면 후속 TS 파일 중에서 그 다음에 해당하는 TS 파일의 재생을 시작한다. 현재 시청중인 컨텐츠에 대해 향후에 필요할 것으로 예상되는 TS 파일에 대한 동적 버퍼링을 미리 수행하였기에 컨텐츠 재생의 끊김 현상은 발생하지 않는다. 즉, 네트워크 대역폭이 갑자기 불량해지더라도 컨텐츠 재생이 끊어지지 않고 부드럽게 재생을 이어갈 수 있는 장점을 얻을 수 있다.
[도 9] 내지 [도 12]는 본 발명에 따른 동적 버퍼링의 처리 프로세스를 나타낸다.
본 발명에서는 동적 버퍼링 프레임워크를 통한 적응 버퍼링의 최적화 기법을 제안하는데, 단일채널 동적 버퍼링과 다중채널 동적 버퍼링을 제시한다. [도 9]는 하나의 미디어 채널 내에서 컨텐츠 파일들 간에 이루어지는 단일채널 동적 버퍼링의 처리 프로세스를 나타내고, [도 10] 및 [도 11]은 인접하는 미디어 채널들 간에 이루어지는 다중채널 동적 버퍼링의 처리 프로세스를 나타낸다.
따라서, 방송 서비스에서 현재 시청중인 채널 내에서 컨텐츠가 전환될 때에는 단일채널 동적 버퍼링을 적용하고, 사용자가 채널 업/다운 조작을 하여 채널 전환이 이루어질 때에는 다중채널 동적 버퍼링을 적용한다. 이를 통해 OTT 서비스의 전반적인 서비스 품질을 개선할 수 있다.
먼저, 단일채널 동적 버퍼링(single-channel dynamic buffering)은 동일한 미디어채널 내에서 여러 개의 미디어 스트림을 동적으로 재생하는데 있어 끊김 없이 자연스럽게 미디어 전환이 되기 위한 버퍼링 기술을 제시한다. 단일채널 동적 버퍼링은 미디어 전환을 부드럽게 만드는 효과를 제공하는데 하나의 방송 컨텐츠가 끝나고 다음 방송 컨텐츠로 넘어가는 상황뿐만 아니라 주문형 방송 중에 동적으로 광고를 삽입하는 상황에도 적용할 수 있다.
그리고, 다중채널 동적 버퍼링(multiple-channel dynamic buffering)은 채널 업/다운의 사용자 조작 등으로 인하여 상이한 미디어 채널들 간에 채널 전환이 일어날 때 컨텐츠 파일의 버퍼링에 소요되는 시간을 최소화하여 빠른 채널전환을 달성하기 위한 버퍼링 기술을 제시한다.
사용자가 지금 시청하고 있는 현재 미디어채널(current media channel)과 논리적으로 인접해 있는 미디어 채널들의 컨텐츠 스트림을 미리 동적으로 버퍼링함으로써 사용자 조작(예: 채널 업/다운, 채널 버튼 입력 등)에 의하여 미디어 전환(채널 변경)이 발생할 경우 빠른 응답성을 제공하는 것이다.
다중채널 동적 버퍼링은 다수의 미디어채널을 운용하는 OTT 서비스에서 채널 간 빠른 전환을 통해 서비스를 향상시키고 네트워크 대역폭을 효율적으로 운용하는 모델로 활용될 수 있다.
OTT 서비스는 QoS가 보장되지 않는 개방 네트워크를 사용하므로 네트워크 대역폭에 대한 보장이 전혀 없다. 그에 따라, 현재 운용되고 있는 OTT 서비스에서는 미디어 채널 전환에 최대 3~4초까지도 소요되는 문제가 발견되고 있는데, 다중채널 동적 버퍼링을 적용하면 미디어 채널 간의 빠른 전환이 가능해져서 종래의 문제점을 해결할 수 있다.
이하에서는 [도 9]를 참조하여 단일채널 동적 버퍼링에 대해서 기술하고, [도 10] 및 [도 11]을 참조하여 멀티채널 동적 버퍼링에 대해서 기술한다.
[도 9]는 단일채널 동적 버퍼링의 처리 프로세스를 나타내는 순서도이다.
첫번째 단계로, 제 1 미디어 플레이어(Player 0)를 생성하고 컨텐츠를 재생한다.
현재의 미디어 채널을 위해 제 1 미디어 플레이어(Player 0)를 생성하고 데이터 소스 URL을 설정하고 디스플레이를 설정하며 프리페어(prepare) 설정한다. 그리고 나서, 제 1 미디어 플레이어에 대해 미디어 재생관련 리스너(Listener)를 등록하고 오디오/비디오의 미디어 방식을 설정한 후 컨텐츠 재생을 시작한다.
이때, 미디어 플레이어에서의 미디어 설정을 위해서는 m3u8 포맷의 미디어 스트리밍 HLS 주소가 필요하고, 미디어 스트리밍을 위해서는 HLS 서버(200)가 필요하다. 또한 동적 버퍼링을 위해 각 비트율 별로 미디어 주소가 있어야 하는데 그 주소는 m3u8 파일에 정의된다.
이러한 첫번째 단계를 의사코드(psuedo code)로 표시하면 다음과 같다.
mp0 = new MediaPlayer();
mp0.setDataSource(TestURL1);
mp0.setDisplay(holder);
mp0.prepare();
mp0.setOnPreparedListener(this);
mp0.setOnCompletionListener(this);
mp0.setVideoStreamType();
mp0.setAudioStreamType();
mp0.start();
두번째 단계로, 제 2 미디어 플레이어(Player 1)를 생성 및 프리페어 설정한다.
제 1 미디어 플레이어(Player 0)에서의 컨텐츠 재생이 완료되기 전에 현재의 미디어 채널 내에서 다음 컨텐츠 재생을 위한 제 2 미디어 플레이어(Player 1)를 생성 및 설정한다.
이를 위해, 현재의 미디어 채널 내에서 제 2 미디어 플레이어(Player 1)를 생성하고 데이터 소스 URL을 설정하고 디스플레이를 설정하며 프리페어 설정한다. 그리고 나서, 제 2 미디어 플레이어에 대해 미디어 재생관련 리스너를 등록하고 오디오/비디오의 미디어 방식을 설정한다. 즉, 제 2 미디어 플레이어(Player 1)에 대해 프리페어 상태로 설정하는 작업까지 수행한다.
이러한 작업을 통하여 제 2 미디어 플레이어(Player 1)가 HLS 서버(200)와 통신하여 다음 컨텐츠에 대한 동적 버퍼링을 수행하게 된다.
이때 제 2 미디어 플레이어(Player 1)를 생성하는 시점은 클라이언트 디바이스의 성능을 고려하여 선택할 수 있다.
이러한 두번째 단계를 의사코드로 표시하면 다음과 같다.
mp1 = new MediaPlayer();
mp1.setDataSource(TestURL2);
mp1.setDisplay(holder);
mp1.prepare();
mp1.setOnPreparedListener();
mp1.setOnCompletionListener();
mp1.setVideoStreamType();
mp1.setAudioStreamType();
세번째 단계로, 제 2 미디어 플레이어(Player 1)를 제 1 미디어 플레이어(Player 0)에 대한 다음 미디어 플레어로 등록한다.
제 2 미디어 플레이어(Player 1)에 대해 등록된 미디어 리스너 중에서 미디어 프리페어가 완료되어 onPreapared 호출을 감지한다. 이때, 현재 컨텐츠 재생 중인 제 1 미디어 플레이어(Player 0)에 대해 다음 컨텐츠를 재생할 미디어 플레이어로서 제 2 미디어 플레이어(Player 1)를 등록한다.
이러한 세번째 단계를 의사코드로 표시하면 다음과 같다.
mp0.setNextMediaPlayer(mp1);
네번째 단계로, 제 1 미디어 플레이어(Player 0)의 컨텐츠 재생이 완료되면 제 2 미디어 플레이어(Player 1)로 컨텐츠 전환을 수행한다.
이상의 과정을 통하여 제 1 미디어 플레이어(Player 0)의 컨텐츠 재생이 진행되는 상황에서 제 2 미디어 플레이어(Player 1)에서 다음 컨텐츠에 대한 프리페어가 완료되고, 제 1 미디어 플레이어(Player 0)에 대한 다음 미디어 플레이어 등록이 완료되었다.
이때 제 1 미디어 플레이어(Player 0)의 컨텐츠 재생이 완료되면 위 등록된 제 2 미디어 플레이어(Player 1)가 자동으로 시작되어 컨텐츠 전환이 이루어진다. 다음 컨텐츠에 대한 동적 버퍼링이 이미 수행되었기 때문에 지연 없이 즉시 컨텐츠 전환이 달성될 수 있다.
한편, 만약 제 1 미디어 플레이어(Player 0)의 컨텐츠 재생이 완료되었지만, 미디어 루프가 형성되어 제 1 미디어 플레이어(Player 0)의 컨텐츠 재생을 재시작해야 하는 상황일 수 있다. 이 경우에는 다음 컨텐츠의 재생은 시작되지 않고 제 2 미디어 플레이어(Player 1)는 프리페어 상태(prepare)를 유지한 상태에서 제 1 미디어 플레이어(Player 0)의 컨텐츠 재생이 다시 시작된다.
이러한 네번째 단계를 의사코드로 표시하면 다음과 같다.
mp1.start();
[도 10] 및 [도 11]은 다중채널 동적 버퍼링의 처리 프로세스를 나타내는 순서도이다.
다중채널 동적 버퍼링은 복수 개의 미디어 채널에 대해 각각 재생할 미디어 파일을 미리 동적으로 버퍼링함으로써 채널 업/다운 등의 사용자 조작에 의해 미디어 채널을 전환할 때 채널 전환 직후의 초기 버퍼링 시간을 감소시켜 빠른 채널 전환을 제공한다.
본 명세서에서 현재 미디어채널(current media channel)은 사용자가 현재 시청하고 있는 채널을 의미하고, 채널다운 미디어채널(channel-down media channel)은 사용자가 채널다운(CH-DOWN) 버튼 조작을 입력했을 경우에 이동할 채널을 의미하고, 채널업 미디어채널(channel-up media channel)은 사용자가 채널업(CH-UP) 버튼 조작을 입력했을 경우에 이동할 채널을 의미한다.
다중채널 동적 버퍼링의 개념은 현재 미디어채널과 인접해 있는 채널다운 미디어채널 및 채널업 미디어채널을 미리 동적으로 버퍼링하여 미디어 채널의 전환이 발생시 신속하게 대응하는 것이다. 이로서 다수의 미디어채널을 운용하는 OTT 방송 서비스에서 채널 간 빠른 전환을 통해 사용자의 UX를 개선할 수 있다. 또한, 채널 전환이 이루어지는 바로 그 시점에 네트워크 대역폭이 양호하지 않더라도 무방하므로 네트워크 대역폭의 운용 효율성을 개선할 수도 있다.
다중채널 동적 버퍼링에서는 현재 시청중인 방송 컨텐츠를 재생하는 현재 미디어 플레이어(mp_cur) 외에 두 개의 전환 미디어 플레이어(mp_chdown, mp_chup)를 미리 생성해 두고, 채널 업/다운 상황에 맞게 전환 미디어 플레이어의 어느 하나(mp_ chdown 또는 mp_ chup)를 현재 미디어 플레이어(mp_cur) 이후에 컨텐츠를 재생할 다음 미디어 플레이어로 등록한다. 이를 통해 채널 전환 시에 자연스러운 컨텐츠 재생이 가능하다.
특히, 전환 미디어 플레이어(mp_chdown, mp_chup)를 생성하면서 미리 프리페어 상태까지 처리해주기 때문에 다음 미디어 플레이어(mp_ chdown 또는 mp_ chup)의 컨텐츠 재생을 시작하기 전에 전환 미디어 플레이어(mp_chdown, mp_chup)에 대한 버퍼링이 미리 수행된다. 이처럼 컨텐츠 파일의 버퍼링이 미리 수행되어 있기에 채널 전환 직후에 버퍼링으로 인한 화면 끊김 현상이 최소화된다.
다중채널 동적 버퍼링의 구조와 동작순서는 다음과 같다.
첫번째 단계로, 방송 시청 중인 현재 미디어 채널을 위해 현재 미디어 플레이어(mp_cur)를 생성 및 프리페어 설정한다.
현재 미디어 채널을 위해 현재 미디어 플레이어(mp_cur)를 생성하고 데이터 소스 URL을 설정하고 디스플레이를 설정하며 프리페어 설정한다. 그리고 나서, 현재 미디어 플레이어(mp_cur)에 대해 미디어 재생관련 리스너를 등록하고 오디오/비디오의 미디어 방식을 설정한 후 컨텐츠 재생을 시작한다.
이때, 미디어 설정을 위해서는 m3u8 포맷의 미디어 스트리밍 HLS 주소가 필요하고, 미디어 스트리밍을 위해서는 HLS 서버(200)가 필요하다. 또한 동적 버퍼링을 위해 각 비트율 별로 미디어 주소가 있어야 하는데 그 주소는 m3u8 파일에 정의된다.
이러한 첫번째 단계를 의사코드로 표시하면 다음과 같다.
mp_cur = new MediaPlayer();
mp_cur.setDataSource(TestURL1);
mp_cur.setDisplay(holder);
mp_cur.prepare();
mp_cur.setOnPreparedListener(this);
mp_cur.setOnCompletionListener(this);
mp_cur.setVideoStreamType();
mp_cur.setAudioStreamType();
두번째 단계로, 현재 미디어 채널에 인접하는 미디어 채널을 위해 전환 미디어 플레이어(mp_chdown, mp_chup)를 생성하고 프리페어 설정한다.
현재 미디어 플레이어(mp_cur)를 생성하면서 채널다운 미디어 채널과 채널업 미디어 채널에서의 컨텐츠 재생을 위한 전환 미디어 플레이어(mp_chdown, mp_chup)를 생성하고 프리페어 상태로 설정하는 작업까지 수행한다. 즉, 전환 미디어 플레이어(mp_chdown, mp_chup)를 생성하고 데이터 소스 URL을 설정하고 디스플레이를 설정하며 프리페어 설정한다. 그리고 나서, 전환 미디어 플레이어에 대해 미디어 재생관련 리스너를 등록하고 오디오/비디오의 미디어 형식을 설정한다.
한편, 전환 미디어 플레이어의 생성 및 프리페어 설정 과정은 현재 미디어 플레이어(mp_cur)를 생성하는 시점에 멀티태스킹으로 수행되는 작업이며, 현재 미디어 플레이어(mp_cur)가 현재 미디어 채널의 컨텐츠 재생을 시작한 이후에 수행되어야 하는 것은 아니다.
이러한 두번째 단계를 의사코드로 표시하면 다음과 같다.
mp_chdown = new MediaPlayer();
mp_chdown.setDataSource(TestURL2);
mp_chdown.setDisplay(holder);
mp_chdown.prepare();
mp_chdown.setOnPreparedListener();
mp_chdown.setOnCompletionListener();
mp_chdown.setVideoStreamType();
mp_chdown.setAudioStreamType();
mp_chup = new MediaPlayer();
mp_chup.setDataSource(TestURL3);
mp_chup.setDisplay(holder);
mp_chup.prepare();
mp_chup.setOnPreparedListener();
mp_chup.setOnCompletionListener();
mp_chup.setVideoStreamType();
mp_chup.setAudioStreamType();
세번째 단계로, 전환 미디어 플레이어(mp_chdown, mp_chup)를 현재 미디어 플레이어(mp_cur)에 대한 다음 미디어 플레어로 등록한다.
현재 미디어 플레이어(mp_cur)에 대해 등록된 미디어 리스너 중에서 미디어 프리페어가 완료되어 onPreapared 호출이 감지되면 그에 대응하여 현재 미디어 플레이어(mp_cur)에 대해 다음 컨텐츠를 재생할 미디어 플레이어로서 전환 미디어 플레이어(mp_chdown 또는 mp_chup)를 등록한다.
이러한 세번째 단계를 의사코드로 표시하면 다음과 같다.
mp_cur.setNextMediaPlayer(mp_chdown); 또는
mp_cur.setNextMediaPlayer(mp_chup);
네번째 단계로, 앞서 생성하였던 현재 미디어 플레이어(mp_cur)를 통해 현재 미디어 채널에 대한 방송 컨텐츠를 재생하는데, 이러한 네번째 단계를 의사코드로 표시하면 다음과 같다.
mp_cur.start();
다섯번째 단계로, 채널전환 입력(예: 사용자에 의한 채널 업/다운 버튼 조작)이 식별되면 그에 대응하여 전환 미디어 플레이어(mp_chdown 또는 mp_chup)로 컨텐츠 전환을 수행한다.
사용자가 인접하는 미디어 채널로 채널 전환을 요청하면 앞서 setNextMediaPlayer에 의해 등록된 전환 미디어 플레이어(mp_chdown 또는 mp_chup)가 자동으로 재생된다. 즉, 사용자가 채널-업 버튼을 조작하면 채널업 미디어채널을 위한 전환 미디어 플레이어(mp_chup)이 재생되고, 사용자가 채널-다운 버튼을 조작하면 채널다운 미디어채널을 위한 전환 미디어 플레이어(mp_chdown)이 재생된다. 이들 전환 미디어 플레이어를 위한 다음 컨텐츠의 동적 버퍼링이 이미 수행되었기 때문에 지연 없이 즉시 채널 전환이 달성될 수 있다.
이러한 다섯번째 단계를 의사코드로 표시하면 다음과 같다.
mp_chdown.start(); 또는
mp_chup.start();
여섯번째 단계로, 이상의 과정을 통해 채널 전환된 미디어 채널을 현재 채널로 설정하고 현재 미디어 플레이어(mp_cur)와 전환 미디어 플레이어(mp_chdown, mp_chup)를 재설정한다.
사용자의 채널 업/다운 조작에 대응하여 채널 전환이 완료되면, 그 전환 완료되어 사용자가 새롭게 시청하게 된 미디어 채널을 다시 현재 채널로 삼고, 이를 기준으로 [도 10] 및 [도 11]의 프로세스를 수행한다.
[도 12]는 동적 버퍼링의 성능 평가를 위한 시뮬레이션 조건을 나타내는 도면이다.
본 발명과 종래기술의 비교 실험을 통해 본 발명에 따른 다중채널 동적 버퍼링이 미디어채널 전환의 성능을 개선함을 확인한다. 이를 위해 안드로이드 기반의 셋톱박스를 두 대 프리페어하고, 각 셋톱박스에 본 발명에 따른 다중채널 동적 버퍼링을 구현한 안드로이드 앱(미디어 플레이어)과 종래기술에 따른 싱글 버퍼링을 구현한 안드로이드 앱(미디어 플레이어)을 구동하였다.
[도 12]는 비교 실험에 사용된 주요 기기들의 사양을 나타낸다. 다양한 경우에 대해 버퍼링 성능을 측정하기 위해 3가지 영상 스트림을 프리페어하였고, 각 영상은 3, 5, 10, 15, 20 Mbps 비트율로 인코딩하여 스트림 비트율에 따른 성능 변화의 경향도 드러나도록 하였다.
[도 13]과 [도 14]를 참조하면, 비교 실험을 통하여, 본 발명의 다중채널 동적 버퍼링을 적용함으로써 채널재핑 지연시간(zapping time)이 종래기술에 비해 대폭 개선됨을 확인하였다. 특히, 본 발명에 따르면 영상 비트율 또는 네트워크 대역폭이 변화하더라도 채널재핑 지연시간이 일정한 수준(예: 1초 미만)을 유지하였다. 종래기술에서는 영상 비트율이나 네트워크 대역폭이 불량한 경우에는 채널재핑 지연시간이 대폭 증가하는 문제점이 있었다.
[도 13]은 동적 버퍼링의 성능 평가를 위해 네트워크 대역폭의 변경에 따른 채널재핑 지연시간의 테스트 결과를 나타내는 도면이다. 이를 위해, 각 영상의 비트율을 6 Mbps로 고정하고 무선랜 공유기에서 네트워크 대역폭을 조정하면서 채널재핑 지연시간을 측정하였다.
그 측정 결과, 본 발명에 의한 채널재핑 지연시간의 개선 효과를 확인할 수 있었는데, 네트워크 대역폭이 낮을 때에 개선 효과가 뚜렷하였다. 또한, 본 발명에 의하면 네트워크 대역폭에 별달리 영향받지 않고 채널재핑 지연시간이 항상 우수하였다.
[도 14]는 동적 버퍼링의 성능 평가를 위해 영상 비트율의 변경에 따른 채널재핑 지연시간의 테스트 결과를 나타내는 도면이다.
[도 13]의 테스트 결과에서 네트워크 대역폭이 20 Mbps 이상일 때에는 본 발명과 종래기술 간의 측정 결과가 유사하였다. 그에 따라, [도 14]의 테스트에서는 무선랜 공유기의 네트워크 대역폭을 20 Mbps로 고정한 상태에서 영상의 비트율을 변경하면서 채널재핑 지연시간을 측정하였다.
그 측정 결과, 본 발명에 의한 채널재핑 지연시간의 개선 효과를 확인할 수 있었는데, 영상의 비트율이 증가할수록 그 성능 개선 효과는 증가하였다. 또한, 본 발명에 의하면 영상 비트율로 별달리 영향받지 않고 채널재핑 지연시간이 항상 우수하였다.
본 발명은 또한 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드의 형태로 구현하는 것이 가능하다. 이때, 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록 장치를 포함한다.
컴퓨터가 읽을 수 있는 기록매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장장치 등이 있다. 또한 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산된 방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다. 그리고 본 발명을 구현하기 위한 기능적인 프로그램, 코드, 코드 세그먼트들은 본 발명이 속하는 기술 분야의 프로그래머들에 의해 용이하게 추론될 수 있다.
Claims (8)
- OTT 방송을 위하여 HLS 적응 버퍼링을 수행하는 미디어 플레이어가 OTT 데이터를 동적 버퍼링 처리하는 방법으로서,
네트워크 대역폭에 대응하는 영상의 초기 비트율을 HLS 서버로 제공하여 상기 초기 비트율에 따라 현재 컨텐츠에 대한 미디어 파일을 스트리밍 제공받아 재생하는 제 1 단계;
해당 시점의 네트워크 대역폭에 대응하는 동적 비트율을 검출하여 상기 HLS 서버로 제공함으로써 상기 미디어 파일에 대해 상기 검출된 동적 비트율에 따라 스트리밍 제공받는 제 2 단계;
현재 재생중인 미디어 파일(이하, '현재 미디어 파일'이라 함)에 대한 다음재생 후보 미디어 데이터를 식별하는 제 3 단계;
상기 다음재생 후보 미디어 데이터에 대한 다중 스트리밍을 상기 HLS 서버로부터 제공받는 제 4 단계;
상기 다중 스트리밍을 통해 제공되는 상기 다음재생 후보 미디어 데이터에 대해 동적 버퍼링을 수행하는 제 5 단계;
미디어 파일의 변경 요구를 식별하면, 상기 현재 미디어 파일의 재생을 종료하고 상기 동적 버퍼링을 수행한 미디어 파일 데이터를 활용하여 상기 다음재생 후보 미디어 데이터의 재생 동작으로 전환하는 제 6 단계;
를 포함하여 구성되고,
상기 제 1 단계는 현재 미디어 플레이어(mp_cur)를 생성 및 프리페어 설정하는 단계를 포함하여 구성되고,
상기 제 3 단계에서 상기 다음재생 후보 미디어 데이터는 상기 OTT 방송의 편성에 따라 채널 업/다운 조작에 의해 나타날 인접 미디어 채널에서 제공되는 컨텐츠의 미디어 파일을 포함하여 구성되고,
상기 제 4 단계는 상기 현재 미디어 플레이어(mp_cur)를 생성하면서 상기 인접 미디어 채널을 위한 하나이상의 전환 미디어 플레이어를 생성하고 상기 다음재생 후보 미디어 데이터의 주소를 상기 인접 미디어 채널 별로 상기 전환 미디어 플레이어에 대해 데이터 소스 URL 설정하는 단계를 포함하여 구성되고,
상기 제 5 단계는 상기 전환 미디어 플레이어에 대해 프리페어 설정하고 onPreapared 호출을 감지하면 상기 전환 미디어 플레이어를 상기 현재 미디어 플레이어(mp_cur)에 대한 다음 미디어 플레어로 등록하며 상기 현재 미디어 플레이어(mp_cur)를 통해 현재 미디어 채널의 방송 컨텐츠를 재생하는 단계를 포함하여 구성되고,
상기 제 6 단계는 채널전환 입력이 식별되면 상기 채널전환 입력에 대응하는 상기 전환 미디어 플레이어를 동작시켜 해당 인접 미디어 채널의 컨텐츠를 재생하는 단계를 포함하여 구성되는 것을 특징으로 하는 동적 적응 버퍼링 기반의 OTT 데이터 처리 방법.
- 삭제
- 삭제
- 청구항 1에 있어서,
상기 인접 미디어 채널은 상기 현재 미디어 채널에 대한 채널다운 미디어 채널과 채널업 미디어 채널을 포함하여 구성되고,
상기 전환 미디어 플레이어는 상기 채널다운 미디어 채널을 위한 제 1 전환 미디어 플레이어(mp_chdown) 및 상기 채널업 미디어 채널을 위한 제 2 전환 미디어 플레이어(mp_chup)를 포함하여 구성되며,
상기 제 6 단계에서 상기 채널전환 입력이 채널-다운 버튼 조작이면 상기 제 1 전환 미디어 플레이어(mp_chdown)를 동작시켜 상기 채널다운 미디어 채널의 방송 컨텐츠를 재생하고,
상기 제 6 단계에서 상기 채널전환 입력이 채널-업 버튼 조작이면 상기 제 2 전환 미디어 플레이어(mp_chup)를 동작시켜 상기 채널업 미디어 채널의 방송 컨텐츠를 재생하는 것을 특징으로 하는 동적 적응 버퍼링 기반의 OTT 데이터 처리 방법.
- OTT 방송을 위하여 HLS 적응 버퍼링을 수행하는 미디어 플레이어가 OTT 데이터를 동적 버퍼링 처리하는 방법으로서,
네트워크 대역폭에 대응하는 영상의 초기 비트율을 HLS 서버로 제공하여 상기 초기 비트율에 따라 현재 컨텐츠에 대한 미디어 파일을 스트리밍 제공받아 재생하는 제 1 단계;
해당 시점의 네트워크 대역폭에 대응하는 동적 비트율을 검출하여 상기 HLS 서버로 제공함으로써 상기 미디어 파일에 대해 상기 검출된 동적 비트율에 따라 스트리밍 제공받는 제 2 단계;
현재 재생중인 미디어 파일(이하, '현재 미디어 파일'이라 함)에 대한 다음재생 후보 미디어 데이터를 식별하는 제 3 단계;
상기 다음재생 후보 미디어 데이터에 대한 다중 스트리밍을 상기 HLS 서버로부터 제공받는 제 4 단계;
상기 다중 스트리밍을 통해 제공되는 상기 다음재생 후보 미디어 데이터에 대해 동적 버퍼링을 수행하는 제 5 단계;
미디어 파일의 변경 요구를 식별하면, 상기 현재 미디어 파일의 재생을 종료하고 상기 동적 버퍼링을 수행한 미디어 파일 데이터를 활용하여 상기 다음재생 후보 미디어 데이터의 재생 동작으로 전환하는 제 6 단계;
를 포함하여 구성되고,
상기 제 1 단계는 제 1 미디어 플레이어(Player 0)를 생성하고 상기 현재 컨텐츠의 미디어 파일을 재생하는 단계를 포함하여 구성되고,
상기 제 4 단계는 제 2 미디어 플레이어(Player 1)를 생성하고 상기 다음재생 후보 미디어 데이터의 주소를 상기 제 2 미디어 플레이어(Player 1)에 대해 데이터 소스 URL 설정하는 단계를 포함하여 구성되고,
상기 제 5 단계는 상기 제 2 미디어 플레이어(Player 1)에 대해 프리페어 설정하고 onPreapared 호출을 감지하면 상기 제 2 미디어 플레이어(Player 1)를 상기 제 1 미디어 플레이어(Player 0)에 대한 다음 미디어 플레어로 등록하는 단계를 포함하여 구성되고,
상기 제 6 단계는 상기 제 1 미디어 플레이어(Player 0)에 의한 상기 현재 컨텐츠의 재생이 완료되면 상기 제 2 미디어 플레이어(Player 1)가 자동으로 시작되는 단계를 포함하여 구성되는 것을 특징으로 하는 동적 적응 버퍼링 기반의 OTT 데이터 처리 방법.
- 청구항 5에 있어서,
상기 다음재생 후보 미디어 데이터는 상기 OTT 방송의 편성에 따라 현재 미디어 채널에서 다음 순서로 배치된 컨텐츠의 미디어 파일, 현재 미디어 채널에서 상기 현재 미디어 파일의 후속 TS 파일, 현재 컨텐츠 중간에 잠시 삽입될 광고 또는 PPL 영상 중의 하나 이상을 포함하여 구성되는 것을 특징으로 하는 동적 적응 버퍼링 기반의 OTT 데이터 처리 방법.
- 삭제
- 컴퓨터에 청구항 1, 4 내지 6 중 어느 하나의 항에 따른 동적 적응 버퍼링 기반의 OTT 데이터 처리 방법을 실행시키기 위한 프로그램을 기록한 컴퓨터로 판독가능한 기록매체.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020160026673A KR101780247B1 (ko) | 2016-03-04 | 2016-03-04 | 동적 적응 버퍼링 기반의 ott 데이터 처리 방법 |
PCT/KR2016/002220 WO2017150753A1 (ko) | 2016-03-04 | 2016-03-05 | 동적 적응 버퍼링 기반의 ott 데이터 처리 방법 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020160026673A KR101780247B1 (ko) | 2016-03-04 | 2016-03-04 | 동적 적응 버퍼링 기반의 ott 데이터 처리 방법 |
Publications (2)
Publication Number | Publication Date |
---|---|
KR20170103575A KR20170103575A (ko) | 2017-09-13 |
KR101780247B1 true KR101780247B1 (ko) | 2017-09-20 |
Family
ID=59744129
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020160026673A KR101780247B1 (ko) | 2016-03-04 | 2016-03-04 | 동적 적응 버퍼링 기반의 ott 데이터 처리 방법 |
Country Status (2)
Country | Link |
---|---|
KR (1) | KR101780247B1 (ko) |
WO (1) | WO2017150753A1 (ko) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR102195516B1 (ko) * | 2018-11-01 | 2020-12-29 | 카테노이드 주식회사 | 방송 서비스 제공 장치, 방송 서비스 수신 장치 및 이를 이용한 방송 서비스 송수신 시스템 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150334144A1 (en) * | 2014-05-14 | 2015-11-19 | Google Inc. | Simulating Broadcast Television Channel Surfing for On-Demand Content |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR101182518B1 (ko) * | 2009-01-22 | 2012-09-12 | 에스케이플래닛 주식회사 | 영상 전송 시스템 및 방법 |
KR20120034550A (ko) * | 2010-07-20 | 2012-04-12 | 한국전자통신연구원 | 스트리밍 컨텐츠 제공 장치 및 방법 |
CN103222276B (zh) * | 2010-09-20 | 2017-04-19 | 数码士有限公司 | 将在http流式传输中发生表达切换时实现的处理方法 |
CN104471955B (zh) * | 2012-07-05 | 2017-08-11 | 谷歌科技控股有限责任公司 | 将视频内容提供到多个媒体装置的方法以及服务器 |
KR102020363B1 (ko) * | 2012-10-31 | 2019-09-10 | 삼성전자 주식회사 | 적응형 스트리밍을 이용한 미디어 세그먼트 송수신 방법 및 장치 |
-
2016
- 2016-03-04 KR KR1020160026673A patent/KR101780247B1/ko active IP Right Grant
- 2016-03-05 WO PCT/KR2016/002220 patent/WO2017150753A1/ko active Application Filing
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150334144A1 (en) * | 2014-05-14 | 2015-11-19 | Google Inc. | Simulating Broadcast Television Channel Surfing for On-Demand Content |
Also Published As
Publication number | Publication date |
---|---|
KR20170103575A (ko) | 2017-09-13 |
WO2017150753A1 (ko) | 2017-09-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11792250B2 (en) | Situation-dependent dynamic bit rate encoding and distribution of content | |
US9578352B2 (en) | Multi-format distribution of content | |
JP6337350B2 (ja) | ビデオ品質向上 | |
KR101983432B1 (ko) | 동적 적응형 스트리밍 오버 http(dash)를 http 라이브 스트리밍(hls)으로 변환 또는 번역하기 위한 장치, 시스템, 및 방법 | |
US9332051B2 (en) | Media manifest file generation for adaptive streaming cost management | |
US9485526B2 (en) | Multi-stream shared communication channels | |
US10250949B2 (en) | Broadcast content to HTTP client conversion | |
US9288250B2 (en) | Mobile multimedia real-time transcoding system, apparatus, storage medium and method | |
US8930442B2 (en) | Apparatus and method for playing media content data | |
US12069115B2 (en) | Video streaming delivery | |
US20120089740A1 (en) | Method and device for selecting an svc operation point, and method and device for providing information of svc operation points | |
KR20130005873A (ko) | 방송 시스템에서 컨텐츠 수신 방법 및 장치 | |
WO2014208377A1 (ja) | コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム | |
JPWO2018079295A1 (ja) | 情報処理装置、及び、情報処理方法 | |
KR102376204B1 (ko) | 분배 장치, 분배 방법, 수신 장치, 수신 방법, 프로그램 및 콘텐츠 분배 시스템 | |
US20160007094A1 (en) | Emergency notification in a network environment | |
KR101780247B1 (ko) | 동적 적응 버퍼링 기반의 ott 데이터 처리 방법 | |
US11223664B1 (en) | Switching between delivery of customizable content and preauthored media content | |
KR102319932B1 (ko) | 수신 장치 및 수신 방법, 재생 장치 및 재생 방법, 공급 장치 및 공급 방법, 그리고 프로그램 | |
KR100880569B1 (ko) | 모바일 아이피티브이의 이피지 환경에서 브이오디 컨텐츠의전송방법 | |
KR20160074310A (ko) | 하이브리드망에서의 스트리밍 방법 및 그 장치 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A201 | Request for examination | ||
E902 | Notification of reason for refusal | ||
E90F | Notification of reason for final refusal | ||
E701 | Decision to grant or registration of patent right |