KR20180086114A

KR20180086114A - 재생 지연 방지 시스템을 포함하는 미디어 재생 장치 및 방법

Info

Publication number: KR20180086114A
Application number: KR1020170087666A
Authority: KR
Inventors: 김도현; 송창희; 송병인
Original assignee: 한화에어로스페이스 주식회사
Priority date: 2017-01-20
Filing date: 2017-07-11
Publication date: 2018-07-30
Also published as: KR101931514B1; KR20180086112A; KR20180086115A; KR101942269B1; KR101986995B1; KR20180086113A; KR101942270B1

Abstract

본 발명은 재생 지연을 방지하는 시스템을 포함하는 미디어 재생 장치 및 방법에 관한 것이다. 본 발명에서는 디코더 앞에 지연 감지 모듈을 설치하여 재생 지연을 감지한다. 본 발명의 재생 지연 감지는 단 일회의 측정으로 네트워크, 디코딩, 및 렌더링에 의한 지연 감별이 가능하도록 한다. 또한 재생 지연이 발생한 경우 서버에 변경된 프로파일의 미디어를 요청하도록 하여 재생 지연을 해결한다. 본 발명에서는 복수의 재생 지연 요인을 단 일회의 측정을 통해 재생 지연 감별이 가능하므로 넌 플러그인 환경에 적합하게 가볍고 안정정인 미디어 재생이 가능하도록 한다.

Description

재생 지연 방지 시스템을 포함하는 미디어 재생 장치 및 방법{Media playback apparatus and method including delay prevention system}

본 발명은 웹 브라우저에서 미디어를 재생하는 장치 및 방법에 관한 것으로서, 보다 상세하게는 네트워크, 디코딩, 및 렌더링 등에 의한 지연을 일회의 측정으로 판단하여 방지하는 시스템을 포함하는 미디어 재생 장치 및 방법에 관한 것이다.

미디어 데이터를 사용자가 인터넷을 통해 웹 브라우저에서 재생하기 위해서, 코덱(code) 디코더(decoder) 및 렌더러(renderer)를 네이티브 코드(native code)로 작성한 플러그인을 이용하는 방법이 알려져 있다. 이러한 웹 브라우저 플러그인으로는 대표적으로 ActiveX와 NPAPI가 사용되고 있다.

ActivieX는 마이크로소프트(MicroSoft)가 COM(Component Object Model)과 OLE(Object Linking and Embedding) 두 개의 기술을 합쳐서 개발한 것을 말한다. 하지만 대개 좁은 의미로 웹 브라우저인 인터넷 익스플로러(Internet Explorer)에서 애드온(add-on)의 형태로 사용되는 ActiveX Control을 말한다. ActiveX는 인터넷 익스플로러 웹 브라우저에서 미디어를 재생하는데 사용된다.

NPAPI는 Netscape 시절에 개발된 API로 인터넷 익스플로러의 ActivieX와 기능이 유사하다. 초기 웹 환경이 열악할 때, 웹 브라우저의 기능을 강화하기 위하여 외부 응용프로그램을 플러그인 형식으로 끌어 쓰기 위해 제공된 API이다. 즉, 초기 웹 페이지에서 음악이나 동영상을 재생하기 위해 개발된 것으로, 자바의 애플릿(Applet), 어도비(Adobe)의 플래시(Flash), 리얼 플레이어 등이 있다.

하지만 플러그인은 해커들이 악성 코드를 배포하는 통로로 사용되면서, 웹 브라우저 업체들이 더 이상 지원을 하지 않는 추세다. NPAPI의 경우 크롬(Chrome)을 제작하여 배포하는 구글에서 크롬 45 버전 이후로는 더 이상 NPAPI의 지원을 하고 있지 않으며, ActiveX의 경우 마이크로소프트에서 윈도우 10의 기본 브라우저로 사용되는 엣지(Edge) 버전부터는 더 이상 ActivieX의 지원을 하고 있지 않다.

플러그인 없이 웹 브라우저에서 미디어를 재생하기 위한 방법으로 HTML5의 비디오 태그를 이용하여 디코딩 등을 수행하는 방법이 있다. 비디오 태그를 이용하여 디코딩을 수행할 경우 고해상도 비디오와 높은 fps의 비디오를 우수한 성능으로 처리할 수 있다. 그러나 비디오 태그는 지원하는 비디오 형식(video formats)에 제한이 있으며 현재 MP4, WebM, 그리고 Ogg의 세가지의 비디오 형식만을 지원하고 있다.

비디오 태그의 비디오 형식 제한으로 인한 한계는 자바스크립트로 구현된 디코더를 사용할 경우 보완이 가능하다. 자바스크립트 디코더는 비디오 형식에 맞춰 디코딩하는 것이 가능하므로 비디오 태그에서 지원하지 않는 코덱 형식의 미디어를 디코딩 하는 것이 가능하다. 이에 본 발명에서는 비디오 코덱 형식에 따라 비디오 태그와 자바스크립트 디코더를 선택적으로 사용하도록 미디어 재생 장치를 구성하였다.

웹 브라우저에서 미디어를 재생하는데 있어서 플러그인 외에 고려해야 할 사항으로 미디어의 재생 지연이 있다. 재생 지연은 사용자에게 불편함을 초래할 뿐만 아니라 실시간 라이브 비디오의 재생이나 영상감시장치 등 실시간 정보전달이 매우 중요한 재생 환경에서 치명적인 요소로 작용할 수 있다.

웹 브라우저에서 미디어 재생의 지연 요소로 첫째는 네트워크에 의한 지연이다. 모바일 기기의 사용이 급격히 증가하고 있는 환경에서 네트워크 대역폭 및 컴퓨팅 장치의 부족한 성능으로 인한 네트워크 지연은 재생 지연의 주요한 요인이 된다. 둘째, 자바스크립트로 디코더를 구현한 경우 발생할 수 있는 지연이다. 자바스크립트의 동적 특성으로 인해 고해상도 비디오에서는 자바스크립트 디코더의 성능이 급격히 떨어져 재생 지연이 발생할 수 있다. 셋째, 렌더링에 의한 지연이다. 렌더링에 필요한 연산량을 CPU 또는 GPU가 수용할 수 없는 경우 등 컴퓨팅 장치의 성능에 따라 렌더링에 의한 지연이 발생할 수 있다.

기존의 재생 지연 판단 방법들은 네트워크, 디코딩, 렌더링 등 각 단계들에 의한 지연시간을 측정하고 이를 종합하는 방식을 사용하였다. 각 단계들에 의한 지연시간은 각 단계에 미디어가 입력될 때와 출력될 때의 시간 차를 계산하는 방식으로 이루어졌다. 그러나 이러한 방식은 상기 언급한 네트워크, 디코딩, 렌더링 외에 기타 단계마다 지연을 측정해야 하고, 가볍고 군더더기 없는 코드로 작성되어야 하는 넌 플러그인(non-plugin) 환경의 미디어 재생 장치에 적합하지 못하다.

따라서, 웹 브라우저 상에서 비디오를 재생하는데 있어 넌 플러그인 환경에 적합한 재생 지연 판단 방법 및 그에 따른 지연 해결 방법이 고안될 필요가 있다.

한국공개공보 제2014-00914호

본 발명이 해결하고자 하는 과제는 네트워크 지연, 디코딩 지연, 렌더링 지연 등 복수의 지연 요인을 갖는 웹 브라우저에서 미디어를 재생하는 환경에 있어서 일회의 측정으로 미디어 재생의 지연 감별이 가능한 방법을 제공하는 것이다.

본 발명이 해결하고자 하는 다른 과제는 넌 플러그인(non plugin) 환경에 적합한 미디어 재생의 지연여부 감별 방법을 제공하는 것이다.

본 발명의 과제들은 이상에서 언급한 과제로 제한되지 않으며, 언급되지 않은 또 다른 과제들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.

상기 과제를 해결하기 위한 본 발명의 실시예에 따른 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치는, 미디어 서비스 장치에서 생성된 미디어 데이터를 웹 서비스를 지원하는 통신 프로토콜을 이용하여 수신하는 수신부; 웹 브라우저가 파싱(parsing)할 수 있는 스크립트로 작성된 디코더에 의해 상기 수신된 미디어 데이터를 디코드하도록 구성되는 제1 미디어 복원부; 상기 스크립트로 작성된 디코더에 의해 디코드 된 미디어 데이터를 표시하기 위해 렌더링하도록 구성되는 렌더러; 상기 미디어 데이터에 포함되는 시간 스탬프와 상기 미디어 데이터가 미디어 복원부에 도착하는 시간을 비교하여, 상기 미디어 데이터의 재생 지연을 감지하도록 구성되는 지연 감지부; 및 상기 지연 감지부에서 상기 재생 지연이 감지된 경우, 상기 미디어 서비스 장치에 변경된 프로파일로 상기 미디어 데이터를 전송할 것을 요청하도록 구성되는 프로파일 변경부를 포함할 수 있다.

상기 과제를 해결하기 위한 본 발명의 실시예에 따른 미디어 서비스 장치는, 미디어 데이터를 상기 미디어 재생 장치에 전송하는 미디어 서비스 장치로서, 상기 미디어 데이터를 상기 미디어 재생 장치의 웹 브라우저 상에서 재생하기 위해 필요한 스크립트 모듈을 저장하는 모듈 저장부; 상기 미디어 재생 장치의 접속에 응답하여 상기 스크립트 모듈을 상기 미디어 재생 장치에 전송하는 모듈 전송부; 상기 미디어 데이터를 패킷화하여 전송 패킷을 생성하는 패킷화부; 및 상기 재생 장치와의 통신 세션을 형성하며, 상기 미디어 재생 장치로부터의 요청된 프로파일에 따라 상기 전송 패킷을 상기 미디어 재생 장치에 전송하는 웹 서버를 포함하되, 상기 스크립트 모듈은, 상기 미디어 재생 장치에서 상기 미디어 데이터를 플러그인 없이 디코드 하는 프로세스와, 상기 미디어 데이터의 재생 중에 발생되는 재생 지연을 감지하는 프로세스를 포함할 수 있다.

본 발명의 기타 구체적인 사항들은 상세한 설명 및 도면들에 포함되어 있다.

본 발명의 실시예들에 의하면 적어도 다음과 같은 효과가 있다.

본 발명에 따르면 자바스크립트로 구현된 디코더를 사용함에도 자바스크립트의 동적 특성으로 인한 미디어 재생 지연의 방지가 가능하다. 따라서 사용자는 비디오의 끊김 없이 미디어를 재생할 수 있으며, 코덱 형식 제한으로 인해 비디오 태그를 사용할 수 없는 환경에서 그 유용성이 극대화 된다.

본 발명에 따르면 네트워크 지연, 디코딩 지연, 렌더링 지연 등 복수의 지연 요소에 의한 지연 여부를 단 일회의 측정으로 판단 가능하므로 넌 플러그인(non plugin)환경에 적합하게 가볍고 안정적인 미디어 재생이 가능하다.

본 발명에 따른 효과는 이상에서 예시된 내용에 의해 제한되지 않으며, 더욱 다양한 효과들이 본 명세서 내에 포함되어 있다.

도 1은 미디어 재생을 위한 전체 시스템의 실시예를 나타낸다.
도 2는 기기들 간의 통신을 위해 계층적으로 정의되는 TCP/IP 4계층 모델을 보여주는 도면이다.
도 3은 미디어 서비스 장치(110)와 미디어 재생 장치(120)간의 웹소켓 연결이 이루어지는 과정을 나타낸다.
도 4는 웹소켓 연결을 통한 데이터의 송수신 과정의 일 예를 보여준다.
도 5는 네트워크 인터페이스(21)를 통해 전송되는 통신 패킷의 구조를 도시한 도면이다.
도 6은 미디어 서비스 장치(110)의 일 실시예를 나타낸다.
도 7은 미디어 서비스 장치(110)의 다른 실시예를 나타낸다.
도 8은 모듈 저장부(115)의 스크립트 모듈의 일 실시예를 나타낸다.
도 9는 모듈 저장부(115)의 스크립트 모듈의 다른 실시예를 나타낸다.
도 10은 미디어 재생 장치(120)의 일 실시예를 나타낸다.
도 11은 지연 감지 모듈에서 재생 지연을 판단하는 방법을 나타낸다.
도 12는 미디어 재생 장치(120)의 다른 실시예를 나타낸다.
도 13은 미디어 재생 장치(120)의 작동 과정을 나타낸 순서도이다.
도 14는 본 발명의 일 실시예에 따른 자바스크립트로 구현된 스크립트 모듈을 생성하는 과정을 설명하기 위한 예시도이다.
도 15는 미디어 재생 장치(120)를 구현하기 위한 컴퓨팅 장치(400)의 예시도이다.

본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

다른 정의가 없다면, 본 명세서에서 사용되는 모든 용어(기술 및 과학적 용어를 포함)는 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 공통적으로 이해될 수 있는 의미로 사용될 수 있을 것이다. 또 일반적으로 사용되는 사전에 정의되어 있는 용어들은 명백하게 특별히 정의되어 있지 않는 한 이상적으로 또는 과도하게 해석되지 않는다.

본 명세서에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 발명을 제한하고자 하는 것은 아니다. 본 명세서에서, 단수형은 문구에서 특별히 언급하지 않는 한 복수형도 포함한다. 명세서에서 사용되는 "포함한다(comprises)" 및/또는 "포함하는(comprising)"은 언급된 구성요소 외에 하나 이상의 다른 구성요소의 존재 또는 추가를 배제하지 않는다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예를 상세히 설명하기로 한다.

도 1은 미디어 재생을 위한 전체 시스템의 실시예를 나타낸다.

도 1의 전체 시스템은 미디어 서비스 장치(110)와 미디어 재생 장치(120) 및 두 장치를 연결하는 네트워크(430)로 이루어진다.

미디어 서비스 장치(110)는 하나 이상의 영상 재생 장치들에 대해 컴퓨팅 서비스를 제공할 수 있도록 적합한 컴퓨팅 또는 프로세싱 장치를 포함한다. 예를 들면, 미디어 서비스 장치(110)는 네트워크 카메라, 네트워크 비디오 레코더(NVR), 디지털 비디오 레코더(DVR) 등과 같이 영상 스트림을 생성하거나 저장하며 사용자 기기들에 전송할 수 있는 장치를 포함한다.

미디어 재생 장치(120)는 네트워크를 통해 미디어 서비스 장치(110)나 다른 컴퓨팅 사용자 기기들과 상호작용할 수 있도록 적합한 컴퓨팅 또는 프로세싱 장치를 포함한다. 예를 들면, 미디어 재생 장치(120)는 데스크톱 컴퓨터, 모바일 전화 또는 스마트폰, PDA(personal digital assistant), 랩톱 컴퓨터 및 타블릿 컴퓨터를 포함할 수 있다.

미디어 서비스 장치(110)에 의해 실시간 촬영 또는 저장된 미디어는 미디어 재생 장치(120)의 요청에 의해 네트워크(430)를 통해 전송된다. 사용자는 미디어 재생 장치(120)의 웹 브라우저(210)상에 구현된 사용자 인터페이스를 통해 전송된 미디어를 재생하는 것이 가능하다. 이때, 웹 브라우저(210)는 구글 크롬, 마이크로소프트 익스플로러, 모질라의 파이어폭스, 애플의 사파리 등, 데스크톱 컴퓨터나 모바일 전화에 탑재되는 일반적으로 알려진 브라우저를 포함할 뿐만 아니라, 웹 브라우저의 리소스나 API를 이용하여 별도로 제작된 소프트웨어 어플리케이션까지 포괄한다.

이하 도 2 내지 도 5를 통해 미디어 서비스 장치(110)와 미디어 재생 장치(120)사이의 네트워크 통신 방식인 웹소켓 상에서 전송되는 RTSP/RTP 프로토콜을 설명한다.

도 2는 기기들 간의 통신을 위해 계층적으로 정의되는 TCP/IP 4계층 모델을 보여주는 도면이다.

4계층은 네트워크 인터페이스 계층(21), 인터넷 계층(22), 전송 계층(23) 및 어플리케이션 계층(24)으로 이루어져 있다. 웹소켓 상에서 전송되는 RTSP/RTP 프로토콜에서 웹소켓 연결은 전송 계층(23) 연결의 상부에 위치하므로, 웹소켓 연결을 사용하기 위해서는, TCP 전송 연결이 미디어 서비스 장치(110)와 미디어 재생 장치(120) 사이에서 먼저 수립되어야 한다. 일단 웹소켓 연결이 예를 들어, 3-way 핸드쉐이크(hand-shake) 과정을 통해 미디어 서비스 장치(110)와 미디어 재생 장치(120)간에 수립되면, 웹소켓 통신은 웹소켓 패킷들을 전송함에 의해 수행된다. 웹소켓 연결 및 웹소켓 패킷은 이하 도 3 내지 도 5를 통해 자세히 설명한다.

도 3은 미디어 서비스 장치(110)와 미디어 재생 장치(120)간의 웹소켓 연결이 이루어지는 과정을 나타낸다.

미디어 재생 장치(120)는 미디어 서비스 장치(110)에 웹소켓 URI를 사용하여 웹소켓 연결을 개시하는 요청을 한다. 웹소켓 URI는 GetServiceCapabilities 명령을 사용하면 획득이 가능하다. 웹소켓 URI는 예를 들어 "ws://192.168.0.5/webSocketServer"와 같은 방식으로 표현된다(S1000).

미디어 재생 장치(120)는 미디어 서비스 장치(110)에 웹소켓 업그레이드 요청을 한다. 미디어 서비스 장치(110)는 프로토콜 전환 요청에 대해 승인한다는 상태코드인 101 코드로 응답한다(S1100).

미디어 서비스 장치(110)와 미디어 재생 장치(120)간에 웹소켓 연결이 이루어진 후부터는 HTTP/1.1 프로토콜이 아닌 웹소켓 상에서 전송되는 RTSP/RTP 프로토콜로 데이터를 주고받는다. 도 3의 DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN 은 RTSP의 명령어이다. DESCRIBE 요청에는 URL이 포함된다. DESCRIBE에 대한 응답 메시지에는 요청한 것에 대한 설명도 포함된다. SETUP 요청은 단일 미디어 스트림이 전송되어야 하는지 규정한다. PLAY 요청은 하나 또는 모든 미디어 스트림을 재생시키는 요청으로 다중 요청이 가능하다. PAUSE 요청은 하나 또는 모든 미디어 스트림에 대해서 일시 중지를 명령한다. PLAY 요청으로 다시 재시작 할 수 있다. TEARDOWN 요청은 세션을 종료하기 위한 명령어이다. TEARDOWN 요청에 의해 모든 미디어 스트림의 재생을 중단하고 관련 데이터에 걸린 모든 세션도 해제한다(S1200).

도 3에 도시된 웹소켓 연결 과정에서 미디어 재생 장치(120)에서 보내는 요청 메세지와 미디어 서비스 장치(110)의 응답 메세지의 예는 다음의 표 1에 기재된 바와 같다.

미디어 재생 장치(120) -> 미디어 서비스 장치(110)
GET /webSocketServer HTTP/1.1
Host: 192.168.0.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: rtsp.onvif.org
Sec-WebSocket-Version: 13.

미디어 서비스 장치(110) -> 미디어 재생 장치(120)
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: rtsp.onvif.org

이러한 웹소켓 연결은 HTML5 표준인 웹소켓 프로토콜에 따라 이루어진다. 특히, 웹소켓 연결은 양방향 통신을 지속적으로 지원하기 때문에, 미디어 서비스 장치(110)와 미디어 재생 장치(120)간에 연결이 끊기지 않고 계속적으로 데이터를 송수신할 수 있도록 할 수 있다.

도 4는 웹소켓 연결을 통한 데이터의 송수신 과정의 일 예를 보여준다.

도 4를 참조하면 먼저, 미디어 재생 장치(120)는 미디어 서비스 장치(110)에 TCP/IP 연결 요청 메시지(TCP/IP connection request)을 전송하고, 미디어 서비스 장치(110)가 이를 수락하여 TCP 응답 메시지(SYN-ACK)를 미디어 재생 장치(120)에 전송하면 TCP/IP 연결이 수립된다. TCP 전송 연결은 로컬 TCP 소켓 및 원격 TCP 소켓의 페어(pair)에 의해 형성될 수 있는데, 각각의 TCP 소켓은 적어도 포트 번호와 IP 주소와 같은 식별자에 의하여 정의된다. 물론, 이러한 TCP/IP 기반의 연결 대신에 양자간에 UDP/IP 기반의 연결을 수립할 수도 있다.

이 후, 미디어 재생 장치(120)와 미디어 서비스 장치(110) 간에 핸드쉐이크 과정을 통해 양자간에 웹소켓 연결이 수립되면, 그 이후에는 양자간의 지속적인 데이터의 송수신이 가능해진다. 즉, 미디어 재생 장치(120)는 미디어 서비스 장치(110)에 미디어 스트리밍 요청을 전송 웹소켓 패킷(socket.send)의 형태로 전송하고, 미디어 서비스 장치(110)는 미디어 재생 장치(120)에 미디어 스트림을 응답 웹소켓 패킷(socket.onMessage)의 형태로 전송한다. 이러한 과정은 미디어 스트림 전송이 중지되거나 완료될 때까지 지속적으로 양자간에 이루어질 수 있다.

도 5는 네트워크 인터페이스(21)를 통해 전송되는 통신 패킷의 구조를 도시한 도면이다.

데이터(45)에 해당하는 RTP 페이로드에 RTP 헤더(44)가 부가 되면 RTP 패킷이 된다. RTP 패킷은 웹소켓 페이로드와 같으며 여기에 웹소켓 헤더(43)가 부가되어 웹소켓 패킷이 된다. 웹소켓 패킷은 TCP 페이로드와 같고 여기에 TCP 헤더(42)가 부가되어 TCP 패킷이 된다. 마지막으로 TCP 패킷은 IP 페이로드와 같고 여기에 IP 헤더(41)가 부가되면 최종적으로 통신 패킷, 즉 IP 패킷이 완성된다. 이와 같이 IP 패킷을 완성하는 과정 및 각각의 헤더를 제거하는 과정은 미디어 서비스 장치(110)와 미디어 재생 장치(120)에서 수행된다.

미디어 서비스 장치(110)와 미디어 재생 장치(120)간의 통신은 이상 도 2 내지 도 5를 통해 설명한 HTML5 기반의 웹소켓 프로토콜을 통해 이루어지기 때문에, RTSP/RTP 송수신 제어를 담당하는 모듈 및 디코더는 HTML5에서 파싱이 가능한 스크립트 코드에 의해 구현될 수 있다. 따라서, 종래와 같이 플러그인을 별도로 설치하지 않고도 RTSP/RTP 프로토콜을 이용한 미디어 재생이 HTML5 환경의 웹 브라우저 내에서 구현될 수 있다.

지금까지 미디어 서비스 장치(110)와 미디어 재생 장치(120)간의 네트워크 통신 방식을 살펴보았다. 이하 도 6 내지 도 15를 통해 미디어 서비스 장치(110)와 미디어 재생 장치(120)의 구성 및 작동 방식을 설명한다.

도 6은 미디어 서비스 장치(110)의 일 실시예를 나타낸다.

일 실시예에서 미디어 서비스 장치(110)는 실시간 비디오 카메라(111), 인코더(112), 패킷화부(113), 웹 서버(114), 모듈 저장부(115), 모듈 전송부(116), 및 제어부(117)를 포함한다.

실시간 비디오 카메라(111)는 미디어를 실시간으로 촬영하는 수단으로 촬영은 비디오 캡쳐 및 오디오 녹음을 모두 진행하는 방식과 비디오 캡쳐만 이루어지는 방식을 포함한다. 이하 설명에서는 실시간 비디오 카메라(111)에서 비디오 캡쳐만 이루어진 경우를 예로 들어 설명한다.

인코더(112)는 실시간 비디오 카메라(111)에 의해 촬영된 비디오를 압축하여 부호화하는 기능을 수행한다. 인코더(112)에 의한 인코딩은 반드시 웹 브라우저에 임베드 된 디코더에서 지원하는 특정 코덱으로 이루어져야 하는 것은 아니며 임의의 코덱 형식으로 인코딩 하는 것이 가능하다.

패킷화부(113)는 인코딩된 미디어 데이터를 패킷화하여 전송 패킷을 생성한다. 패킷화란 비디오를 네트워크(430)를 통해 전송하는 것이 용이하도록 적당한 길이로 분할하거나 또는 비디오가 짧은 경우 적당한 길이로 일괄하여 그 각각에 수신되어야 할 주소 등의 제어정보를 부여하는 것을 뜻한다. 이 때 제어정보는 전송 패킷의 헤더에 위치하게 된다. 전송 패킷은 전술한 웹소켓 패킷의 형태로 이루어진다.

패킷화부(113)는 미디어 재생 장치(120)에서 요청하는 방식에 따라 비디오의 패킷화를 수행하는 기능을 포함한다. 도 12의 일 실시예에서 살펴 볼 미디어 재생 장치(120)는 웹 브라우저에서 파싱할 수 있는 스크립트로 작성된 디코더로 자바스크립트 디코더와 웹 브라우저에 임베드 된 디코더로 비디오 태그 디코더를 포함하는데, 실시간 비디오의 재생, 저장된 비디오의 재생, 비디오의 코덱 형식 등의 요인에 따라 디코더를 선택적으로 사용할 수 있다. 도 12에서 후술하겠지만, 자바스크립트 디코더에서는 프레임 단위로, 비디오 태그 디코더에서는 컨테이너 단위로 디코딩을 수행한다. 따라서 미디어 재생 장치(120)는 디코딩을 수행하는 디코더에 따라 패킷화부(113)에 전송 패킷을 컨테이너 또는 프레임 형식으로 요청할 수 있고 패킷화부(113)는 이에 응답하여 패킷화를 수행할 수 있다.

웹 서버(114)는 미디어 재생 장치(120)와 통신 세션을 형성하는 기능을 수행한다. 즉, 미디어 서비스 장치(110)의 웹 서버(114)와 미디어 재생 장치(120) 간의 핸드쉐이크 과정을 통해 양자간에 웹소켓 연결이 수립된다. 이후 미디어 재생 장치(120)의 요청에 따라 패킷화부(113)에서 생성된 전송 패킷을 웹 서버(114)를 통해 전송하게 된다.

모듈 저장부(115)는 미디어 재생 장치(120)에서 비디오를 재생 및 탐색하는데 필요한 스크립트 모듈을 저장하는 모듈이다. 스크립트 모듈은 웹 브라우저에서 파싱 할 수 있는 스크립트로 작성된 코드로 미디어 재생 장치(120)에서 플러그인이나 별도의 응용프로그램 설치 없이 HTML5환경의 웹 브라우저에서 비디오 재생이 가능하도록 해주는 모듈이다. 스크립트 모듈은 일 실시예로 자바스크립트로 작성된 코드일 수 있다. 스크립트 모듈에 대해서는 도 8 및 도 9를 참조하여 후술한다.

모듈 전송부(116)는 모듈 저장부(115)에 저장된 스크립트 모듈을 미디어 재생 장치(120)로 전송하는 모듈이다. 모듈 전송부(116)는 미디어 재생 장치(120)가 네트워크(430)를 통해 미디어 서비스 장치(110)에 접속한 경우 이에 응답하여 스크립트 모듈을 전송한다.

제어부(117)는 미디어 서비스 장치(110)의 다른 구성 모듈들을 제어하는 모듈이다. 예를 들어 네트워크(430)를 통해 웹 서버(114)에 미디어 재생 장치(120)의 접속이 이루어진 경우 모듈 저장부(115)에 저장된 스크립트 모듈이 모듈 전송부(116)를 통해 미디어 재생 장치(120)로 전송되는데, 제어부(117)는 각 모듈들로부터 신호를 주고 받아 해당 작업이 원활이 이루어지게끔 통제하는 역할을 수행한다.

이상의 도 6의 미디어 서비스 장치(110)의 구성 모듈들에 대한 설명을 바탕으로 작동 방식을 살펴본다. 네트워크(430)를 통해 웹 서버(114)에 미디어 재생 장치(120)의 접속이 이루어지면 모듈 전송부(116)는 모듈 저장부(115)에 저장된 스크립트 모듈을 미디어 재생 장치(120)로 전송한다. 미디어 재생 장치(120)에 스크립트 모듈이 설치되면 사용자는 사용자 인터페이스를 통해 미디어 재생을 요청한다. 이에 미디어 서비스 장치(110)는 실시간 비디오 카메라(111)에서 촬영되는 실시간 라이브 비디오를 인코더(112)에서 인코딩하고 패킷화부(113)에서 프레임 또는 컨테이너 형식에 맞게 전송 패킷으로 패킷화하여 웹 서버(114)를 통해 미디어 재생 장치(120)로 전송한다.

도 7은 미디어 서비스 장치(110)의 다른 실시예를 나타낸다.

도 6의 미디어 서비스 장치(110)는 실시간 비디오 카메라(111)에 의해 실시간 라이브 비디오를 전송하기 위한 실시예이고, 도 7의 미디어 서비스 장치(110)는 미디어 저장부(118)에 저장된 비디오를 전송하기 위한 실시예를 나타낸다.

미디어 저장부(118)는 네트워크 비디오 레코더(NVR) 또는 개인용 녹화기(PVR)를 포함하나 도 7의 실시예에서는 네트워크 비디오 레코더인 경우를 예로 들어 설명한다. 미디어 저장부(118)는 카메라 또는 서버로부터 비디오를 전송받아 압축 저장한다. 미디어 재생 장치(120)로부터 저장된 비디오에 대한 전송요청이 있는 경우 미디어 서비스 장치(110)는 미디어 저장부(118)에 저장된 비디오를 패킷화부(113)에서 패킷화하여 웹 서버(114)를 통해 전송한다. 도 7의 미디어 서비스 장치(110) 구성모듈 중 패킷화부(113), 웹 서버(114), 모듈 저장부(115), 모듈 전송부(116), 제어부(117)는 도 6의 실시예에서 설명한 모듈들로 중복되는 설명은 생략한다.

도 8은 모듈 저장부(115)의 스크립트 모듈의 일 실시예를 나타낸다.

도 8의 스크립트 모듈은 RTSP/RTP 클라이언트 모듈(121), 디패킷화 모듈(122), 지연 감지 모듈(123), 디코더 모듈(124), 및 렌더러 모듈(125)로 포함한다. 또한 도 8의 일 실시예에서는 스크립트 모듈이 웹 브라우저에서 파싱할 수 있는 스크립트인 자바스크립트로 구현된다.

RTSP/RTP 클라이언트 모듈(121)은 미디어 서비스 장치(110)와 RTSP/RTP 통신을 지원하는 기능을 수행한다. 현재로서 플러그인 없이 웹 브라우저 상에서 RTSP/RTP에 따라 미디어를 처리하는 것이 가능하지 않은데, RTSP/RTP 클라이언트 모듈(121)을 이용하면 웹 브라우저에서 HTTP 방식을 이용함에도 안정적으로 RTSP/RTP 프로토콜로 전송된 데이터를 수신할 수 있다.

디패킷화 모듈(122)은 RTSP/RTP 클라이언트 모듈(121)로부터 전달받은 패킷을 디패킷화(depacketization)하는 모듈이다. 디패킷화란 패킷화의 반대되는 개념으로 패킷화가 비디오 데이터를 적당한 길이로 분할하여 패킷을 형성하는 것을 의미한다면 이를 다시 이어 붙여 패킷화 이전의 상태로 비디오 데이터를 복원해주는 것을 뜻한다.

지연 감지 모듈(123)은 비디오의 재생이 지연되고 있는지 여부를 판단하는 모듈이다. 지연 감지 모듈(123)은 미디어 서비스 장치(110)와 미디어 재생 장치(120)간의 네트워크에 의한 지연, 디코더 모듈(124)에 의한 디코딩 지연, 렌더러 모듈(125)에 의한 렌더링 지연 등 복수의 요소에 의한 비디오의 재생 지연을 일회의 측정으로 판단할 수 있는 모듈로 자세한 설명은 도 11을 참조하여 후술한다.

디코더 모듈(124)은 인코딩된 비디오의 압축 및 부호화를 해제하는 것, 즉 디코딩을 수행하는 모듈이다. 디코더 모듈(124)은 스크립트 모듈의 다른 모듈들과 마찬가지로 자바스크립트로 구현된다. 디코더 모듈(124)을 자바스크립트로 구현하기 때문에 웹 브라우저에 임베드 된 디코더와 달리 코덱 형식에 제한 없이 임의의 코덱 형식에 대하여 디코딩이 가능하다. 또한 프레임 단위로 디코딩이 가능하다.

도 8의 일 실시예에 따라 디코더 모듈(124)을 자바스크립트로 구현하면 예를 들어 다음의 표 2 및 표 3과 같은 코드로 표현될 수 있다(표 3은 표 2에서 이어진 내용이다).

function HevcDecoder () {

var _name = "HevcDecoder";
var self = this;

this._decoderParameters = null;
this._isRequestActive = false;
this._player = null;
this._requestContext = null;
this._requestContextQueue = [];

this.pushRequestContext = function (requestContext) {
self._requestContextQueue.push(requestContext);
};
this.decode = function () {
if (self._isRequestActive) {
return;
}

if (self._requestContextQueue.length) {

self._isRequestActive = true;
self._requestContext = self._requestContextQueue.pop();
self._playStream(self._requestContext.stream);}
};
this._createDecodeCanvas = function(parentElement) {
self.canvas = document.createElement("canvas");
self.canvas.style.display = "none";
self.canvas.id = "decode-canvas";
parentElement.appendChild(self.canvas);
self.ctx = self.canvas.getContext("2d");
};
this._playStream = function (buffer) {
this._reset();
this._handleOnLoad(buffer);
}
this._onImageDecoded = function (image) {
var width = image.get_width();
var height = image.get_height();
this.canvas.width = width;
this.canvas.height = height;
this._imageData = this.ctx.createImageData(width, height);
image.display(this._imageData, function (displayImageData) {
var itemId = self._requestContext.itemIds[self._requestContext.currentFrameIndex];
var payload = self._requestContext.payload;
if (height > payload.displayHeight) {
payload.displayHeight = height;
}
if (!(itemId in self._requestContext.dependencies)) {
if (width > payload.displayWidth) {
payload.displayWidth = width;
}
payload.frames.push({
canvasFrameData: displayImageData.data,
itemId: itemId,
width: width,
height: height
});
}
self._requestContext.currentFrameIndex++;
if (self._requestContext.currentFrameIndex >= self._requestContext.itemIds.length) {
self._requestContext.callback(payload);
self._isRequestActive = false;
self.decode(); // Decode next queued request
}
});
};
...
this._createDecodeCanvas(document.documentElement);
this._reset();
}

렌더러 모듈(125)은 디코딩 된 비디오를 렌더링하여 모니터 등과 같은 출력 기기에 디스플레이 되도록 하는 기능을 수행한다. 렌더러 모듈(125)은 WebGL을 이용하며 YUV 형식의 비디오 데이터를 RGB 형식으로 변환시킨다. WebGL이란 자바스크립트를 통해 사용이 가능하고 3D 그래픽 인터페이스를 만들 수 있게 해주는 웹 기반의 그래픽 라이브러리이다.

도 9는 모듈 저장부(115)의 스크립트 모듈의 다른 실시예를 나타낸다.

도 9의 스크립트 모듈은 RTSP/RTP 클라이언트 모듈(121), 디패킷화 모듈(122), 및 컨테이너 생성 모듈(127)을 포함한다. 또한 도 9의 실시예에서 스크립트 모듈은 자바스크립트로 구현될 수 있다. RTSP/RTP 클라이언트 모듈(121) 및 디패킷화 모듈(122)은 각각 도 8에서 설명한 모듈들로 중복되는 설명은 생략한다.

도 9의 스크립트 모듈을 자세히 살펴보면 도 8의 경우와 다르게 컨테이너 생성 모듈(127)이 포함된 것을 볼 수 있다. 컨테이너 생성 모듈(127)은 비디오가 컨테이너 단위로 패키징이 이루어져 있지 않은 경우 프레임들을 모아 컨테이너를 형성하는 기능을 수행한다.

컨테이너는 MPEG-DASH 컨테이너 등 비디오 태그에서 지원하는 컨테이너를 포함하는 개념이다. 컨테이너 생성 모듈(127)에서 비디오 태그와 호환되는 컨테이너 형식으로 비디오 프레임을 구성해주기 때문에 영상 촬영 장치에서 컨테이너 형식으로 비디오를 전송하지 않더라도 호환성 문제 없이 비디오 태그의 사용이 가능하다. 즉, 기존에 설치된 영상 촬영 장치의 수정 없이도 비디오 태그의 사용이 가능한 환경을 제공한다.

이상 도 8 및 도 9에서 설명한 스크립트 모듈은 미디어 서비스 장치(110)에서 미디어 재생 장치(120)로 전송되어 미디어 재생 장치(120)의 웹 브라우저(210)에서 플러그인 없이 미디어 재생이 가능한 환경을 제공한다. 즉, 스크립트 모듈은 미디어 재생 장치(120)에 설치되어 미디어 재생을 위한 시스템을 구성하게 된다. 스크립트 모듈이 설치된 미디어 재생 장치(120)의 실시예는 이하 도 10 및 도 12를 통해 살펴본다.

도 10은 미디어 재생 장치(120)의 일 실시예를 나타낸다.

도 10의 미디어 재생 장치(120)는 웹소켓 클라이언트(131), RTSP/RTP 클라이언트 모듈(121), 디패킷화 모듈(122a, 122b), 지연 감지 모듈(123a, 123b), 디코더 모듈(124a, 124b), 렌더러 모듈(125), 캔버스 태그(133)를 포함한다. 이때, RTSP/RTP 클라이언트 모듈(121)에서 화살표를 따라 렌더러 모듈(125)까지의 모듈들은 미디어 재생 장치(120)가 네트워크(430)를 통해 미디어 서비스 장치(110)에 접속한 뒤 스크립트 모듈을 수신하여 구성되는 모듈들이다. 이하 도 10의 미디어 재생 장치(120)의 작동을 설명한다.

웹소켓 클라이언트(131)는 미디어 서비스 장치(110)의 웹 서버(114)와 웹소켓 연결을 수립하는 모듈이다. 미디어 재생 장치(120)와 미디어 서비스 장치(110)는 각각 웹소켓 클라이언트(131)와 웹 서버(114)간의 핸드쉐이크를 거쳐 전송 패킷을 주고 받는다.

RTSP/RTP 클라이언트 모듈(121)은 도 8의 일 실시예에서 설명한 바와 같이 사용자의 웹 브라우저(210)에 RTSP/RTP 통신이 지원되도록 하는 기능을 수행한다. 따라서 사용자는 별도의 플러그인 설치 없이 RTSP/RTP 프로토콜을 사용하여 HTML5 환경의 웹 브라우저(210)를 통해 비디오를 재생하는 것이 가능하다.

RTSP/RTP 클라이언트 모듈(121)로부터 비디오 데이터는 코덱 형식에 따라 H.264 디패킷화 모듈(122a) 또는 H.265 디패킷화 모듈(122b)로 전달된다. 모듈의 명칭에서 알 수 있듯이 H.264 디패킷화 모듈(122a)은 H.264 코덱 형식의 비디오를, H.265 디패킷화 모듈(122b)는 H.265 코덱 형식의 비디오를 디패킷화 하는 모듈이다. 코덱 형식이 다르더라도 비디오 재생 과정은 동일하므로 이하 H.264 코덱 형식의 비디오를 기준으로 설명한다.

H.264 디패킷화 모듈(122a)에서 디패킷화된 비디오는 지연 감지 모듈(123a)로 전달된다. 지연 감지 모듈(123a)에서는 재생지연을 감별하는데 자세한 설명을 위해 도 11을 참조한다.

도 11은 지연 감지 모듈에서 재생 지연을 판단하는 방법을 나타낸다.

여기서 재생 지연은 미디어 서비스 장치(110)에서 미디어 재생 장치(120)로데이터가 전송되는 동안 발생하는 네트워크 지연, 미디어 재생 장치(120)의 제1 미디어 복원부(143)에서의 디코드 과정에서 발생하는 디코딩 지연 및 렌더러 모듈(125)에서 발생하는 렌더링 지연을 포함한다.

지연 감지는 디코더 모듈(124a) 앞에서 프레임 단위로 이루어진다. 지연 감지 모듈(123a)은 프레임이 디코더 모듈(124a)에 도착한 순간의 시간과 프레임의 시간 스탬프를 이용하여 지연 여부를 감별한다. 이하 지연 감지 방법에 대해 자세히 설명한다.

먼저, 최초로 디코더 모듈(124a)에 도착한 프레임인 최초 프레임에 대해 살펴본다. 최초 프레임이 디코더 모듈(124a)에 도착한 순간의 시간을 Ta1, 최초 프레임의 시간 스탬프를 Tf1이라 하였을 때, Ta1과 Tf1의 시간 차이인 Td1을 계산한다. Td1은 재생 지연 감별의 기준이 된다.

다음으로, 재생이 진행되며 최초 프레임 이후의 임의의 프레임인 이후 프레임이 디코더 모듈(124a)에 도착한 순간의 시간을 Tax, 상기 이후 프레임의 시간 스탬프를 Tfx라 한다. Tax와 Tfx의 시간차이인 Tdx를 계산한다.

지연 감지는 Tdx와 Td1을 비교하여 판단한다. 판단 방법으로 Tdx와 Td1의 값의 차가 기 설정한 최대 지연시간(Td_max)을 넘는 경우 재생이 지연된다고 판단할 수 있다. 최대 지연시간은 사용자가 설정하는 임의의 값으로 최초 설정 뒤 학습에 따라 자동으로 최적의 값을 갖도록 변경할 수 있다.

이상의 지연 감지 방법을 예를 들어 설명하면, 최초 프레임이 디코더 모듈(124a)에 도착한 순간의 시간이 4초이고 최초 프레임의 시간 스탬프는 1초인 경우 Td1은 두 값의 차인 3초가 된다. 재생이 진행되며 임의의 이후 프레임이 디코더 모듈(124a)에 도착한 순간의 시간이 10초이고 상기 이후 프레임의 시간 스탬프가 6초인 경우 Tdx는 두 값의 차인 4초가 된다. 기 설정한 허용되는 Td_max를 5초라 하였을 때, Tdx와 Td1의 차는 4초-3초로 1초가 되므로 Td_max인 5초를 넘지 않아 재생 지연이 이루어지지 않는다고 판단하게 된다.

또 다른 판단 방법으로 Tdx와 Td1의 값의 차가 일정 횟수 이상 최대 지연시간을 넘는지 여부를 기준으로 재생 지연을 감지할 수 있다. 이는 짧은 시간동안 일시적으로 재생 지연이 발생하는 경우까지 재생 지연으로 감별하지 않도록 하기 위함이다. 예를 들어 Td1과 Td_max은 이전 단락의 예와 같이 각각 3초와 5초이고, 이후 연속되는 네 개의 프레임들에서 Tdx의 값이 4초, 9초, 6초, 6초라 하였을 때, Tdx와 Td1의 차는 1초, 6초, 3초, 3초가 된다. 일정 횟수를 3회라 설정하였을 때 Td_max을 넘는 Tdx와 Td1의 차는 6초인 때로 1회이므로 재생 지연이 이루어지지 않는다고 판단하게 된다.

이상 설명한 방법으로 디코더 앞단에서 지연 감지를 할 경우 단 일회의 측정으로 네트워크, 디코딩, 렌더링에 의한 지연 감별이 가능하다. 이는 자바스크립트의 싱글 스레드 특성 때문인데, 자바스크립트로 구현된 디코더 모듈(124a)은 싱글 스레드로 작동하므로 현재 프레임을 처리하기 전에는 다음 프레임을 받아들일 수 없다. 따라서 디코더 모듈(124a) 앞에서 지연감지를 하게 되면 네트워크에 의한 지연뿐만 아니라 디코딩과 렌더링 의한 지연까지도 감별이 가능하다.

미디어 재생 장치(120)에서 멀티 스레드 기능을 수행하는 웹 워커(web worker)를 사용하여 수신부에서의 수신 과정, 제1 미디어 복원부(143)에서의 디코딩 과정 및 렌더러에서의 렌더링 과정을 수행할 수도 있다. 이때에도 각 과정은 하나의 파이프라인으로 구성되기 때문에 상기 지연 감지 방법은 여전히 유효하다.

도 11의 지연 감지 방법을 사용하면 단 일회의 측정으로 네트워크, 디코딩, 렌더링에 의한 지연 감별이 가능하므로 네트워크에 의한 지연, 디코딩에 의한 지연, 렌더링에 의한 지연을 개별적으로 측정해야 하는 기존의 방법에 비해 훨씬 간단하게 재생 지연의 감별이 가능하다. 따라서 상기 지연 감지 방법을 사용할 경우 넌 플러그인 환경에 적합하게 가볍고 안정적인 미디어 재생이 가능하다.

다시 도 10로 돌아가, 지연 감지 모듈(123a)에서 화살표를 따라 나오는 H.264 디코더 모듈(124a)부터 설명한다. H.264 디코더 모듈(124a)은 H.264 코덱 형식의 비디오를 디코딩하는 모듈이다. H.264 디코더 모듈(124a)에서 디코딩은 비디오의 프레임 단위로 이루어진다.

잠시 디코딩을 수행하는 다른 모듈인 H.265 디코더 모듈(124b)을 참조한다. H.265 디코더 모듈(124b)은 H.265 코덱 형식의 비디오를 디코딩하는 모듈이다. 도 10의 미디어 재생 장치(120)에는 H.254 및 H.265 코덱 형식만을 예로 들었으나 비디오의 코덱 형식에 구애 받지 않고 자바스크립트로 디코더를 구현하는 것이 얼마든지 가능하므로 그 외의 코덱 형식에 대하여도 디코딩을 수행하는 것이 가능하다.

다시 H.264 디코더 모듈(124a)로 돌아오면, H.264 디코더 코듈(124a)에서 디코딩이 이루어진 비디오는 렌더러 모듈(125)과 캔버스 태그(Canvas Tag, 133)를 통해 웹 브라우저 상에 디스플레이 된다. 캔버스 태그(133)는 2D 모양 및 비트맵 이미지를 동적으로 렌더링할 수 있게 해주는 HTML5의 요소이다. 즉 웹 브라우저 위의 그림판 이라고 볼 수 있다. 최신 버전의 웹 브라우저는 대부분 지원하는 기능이므로 자바스크립트로 구현된 디코더에서 비디오를 프레임 단위로 처리하고 캔버스 태그(133)를 이용하여 웹 브라우저에 비디오를 표시할 수 있다.

도 12는 미디어 재생 장치(120)의 다른 실시예를 나타낸다.

도 12의 실시예에서 RTSP/RTP 클라이언트 모듈(121)부터 왼쪽 아래의 화살표를 따라 렌더러 모듈(125)까지는 미디어 서비스 장치(110)로부터 도 8의 스크립트 모듈을 수신하여 구성되는 모듈들이고, RTSP/RTP 클라이언트 모듈(121)에서 오른쪽 아래의 화살표를 따라 컨테이너 생성 모듈(127)까지는 도 9의 스크립트 모듈을 받아 구성되는 모듈들이다. 도 12에서는 미디어 재생 장치(120)의 작동 과정과 재생 지연이 판별된 경우의 지연 해소 방법을 중심으로 설명한다. 이때 재생되는 미디어는 H.264 또는 H.265의 코덱 형식의 비디오인 경우에 대하여 설명한다.

웹소켓 클라이언트(131)와 RTSP/RTP 클라이언트 모듈(121)로 구성되는 수신부(141)는 미디어 서비스 장치(110)로부터 웹소켓 상에서 전송되는 RTSP/RTP 프로토콜을 이용하여 비디오를 수신한다.

수신부(141)를 통해 수신된 비디오는 제1 미디어 복원부(143) 또는 제2 미디어 복원부(144)에서 디코딩될 것인지에 따라 서로 다른 모듈로 전달된다. 제1 미디어 복원부(143)는 스크립트 모듈의 디코더 모듈(124)에 의해 디코딩하도록 구성된다. 즉, 웹 브라우저에서 파싱할 수 있는 스크립트로 구현된 디코더에 의해 프레임 단위로 디코딩하도록 구성된다. 제2 미디어 복원부(144)는 웹 브라우저에 임베드 된 디코더에 의해 디코딩하도록 구성된다. 어느 미디어 복원부에 의해 디코딩 될지는 웹 브라우저에 임베드 된 디코더에서 지원하는 코덱 형식의 비디오인지, 고해상도의 비디오인지 등에 따라 결정할 수 있다. 결정 기준은 도 13에 후술되어 있다.

먼저 제1 미디어 복원부(143)에서 디코딩 되는 경우를 설명한다.

수신부(141)로부터 전달된 비디오는 코덱 형식에 따라 알맞은 디패킷화 모듈에서 디패킷화가 이루어진다. 디패킷화가 이루어진 비디오는 프레임 단위로 지연 감지부(142)에 전달된다. 지연 감지부(142)는 스크립트 모듈의 지연 감지 모듈(123)을 포함하며 도 11에서 설명한 지연 감지 방법으로 미디어의 재생 지연 여부를 판단한다.

지연 감지부(142)에서 재생 지연이 감지된 경우 미디어 서비스 장치(110)에 변경된 프로파일로 미디어 데이터를 요청하는 작업은 프로파일 변경부에 의해 이루어진다. 즉, 지연 감지부(142)는 재생 지연을 감지한다면, 프로파일 변경부는 지연 감지부(142)로부터 재생이 지연된다는 신호를 받아 미디어 서비스 장치(110)에 변경된 프로파일의 미디어 데이터를 요청하도록 하는 기능을 수행한다.

도 12를 자세히 살펴보면, 지연 감지부(142)에서 수신부(141)로 점선으로 화살표가 그려져 있다. 이는 지연 감지부(142)에서 재생 지연이 감지된 경우 미디어 서비스 장치(110)에 미디어 데이터의 프로파일을 변경하여 전송할 것을 요청하기 위해 프로파일 변경부에 의해 피드백이 보내지는 것을 나타낸다. 미디어 서비스 장치(110)에 미디어 프로파일 변경 요청은 이와 같이 수신부(141)를 통해 이루어질 수 있으며 프로파일 변경부에서 직접 별도의 채널을 형성하여 이루어질 수도 있다.

재생 지연은 미디어의 프로파일을 변경하는 것을 통해 해소가 가능하다. 미디어의 무게를 감소시키는 방향으로 미디어의 프로파일을 변경시키면 네트워크에서의 전송과 디코딩, 렌더링이 보다 가볍게 이루어질 수 있다.

이때, 미디어의 프로파일은 해상도, 프레임 레이트(frame rate), 및 비트 레이트(bit rate)를 포함한다. 해상도는 이미지를 이루는 픽셀의 숫자를 말하며 가로x세로의 형태로 주로 표현된다. 프레임 레이트의 단위는 fps(frames per second)로 1초 동안 재생되는 이미지의 수를 의미한다. 비트 레이트의 단위는 bps(bits per second)로 1초의 비디오를 구성하는 데이터의 크기를 의미한다.

이러한 미디어의 프로파일은 복수의 단계로 미리 설정되어 제공될 수 있는데, 상기 복수의 단계는 미디어의 프로파일 요소가 모두 다르게 구성되거나 프로파일 요소 중 적어도 어느 하나가 다르게 구성될 수 있다. 예를 들어 해상도와 프레임 레이트 및 비트 레이트가 모두 다르도록, 또는 미디어의 해상도만 변경되도록 복수의 단계를 구성할 수 있다. 또한 복수의 단계는 상위 단계일수록 고해상도, 높은 프레임 레이트, 또는 높은 비트 레이트로 이루어지고 하위 단계일수록 저해상도, 낮은 프레임 레이트, 또는 낮은 비트 레이트로 이루어질 수 있다.

상기 미디어 데이터의 프로파일 변경은 현재 프로파일에서 하위 단계, 또는 상위 단계 프로파일로의 변경을 의미할 수 있다. 예를 들어 미디어의 해상도를 상위 단계로 높이거나 하위 단계로 낮추고 종횡비(aspect ratio)를 유지하는 프로파일 변경일 수 있고 해상도, 프레임 레이트 및 비트 레이트를 모두 상위 단계로 높이거나 하위 단계로 낮추는 변경일 수 있다.

미디어 프로파일의 복수의 단계는 예를 들어 다음의 표 4와 같이 구성될 수 있다. 현재 프로파일을 1280x720의 해상도, 20fps의 프레임 레이트, 2Mbps의 비트 레이트로 가정했을 때, 복수의 단계에 따른 프로파일 변경은 상위단계로의 변경의 경우 해상도, 프레임 레이트 및 비트 레이트가 모두 상향 조정된 1920x1080의 해상도, 30fps의 프레임 레이트, 2.5Mbps의 비트 레이트의 프로파일이 되고, 하위단계로의 변경의 경우 비트 레이트만 1Mbps로 하향 조정된 프로파일이 된다.

해상도	프레임 레이트	비트 레이트
2704 x 1520	30 fps	4 Mbps
1920 x 1080	30 fps	2.5 Mbps
1280 x 720	20 fps	2 Mbps
1280 x 720	20 fps	1 Mbps

지연 감지부(142)는 미디어의 프로파일이 변경된 후에도 계속해서 재생 지연을 감지할 수 있다. 이때 재생 지연 감지에 기준이 되는 최초 프레임은 프로파일이 변경된 미디어 데이터의 첫번째 프레임이 되며 도 11에서 설명한 지연 감지 방법을 반복하여 재생 지연을 감지한다.

프로파일을 변경한 후에도 여전히 지연 감지부(142)에서 미디어 재생이 지연된다고 판단한 경우, 프로파일 변경부는 미디어 서비스 장치(110)에 변경된 프로파일의 하위 단계의 프로파일로 미디어 데이터를 전송할 것을 요청할 수 있다.

이와 반대로 프로파일을 변경한 후에 지연 감지부(142)에서 감지되는 Tdx와 Td1의 차가 기준치 이하로서 기준 시간 이상 지속되는 경우, 미디어 재생이 원활히 이루어지고 있다고 보아, 프로파일 변경부는 미디어 서비스 장치(110)에 변경된 프로파일의 상위 단계의 프로파일로 미디어 데이터를 전송할 것을 요청할 수 있다. 이때, 상기 기준치는 최대 지연시간 또는 사용자가 설정한 이보다 작은 값일 수 있고, 상기 기준 시간은 일시적인 노이즈에 의해 프로파일이 변경되지 않도록 하기 위한 최소 지속시간이다.

이상의 지연 여부 판별 과정을 거쳐 프로파일이 변경 또는 유지된 비디오 프레임은 제1 미디어 복원부(143)에서 디코딩이 이루어진다. 도 12의 실시예에서 제1 미디어 복원부(143)는 웹 브라우저에서 파싱할 수 있는 스크립트인 자바스크립트로 디코더가 구현되며, 자바스크립트 디코더에서 비디오는 프레임 단위로 디코딩 된다. 디코딩이 이루어진 비디오는 렌더러 모듈(125)과 캔버스 태그(Canvas Tag, 133)를 통해 웹 브라우저 상에 디스플레이 된다.

다음으로 제2 미디어 복원부(144)를 통해 디코딩되는 경우를 설명한다.

수신부(141)는 비디오를 오른쪽 화살표를 따라 디패킷화 모듈로 전달한다. 디패킷화 모듈에서 디패킷화가 수행된 비디오는 컨테이너 생성 모듈(127)로 전달된다.

컨테이너 생성 모듈(127)은 도 9에서 설명한대로 비디오가 컨테이너 형식으로 전송되지 않은 경우 프레임들을 모아 컨테이너를 생성하는 기능을 수행한다. 컨테이너 생성 모듈(127)을 거친 비디오는 컨테이너 형식으로 인한 호환성 문제 없이 MSE(134)와 제2 미디어 복원부(144)로 전달된다.

MSE(134)는 HTTP 다운로드를 이용해 동영상 스트리밍 재생을 위해 만들어진 HTML5용 자바스크립트 API이다. W3C에 의해 표준화 된 이 기술은 엑스박스(Xbox)와 플레이스테이션4(PS4) 같은 콘솔 게임기나 크롬 캐스트 브라우저 등에서 스트리밍 재생을 가능하게 해준다.

도 12에서 제2 미디어 복원부(144)는 웹 브라우저에 임베드 된 디코더인 비디오 태그(135)로 구성된다. 비디오 태그(135)에서는 디코딩 및 렌더링을 수행하여 비디오가 웹 브라우저에 디스플레이 되도록 한다.

제2 미디어 복원부(144)의 비디오 태그(135) 디코더를 사용하면 자바스크립트의 동적 언어 특성으로 인해 한계를 지닌 디코더 모듈(124)보다 우수한 성능으로 디코딩이 가능하다. 즉, 고해상도 영상과 높은 fps의 디코딩이 가능하다.

도 12에는 제1 미디어 복원부(143)에만 지연 감지부(142)가 설치되어 있으나, 제2 미디어 복원부(144)의 디코더 앞단에도 지연 감지부(142)를 설치하여 제2 미디어 복원부(144)의 디코더에 의한 재생 지연을 감지하고 재생 지연이 감지된 경우 프로파일이 변경된 미디어를 요청하여 지연을 방지하도록 미디어 재생 장치(120)를 구성할 수 있다.

도 13은 미디어 재생 장치(120)의 작동 과정을 나타낸 순서도이다. 보다 자세히, 도 13은 도 12의 실시예의 미디어 재생 장치(120)의 작동 과정을 나타낸다.

미디어 재생 장치(120)에 전송된 비디오의 코덱 형식이 비디오 태그에서 지원하는 코덱 형식이고 고해상도(FHD 초과)인지 여부를 판단한다(S2100). 두 조건을 모두 만족하는 경우는 성능이 우수한 비디오 태그를 이용하여 디코딩 하기에 적합한 경우이므로, 제2 미디어 복원부(144)를 통해 디코딩을 수행한다(S2200). 두 조건 중 어느 하나를 만족하지 못하는 경우는 비디오 태그에서 지원하는 코덱 형식이 아니거나, 지원하더라도 고해상도의 비디오가 아닌 경우이다. 이 때는 자바스크립트로 구현된 제1 미디어 복원부(143)를 통해 비디오를 디코딩한다(S2300). 이후 비디오 재생이 진행되며 지연이 발생하는지 여부를 판단한다(S2400). 재생 지연이 발생하지 않는 경우는 프로파일 변경 없이 제1 미디어 복원부(143)를 통해 비디오 디코딩을 계속 수행한다(S2300). 그러나 재생 지연이 발생하였다고 판단된 경우는 프로파일을 변경하여(S2500) 제1 미디어 복원부(143)를 통해 비디오 디코딩을 수행한다(S2300).

도 14는 본 발명의 일 실시예에 따른 자바스크립트로 구현된 스크립트 모듈을 생성하는 과정을 설명하기 위한 예시도이다.

도 14를 참고하면 자바스크립트로 구현된 스크립트 모듈은 종래의 C와 C++의 네이티브 코드로 작성된 소스를 Emscripten과 같은 컨버터(converter)로 변환하여 브라우저에서 사용할 수 있는 자바스크립트 코드를 얻을 수 있다.

Emscripten과 같은 컨버터(converter)를 이용하면, 종래의 네이티브 코드로부터 자바스크립트로 구현된 디코더나 컨테이너를 얻을 수 있으므로 코덱 종속성을 낮출 수 있는 장점이 있다.

플러그인 대신에 자바스크립트 코드를 사용하므로 웹 브라우저 제작 업체의 지원 중단을 염려할 필요도 없다. 또한, 웹 브라우저에 따라 ActiveX 인터페이스를 사용할지 NPAPI 인터페이스를 사용할지 고민할 필요가 없다. 즉, 웹 브라우저 종속성을 낮출 수 있는 장점이 있다.

도 1에 도시된 미디어 재생 장치(120)는 예를 들어, 다음의 도 15에 도시된 컴퓨팅 장치(400)로 구현될 수 있다. 컴퓨팅 장치(400)는 모바일 핸드헬드 기기들(스마트 폰, 태블릿 컴퓨터 등), 랩톱 또는 노트북 컴퓨터, 분산된 컴퓨터 시스템, 컴퓨팅 그리드 또는 서버일 수 있으나 이에 한하지는 않는다. 컴퓨팅 장치(400)는 버스(440)를 통해 서로 간에 또는 다른 요소들과 통신하는 프로세서(401) 및 메모리(403) 및 스토리지(408)를 포함할 수 있다. 버스(440)는 디스플레이(432), 하나 이상의 입력 장치들(433), 하나 이상의 출력 장치들(434)과 연결될 수 있다.

이러한 모든 요소들은 버스에(400) 직접 또는 하나 이상의 인터페이스들 또는 어댑터들을 통하여 접속될 수 있다. 버스(440)는 광범위한 서브 시스템들과 연결된다. 버스(440)는 메모리 버스, 메모리 컨트롤러, 주변 버스(peripheral bus), 로컬 버스 및 이들의 조합을 포함할 수 있다.

메모리(403)는 RAM(404, random access memory), ROM(405, read-only component) 및 이들의 조합으로 구성될 수 있다. 또한, 컴퓨팅 장치(400) 내에서 부팅(booting)을 위해 필요한 기본 루틴들을 구비하는 바이오스(내지 펌웨어)가 메모리(403) 내에 포함될 수 있다.

스토리지(408)는 오퍼레이팅 시스템(409), 실행 가능한 파일들(EXEC, 410), 데이터(411), API 어플리케이션(412) 등을 저장하기 위해 사용된다. 스토리지(408)는 하드 디스크 드라이브, 광디스크 드라이브, SSD(solid-state memory device) 등을 포함할 수 있다.

컴퓨팅 장치(400)는 입력 장치(433)을 포함할 수 있다. 사용자는 입력 장치(433)를 통하여 컴퓨터 장치(400)에 명령 및/또는 정보를 입력할 수 있다. 입력 장치(433)의 예로는, 키보드, 마우스, 터치패드, 조이스틱, 게임패드, 마이크로폰, 광학 스캐너, 카메라 등이 있다. 입력 장치(433)는 직렬 포트, 병렬 포트, 게임 포트, USB 등을 포함하는 입력 인터페이스(423)를 통해 버스(440)에 접속될 수 있다.

특정 실시예에서, 컴퓨팅 장치(400)는 네트워크(430)에 연결된다. 컴퓨팅 장치(400)는 다른 장치들과 네트워크(430)를 통하여 연결된다. 이 때, 네트워크 인터페이스(420)는 네트워크(430)로부터 하나 이상의 패킷의 형태로 된 통신 데이터를 수신하고, 컴퓨팅 장치(400)는 프로세서(401)의 처리를 위해 상기 수신된 통신 데이터를 저장한다. 마찬가지로, 컴퓨팅 장치(400)는 전송한 통신 데이터를 하나 이상의 패킷 형태로 메모리(403) 상에 저장하고, 네트워크 인터페이스(420)는 상기 통신 데이터를 네트워크(430)로 전송한다.

네트워크 인터페이스(420)는 네트워크 인터페이스 카드, 모뎀 등을 포함할 수 있다. 네트워크(430)의 예로는, 인터넷, WAN(wide area network), LAN(local area network), 전화 네트워크, 직접 연결 통신 등이 있으며, 유선 및/또는 유선 통신 방식을 채용할 수 있다.

프로세서(401)에 의한 소프트웨어 모듈의 실행 결과는 디스플레이(432)를 통해 표시될 수 있다. 디스플레이(432)의 예로는, LCD(liquid crystal display), OLED(organic liquid crystal display), CRT(cathode ray tube), PDP(plasma display panel) 등이 있다. 디스플레이(432)는 비디오 인터페이스(422)를 통하여 버스(440)에 연결되고, 디스플레이(432)와 버스(440) 간의 데이터 전송은 그래픽 컨트롤러(421)에 의해 제어될 수 있다.

디스플레이(432)와 더불어, 컴퓨팅 장치(400)는 오디오 스피커, 프린터 등과 같은 하나 이상의 출력 장치(434)를 포함할 수 있다. 출력 장치(434)는 출력 인터페이스(424)를 통해 버스(440)와 연결된다. 출력 인터페이스(424)는 예를 들어, 직렬 포트, 병렬 포트, 게임 포트, USB 등이 있다.

본 발명이 속하는 기술분야의 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다. 본 발명의 범위는 상기 상세한 설명보다는 후술하는 특허청구범위에 의하여 나타내어지며, 특허청구범위의 의미 및 범위 그리고 그 균등 개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.

110: 미디어 서비스 장치 111: 카메라
112: 인코더 113: 패킷화부
114: 웹 서버 115: 모듈 저장부
116: 모듈 전송부 117: 제어부
120: 미디어 재생 장치 121: RTSP/RTP 클라이언트 모듈
122: 디패킷화 모듈 123: 지연 감지 모듈
124: 디코더 모듈 125: 렌더러 모듈
127: 컨테이너 생성 모듈 131: 웹소켓 클라이언트
133: 캔버스 태그 141: 수신부
142: 지연 감지부 143: 제1 미디어 복원부
144: 제2 미디어 복원부 210: 웹 브라우저

Claims

미디어 서비스 장치에서 생성된 미디어 데이터를 웹 서비스를 지원하는 통신 프로토콜을 이용하여 수신하는 수신부;
웹 브라우저가 파싱(parsing)할 수 있는 스크립트로 작성된 디코더에 의해 상기 수신된 미디어 데이터를 디코드하도록 구성되는 제1 미디어 복원부;
상기 스크립트로 작성된 디코더에 의해 디코드 된 미디어 데이터를 표시하기 위해 렌더링하도록 구성되는 렌더러;
상기 미디어 데이터에 포함되는 시간 스탬프와 상기 미디어 데이터가 미디어 복원부에 도착하는 시간을 비교하여, 상기 미디어 데이터의 재생 지연을 감지하도록 구성되는 지연 감지부; 및
상기 지연 감지부에서 상기 재생 지연이 감지된 경우, 상기 미디어 서비스 장치에 변경된 프로파일로 상기 미디어 데이터를 전송할 것을 요청하도록 구성되는 프로파일 변경부를 포함하는, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제1항에 있어서, 상기 재생 지연은
상기 미디어 서비스 장치로부터 상기 미디어 재생 장치로 상기 미디어 데이터가 전송되는 동안 발생하는 네트워크 지연과, 상기 제1 미디어 복원부에서의 디코드 과정에서 발생하는 디코딩 지연과, 상기 렌더러에서의 렌더링 과정에서 발생하는 렌더링 지연을 포함하는, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제1항에 있어서, 상기 지연 감지부는
상기 미디어 데이터가 상기 미디어 복원부 앞에 도착하는 시간과 상기 시간 스탬프 간의 차이 값을 기준으로 상기 재생 지연을 감지하는, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제1항에 있어서, 상기 지연 감지부는
상기 미디어 데이터 중에서 최초의 프레임이 상기 미디어 복원부 앞에 도착하는 시간과 상기 최초의 프레임의 시간 스탬프 간의 차이 Td1과,
상기 미디어 데이터 중에서 이후의 프레임이 상기 미디어 복원부 앞에 도착하는 시간과 상기 이후의 프레임의 시간 스탬프 간의 차이 Tdx를 비교하여 상기 재생 지연을 감지하는, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제4항에 있어서, 상기 최초의 프레임은
상기 미디어 데이터 자체에 포함된 최초의 프레임과, 상기 프로파일이 변경된 미디어 데이터에서의 첫번째 프레임을 포함하는, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제5항에 있어서, 상기 지연 감지부는
상기 Tdx와 상기 Td1의 차이가 일정 횟수 이상 계속하여 증가하는가를 기준으로 상기 재생 지연을 감지하는, 웹 브라우저 상에서 미디어를 재생하는, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제5항에 있어서, 상기 지연 감지부는
상기 Tdx와 상기 Td1의 차이가 5초를 초과하는가를 기준으로 상기 재생 지연을 감지하는, 웹 브라우저 상에서 미디어를 재생하는, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제1항에 있어서, 상기 변경된 프로파일은
상기 미디어 데이터의 해상도, 프레임 레이트 및 비트 레이트 중 적어도 하나가 변경된 프로파일인, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제8항에 있어서, 상기 변경된 프로파일은
상기 미디어 데이터의 해상도를 낮추고 종횡비(aspect ratio)를 유지하는 프로파일인, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제1항에 있어서,
상기 웹 브라우저에 임베드 된 디코더에 의해 상기 수신된 미디어 데이터를 디코드하도록 구성되는 제2 미디어 복원부를 더 포함하는, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제10항에 있어서,
상기 스크립트로 작성된 디코더는 자바스크립트로 작성된 디코더이고, 상기 웹 브라우저에 임베드 된 디코더는 HTML5에서 지원하는 비디오 태그인, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제1항에 있어서,
상기 수신부에서의 수신 과정, 상기 제1 미디어 복원부에서의 디코딩 과정 및 상기 렌더러에서의 렌더링 과정은 다중 쓰레드 형태의 복수의 웹 워커에 의해 하나의 파이프 라인으로 처리되는, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제1항에 있어서, 상기 변경된 프로파일은 미리 정해진 복수의 단계로 이루어진 프로파일들 중에서 현재 프로파일의 하위 단계의 프로파일인, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제13항에 있어서,
상기 프로파일을 변경한 후에도 상기 지연 감지부가 여전히 상기 미디어 데이터의 재생 지연을 감지한 경우에는,
상기 프로파일 변경부는 상기 미디어 서비스 장치에 상기 변경된 프로파일의 하위 단계의 프로파일로 상기 미디어 데이터를 전송할 것을 요청하는, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
제1항에 있어서,
상기 프로파일을 변경한 후에 상기 지연 감지부에서 감지되는 상기 미디어 데이터의 재생 지연이 소정의 기준치 이하로서 소정의 기준 시간 이상 지속되는 경우에는,
상기 프로파일 변경부는 상기 미디어 서비스 장치에 상기 변경된 프로파일의 상위 단계의 프로파일로 상기 미디어 데이터를 전송할 것을 요청하는, 웹 브라우저 상에서 미디어를 재생하는 미디어 재생 장치.
미디어 데이터를 상기 미디어 재생 장치에 전송하는 미디어 서비스 장치로서,
상기 미디어 데이터를 상기 미디어 재생 장치의 웹 브라우저 상에서 재생하기 위해 필요한 스크립트 모듈을 저장하는 모듈 저장부;
상기 미디어 재생 장치의 접속에 응답하여 상기 스크립트 모듈을 상기 미디어 재생 장치에 전송하는 모듈 전송부;
상기 미디어 데이터를 패킷화하여 전송 패킷을 생성하는 패킷화부; 및
상기 재생 장치와의 통신 세션을 형성하며, 상기 미디어 재생 장치로부터의 요청된 프로파일에 따라 상기 전송 패킷을 상기 미디어 재생 장치에 전송하는 웹 서버를 포함하되,
상기 스크립트 모듈은, 상기 미디어 재생 장치에서 상기 미디어 데이터를 플러그인 없이 디코드 하는 프로세스와, 상기 미디어 데이터의 재생 중에 발생되는 재생 지연을 감지하는 프로세스를 포함하는 미디어 서비스 장치.
제16항에 있어서,
상기 스크립트 모듈은 상기 웹 브라우저에서 파싱(parsing) 가능한 자바 스크립트로 작성된 코드인 미디어 서비스 장치.
제16항에 있어서, 상기 재생 지연은
상기 미디어 서비스 장치로부터 상기 미디어 재생 장치로 상기 미디어 데이터가 전송되는 동안 발생하는 네트워크 지연과, 상기 미디어 재생 장치에서의 디코드 과정에서 발생하는 디코딩 지연과, 상기 미디어 재생 장치에서의 렌더링 과정에서 발생하는 렌더링 지연을 포함하는 미디어 서비스 장치.
제16항에 있어서, 상기 재생 지연을 감지하는 프로세스는
상기 미디어 데이터가 상기 미디어 재생 장치에서 상기 미디어 데이터를 플러그인 없이 디코드하는 디코딩 모듈 앞에 도착하는 시간과, 상기 미디어 데이터의 시간 스탬프 간의 차이 값을 기준으로 상기 재생 지연을 감지하는 미디어 서비스 장치.
제16항에 있어서, 상기 재생 지연을 감지하는 프로세스는
상기 미디어 데이터 중에서 최초의 프레임이 디코딩 모듈 앞에 도착하는 시간과 상기 최초의 프레임의 시간 스탬프 간의 차이 Td1과,
상기 미디어 데이터 중에서 이후의 프레임이 상기 디코딩 모듈 앞에 도착하는 시간과 상기 이후의 프레임의 시간 스탬프 간의 차이 Tdx를 비교하여 상기 재생 지연을 감지하는 미디어 서비스 장치.
제20항에 있어서, 상기 최초의 프레임은
상기 미디어 데이터 자체에 포함된 최초의 프레임과, 상기 프로파일이 변경된 미디어 데이터에서의 첫번째 프레임을 포함하는 미디어 서비스 장치.
제21항에 있어서, 상기 재생 지연을 감지하는 프로세스는
상기 Tdx과 상기 Td1의 차이가 일정 횟수 이상 계속하여 증가하는가를 기준으로 상기 재생 지연을 감지하는 미디어 서비스 장치.
제21항에 있어서, 상기 변경된 프로파일은
상기 미디어 데이터의 해상도, 프레임 레이트 및 비트 레이트 중 적어도 하나가 변경된 프로파일인 미디어 서비스 장치.
제23항에 있어서, 상기 변경된 프로파일은
상기 미디어 데이터의 해상도의 해상도를 낮추고 종횡비(aspect ratio)를 유지하는 프로파일인 미디어 서비스 장치.