KR20170114219A - 웹브라우저 상에서 미디어 스트림을 재생하는 방법 및 장치 - Google Patents

웹브라우저 상에서 미디어 스트림을 재생하는 방법 및 장치 Download PDF

Info

Publication number
KR20170114219A
KR20170114219A KR1020160069468A KR20160069468A KR20170114219A KR 20170114219 A KR20170114219 A KR 20170114219A KR 1020160069468 A KR1020160069468 A KR 1020160069468A KR 20160069468 A KR20160069468 A KR 20160069468A KR 20170114219 A KR20170114219 A KR 20170114219A
Authority
KR
South Korea
Prior art keywords
media
web
module
media stream
streaming
Prior art date
Application number
KR1020160069468A
Other languages
English (en)
Other versions
KR101821124B1 (ko
Inventor
조성봉
라만 수지트 쿤히
요가바난 마티바난
타라크 람고팔 아노모루
벤카테스와라 라오 아라바팔리
Original Assignee
한화테크윈 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 한화테크윈 주식회사 filed Critical 한화테크윈 주식회사
Priority to US15/393,936 priority Critical patent/US10412130B2/en
Priority to EP17150632.2A priority patent/EP3229476B1/en
Priority to CN201710112610.4A priority patent/CN107277612B/zh
Publication of KR20170114219A publication Critical patent/KR20170114219A/ko
Application granted granted Critical
Publication of KR101821124B1 publication Critical patent/KR101821124B1/ko

Links

Images

Classifications

    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2355—Processing of additional data, e.g. scrambling of additional data or processing content descriptors involving reformatting operations of additional data, e.g. HTML pages
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 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, manipulating MPEG-4 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
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet

Abstract

미디어 서버로부터 전송되는 미디어 스트림을 수신하여 웹브라우저 상에서 재생하는 미디어 스트림 재생 장치는, 상기 미디어 서버와 전송 계층 레벨의 통신 연결을 수립하는 전송 모듈과, 상기 전송 계층 레벨의 연결을 기초로 상기 미디어 서버와 핸드쉐이크를 통해 웹소켓 연결을 수립한 후 상기 수립된 웹소켓 연결을 지속적으로 유지하면서, 상기 미디어 서버와 웹소켓 패킷을 송수신하는 웹소켓 모듈과, 상기 웹소켓 패킷에 의해 운반되는 실시간 전송 프로토콜 패킷을 수신하는 스트리밍 모듈과, 상기 실시간 전송 프로토콜 패킷으로부터 얻어지는 상기 미디어 스트림을 디코드 하여 영상을 복원하는 미디어 디코더와, 상기 복원된 영상을 상기 웹브라우저에 임베드하여 화면 상에 표시하는 출력 장치로 이루어진다.

Description

웹브라우저 상에서 미디어 스트림을 재생하는 방법 및 장치{Method and apparatus for playing media stream on web-browser}
본 발명은 웹브라우저 상에서 미디어 스트림을 재생하는 방법 및 장치에 관한 것으로, 보다 자세하게는 카메라에서 획득된 영상과 음성을 플러그인 없이도 웹브라우저에서 직접 스트리밍하는 기술에 관한 것이다.
미디어 컨텐츠는 인터넷을 통해 다양한 영상 소스와 연결된 복수의 사용자 기기들에 의해 억세스될 수 있다. 이를 위해, 상기 사용자 기기들에는 HTTP(hypertext transfer protocol)를 사용하여 서버 어플리케이션과 통신할 수 있도록 웹브라우저가 설치된다. 그런데 이러한 웹브라우저는 하프 듀플렉스(half-duplex) 방식이고 HTTP 요청 및 응답 메시지를 통한 반복적인 정보 교환으로 인해 오버헤드가 발생하기 때문에, 연속적인 미디어를 스트리밍 하기에는 적합하지 않다.
도 1에 도시된 종래의 HTTP 연결 방식에 따르면, 웹브라우저(15)는 웹서버(25)에 연결 요청 메시지(Long-lived request)를 전송한 후, 웹서버(25)에 의해 요청 대기(request suspended) 상태로 전환되고 양자간의 접속이 수립된다. 이 상태에서 웹브라우저(15)가 특정 동작(action)을 수행하기 위한 명령(client action)을 웹서버(25)에 전송하면, 이에 대한 응답으로서 웹서버(25)는 응답 메시지를 웹브라우저(15)에 전송한다. 예를 들어, 상기 명령(client action)이 특정 영상에 관한 스트리밍 요구라면 상기 응답 메시지는 상기 영상의 패킷 데이터가 될 것이다. 이러한 연결은 지속적으로 이루어질 수는 없고 웹서버(25)가 완료 명령(Long-lived request completes)을 웹브라우저(15)에 전송하면서 양자간의 연결은 단절된다. 이후에 웹브라우저(15)가 추가적으로 상기 스트리밍을 요구하여야 한다면 위의 과정들을 재차 반복하여야 한다.
즉, 종래의 HTTP 연결 방식으로 웹서버와 웹브라우저 간의 통신하는 방식은, 특정한 이벤트마다 웹서버와 웹브라우저간의 연결이 필요하고 그 이벤트가 끝나면 연결이 종료된다. 따라서, 상기 방식은 웹 페이지의 접속 등 비연속적인 이벤트의 처리에 적합하지만, 영상 및 음성 스트리밍과 같이 웹서버와 웹브라우저간에 지속적인 연결 유지가 필요한 분야에는 적합하지 않다.
이러한 문제로 인해, 웹브라우저에 다양한 형태의 플러그인(ActiveX, NPAPI, PPAPI)의 설치를 통해 웹브라우저 및 웹서버 간의 네트워크 연결 기능, 수신한 영상을 디코딩하는 기능 및 디코딩된 영상을 출력하는 기능을 구현하는 방식이 많이 사용되고 있다. 특히, 네트워크 카메라에는 일반적으로 웹 뷰어라고 불리는 영상/음성을 수신하고 출력할 수 있는 기능이 제공되고 있다. 이러한 웹 뷰어라는 기능은 사용자가 원격지에서 CMS(Central Monitoring System)나 VMS(Video Management System)와 같은 소프트웨어를 설치하지 않고도, 카메라의 네트워크 주소의 입력을 통해 네트워크 카메라에 접속하면 플러그인이 자동으로 설치되고, 이렇게 설치된 플러그인을 통해서 영상 및 음성을 수신할 수 있게 한다. 그리고, 이러한 기능을 제공하기 위해서 상기 네트워크 카메라는 웹서비스를 제공할 수 있는 웹서버를 탑재한다. 따라서, 기존의 웹 서비스 방식은 웹브라우저를 탑재한 사용자 단말이 특정 URL을 통해 웹서버에 접속하면 자동으로 플러그인이 설치되고 영상 및 음성의 송수신 기능은 플러그인을 통해서 이루어지게 된다.
그러나, 이와 같이 웹브라우저에 플러그인을 설치하는 방식은 보안의 취약성, 웹브라우저의 기능 제한, 지나친 리소스의 소모 등 많은 문제를 노출하면서 사용 빈도가 줄어들고 있는 추세이다. 또한, 영상 스트림을 전송하기 위한 또다른 표준화의 결과물의 예로서, HTML5에서는 비디오 태그(video tag)를 통해 원격 소스에 저장된 영상 파일을 수신하는 기능을 지원하고 있고, WebRTC, openWebRTC, MPEG-DASH 등에서는 실시간 영상 송수신을 위한 표준 규격을 제공하고 있다.
이와 같이, 최근 플러그인 기술의 배제로 인해 영상 수신, 재생 및 표시 기능은 HTML5, WebRTC, open WebRTC, MPEG-DASH 등의 표준에서 지원하는 방식에 따라 구현할 수 있다. 그러나, 지금까지 영상 송수신 표준으로 많이 사용되었던 RTP/RTSP(Real Time Transport Protocol / Real Time Streaming Protocol)를 이용하여 웹브라우저 상에서 영상을 처리하기 위해서는 플러그인이 사용이 필요하며, 현재로서는 플러그인 없이 웹브라우저 상에서 RTP/RTSP에 따라 영상 처리하는 것은 가능하지 않다. 그렇다고 해서, 네트워크 카메라나 저장장치 등 시스템 리소스의 제약을 받는 임베디드 시스템(embedded system)에서 RTP/RTSP외에 다른 무거운 프로토콜을 추가로 탑재하는 것도 현실적인 선택이 될 수 없을 것이다.
따라서, 네트워크 카메라, NVR/DVR, 인코더/디코더, 비디오관리 소프트웨어 등의 기술 분야에 있어서, 별도의 플러그인 없이 RTP/RTSP 통신을 그대로 이용하여 웹브라우저 상에서 미디어(영상 및 음성)를 스트리밍할 수 있는 기술을 고안할 필요가 있다.
한국특허공개공보 2015-0119003호
본 발명이 이루고자 하는 기술적 과제는, 웹브라우저 상에서 영상 및 음성을 스트리밍함에 있어서, 플러그인의 설치 없이 최소한의 시스템 사양만으로도 지연없는 스트리밍을 가능하게 하는 것이다.
본 발명의 기술적 과제들은 이상에서 언급한 기술적 과제로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.
상기 기술적 과제를 달성하기 위한, 미디어 서버로부터 전송되는 미디어 스트림을 수신하여 웹브라우저 상에서 재생하는 미디어 스트림 재생 장치는, 상기 미디어 서버와 전송 계층 레벨의 통신 연결을 수립하는 전송 모듈; 상기 전송 계층 레벨의 연결을 기초로 상기 미디어 서버와 핸드쉐이크를 통해 웹소켓 연결을 수립한 후 상기 수립된 웹소켓 연결을 지속적으로 유지하면서, 상기 미디어 서버와 웹소켓 패킷을 송수신하는 웹소켓 모듈; 상기 웹소켓 패킷에 의해 운반되는 실시간 전송 프로토콜 패킷을 수신하는 스트리밍 모듈; 상기 실시간 전송 프로토콜 패킷으로부터 얻어지는 상기 미디어 스트림을 디코드 하여 영상을 복원하는 미디어 디코더; 및 상기 복원된 영상을 상기 웹브라우저에 임베드하여 화면 상에 표시하는 출력 장치를 포함한다.
본 발명에 따르면, 플러그인 없이도 웹소켓을 이용하여 RTP/RTSP와 호환되고 영상 및 음성을 실시간으로 스트리밍할 수 있는 사용자 기기를 제공할 수 있다. 특히, 웹소켓을 통해 RTSTP/RTP를 제어하기 때문에 웹소켓을 지원하는 모든 브라우저에 의해 쉽게 지원될 수 있으며, 새로운 별도의 프로토콜을 고안할 필요가 없다는 장점이 있다.
또한 본 발명에 따르면, 네트워크 카메라, 네트워크 비디오 레코더, 디지털 비디오 레코더 등 높은 시스템 사양을 구비하기 어려운 기기들에서도, 플러그인 없이 웹브라우저 상에서 미디어를 스트리밍할 수 있게 된다. 특히, 상기와 같은 기기들에서 탐색 및 백채널 오디오를 포함한 실시간 방식 및 재생 방식이 모두 지원될 수 있고 미디어 포맷에 관한 제약이 없다는 장점이 있다.
도 1은 종래의 HTTP 연결 방식으로 웹서버와 웹브라우저 간의 통신하는 방식을 보여주는 도면이다.
도 2는 본 발명의 일 실시예에 따른 전체 시스템을 보여주는 도면이다.
도 3은 기기들 간의 통신을 위해 계층적으로 정의되는 OSI 7계층 모델과 TCP/IP 4계층 모델을 보여주는 도면이다.
도 4는 본 발명의 일 실시예에 따른 미디어 스트림 재생 장치의 구성을 도시한 블록도이다.
도 5는 웹소켓 연결을 통한 데이터의 송수신 과정의 일 예를 보여주는 시퀀스도이다.
도 6은 이와 같이 미디어 스트림 재생 장치와 스트림 서버 간에 송수신되는 웹소켓 패킷의 구체적인 구조도이다.
도 7은 RTP 프로토콜의 구체적인 구조도이다.
도 8은 도 4의 스트리밍 모듈의 세부 구성을 도시한 블록도이다.
도 9는 네트워크 인터페이스를 통해 스트림 서버와 통신하는 통신 패킷의 구조를 도시한 도면이다.
도 10은 도 3의 미디어 스트림 재생 장치와 통신하는 미디어 서버의 구성을 도시한 블록도이다.
도 11은 미디어 스트림 재생 장치 내의 스트리밍 모듈과 미디어 서버 간의 RTSP 셋업 과정을 나타낸 시퀀스도이다.
도 12는 도 11의 셋업 과정 이후에 상기 스트리밍 모듈이 상기 미디어 서버로부터 RTP 데이터를 수신하는 과정을 나타내는 시퀀스도이다.
도 13은 상기 스트리밍 모듈과 상기 미디어 서버간에 더 이상의 연결이 불필요한 경우에 접속 종료 과정를 보여주는 시퀀스도이다.
본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 것이며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하며, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다. 이하 첨부된 도면들을 참조하여 본 발명의 일 실시예를 상세히 설명한다.
도 2에 도시된 바와 같이, 본 발명에 따른 전체 시스템(10)은 다양한 사용자 기기들(106-114) 및 미디어 서버들(202, 204, 206) 간의 통신을 가능하게 하는 네트워크(50)를 포함한다. 상기 네트워크(50)는 직접적 또는 간접적 물리 통신 연결, 모바일 연결 네트워크, 인터넷, 인트라넷, LAN(Local Area Network), WAN(Wide Area Network), SAN(Storage Area Network) 및 2이상의 다른 시스템을 연결하는 다른 형태 등을 포함한다. 각각의 미디어 서버(202, 204, 206)는 하나 이상의 클라이언트 사용자 기기들 내지 미디어 스트림 재생 장치들에 대해 컴퓨팅 서비스를 제공할 수 있도록 적합한 컴퓨팅 또는 프로세싱 장치를 포함한다. 예를 들면, 미디어 서버(202, 204, 206)는 네트워크 카메라, 네트워크 비디오 레코더(NVR), 디지털 비디오 레코더(DVR) 등과 같이 미디어 스트림를 생성하거나 저장하며 상기 미디어 스트림을 클라이언트 사용자 기기들에 전송할 수 있는 장치를 포함한다. 각각의 클라이언트 사용자 기기(106-114)는 네트워크(50)를 통해 미디어 서버(202, 204, 206)나 다른 컴퓨팅 사용자 기기들과 상호작용할 수 있도록 적합한 컴퓨팅 또는 프로세싱 장치를 포함한다. 예를 들면, 클라이언트 사용자 기기들(106-114)은 데스크톱 컴퓨터(106), 모바일 전화 또는 스마트폰(108), PDA(personal digital assistant, 110), 랩톱 컴퓨터(112) 및 타블릿 컴퓨터(114)를 포함할 수 있다. 그렇지만, 추가적인 클라이언트 사용자 기기들이 도 1의 시스템(10)에 더 포함될 수 있음은 물론이다. 이러한 미디어 서버들(202, 204, 206) 또는 클라이언트 사용자 기기들(106-114)은 예를 들면, 명령을 처리하는 하나 이상의 컨트롤러, 명령 및 데이터를 저장하는 하나 이상의 메모리, 및 네트워크(50)를 통한 통신을 가능하게 하는 하나 이상의 네트워크 인터페이스를 포함할 수 있다.
여기서, 몇몇 클라이언트 사용자 기기들(108-114)는 네트워크(50)와 간접적으로 통신한다. 예를 들면, 상기 클라이언트 사용자 기기들(108-110)는 셀 망에 기초한 하나 이상의 기지국(116)과 통신한다. 또한, 클라이언트 사용자 기기들(112-114)은 IEEE 802.11 무선 공유기와 같은 하나 이상의 무선 억세스 포인트들(118)을 통해 통신한다. 이상의 설명들은 예시적인 것이며 각각의 사용자 기기는 적절한 중간 사용자 기기들 또는 네트워크를 통하여, 네트워크(50)와 직접적 또는 간접적으로 통신할 수 있다. 본 발명에서 네트워크(50)는 효율적인 미디어 스트리밍을 가능하게 한다. 특히, 하나 이상의 미디어 서버들(202, 204, 206)은 미디어 스트리밍이 웹소켓 상에서 이루어지도록 지원한다. 하나 이상의 클라이언트 사용자 기기들(106-114)은 미디어 서버(202, 204, 206)가 웹소켓 상에서 미디어 스트림을 지원하는 때를 감지할 수 있다. 미디어 서버(202, 204, 206)가 웹소켓 상에서 미디어가 스트리밍되는 것을 지원할 때, 하나 이상의 클라이언트 사용자 기기들(106-114)은 상기 미디어 서버(202, 204, 206)에 웹소켓 연결을 수립하고 상기 선택된 미디어의 대상과 스트림 내의 위치를 나타내는 초기 요청을 전송할 수 있다. 각각의 클라이언트 사용자 기기들(106-114)은 미디어 서버(202, 204, 206)로부터 제공되는 미디어 스트림의 세그먼트들을 순차적으로 수신한다.
도 2와 같이 사용자 기기들(106-114)과 미디어 미디어 서버(202, 204, 206) 간의 통신을 위해서는 각각 네트워크 인터페이스를 구비하고, 기타 네트워크 인터페이스로의 데이터의 교환을 위한 추가적인 모듈들을 구비할 필요가 있다. 도 3은 기기들 간의 통신을 위해 계층적으로 정의되는 OSI(Open System Interconnection) 7계층 모델과 TCP/IP(transmission control protocol/Internet protocol) 4계층 모델을 나타낸다.
TCP/IP 모델은 네트워크 내에서 연결 처리를 설명하기 위한, 고전적인 OSI 모델(7개 계층)보다 간략화된 모델로서 연결 처리를 4개의 계층으로 분류한다. 상기 4개의 계층은 네트워크 인터페이스 계층(61), 인터넷 계층(62), 전송 계층(63) 및 어플리케이션 계층(64)이다. TCP/IP 모델에서의 각각의 계층은 유사한 기능과 역할의 측면에서 상기 OSI 모델과 연관된다. 예를 들어, 상기 네트워크 인터페이스 계층(61)은 OSI 모델에서는 물리층(41) 및 데이터 링크층(42)에 대응된다. 상기 인터넷 계층(62)은 OSI 모델의 네트워크층(43)에 대응되고, 상기 전송 계층(63)은 OSI 모델의 전송층(44)에 대응된다. 또한, 어플리케이션 계층(64)은 OSI 모델의 세션층(45), 표현층(46) 및 어플리케이션층(47)을 포함한 그룹에 대응된다. 이러한 TCP/IP 모델은 RFC 1122 문서에 구체적으로 정의되어 있다.
상기 TCP/IP 모델에서, 네트워크 인터페이스 계층(61)은 물리 연결 매체와 인터페이스하고, LTE(Long-Term Evolution), 802.11(WLAN), 802.3(이더넷) 또는 다른 적절한 프로토롤을 구현한다. 상기 인터넷 계층(62)은 사용자 기기가 LAN이나 WAN 내에서 상기 인터넷 계층들을 연결하기 위한 서비스를 제공한다. 상기 인터넷 계층(62)은 IPv4, IPv6나 다른 적절한 프로토콜을 구현할 수 있다. 상기 전송 계층(63)은 사용자 기기들 간의 엔드-투-엔드 연결을 수립하기 위하여 사용된다. 전송 프로토콜의 대표적인 예는 TCP 및 UDP(user datagram protocol)이다. 또한, 상기 어플리케이션 계층(64)은 일반적으로 HTTP, RTP 및 FTP(File Transfer Protocol)와 같은 통신 프로토콜을 구현한다. 여기서, HTTP는 VOD와 같은 안정적 배포 컨텐츠를 위해 일반적으로 사용되고, RTP는 실시간 컨텐츠 스트리밍을 위하여 사용되며, FTP는 대용량 저장 데이터를 비동기적으로 전송하기 위하여 사용된다. 본 발명에서, "실시간"의 의미는 미디어 서버와 미디어 스트림 재생 장치간에 시차를 최소화한, 미디어 스트림 재생 장치에서의 미디어 재생을 의미한다.
도 4는 본 발명의 일 실시예에 따른 미디어 스트림 재생 장치(100)의 구성을 도시한 블록도이다. 미디어 스트림 재생 장치(100)는 도 2에서 사용자 기기들 중에서 어느 하나로 구현될 수 있으며, 미디어 서버로부터 전송되는 미디어 스트림을 수신하여 웹브라우저 상에서 재생한다. 미디어 스트림 재생 장치(100)는 네트워크 인터페이스(120), 전송 모듈(130), 웹소켓 모듈(135), 스트리밍 모듈(140), 미디어 디코더(150), 비디오 렌더러(160), 웹브라우저(170) 및 출력 장치(180)를 포함하여 구성될 수 있다. 여기서, 웹브라우저(170)는 미디어 스트림 재생 장치에 내장된 운영 체제(OS, operating system)(미도시됨)에 근접한 레벨의 어플리케이션일 수 있다. 또한, 스트리밍 모듈(140), 미디어 디코더(150) 및 비디오 렌더러(160)는 상기 웹브라우저(170) 및 운영 체제에 의해 호스팅되는, 예를 들어 자바 스크립트에 의해 구현되는 자바 어플리케이션이다. 또한, 네트워크 인터페이스(120), 전송 모듈(130) 및 웹소켓 모듈(135)은 네트워크 통신을 위한 통신 모듈에 속하며, 장치 구현의 관점에서는 운영 체제(OS) 커널에 해당된다.
도 4를 참조하면, 먼저 네트워크 인터페이스(120)는 미디어 스트림 재생 장치(100)와 미디어 서버(200)간의 데이터 송수신을 담당하기 위해 물리 연결 매체와 인터페이스를 담당한다. 네트워크 인터페이스(120)는 도 3의 TCP/IP 모델에서 네트워크 인터페이스(61)에 대응된다. 상기 네트워크 인터페이스(120)에서 사용되는 물리 연결 매체는 LTE(Long-Term Evolution), 802.11(WLAN), 802.15.3(WPAN) 등과 같은 무선 매체와, 802.3(이더넷)와 같은 무선 매체를 포함할 수 있다.
전송 모듈(130)은 미디어 스트림 재생 장치(100)와 미디어 서버(200) 간에 데이터를 송수신하기 위한 전송 제어 기능을 담당하며 도 3의 TCP/IP 모델에서 전송 계층(63)에 대응된다. 구체적으로 전송 모듈(130)은 미디어 스트림 재생 장치(100)와 미디어 서버(200) 간에 전송 레벨 계층의 통신 연결을 수립하고, 안정적인 데이터의 송수신을 위한 전송 오류 복구, 데이터 패킷의 순차 전달 등을 담당한다. 특히, 본 발명에서 전송 모듈(130)은 미디어 스트림 재생 장치(100)와 미디어 서버(200)간의 웹소켓 연결을 전송 계층 레벨 상에서 보장하기 위한, TCP 또는 UDP 프로토콜을 지원한다. TCP는 컨텐츠를 연결 지향으로 안정적으로 배포하기 위한 프로토콜이며, UDP는 낮은 오버헤드를 갖는 끊김없는 컨텐츠의 배포를 제공하기 위한 프로토콜이다. 본 발명에서 웹소켓 프로토콜 패킷은 안정적 전송을 위해 TCP가 이용될 수 있지만 낮은 오버헤드 전송을 위해 UDP가 이용될 수도 있다.
한편, 웹소켓 모듈(135)은 상기 전송 계층 레벨의 연결을 기초로 상기 미디어 서버와 핸드쉐이크를 통해 웹소켓 연결을 수립한 후 상기 수립된 웹소켓 연결을 지속적으로 유지하면서, 상기 미디어 서버와 웹소켓 패킷을 송수신한다. 웹소켓 모듈(135)은 전송 모듈(130) 내에 구현될 수도 있고 전송 모듈(130)과 별도로 전송 모듈(130)의 상위 계층으로 구현될 수도 있다.
상기 웹소켓은 종래의 하프-듀플렉스 HTTP 통신을 개선하여 TCP 연결을 통해 양방향, 완전한 듀플렉스 통신 채널을 가능하게 하는 프로토콜이다. 상기 웹소켓 프로토콜은 IETF(Internet Engineering Task Force) 표준화 기구에 의해 RFC6455로서 표준화되었다. 다만, 상기 표준화된 웹소켓 프로토콜은 일반적인 프로토콜로서 의도된 것이며 사용자가 희망하는 확장적인 기능들은 결여되어 있으며, 새로운 기능들을 지원하기 위해 웹브라우저 내에서 자바 스크립트 등을 통해 상기 프로토콜이 확장되는 것을 허용한다.
웹소켓 연결은 두 기기 사이의 기존의 전송 계층(TCP 또는 UDP) 연결의 상부에 위치하므로, 웹 소켓 연결을 사용하기 위해서는, TCP 전송 연결이 두 기기 사이에서 먼저 수립되어야 한다. 일단 웹소켓 연결이 예를 들어, 3-way 핸드쉐이크(hand-shake) 과정을 통해 미디어 스트림 재생 장치(100)와 미디어 서버(200)간에 수립되면, 웹소켓 통신은 웹소켓 패킷들을 전송함에 의해 수행된다.
다음의 도 5는 웹소켓 연결을 통한 데이터의 송수신 과정의 일 예를 보여준다. 이러한 웹소켓 연결은 HTML5 표준인 웹소켓 프로토콜에 따라 이루어진다. 특히, 상기 웹소켓 연결은 양방향 통신을 지속적으로 지원하기 때문에, 네트워크 카메라의 웹서버와 사용자 단말 장치의 웹브라우저 간에 연결이 끊기지 않고 계속적으로 데이터를 송수신할 수 있도록 할 수 있다.
도 5를 참조하면 먼저, 미디어 스트림 재생 장치(100)는 스트림 서버(200)에 TCP/IP 연결 요청 메시지(TCP/IP connection request)을 전송하고, 스트림 서버(200)가 이를 수락하여 TCP 응답 메시지(SYN-ACK)를 미디어 스트림 재생 장치(100)에 전송하면 TCP/IP 연결이 수립된다. TCP 전송 연결은 로컬 TCP 소켓 및 원격 TCP 소켓의 페어(pair)에 의해 형성될 수 있는데, 각각의 TCP 소켓은 적어도 포트 번호와 IP 주소와 같은 식별자에 의하여 정의된다. 물론, 이러한 TCP/IP 기반의 연결 대신에 양자간에 UDP/IP 기반의 연결을 수립할 수도 있다.
이 후, 미디어 스트림 재생 장치(100)와 스트림 서버(200) 간에 핸드쉐이크 과정을 통해 양자간에 웹소켓 연결이 수립되면, 그 이후에는 양자간의 지속적인 데이터의 송수신이 가능해진다. 즉, 미디어 스트림 재생 장치(100)는 스트림 서버(200)에 통해 미디어 스트리밍 요청을 전송 웹소켓 패킷(socket.send)의 형태로 전송하고, 스트림 서버(200)는 미디어 스트림 재생 장치(100)에 미디어 스트림을 응답 웹소켓 패킷(socket.onMessage)의 형태로 전송한다. 이러한 과정은 미디어 스트림 전송이 중지되거나 완료될 때까지 지속적으로 양자간에 이루어질 수 있다.
도 6은 이와 같이 미디어 스트림 재생 장치(100)와 스트림 서버(200) 간에 송수신되는 웹소켓 패킷의 구체적인 구조를 도시한다. 이와 같이, 웹소켓의 시작 부분은 웹소켓 패킷에 포함된 데이터 구성에 관한 메타데이터 정보를 포함한다. 또한 웹소켓 패킷의 마지막 부분은 실제의 페이로드 데이터(어플리케이션 수준의 데이터)를 포함한다. 웹소켓 패킷 내의 페이로드 데이터의 위치는 페이로드 데이터의 크기와, 마스킹 키가 사용되는지 여부에 따라 달라진다. 웹소켓 패킷들은 웹소켓 통신에서 프레임화되는 통신 데이터의 기본 단위들이다. 기본적으로 웹소켓 프로토콜은 고정된 80 포트를 사용할 수 있지만 반드시 이에 한하지는 않는다. 예를 들어, 전송 레벨 보안(TLS)를 통해 터널링되는 웹소켓 연결을 위해서는 443 포트가 이용될 수도 있다.
도 3의 TCP/IP 모델에서, 상기 웹소켓 프로토콜은 어플리케이션 계층(64) 및 전송 계층(63) 사이에 위치한다. 즉, 웹소켓 프로토콜은 전송 계층(63)에 속하는 TCP나 UDP와, 어플리케이션(62)에 속하는 RTP/RTSP의 사이에 위치한다. 이를 도 4와 관련하여 설명하면, 도 4의 전송 모듈(130)은 기본적으로 TCP나 UDP와 같은 종래의 전송 계층 프로토콜 위에 웹 소켓이 프로토콜이 스택된 구조로 이루어진다.
상기 웹 소켓 통신은 적어도 상위의 어플리케이션에 대해서는 완전한 듀플렉스 통신을 제공하고, 하위의 TCP 또는 UDP 전송의 연결을 유지하면서 오버헤드를 감소시키는 것에 의해 웹브라우저와 웹서버 간의 통신을 향상시킨다. 먼저, 하프 듀플렉스이고 클라이언트 기기와 서버 기기 간에 선택적으로 송수신되는 HTTP를 통한 통신과 달리, 웹소켓을 통한 통신은 완전한 듀플렉스이고 동시에 송수신될 수 있다. 또한, 웹소켓을 통해 통신할 때 단위 메시지 당 적은 헤더 정보가 전송되어 전송시 오버헤드를 감소시킨다. 그리고, 상기 제1 기기로부터 제2 기기를 폴링하기 위해 HTTP 요청 및 응답 메시지를 교환하지 않고도 제1 기기 및 제2 기기 간의 하부 TCP 계층 연결을 유지할 수 있게 된다.
다시 도 4를 참조하면, 전송 모듈(130)에서 TCP/IP(또는 UDP/IP) 및 웹소켓 연결의 수립이 이루어지면 미디어 스트림 재생 장치(100)와 미디어 서버(200) 간에는 웹소켓 패킷을 지속적으로 송수신할 수 있는 상태가 된다. 전송 모듈(130)은 미디어 서버(200)로부터 전송된 웹소켓 패킷 형태로 패킷화된 미디어 스트림을 수신하고 이를 스트리밍 모듈(140)로 전달하거나, 스트리밍 모듈(140)로부터 전달되는 명령을 웹소켓 패킷 형태로 패킷화하여 미디어 서버(200)로 전송한다.
스트리밍 모듈(140)은, 웹브라우저(170)의 요청에 따라 미디어 서버(200)에 미디어 스트림를 실시간 전송 프로토콜로 전송할 것을 요청하고, 미디어 서버(200)로부터 상기 미디어 스트림을 포함하는 실시간 전송 프로토콜 패킷을 수신하면서, 상기 미디어 스트림의 재생을 실시간 스트리밍 프로토콜에 따라 제어한다.
이를 위해, 스트리밍 모듈(140)은 예를 들어, 기존에 알려진 RTP(Realtime Transport Protocol) 및 RTSP (Real Time Steaming Protocol)를 이용할 수 있다. RTP는 실시간 또는 저장된 영상을 전송하는 표준으로써, MJPEG, MPEG-4, H.264, H.265 등의 영상을 전송할 수 있는 프로토콜이다.
도 7은 RTP 프로토콜의 구체적인 데이터 구조를 도시한다. 도시된 바와 같이, RTP 프로토콜은 헤더 및 페이로드로 구분되며, 헤더에는 RTP 데이터 패킷의 전송 순서를 나타내는 시퀀스 번호(sequence number), 미디어의 표현하는 시간의 동기화를 위한 시간 스탬프(Timestamp), 데이터 스트림을 위한 동기화 소스를 나타내는 SSRC 식별자(Synchronization source identifier) 등이 기록된다. 이러한 RTP를 기반으로한 미디어 스트림의 패킷의 크기가 제한적이므로 상기 미디어 스트림은 소정의 크기(예: 1.5kByte)로 분할되어 전송될 수 있다(packetization). 이렇게 분할되어 전송된 패킷들은 스트리밍 모듈(140)이 수신한 후에는 다시 하나의 영상 프레임으로 합쳐지게 된다(depacketization). 또한, 하나의 음성 프레임도 마찬가지로 분할되어 전송될 수도 있지만 음성 프레임의 경우 영상 프레임보다는 데이터량이 적기 때문에 하나의 패킷 당 하나의 음성 프레임이 전송된 수도 있다.
또한, RTSP는 실시간 또는 저장된 영상을 수신하기 위하여 미디어 서버(200)(예: 네트워크 카메라)와 미디어 스트림 재생 장치(100) 사이의 네트워크 포트를 설정하고, 재생과 관련된 명령들(Play, Pause, Teardown, Setup, Option, Describe 등)을 제어하기 위한 프로토콜이다. 이 중에서 재생(Play)은 미디어 스트림을 시작하기 위해, 일시정지(Pause)는 시작된 미디어 스트림을 일시 중단하기 위해, 해체(Teardown)는 특정 미디어 세션을 해체/파괴하기 위해 사용되는 명령이다. 또한, 셋업(setup)은 미디어 세션 파라미터들을 설정하기 위해, 옵션(option)은 옵션 메쏘드 기능을 획득하고 추후 다른 버전을 허용하기 위해, 디스크라이브(describe)는 지정된 프로파일로 미디어 파라미터들을 획득하기 위해 사용되는 명령이다.
이와 같이, RTP 프로토콜은 미디어 스트림을 패킷화하여 실제로 전송하는 것을 위한 프로토콜임에 비해, RTSP 프로토콜은 이러한 전송을 시작/종료하거나 이미 전송되고 있는 미디어 스트림의 재생을 제어하기 위한 프로토콜로 사용된다.
상기 스트리밍 모듈(140)은 구체적으로, 도 8에 도시된 바와 같이, 스트리밍 세션 모듈(142), 스트리밍 클라이언트(144), 클라이언트 관리자(146) 및 디패킷화 모듈(148)을 포함하여 구성될 수 있다. 상기 스트리밍 모듈(140)을 구성하는 각각의 요소들(142, 144,146, 148)은 HTML5 표준에서 지원하는 자바 스크립트로 프로그래밍되므로, 스트리밍 모듈(140)의 기능을 웹브라우저(170) 상에서 구현하기 위한 별도의 플러그인은 필요하지 않다.
스트리밍 세션 모듈(142)은 실시간 전송 프로토콜로 전송되는 미디어 스트림을 안정적으로 수신하기 위해 미디어 서버(200) 사이에 세션을 형성한다. 이에 따라, 전송 모듈(130)은 전송되는 미디어 스트림을 수신하거나 미디어 스트림 재생 장치(100)에서 전송되는 재생 제어 명령을 전송하는 포트 역할을 할 수 있게 된다.
스트리밍 클라이언트(144)는 클라이언트 관리자(146)의 요청에 따라 새로운 스트리밍 제어를 위한 클라이언트 모듈을 생성하거나 생성된 클라이언트 모듈을 종료한다. 또한, 웹브라우저(170)로부터 요청되는 미디어 서버(200)와의 연결 명령을 수신하거나, 웹브라우저(170)로부터 미디어 스트림의 재생 명령을 수신하여 전송 모듈(130)을 통해 미디어 서버(200)에 해당 명령을 패킷화하여 전송 모듈(130)로 하여금 전송하게 하고, 미디어 서버(200)로부터 전달되는 응답(미디어 스트림)을 전송 모듈(130)을 통해 수신한다. 구체적으로, 스트리밍 클라이언트(144)는 전송 모듈(130) 내의 웹소켓 모듈(135)로부터 RTSP 패킷을 수신하여 처리하는 한편, 웹소켓 모듈(135)로부터 수신되는 RTP 패킷은 데이터 프레임(영상 프레임 또는 음성 프레임)을 생성하기 위한 버퍼링을 위해 디패킷화 모듈(148)로 전달한다.
클라이언트 관리자(146)는 웹브라우저(170)의 요청에 따라 스트리밍 클라이언트(144)에서 클라이언트 모듈을 생성하거나, 생성된 클라이언트 모듈을 제거 또는 종료(destroy)한다. 즉, 스트리밍 클라이언트(144)가 동작하기 위한 기초가 되는 클라이언트 모듈의 생성과 종료를 담당한다.
디패킷화(Depacketization) 모듈(148)은 스트리밍 클라이인터(144) 로부터 전달되는 미디어 스트림이 분할되어 있는 경우, 이를 순차적으로 버퍼(미도시됨)에 축적하였다가 조립하여(depacketization) 완전한 하나의 프레임으로 생성한다. 물론, 상기 미디어 스트림이 분할되어 있지 않으면 이러한 과정은 생략될 수 있다. 영상 스트림을 구성하는 영상 프레임은 그 크기로 인해 단일의 패킷으로 실어보내기 어렵기 때문에 분할되어 전송되는 것이 일반적이지만, 음성 프레임은 상대적으로 크기가 작기 때문에 단일의 패킷으로 실어보내는 것이 가능할 수 있다.
이와 같이, 스트리밍 모듈(140)에서 생성된 영상 프레임 및 음성 프레임은 미디어 디코더(150)에 제공된다. 미디어 디코더(150)는, MJPEG, MPEG-4, H.264, H.265 등의 영상 코딩 규격에 따라 부호화된 미디어 스트림(특히, 영상 프레임)을 복호화하는 영상 디코더를 적어도 포함하며, MP3 (MPEG layer-3), G.711, G.726, AC3(Audio Codec code 3), DTS(Digital Theatre System), FLAC(free lossless audio codec), AAC(Advanced Audio Coding) 등 음성 코딩 규격에 따라 부호화된 미디어 스트림(특히, 음성 프레임)을 복호화하는 음성 디코더를 더 포함할 수 있다. 상기 미디어 디코더(150)는 FFmpeg 기능을 포함할 수 있으며, 특히 HTML5 표준에서 지원하는 자바 스크립트로 프로그래밍된다. 따라서, 미디어 디코더(150)의 기능을 위해 별도의 플러그인은 필요하지 않다. 상기 FFmpeg은 완전한 크로스-플랫폼 솔루션으로 영상 및 음성을 변환하고 다양한 옵션을 설정할 수 있는 유연성을 제공한다. 예를 들면, 입력된 영상 프레임에 대해 FFmpeg은 비트레이트, 프레임 레이트, 표시되는 영상의 해상도(resolution), 종횡비(aspect ratio), 일부 영역 잘라내기(cropping) 등 다양한 변환 및 처리를 수행한다.
미디어 디코더(150)에서 처리되고 복원된 영상 데이터는 비디오 렌더러(160)로 입력되고 실제 디스플레이에서 표시할 수 있는 영상 신호로 변환되어 웹브라우저(170)로 입력된다. 구체적으로 비디오 렌더러(160)는 영상의 2D 또는 3D 표현을 표준적으로 정의한 응용 프로그램 인터페이스(API)로서, 각 운영 체계(OS)의 독립된 기능으로서, 투명화, 반 에일리어싱, 텍스처 매핑, 픽셀 조작 등의 영상 처리 기능을 포함한다. 이러한 비디오 렌더러(160)로는 Direct Draw, D2D, D3D, OpenGL, GDI+ 등이 알려져 있으나 이것들은 별도로 구현하기 위한 플러그인을 요하므로, 별도의 플러그인 없이 HTML 5에서 지원되는 WebGL을 이용하는 것이 바람직하다. 상기 WebGL은 웹 기반의 그래픽 라이브러리로서, 자바 스크립트 프로그래밍 언어를 통해서 구현할 수 있으며, 호환성이 있는 웹브라우저에서 인터랙티브한 3D 그래픽을 사용할 수 있도록 제공된다.
이와 같이 비디오 렌더러(160)에서 처리된 영상 신호는 웹브라우저(170) 내에 임베드되고, 이렇게 임베드된 영상이 출력 장치(180)로 전달되어 사용자가 시각으로 인지할 수 있는 영상으로 화면상에 출력된다. 상기 웹브라우저(170)는 알려진 Internet Explorer, Chrome, Firfox, Safari, Edge Browser 등으로 구현될 수 있으며 플러그인을 지원하지 않는 브라우저여도 무방하다. 상기 출력 장치(180)는 LCD, LED, OLED 등 영상을 물리적으로 표현할 수 있는 디스플레이 장치를 포함한다.
한편, 미디어 디코더(150)에서 출력되는 음성 신호는 웹브라우저(170)에서 재생가능한 오디오 신호로 변경된 형태로서, 예를 들면 HTML5표준의 IO API를 통해 웹브라우저(170)에 제공된다. 이와 같이, 영상과 동기적으로 웹브라우저(170) 내에 임베드되는 음성은 최종적으로 출력 장치(180)를 통해 사용자가 청각으로 인지할 수 있도록 출력된다. 이를 위해, 출력 장치(180)는 오디오 리시버, 앰프, 스피커 등의 음성 출력 장치를 포함할 수 있다.
도 9는 네트워크 인터페이스(120)를 통해 스트림 서버(200)와 통신하는 통신 패킷의 구조를 도시한 도면이다. 미디어 스트림(95)에 해당하는 RTP 페이로드에 RTP 헤더(94)가 부가 되면 RTP 패킷이 된다. 상기 RTP 패킷은 웹소켓 페이로드와 같으며 여기에 웹소켓 헤더(93)가 부가되어 웹소켓 패킷이 된다. 상기 웹소켓 패킷은 TCP 페이로드와 같고 여기에 TCP 헤더(92)가 부가되어 TCP 패킷이 된다. 마지막으로 상기 TCP 패킷은 IP 페이로드와 같고 여기에 IP 헤더(91)가 부가되면 최종적으로 통신 패킷, 즉 IP 패킷이 완성된다. 이와 같이 IP 패킷을 완성하는 과정 및 각각의 헤더를 제거하는 과정은 미디어 스트림 재생 장치(100)와 스트림 서버(200)에서 모두 수행된다.
이러한 IP 패킷이 네트워크 인터페이스(120)를 통해 수신되면, IP 헤더(91) 및 TCP 헤더(92)는 전송 모듈(130)에서 처리되고 TCP 페이로드 내지 웹소켓 패킷이 웹소켓 모듈(135)에 전달된다. 웹소켓 모듈(135)은 상기 웹소켓 패킷으로부터 웹소켓 헤더(93)를 처리하여 생성된 RTP 패킷을 스트리밍 모듈(140)로 전달한다. 스트리밍 모듈(140)은 상기 RTP 패킷에서 RTP 헤더(94)를 처리하여 최종적으로 미디어 스트림을 복원하게 된다. 물론, 여기서는 웹소켓 패킷을 전송하기 위한 하부 프로토콜로 TCP를 예시하였으나 상기 TCP 대신에 UDP나 HTTP 터널링을 이용할 수도 있다. 또한, 여기서는 RTP 패킷이 웹소켓 페이로드가 되는 것으로 설명하였으나, RTSP 패킷이 웹소켓 페이로드가 될 수도 있다.
이상의 도 4와 같은 미디어 스트림 재생 장치(100)에 있어서, 미디어 스트림 재생 장치(100)와 미디어 서버(200)간의 통신은 HTML5 기반의 웹소켓 프로토콜을 통해 이루어지기 때문에, RTP/RTSP 송수신 제어를 담당하는 스트리밍 모듈(140), 영상/음성의 복호화를 담당하는 미디어 디코더(150), 및 복호화된 영상의 표시 처리를 담당하는 비디오 렌더러(160)도 모두 HTML5에서 지원되는 자바 스크립트 코드에 의해 구현될 수 있다. 따라서, 종래와 같이 액티브 엑스나 NPAPI와 같은 플러그인을 별도로 설치하지 않고도 미디어의 실시간 스트리밍 및 재생이 웹브라우저 내에서 구현될 수 있는 것이다.
본 발명의 일 실시예에 따라 RTSP 제어를 위한 웹소켓 프로그램을 자바 스크립트로 구현하면 예를 들어 다음의 표 1 및 2와 같은 의사 코드로 표현될 수 있다(표 2는 표 1에서 계속된 내용임).
var META = 0,
VIDEO = 1,
AUDIO = 2,
AUDIO_BACKUP = 3,
RTCP_VIDEO = 4;
RTCP_AUDIO = 5;
RTCP_META = 6;

var RtspClient = function () {
// RTSP Client
// RTSP Command Parsing
// OPTIONS, TEARDOWN, GET_PARAMETERS, SET_PARAMETERS, DESCRIBE, SETUP, PLAY, STOP
var CommandConstructor = function (method, requestURL, extHeader) {
switch (method) {
case 'OPTIONS':
// OPTIONS Reaction
case 'TEARDOWN':
// TEARDOWN Reaction
case 'GET_PARAMETER':
// GET_PARAMETER Reaction
case 'SET_PARAMETERS':
// SET_PARAMETERS Reaction
case 'DESCRIBE':
// DESCRIBE Reaction
case 'SETUP':
// SETUP Reaction
case 'PLAY':
// PLAY Reaction
case 'PAUSE':
// PAUSE Reaction
default:
break;
}
isReceive = false;
return sendMessage;
};

var parseDescribeResponse = function (message1) {
// DESCRIBE Operation
// SDP Parsing
return SDPData;
}
var parseRtspResponse = function (message1) {
// RTSP Response Operation
// Error or OK
return RtspResponseData;
}
var formDigestAuthHeader = function (stringMessage, method) {
// Authentication
};
var RtspResponseHandler = function (stringMessage) {
// RTSP Response Handler
// Error Code Handling
};
var RtpDataHandler = function (rtspinterleave, rtpheader, rtpPacketArray) {
// RTP Data Handling
// Depacketization
};
var connectionCbFunc = function (type, message) {
// Connection Callback
};
module.SetMetaCallback = function (metaCallbackFunc) {
// Metadata Callback
};
module.SetH264VideoCallback = function (videoCallbackFunc) {
// H.264 Callback
};
module.SetH265VideoCallback = function (videoCallbackFunc) {
// H.265 Callback
};
module.SetMjpegVideoCallback = function (videoCallbackFunc) {
// MJPEG Callback
};
module.SetG711AudioCallback = function (audioCallbackFunc) {
// G.711 Audio Callback
};
module.SetG726AudioCallback = function (audioCallbackFunc) {
// G.726 Audio Callback
};
module.SetAACAudioCallback = function (audioCallbackFunc) {
// AAC Audio Callback
};
...
return module;
};
도 10은 도 3의 미디어 스트림 재생 장치(100)와 통신하는 미디어 서버(200)의 구성을 도시한 블록도이다. 미디어 서버(200)는 네트워크 인터페이스(220), 웹서버(230), 미디어 서버(240), 미디어 스토리지(250)를 포함하며, 미디어 인코더(260)와 캡쳐 장치(270)를 더 포함할 수 있다.
캡쳐 장치(270)는 입력되는 영상과 음성을 전기적인 신호(아날로그 신호 또는 디지털 신호)의 형태로 변환하고 영상 신호 및 음성 신호를 생성하여 미디어 인코더(260)에 전달한다. 미디어 인코더(260)는 미디어 디코더(150)에 대응되는 요소로서 입력된 영상 신호를 MJPEG, MPEG-4, H.264, H.265 등의 영상 코딩 규격에 따라 부호화하는 영상 인코더를 적어도 포함한다. 마찬가지로, 미디어 인코더(260)는 입력된 음성 신호를 MP3, G.711, G.726, AC3, DTS, FLAC, AAC 등 음성 코딩 규격에 따라 부호화하는 음성 인코더를 더 포함할 수 있다.
이와 같은 과정을 통해, 미디어 인코더(260)에서 생성되는 미디어 스트림은 미디어 스토리지(250)에 저장된다. 미디어 스토리지(250)는 휘발성, 비휘발성 매체인지를 불문하며, 자기장 저장 매체, 광 저장 매체, 하드디스크 드라이브, SSD(Solid State Drive), 플래시 메모리 등 매체의 물리적 종류를 불문한다. 미디어 스토리지(250)는 미디어 인코더(260)에서 생성된 미디어 스트림을 장기간 저장하거나 미디어 서버(240)의 스트리밍을 지원하기 위한 용도로 일시적으로 저장할 수도 있다.
미디어 서버(240)는 미디어 스토리지(250)로부터 제공되는 미디어 스트림을 네트워크 상에서 전송할 수 있는 미디어 스트림의 형태로 변환한다. 이를 위하여, 미디어 서버(240)는 RTP/RTSP 프로토콜을 지원한다. 예를 들어, 미디어 서버(240)는 미디어 스트림 재생 장치(100)로부터 전달되는 RTSP 패킷에 기초하여, RTP 패킷을 생성하고 미디어 스트림 재생 장치(100)로의 전송을 제어한다. 이러한 RTP 패킷은 도 6에 도시된 바와 같이 구성될 수 있다.
웹서버(230)는 미디어 스트림 재생 장치(100)에 의해 획득되는 웹 컨텐츠를 호스팅한다. 이 때, 어떠한 종류의 데이터 및 서비스도 웹서버(230)에 의해 제공될 수 있다. 따라서, 미디어 스트림 재생 장치(100)의 웹브라우저(170)는 웹서버(230)에 의해 적어도 부분적으로 제공되는 서비스나 컨텐츠에 접근할 수 있게 된다. 특히, 웹서버(230)는 웹소켓 프로토콜을 사용하여 미디어 스트림 재생 장치(100)의 요청과 연결을 처리할 수 있다.
구체적으로, 웹서버(230)는, 미디어 스트림 재생 장치(100)에 웹소켓 기반으로 미디어 스트림(미디어 서버(240)에서 생성된 RTP 패킷)을 전송한다. 이를 위해, 웹서버(230)는 HTML5 기반의 양방향 통신용 기술 규격인 웹소켓 프로토콜과, 상기 웹소켓 프로토콜에 따른 웹소켓 패킷(도 7에 도시됨)을 실어 보내기 위한 하위 프로토콜인 TCP/IP(또는 UDP/IP)를 지원한다. 웹서버(230)는 기본적으로 어떠한 종류여도 상관없으나, 네트워크 카메라와 같이 고사양을 구비하기 어려운 환경을 고려하여, lighttpd와 같이 용량이 작고 적은 리소스를 요하는 종류를 이용하는 것이 바람직하다.
한편, 미디어 서버(240)와 웹서버(230) 사이에 프록시 소켓(235)을 추가로 배치할 수도 있다. 웹서버(230)와 미디어 스트림 재생 장치(100)의 웹브라우저(170) 간의 웹소켓 연결이 수립되면, 웹서버(230)는 웹소켓 연결을 프록시 소켓(235)에 전달한다. 이 때, 프록시 소켓(235)은 그 연결 방식에 상관없이 정해진 소켓을 통해 미디어 서버(240)와 웹서버(230) 간의 데이터 송수신을 중계한다. 따라서, 이러한 프록시 소켓(235)을 이용하면, 미디어 서버(240)는 상기 연결이 통상의 UDP, TCP인지, WS/TCP(TCP 기반의 웹소켓), WS/UDP(UDP 기반의 웹소켓)인지, 또는 접속 포트가 무엇인지 상관없이 정해진 소켓 모듈을 통해 데이터를 송수신할 수 있다. 기본적으로 웹소켓 은 TCP 연결의 HTTP 기반이기 때문에 프록시 소켓(235)은 TCP 소켓을 기준으로 할 수 있다. 이를 위하여, 프록시 소켓(235)은 미디어 서버(200)에 의해 전송되는 통신을 미디어 스트림 재생 장치(100)에 전송될 웹소켓 패킷으로 인코드하고, 미디어 스트림 재생 장치(100)로부터 수신된 웹소켓 패킷을 미디어 서버(200)가 원하는 데이터 포맷으로 디코드하는 기능을 갖는다.
네트워크 인터페이스(220)는 미디어 스트림 재생 장치(100)와 네트워크 인터페이스(120)와 대응되며, 미디어 스트림 재생 장치(100)와의 데이터 송수신을 담당하기 위해 물리 연결 매체와의 인터페이스를 담당한다. 네트워크 인터페이스(220)는 도 3의 TCP/IP 모델에서 네트워크 인터페이스(61)에 대응된다. 상기 네트워크 인터페이스(220)에서 사용되는 물리 연결 매체는 LTE(Long-Term Evolution), 802.11(WLAN), 802.15.3(WPAN) 등과 같은 무선 매체와, 802.3(이더넷)와 같은 무선 매체를 포함한다.
지금까지 도 2, 도 8 및 도 10의 각 구성요소들은 메모리 상의 소정 영역에서 수행되는 태스크, 클래스, 서브 루틴, 프로세스, 오브젝트, 실행 쓰레드, 프로그램과 같은 소프트웨어(software)나, FPGA(field-programmable gate array)나 ASIC(application-specific integrated circuit)과 같은 하드웨어(hardware)로 구현될 수 있으며, 또한 상기 소프트웨어 및 하드웨어의 조합으로 이루어질 수도 있다. 상기 구성요소들은 컴퓨터로 판독 가능한 저장 매체에 포함되어 있을 수도 있고, 복수의 컴퓨터에 그 일부가 분산되어 분포될 수도 있다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능하다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.
다음의 도 11 내지 13은 본 발명의 일 실시예에 따라 스트리밍 모듈(140) 및 웹소켓 모듈(135)에서 미디어 서버(200)와 RTSP 제어 및 RTP 전송을 구현한 시퀀스도이다. 스트리밍 클라이언트(144)는 RTSP 클라이언트 인스턴스 생성과 RTSP 프로파일 정보를 담당하고, 인증 정보도 스트리밍 클라이언트(144)에 의해 관리된다. 웹소켓 모듈(135)은 웹소켓과 관련된 기능들을 담당하는데, 스트리밍 클라이언트(144)에 의한 RTSP 명령을 전송하고 그 응답을 수신하기 위해 상기 웹소켓이 이용된다. 스트리밍 클라이언트(144) 내에서, 연결 방법의 순서는 전체적으로, 1) 전송 모듈의 초기화, 2) RTSP 응답 및 RTP 응답 콜백들의 등록, 3) 디스크립션(단말 장치의 기능, 속성, 사양 등의 정보) 명령의 전송, 4) RTP 세션의 초기화 및 셋업 명령의 전송 순서이다. 도 11 내지 13에서 실선으로 표시된 화살표는 특정 명령을 의미하고, 이어서 점선으로 표시된 화살표는 상기 명령에 대한 응답 내지 Ack를 의미한다.
도 11은 이 중에서, 스트리밍 모듈(140)과 미디어 서버(200) 간의 RTSP 셋업 과정을 나타낸다. 먼저, 웹브라우저(170)가 RTSP 클라이언트를 생성하기 위해 클라이언트 관리자에게 요청하면(S1: Create RtspClient), 클라이언트 관리자(146)는 스트리밍 클라이언트(144)에 새로운 RTSP 클라이언트를 생성하게 한다(S2: new RtspClient). 이와 같이 새로운 RTSP 클라이언트가 생성된 후, 웹브라우저(170)는 스트리밍 클라이언트(144)에 대해 RTSP URL을 설정하고 인증을 수행한다(S5: Set RtspURL, Authentication). 이로서, 웹브라우저는 미디어 서버(200)와 데이터를 송수신할 수 있는 기본적인 상태가 된다.
웹브라우저(170)가 스트리밍 클라이언트(144)에게 미디어 서버와의 연결을 요청하면(S7: Connect), 스트리밍 클라이언트(144)는 웹소켓 모듈(135)에게 새로운 전송을 요청하면서(S9: new Transport), 콜백을 설정한다(S11: Set callback). 또한, 스트리밍 클라이언트(144)가 웹소켓 모듈(135)에 RTSP 명령을 전송하면(S13: Send RtspCommand), 웹소켓 모듈(135)은 미디어 서버에 디스크립션 명령을 전송한다(S14: Describe command). 이후, 스트리밍 클라이언트(144)가 웹소켓 모듈(135)에 후속 RTSP 명령을 전송하면(S18: Send RtspCommand), 웹소켓 모듈(135)은 미디어 서버에 셋업 명령을 전송한다(S19: Setup command). 이에 따라, 미디어 서버(200)로부터 웹소켓 모듈(135)에 셋업 응답이 수신되면(S21: setup Response), 웹소켓 모듈(135)은 스트리밍 클라이언트(144)에 RTSP 응답을 전송한다(S22: RtspResponse).
이 후, 스트리밍 클라이언트(144)가 RTSP 세션의 생성 명령을 스트리밍 세션 모듈(142)에 전송하면서(S24: Create RtspSession), 콜백을 설정하고(S26: Set Callback), 웹브라우저(170)에 콜백 연결 완료를 알리면(S28: OnConnectedCallback), 스트리밍 모듈(140)과 미디어 서버(200)간의 RTSP 셋업 과정이 완성되고, 이후부터는 양자 간의 RTP 데이터를 웹소켓 상에서(over websocket) 송수신하는 것이 가능하게 된다.
도 12는 도 11의 셋업 과정 이후에 스트리밍 모듈(140)이 미디어 서버(200)로부터 RTP 데이터를 수신하는 과정을 나타낸다. 먼저, 웹브라우저(170)가 스트리밍 클라이언트(144)에게 미디어 접속 명령을 전송하면(S30: OpenMedia), 스트리밍 클라이언트(144)는 웹소켓 모듈(135)에 RTSP 명령을 전송한다(S32: SendRtspCommand). 그러면, 웹소켓 모듈(135)은 미디어 서버(200)에 미디어 재생 명령을 전송한다(S33: Play Command). 이 후, 스트리밍 클라이언트(144)가 웹소켓 모듈(135)로부터 RTSP 응답을 수신하면(S35: RtspRespond), 웹브라우저(170)에 미디어 오픈이 가능한 상태가 되었음을 알린다(S37: OnOpenMedia).
한편, 미디어 서버(200)는 S33의 재생 명령에 따라 웹소켓 모듈(135)에 RTP 데이터 전송을 수행한다(S30: RTP Data->OnReceive). 이 때, 웹소켓 모듈(135)은 스트리밍 세션 모듈(142)에 RTP 데이터를 전달하고(S40: SendRtpData), 스트리밍 세션 모듈(142)은 웹브라우저(170)에 RTP 데이터에 포함되는 미디어 스트림(미디어 프레임)를 웹브라우저(170)에 전송한다(S41: OnFrameRecv). 이상과 같은 도 12의 과정에서 특정 RTP 데이터의 스트리밍 중에라도, 스트리밍 클라이언트(144)가 RTSP 명령을 미디어 서버(200)에 전송함에 따라 RTP 데이터의 제어(재생, 일시정지 등)를 할 수 있다.
도 12와 같은 RTP 데이터의 스트리밍이 완료되고 스트리밍 모듈(140)과 미디어 서버(200)간에 더 이상의 연결이 불필요한 경우, 도 13과 같은 접속 종료 과정이 수행될 수 있다. 먼저, 웹브라우저(170)가 스트리밍 클라이언트(144)에 RTSP를 종료하는 명령을 전달하면(S44: CloseRtsp), 스트리밍 클라이언트(144)는 웹소켓 모듈(135)에 RTSP 명령을 전송한다(S46: SendRtspCommand). 이에 따라 웹소켓 모듈(135)이 미디어 서버(200)에 해체 명령을 전송하고(S47: SendTeardown), 미디어 서버(200)로부터 Ack를 수신한다(S48).
웹소켓 모듈(135)이 스트리밍 클라이언트(144)에 Rtsp 응답 메시지를 전송하면(S49: RtspResponse), 스트리밍 클라이언트(144)는 웹브라우저(170)에 미디어 스트리밍의 오픈을 종료하는 명령을 전송한다(S50: Onclose). 이후, 웹브라우저(170)는 클라이언트 관리자(146)에게 이미 생성된 Rtsp 클라이언트를 제거하는 명령을 전송하면(S53: RemoveRtspClient), 클라이언트 관리자(146)는 스트리밍 클라이언트(144)에 Rtsp 클라이언트의 제거(destroy) 명령을 전송하면서(S54: destroy), 스트리밍 모듈(140)과 미디어 서버(200)간의 모든 연결은 종료된다.
이상에서 설명한 바와 같이 본 발명에 따르면, 웹브라우저(170)에 플러그인을 설치하지 않고서도 네트워크 카메라와 같은 미디어 서버(200)로부터 미디어를 실시간으로 스트리밍할 수 있다. 그러나, 사용자의 선택에 따라 플러그인의 설치를 통해 전용의 웹 뷰어 방식으로 미디어를 스트리밍하는 방식과, 플러그인 없이 미디어 스트리밍하는 방식을 혼합한 하이브리드 방식도 가능하다. 이러한 실시에에 따르면, 사용자가 미디어 스트림 재생 장치(100)로부터 미디어 서버(200)에 접근하면, 미디어 서버(200)는 웹서버(230)를 통해 사용자 환경정보(웹브라우저 버전, 사용자 장치의 해상도 등)을 확인할 수 있고, 사용자 환경이 플러그인 설치가 가능한 환경인지를 체크할 수 있다. 만약, 상기 사용자 환경이 플러그인 설치가 가능한 환경이라면 웹서버(230)는 웹브라우저(170)에 플러그인 설치 여부를 확인하는 웹페이지를 제시하고 사용자의 선택을 받을 수 있다. 사용자가 플러그인 설치를 선택하면, 사용자는 웹서버(230)로부터 웹 뷰어를 다운로드 받아 웹브라우저(170) 상에 설치하고 종래와 같이 설치된 웹 뷰어를 이용하면 된다. 반면에, 사용자가 플러그인 설치를 원하지 않으면, 플러그인 없이도 본 발명에 따른 미디어 스트림 재생 방법에 따라 미디어 스트리밍을 제어하면서 영상/음성을 재생할 수 있다.
이상 첨부된 도면을 참조하여 본 발명의 실시예를 설명하였지만, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야 한다.
100: 미디어 스트림 재생 장치 120, 220: 네트워크 인터페이스
130: 전송 모듈 135: 웹소켓 모듈
140: 스트리밍 모듈 142: 스트리밍 세션 모듈
144: 스트리밍 클라이언트 146: 클라이언트 관리자
148: 디패킷화 모듈 150: 미디어 디코더
160: 비디오 렌더러 170: 웹브라우저
180: 출력 장치 200: 미디어 서버
230: 웹서버 235: 프록시 소켓
240: 미디어 서버 250: 미디어 스토리지
260: 미디어 인코더 270: 캡쳐 장치

Claims (10)

  1. 미디어 서버로부터 전송되는 미디어 스트림을 수신하여 웹브라우저 상에서 재생하는 미디어 스트림 재생 장치로서,
    상기 미디어 서버와 전송 계층 레벨의 통신 연결을 수립하는 전송 모듈;
    상기 전송 계층 레벨의 연결을 기초로 상기 미디어 서버와 핸드쉐이크를 통해 웹소켓 연결을 수립한 후 상기 수립된 웹소켓 연결을 지속적으로 유지하면서, 상기 미디어 서버와 웹소켓 패킷을 송수신하는 웹소켓 모듈;
    상기 웹소켓 패킷에 의해 운반되는 실시간 전송 프로토콜 패킷을 수신하는 스트리밍 모듈;
    상기 실시간 전송 프로토콜 패킷으로부터 얻어지는 상기 미디어 스트림을 디코드 하여 영상을 복원하는 미디어 디코더; 및
    상기 복원된 영상을 상기 웹브라우저에 임베드하여 화면 상에 표시하는 출력 장치를 포함하는 미디어 스트림 재생 장치.
  2. 제1항에 있어서, 상기 스트리밍 모듈은
    상기 미디어 서버와, 상기 실시간 전송 프로토콜 패킷의 전송을 제어하기 위한 실시간 스트리밍 프로토콜 패킷을 송수신하는 미디어 스트림 재생 장치.
  3. 제1항에 있어서,
    상기 웹브라우저는 HTML5 표준을 지원하는 미디어 스트림 재생 장치.
  4. 제1항에 있어서,
    상기 미디어 디코더에서 복원된 영상을 상기 출력 장치로 전달하기 전에 상기 출력 장치의 출력에 적합하도록 영상 처리를 수행하는 비디오 렌더러를 더 포함하는 미디어 스트림 재생 장치.
  5. 제4항에 있어서,
    상기 스트리밍 모듈, 상기 미디어 디코더 및 상기 비디오 렌더러는, 상기 웹브라우저에 별도로 설치되는 플러그인 프로그램 없이, 자바 스크립트에 의해 구현되는 미디어 스트림 재생 장치.
  6. 제5항에 있어서,
    상기 미디어 디코더는 상기 자바 스크립트로 구현된 FFmpeg을 포함하고, 상기 비디오 렌더러는 상기 자바 스크립트로 구현된 WebGL을 포함하는 미디어 스트림 재생 장치.
  7. 제1항에 있어서,
    상기 미디어 디코더는 상기 미디어 스트림을 디코드 하여 상기 영상과 함께 음성을 복원하는 미디어 스트림 재생 장치.
  8. 제1항에 있어서,
    상기 웹소켓 패킷은 웹소켓 헤더와, 상기 웹소켓 헤더와 인접하여 후속하는 실시간 전송 프로토콜 헤더와, 상기 실시간 전송 헤더와 인접하여 후속하는 상기 미디어 스트림으로 구성되는 미디어 스트림 재생 장치.
  9. 제1항에 있어서,
    상기 미디어 서버는 영상을 실시간으로 캡쳐하여 상기 미디어 스트림 재생 장치에 제공하는 네트워크 카메라인 미디어 스트림 재생 장치.
  10. 제1항에 있어서, 상기 스트리밍 모듈은
    상기 실시간 전송 프로토콜로 전송되는 상기 미디어 스트림을 안정적으로 수신하기 위해 상기 미디어 서버와의 통신 세션을 형성하는 스트리밍 세션 모듈;
    상기 실시간 전송 프로토콜 패킷을 수신하고, 상기 실시간 전송 프로토콜의 전송 제어를 위해 상기 미디어 서버와 실시간 스트리밍 프로토콜 패킷을 송수신하는 스트리밍 클라이언트;
    상기 웹브라우저의 요청에 따라 상기 스트리밍 클라이언트 내에 클라이언트 모듈을 생성하거나 제거하는 클라이언트 관리자; 및
    상기 미디어 스트림을 버퍼에 축적하고 축적된 미디어 스트림을 조립하여 적어도 하나의 영상 프레임을 생성하는 디패킷화 모듈을 포함하는 미디어 스트림 재생 장치.
KR1020160069468A 2016-04-04 2016-06-03 웹브라우저 상에서 미디어 스트림을 재생하는 방법 및 장치 KR101821124B1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US15/393,936 US10412130B2 (en) 2016-04-04 2016-12-29 Method and apparatus for playing media stream on web browser
EP17150632.2A EP3229476B1 (en) 2016-04-05 2017-01-09 Method and apparatus for playing media stream on web browser
CN201710112610.4A CN107277612B (zh) 2016-04-05 2017-02-28 用于在web浏览器上播放媒体流的方法和设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20160041426 2016-04-05
KR1020160041426 2016-04-05

Publications (2)

Publication Number Publication Date
KR20170114219A true KR20170114219A (ko) 2017-10-13
KR101821124B1 KR101821124B1 (ko) 2018-01-23

Family

ID=60139668

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020160069468A KR101821124B1 (ko) 2016-04-04 2016-06-03 웹브라우저 상에서 미디어 스트림을 재생하는 방법 및 장치

Country Status (1)

Country Link
KR (1) KR101821124B1 (ko)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113556612A (zh) * 2021-07-15 2021-10-26 中国电子科技集团公司第五十二研究所 一种浏览器上播放h.265视频流的方法及系统
CN113709518A (zh) * 2021-08-24 2021-11-26 天津津航计算技术研究所 一种基于rtsp协议的视频实时传输模式设计方法
CN113938656A (zh) * 2021-10-27 2022-01-14 南京工业大学 一种浏览器无插件低延迟播放网络监控摄像头视频方法
CN115589399A (zh) * 2022-10-11 2023-01-10 北京太格时代自动化系统设备有限公司 变电所辅助监控视频远程播放方法和装置
CN117097705A (zh) * 2023-10-21 2023-11-21 北京蔚领时代科技有限公司 一种基于WebTransport的音视频传输方法和系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6771264B1 (en) 1998-08-20 2004-08-03 Apple Computer, Inc. Method and apparatus for performing tangent space lighting and bump mapping in a deferred shading graphics processor
JP2016517642A (ja) * 2013-03-08 2016-06-16 ▲華▼▲為▼終端有限公司Ｈｕａｗｅｉ Ｄｅｖｉｃｅ Ｃｏ．， Ｌｔｄ． ビデオ通信方法、ホーム端末及びホームサーバ
US9930308B2 (en) * 2014-07-26 2018-03-27 Clipchamp Ip Pty Ltd Platform-agnostic video player for mobile computing devices and desktop computers

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113556612A (zh) * 2021-07-15 2021-10-26 中国电子科技集团公司第五十二研究所 一种浏览器上播放h.265视频流的方法及系统
CN113709518A (zh) * 2021-08-24 2021-11-26 天津津航计算技术研究所 一种基于rtsp协议的视频实时传输模式设计方法
CN113709518B (zh) * 2021-08-24 2023-11-28 天津津航计算技术研究所 一种基于rtsp协议的视频实时传输模式设计方法
CN113938656A (zh) * 2021-10-27 2022-01-14 南京工业大学 一种浏览器无插件低延迟播放网络监控摄像头视频方法
CN115589399A (zh) * 2022-10-11 2023-01-10 北京太格时代自动化系统设备有限公司 变电所辅助监控视频远程播放方法和装置
CN115589399B (zh) * 2022-10-11 2023-06-27 北京太格时代电气股份有限公司 变电所辅助监控视频远程播放方法和装置
CN117097705A (zh) * 2023-10-21 2023-11-21 北京蔚领时代科技有限公司 一种基于WebTransport的音视频传输方法和系统

Also Published As

Publication number Publication date
KR101821124B1 (ko) 2018-01-23

Similar Documents

Publication Publication Date Title
CN107277612B (zh) 用于在web浏览器上播放媒体流的方法和设备
KR101821123B1 (ko) 웹브라우저 상에서 미디어 스트림을 재생하는 방법 및 장치
US10219010B2 (en) Selective media playing method and apparatus according to live streaming and recorded streaming
US20220263885A1 (en) Adaptive media streaming method and apparatus according to decoding performance
KR101821124B1 (ko) 웹브라우저 상에서 미디어 스트림을 재생하는 방법 및 장치
US10979785B2 (en) Media playback apparatus and method for synchronously reproducing video and audio on a web browser
US11089349B2 (en) Apparatus and method for playing back and seeking media in web browser
US20160119399A1 (en) Extending browser support of real time media to any available codec
CN107819809B (zh) 对内容进行同步操作的方法及装置
KR101942269B1 (ko) 웹 브라우저에서 미디어를 재생하고 탐색하는 장치 및 방법
WO2016200520A1 (en) Tunneling hdmi data over wireless connections
US11089381B2 (en) Apparatus and method for simultaneous playback and backup of media in a web browser
WO2024022317A1 (zh) 视频流的处理方法及装置、存储介质、电子设备
CN114339146B (zh) 音视频监控方法、装置、电子设备及计算机可读存储介质
WO2016199609A1 (ja) 情報処理装置および情報処理方法
US20220182732A1 (en) Systems and Methods of Alternative Networked Application Services
US11265357B2 (en) AV1 codec for real-time video communication
TWI718957B (zh) 遠端即時影像支援系統與方法
WO2024087938A1 (zh) 一种媒体直播方法、装置及电子设备
CN117939199A (zh) 一种直播方法、装置、电子设备及可读存储介质
JP2008270968A (ja) 画像処理システム、画像処理装置、画像処理方法、およびプログラム
Zhang et al. Integrated Civil Monitoring System Based on POSA
de Popaydn Testing environment for video streaming support using open source tools

Legal Events

Date Code Title Description
A201 Request for examination
A302 Request for accelerated examination
AMND Amendment
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
AMND Amendment
X701 Decision to grant (after re-examination)
GRNT Written decision to grant