WO2019189988A1

WO2019189988A1 - Html5 realtime player and realtime playback method using same

Info

Publication number: WO2019189988A1
Application number: PCT/KR2018/004999
Authority: WO
Inventors: 강용일; 배상규
Original assignee: (주)디디오넷
Priority date: 2018-03-30
Filing date: 2018-04-30
Publication date: 2019-10-03

Abstract

The present invention relates to an HTML5 realtime player. According to the present invention, an HTML5 realtime player having a web browser installed comprises: a request unit for requesting, to a streaming server, a playback of media data; a reception unit for receiving, from the streaming server, in streaming units, the media data to which playback metadata is inputted; a buffer for accumulating the received media data; a conversion unit for converting T1 length of data into a segmented MP4 format in realtime each time the media data is accumulated in the buffer by the length of T1; a transmission unit for transmitting the converted T1 length of data to a web browser via a standard API; and a playback unit for starting the playback of T2 length of data by operating a codec embedded in the web browser, if the amount of transmitted data reaches the length of T2. According to the present invention, only around 2-3 seconds of playback delay occurs, as the media data is divided into 0.5-1 second units directly by the player, converted into segmented MP4, accumulated on the web browser by 2-3 second amounts, and then played.

Description

HTML5 Real Time Player and Real Time Playback Method Using It

The present invention relates to an HTML5 real time player and a real time playback method using the same, and to an HTML5 real time player capable of reducing a playback delay time and a real time playback method using the same.

The current HTML5 real-time player uses DASH or HLS, a standard streaming protocol that supports HTTP-based streaming. DASH is an HTTP-based adaptive multimedia streaming protocol standardized by MPEG, and HLS represents an HTTP-based streaming protocol proposed by Apple.

These protocols are driven in a request & reply manner, and have a structure in which requests and responses are repeated continuously over time. The streaming server transmits a segmented file (Segemented TS or Segmented mp4) which segmented the media data by about 2 seconds to the player.

Here, the player can start playing the media data after receiving about three segmented files from the streaming server. However, no matter how short the segmentation file is, the second unit is the shortest unit, and the unit below it causes a large decrease in reproduction quality.

In addition, it takes 6 seconds to receive 3 files of 2 seconds in the player, which means that the data starts to be played after a 6 second delay after the playback request. Due to this delay problem, HTML5 real-time player is not used in CCTV that requires fast real-time monitoring.

The background technology of the present invention is disclosed in Korean Patent Laid-Open No. 2016-0036924 (published on April 5, 2016).

An object of the present invention is to provide an HTML5 real time player capable of minimizing a playback delay time and a real time playback method using the same.

According to an aspect of the present invention, there is provided an HTML5 real-time player equipped with a web browser, including: a requesting unit for requesting playback of media data to a streaming server, a receiving unit for receiving the media data in which playback meta information is inserted from the streaming server in units of streams, and the reception unit. A buffer for accumulating the stored media data, and a conversion unit for converting the data of the T1 length into a segmented MP4 format in real time whenever the media data is accumulated in the buffer in a first time (T1) length unit; A transmission unit for transmitting the converted T1 length data to the web browser through a standard API, and when the amount of the transmitted data meets the second time T2 length, the codec embedded in the web browser is operated. An HTML5 real time player including a playback unit for starting playback of the T2 length data is provided.

The playback unit may play the data of the T2 length by operating the codec whenever the amount of data transmitted to the web browser satisfies the T2 length.

In addition, the T2 may be an N multiple of the T1 (N is an integer of 2 or more).

In addition, the T1 ranges from 0.5 seconds to 1 second, and the T2 ranges from 2 seconds to 3 seconds.

In addition, the standard API is Media Source Extensions (MSE) corresponding to a JavaScript API for HTML5, and the MSE may be mounted in the web browser.

In addition, the playback delay time of the media data may be generated by the length of the T2.

The present invention provides a method of real-time playback of an HTML5 real-time player equipped with a web browser, the method comprising: requesting playback of media data from a streaming server, and converting the media data into which the playback metadata is inserted from the streaming server on a stream basis. Receiving, accumulating the received media data in the buffer, and each time the media data is stored in the buffer in the unit of the first time (T1) length unit, the data of the T1 length segmented MP4 (Segmented Real time conversion to MP4) format, transferring the converted T1 length data to the web browser through a standard API, and if the amount of the transferred data meets the second time T2 length, Operating a codec embedded in a web browser to start playback of the T2 length data. The ball.

The real-time reproduction method may further include reproducing the data of the T2 length by operating the codec whenever the amount of data transmitted to the web browser satisfies the T2 length.

According to the present invention, the media data requested by the streaming server is directly divided by the player in 0.5 to 1 second unit, converted into segmented MP4, and the converted data is accumulated and reproduced for 2 to 3 seconds on a web browser, thereby, about 2 to Only a 3 second playback delay occurs, and data can be stably streamed without being disconnected from the streaming server.

1 is a diagram illustrating an HTML5 real time playback system according to an embodiment of the present invention.

FIG. 2 is a diagram showing the configuration of the player shown in FIG.

FIG. 3 is a diagram for explaining a real-time playback method using the player shown in FIG. 2.

4 is a diagram comparing network usage of the system of FIG. 1 and the conventional system.

DETAILED DESCRIPTION Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present disclosure.

1 is a diagram illustrating an HTML5 real time playback system according to an embodiment of the present invention. As shown in FIG. 1, the HTML5 real time playback system includes a streaming server 100 and a player 200.

The streaming server 100 and the player 200 are connected through a wired or wireless network.

The player 200 may refer to a general user terminal including a smart phone, a PDA, a desktop, a pad (PAD), a notebook, and the like, and a web browser supporting HTML5 is installed. Here, of course, the player 200 may be implemented in a form included in or embedded in the user terminal.

When the streaming server 100 receives a request for playing media data such as video and audio from the player 200, the streaming server 100 transmits the requested media data in units of streams in real time.

The streaming server 100 attaches the play meta information to the front of the media data and sends it. In this case, the reproduction meta information may include at least one of TimeStamp (Time Stamp), Payload Size (Payload Size), Data Type (Data Type such as Video / Audio), and Counter (Counter Information).

In general, the time stamp may indicate time information on which data is scattered on the reproduction screen, and the counter information may indicate information that counts a situation in which a break occurs in case the data reproduction is stopped and retransmission is required. Of course, since the above-described reproduction meta information corresponds to a known one, a detailed description thereof will be omitted.

When the streaming server 100 delivers the media data to the player 200, the streaming server 100 continuously delivers the media data. At this time, the streaming server 100 does not transmit the media data in units of segments as in the HTTP-based protocol (HLS or DASH), but in units of streams.

In the case of the HTTP protocol, the process of connecting, requesting, sending and terminating must be repeated in order to reproduce data. In contrast, in the exemplary embodiment of the present invention, the player 200 may perform only one request to the streaming server 100, and the streaming server 100 may continue to send only the request after the request.

Therefore, the streaming server 100 continuously transmits the media data in units of streams after receiving the request for playing the media data from the player 200. Accordingly, the player 200 continuously receives data from the streaming server 100 after requesting data once, and processes and reproduces the received data in real time.

FIG. 2 is a diagram illustrating a configuration of a player illustrated in FIG. 1, and FIG. 3 is a diagram illustrating a real-time reproduction method using the player illustrated in FIG. 2.

2 and 3, the player 200 includes a request unit 210, a receiver 220, a buffer 230, a converter 240, a transfer unit 250, and a playback unit 260. .

First, the request unit 210 requests the streaming server 100 to play media data (S310).

For example, the requesting unit 210 receives (selects) a playback button for media data such as audio and video provided by an application (YouTube, Naver Player, Melon Player, etc.) accessed through a web browser. You can request a regeneration through it.

The streaming server 100 inserts play meta information in front of the media data and sends the stream in real time in units of streams. Accordingly, the receiver 220 receives the media data in which the play metadata is inserted from the streaming server 100 in units of streams (S320).

The buffer 230 accumulates the received media data according to time (S330). Here, the buffer 230 may collect and accumulate the received media data stream in units of a first time T1 length, and may immediately transfer the accumulated T1 length data to the converter 240.

The buffer 230 may continue to repeat the above operation until the transmission of the media data as temporary storage is terminated. That is, the buffer 230 may transfer the corresponding data to the converter 240 whenever the T1 length data is stored and repeat the operation of emptying the data.

Whenever media data is accumulated in the T1 length unit on the buffer 230, the conversion unit 240 converts the data of the T1 length into a segmented MP4 format in real time (S340).

That is, the conversion unit 240 converts the data of the length T1 into segmented MP4 at one time. Here, T1 may be in a range of 0.5 seconds to 1 second (0.5s ≦ T1 ≦ 1s).

As described above, the embodiment of the present invention does not divide the media data in the server 100, but rather divides the media data by the unit of 0.5 to 1 second in the player 200. In addition, the player 200 may collect the received media data stream into the buffer 230 in units of 0.5 to 1 seconds and then convert the data in units of 0.5 to 1 seconds into a segmented MP4 in real time.

Next, the transmission unit 250 transmits the data of the length T1 converted into the segmented MP4 in the conversion unit 240 to the web browser through the standard API (S350).

Here, the standard API may be Media Source Extensions (MSE) which is a JavaScript API for HTML5. Such MSEs are typically mounted on web browsers. The web browser means a conventional web browser and may be installed as a kind of application in the player 200.

If the amount of the transmitted data satisfies the length of the second time T2, the reproduction unit 260 starts the reproduction of the data of the length T2 by operating the codec Codec embedded in the web browser (S360).

Here, T2 corresponds to N multiples of T1 (N is an integer of 2 or more). Further, T2 may range from 2 seconds to 3 seconds longer than T1 (2s ≦ T2 ≦ 3s).

In the embodiment of the present invention, the playback delay time of the media data is generated by the length of T2 described above. For example, the playback unit 260 sequentially delivers four 0.5-second segmented MP4 conversion data to a web browser and delivers it to the web browser for two seconds. The playback unit 260 executes the codec to start the playback of the data. .

According to this, a playback delay of about T2 (2 to 3 seconds) occurs from the time point after the playback request is made by the player 200, and data can be reproduced thereafter without interruption. If T2 occurs about 2 seconds, it can be seen that the delay time is reduced by 1/3 compared to 6 seconds in the conventional system.

According to the exemplary embodiment of the present invention, when the T2 amount of data is delivered to the web browser, the data is started to be reproduced. After that, the data can be reproduced without interruption by repeating the same operation in the player 200.

That is, the playback unit 260 reproduces the data of the length T2 by operating the codec in the web browser whenever the amount of data delivered to the web browser satisfies the length T2 (S370).

As such, whenever the T2 amount of data is delivered to the web browser, the playback unit 260 plays back the data by operating the codec, whereby the data can be played back without interruption.

The conventional system uses a method of directly dividing media data from the server 100 and has a structure in which a request and reply of data are continuously repeated between the server 100 and the player 200. In addition, a reproduction delay time of about 6 seconds occurs.

Referring to FIG. 4, in the case of the system (solid line) of the present invention, when the player 200 requests media data once, the media data is continuously transmitted from the streaming server 100 in units of streams. It can be seen that the network usage is almost constant until terminated.

However, in a conventional system (dotted line) in which data requests and transmissions occur repeatedly, network usage is low in a section for requesting media data, but network usage is rapidly increasing in a section in which media data is received. It can be seen that it is repeated until this is completed.

As described above, in the conventional system, since the data request section and the data reception section are repeated with time, the network usage is irregular and the network overuse section repeatedly occurs.

However, in the exemplary embodiment of the present invention, the playback delay time is significantly reduced than before, and since only one data request is performed after one data request, network usage and traffic can be reduced and network overuse can be prevented.

According to the present invention as described above, by dividing the media data requested by the streaming server in the unit of 0.5 to 1 seconds directly from the player to convert to Segmented MP4 and by accumulating and playing the converted data in a web browser for 2 to 3 seconds, Only a delay of about 2-3 seconds of playback delay occurs, and unlike the existing HTTP protocol, data can be stably streamed without being disconnected from the streaming server.

Although the present invention has been described with reference to the embodiments shown in the drawings, this is merely exemplary, and it will be understood by those skilled in the art that various modifications and equivalent other embodiments are possible. Therefore, the true technical protection scope of the present invention will be defined by the technical spirit of the appended claims.

Claims

In an HTML5 real-time player with a web browser,

A request unit for requesting playback of the media data to the streaming server;

A receiving unit for receiving the media data into which the play meta information is inserted from the streaming server in units of streams;

A buffer that accumulates the received media data;

A conversion unit for converting the data of the T1 length into a segmented MP4 format in real time whenever the media data is accumulated in the buffer in a first time (T1) length unit;

A transmission unit for transmitting the converted T1 length data to the web browser through a standard API; And

And a playback unit for starting the reproduction of the data of the T2 length by operating the codec embedded in the web browser when the amount of the transmitted data meets the second time (T2) length.
The method according to claim 1,

The regeneration unit,

An HTML5 real time player for reproducing the data of the T2 length by operating the codec whenever the amount of data delivered to the web browser satisfies the T2 length.
The method according to claim 1,

T2 is an N multiple of T1 (N is an integer of 2 or more).
The method according to claim 1,

The T1 ranges from 0.5 seconds to 1 second and the T2 ranges from 2 seconds to 3 seconds.
The method according to claim 1,

The standard API is

Media Source Extensions (MSE) corresponding to a JavaScript API for HTML5, wherein the MSE is an HTML5 real-time player mounted in the web browser.
The method according to claim 1,

The playback delay time of the media data is generated by the T2 length HTML5 real time player.
In the real-time playback method of the HTML5 real-time player with a web browser,

Requesting playback of media data to a streaming server;

Receiving the media data inserted with reproduction meta information from the streaming server in units of streams;

Accumulating the received media data in a buffer;

Whenever the media data is accumulated in the buffer in a first time (T1) length unit, converting the data of the T1 length into a segmented MP4 format in real time;

Passing the converted T1 length data to the web browser through a standard API; And

Starting the reproduction of the data of the length T2 by operating the codec embedded in the web browser if the amount of the transmitted data meets the length of the second time (T2).
The method according to claim 7,

Whenever the amount of data delivered to the web browser satisfies the T2 length, operating the codec to play the data of the T2 length.
The method according to claim 7,

The T2 is a multiple of N (N is an integer of 2 or more) of the T1.
The method according to claim 7,

The T1 ranges from 0.5 second to 1 second, and the T2 ranges from 2 seconds to 3 seconds.
The method according to claim 7,

The standard API is

Media Source Extensions (MSE) corresponding to a JavaScript API for HTML5, wherein the MSE is a real-time playback method mounted in the web browser.
The method according to claim 7,

The playback delay time of the media data is generated by the length of the T2.