KR20160031467A - Operating method of client and server for streaming service - Google Patents

Abstract

Disclosed is an operation method of a client and a server for a streaming service. According to an embodiment of the present invention, the client transmits a request packet including a parameter which commands a data request to a server. According to the embodiment, the server transmits a response packet including data of an address range corresponding to the parameter to the client.

Description

[0001] OPERATING METHOD OF CLIENT AND SERVER FOR STREAMING SERVICE [0002]

The following embodiments relate to a method of operating a client and a server for a streaming service.

Techniques that constitute the background of the present invention are disclosed in the following documents.

1) Korean Laid-Open Patent Publication No. 2014-0054138 (Published May 2014, 2008)

2) Korea Patent Publication No. 2012-0117384 (disclosed on 24, 2012)

Most streaming technologies in the past have used streaming-only protocols such as the Real Time Streaming Protocol (RTSP). However, recent streaming technologies are designed to work efficiently over a widely distributed HTTP network such as the Internet. For example, adaptive bitrate streaming is an HTTP-based streaming technique that transmits content with quality that can be consumed based on the state of the network or transmission speed.

Variable bitrate streaming transfers files in time units. For example, variable bit rate streaming can provide a streaming service using chunks that store 2 to 10 seconds of content. At this time, each piece to be transmitted is required to start with a predetermined key frame such as an I-frame. In order to satisfy such a condition, a process of transcoding an image file into a streaming file is required in variable bit rate streaming. In this conversion process, the image quality of the image file is degraded, and additional time and computing power for conversion are additionally consumed.

Variable bitrate streaming also makes use of a manifest file. The manifest file is a file that stores information about each piece of the streaming file. The manifest file is created when a video file is converted to a streaming file. According to the variable bit rate streaming, the client must refer to the manifest file in order to receive the streaming service.

The embodiments described below provide an HTTP-based streaming technique that uses the video file format as it is without using the streaming file format. Embodiments provide techniques for transferring an image file in units of capacity. For example, embodiments may provide a streaming service that transmits a portion of an image file on a byte address basis without actually dividing the image file. According to the embodiments, the transmitted pieces are not required to start with a key frame, and the process of converting a video file to a streaming file can be omitted.

Embodiments can omit the process of converting the video file into the streaming file, thereby preventing the deterioration of image quality caused in the conversion and reducing the load on the server. Further, according to the embodiments, it is not required to convert a video file into a streaming file after the video file is uploaded to the server, so that a streaming service can be provided more rapidly. In addition, according to the embodiments, since a streaming file is not separately generated, a manifest file for storing fragment information of the streaming file is not required.

A method of operating a client for a streaming service according to one side comprising the steps of: transmitting a first request packet including a file URL and a first parameter indicating a playback information request; Receiving a first response packet including playback information of a file corresponding to the file URL; Sending a second request packet comprising a file URL and a second parameter indicating a data request; Receiving a second response packet including data in an address range corresponding to the second parameter in the file; Extracting key frames of the file from the second response packet; And generating key frame information of the file based on the key frames.

The method comprising: setting the first parameter to a predetermined first indicator; Extracting a resolution of the content stored in the file from the first response packet, a URL of a second file storing a content having a second resolution different from the resolution, and the second resolution; Extracting at least one of a size of the first piece and a number of the first pieces that divide the file from the first response packet; And extracting at least one of a size of the second piece that divides the second file from the first response packet and a number of the second piece.

The method of operating the client includes: checking a remaining amount of the buffer; Setting the second parameter to an index of a piece to be reproduced next when the remaining amount of the buffer becomes less than a threshold value; And inputting the data of the second response packet to the buffer.

The method of operating the client includes receiving a resolution change input; And setting the file URL to a URL of a second file corresponding to the new resolution included in the resolution change input.

The method of operating the client includes receiving a resolution change input; Setting the file URL to a URL of a second file corresponding to a new resolution included in the resolution change input; Estimating a piece corresponding to the current playback time based on a current playback time and a total playback time; Setting the second parameter to an index of the estimated fragments; Detecting a key frame corresponding to the current playback time from the data of the second response packet when the time of the frame included in the second response packet is included in a predetermined range based on the current playback time; And inputting the data after the detected key frame to the buffer.

Estimating a new index corresponding to the current playback time if the time of a frame included in the second response packet is not included in the predetermined range based on the current playback time; Setting a third parameter indicating the data request to the new index; Sending a third request packet comprising the file URL and the third parameter; Receiving a third response packet including data in an address range corresponding to the third parameter in the file; And detecting a key frame corresponding to the current playback time from the data of the third response packet.

The method comprising: receiving a search time; Estimating a piece corresponding to the search time based on the search time and the total play time of the file; Setting the second parameter to an index of the estimated fragments; Detecting a key frame from data of the second response packet when a time of a frame included in the second response packet is included in a predetermined range based on the search time; And inputting the data after the detected key frame into a buffer.

Estimating a new index corresponding to the search time when the time of a frame included in the second response packet is not included in a predetermined range based on the search time; Setting a third parameter indicating the data request to the new index; Sending a third request packet comprising the file URL and the third parameter; Receiving a third response packet including data in an address range corresponding to the third parameter in the file; And detecting a key frame from the data of the third response packet.

The client can use the http protocol for communication with the server.

A method of operating a client for a streaming service according to one side comprising the steps of: transmitting a first request packet including a file URL and a first parameter indicating a playback information request; Receiving a first response packet including playback information of a file corresponding to the file URL; Sending a second request packet comprising a file URL and a second parameter indicating a data request; Receiving a second response packet including data in an address range corresponding to the second parameter in the file; Inputting data of the second response packet into a buffer; Receiving search time; Detecting a key frame corresponding to the search time using key frame information of the file; Setting a third parameter indicating a data request to an index of a fragment to which the detected key frame belongs; Sending a third request packet comprising the file URL and the third parameter; Receiving a third response packet including data in an address range corresponding to the third parameter in the file; And inputting the data of the third response packet to the buffer.

The header of the third request packet includes an address range parameter, and the address range parameter includes an address of the detected key frame, an address range including the address of the detected key frame, and an address range of the detected key frame And may indicate at least one of the corresponding offset addresses.

A method of operating a client for a streaming service according to one side comprising the steps of: transmitting a first request packet including a file URL and a first parameter indicating a playback information request; Receiving a first response packet including playback information of a file corresponding to the file URL; Sending a second request packet comprising a file URL and a second parameter indicating a data request; Receiving a second response packet including data in an address range corresponding to the second parameter in the file; Inputting data of the second response packet into a buffer; Receiving a resolution change input; Setting the file URL to a URL of a second file corresponding to a new resolution included in the resolution change input; Detecting a key frame corresponding to a current playback time based on key frame information of the second file; Setting a third parameter indicating a data request to an index of a fragment to which the detected key frame belongs; And sending a third request packet comprising the file URL and the third parameter; Receiving a third response packet including data in an address range corresponding to the third parameter in the second file; And inputting the data of the third response packet to the buffer.

The header of the third request packet includes an address range parameter, and the address range parameter includes an address of the detected key frame, an address range including the address of the detected key frame, and an address range of the detected key frame And may indicate at least one of the corresponding offset addresses.

A method of operating a client for a streaming service according to one side comprising the steps of: transmitting a first request packet including a file URL and a first parameter indicating a playback information request; Receiving a first response packet including playback information of a file corresponding to the file URL; Setting a second parameter indicating a data request to an initial index; And sending a second request packet comprising the file URL and the second parameter; Receiving a second response packet including data in an address range corresponding to the second parameter in the file; Extracting an offset address for key frame information of the file from the second response packet; Extracting the key frame information from the second response packet if data of the offset address is included in the second response packet; Setting a third parameter indicating the data request to the offset address when the data of the offset address is not included in the second response packet; Sending a third request packet comprising the file URL and the third parameter; Receiving a third response packet including data in an address range corresponding to the third parameter in the file; And extracting the key frame information from the third response packet.

A method of operating a server for a streaming service according to one side includes receiving a request packet including a file URL and parameters; If the parameter indicates a data request, responding data in an address range corresponding to the parameter in the file corresponding to the file URL; And responding to the reproduction information of the file when the parameter indicates the reproduction information request.

Wherein the step of responding to the data comprises the step of, when the parameter includes an index and the header of the request packet includes an address range parameter, extracting, from the data of the address range corresponding to the index in the file, And responding to some data.

The reproduction information may include a resolution of the content stored in the file, a URL of a second file storing a content having a second resolution different from the resolution, and the second resolution.

Wherein the playback information includes at least one of a size of a first piece that divides the file and at least one of the number of the first pieces and a size of a second piece that divides the second file and a number of the second pieces .

The address range corresponding to the index can be determined based on the size of the piece dividing the file.

The server can use the http protocol for communication with the client.

1 illustrates a method of operating a client according to an embodiment;
FIGS. 2 to 7 are diagrams for explaining a method of operating a server according to an embodiment; FIG.
8 illustrates a basic operation of a client according to an embodiment;
9 to 11 are diagrams for explaining an operation of obtaining key frame information according to an embodiment;
12 to 14 are diagrams for explaining a resolution changing operation according to an embodiment.
15 to 17 are diagrams for explaining a search operation according to an embodiment;
Figures 18 and 19 illustrate the operation of a client using a plurality of url streams.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. Like reference symbols in the drawings denote like elements. The embodiments described below can be applied to a client or a server for a streaming service.

A client according to an exemplary embodiment may be a computing device that is provided with a streaming service, for example, a personal computer, a laptop computer, a tablet computer, a PDA, a smart phone, or the like. A client may be installed with a client application communicating with the server using the http protocol, such as a swf player. A server according to an exemplary embodiment is a computing device that provides a streaming service, and may include a web server, for example. The server can be configured not only as a server-specific computing device, but also as a personal computer, laptop computer, tablet computer, PDA, or smart phone. A server application that communicates with a client using the http protocol, for example, an Apache server, may be installed in the server.

1 is a view for explaining a method of operating a client according to an embodiment. Referring to FIG. 1, a client 110 according to an embodiment transmits a first request packet to a server 120. The first request packet may include a file URL and a first parameter indicating a playback information request. Here, the file URL is information for uniquely indicating a resource on the computer network, for example, information that uniquely indicates a video file to be a streaming service target. The first parameter indicating the playback information request may be a predetermined character or string, for example, 'i' or 'r'. The client 110 may request the playback information of the file corresponding to the file URL by transmitting the first request packet to the server 120. [ The reproduction information of the file is information for reproducing the file through the streaming service. For example, the information of the file may be divided for transmission.

The client 110 receives the first response packet from the server 120. The first response packet may include playback information of the file corresponding to the file URL. As described above, the embodiments can provide a streaming technique in which a file is divided into units of capacity and transmitted. Hereinafter, an individual capacity unit for dividing a file may be referred to as a piece.

According to one embodiment, the size of the piece that splits the file may be determined by the server 120. [ The server 120 can calculate the number of pieces required to divide the file according to the size of the piece dividing the file. In this case, the reproduction information of the first response packet may include the size of the piece and the number of pieces. Alternatively, the server 120 may include the size of the piece and the total size of the file in the first response packet. In this case, the client 110 can calculate the number of pieces necessary for dividing the file based on the size of the piece and the total size of the file.

According to another embodiment, the size of the piece dividing the file may be determined by the client 120. [ The client 120 may include the size of the fragment in the first parameter and send it to the server 120. The server 120 may calculate the number of pieces needed to divide the file based on the size of the received piece. In this case, the reproduction information of the first response packet may include the number of pieces. Alternatively, the server 120 may include the total size of the file in the first response packet. In this case, since the client 110 already knows the size of the piece, it can calculate the number of pieces necessary to divide the file based on the total size of the file.

The client 110 transmits a second request packet to the server 120. [ The second request packet may include a file URL and a second parameter indicating a data request. The second parameter indicating the data request may be a number or a string indicating the address in the file, for example, 'address r' or 'address 1r address 2'. Hereinafter, the address in the file may be a byte address. The client 110 can request at least a part of the file corresponding to the file URL on a capacity basis by transmitting the second request packet to the server 120. [

The client 110 receives the second response packet from the server 120. The second response packet may include data in the address range corresponding to the second parameter in the file corresponding to the file URL. The client 110 may input the data of the second response packet into the buffer. As will be described in detail below, data input to the buffer can be reproduced through a demux and / or a decoder.

2 to 7 are diagrams illustrating a method of operating a server according to an embodiment. Referring to FIG. 2, a server 220 according to an embodiment receives a request packet from a client 210. The request packet may include a file URL and a parameter. The file URL may be information that uniquely indicates a resource on the computer network, for example, information indicating a file stored in the server 220. [

The server 220 can determine whether the parameter indicates a data request or a playback information request. For example, the server 220 may determine whether the parameter included in the request packet is a first parameter indicating a replay information request, or a second parameter indicating a data request. A first parameter indicating a playback information request and a second parameter indicating a data request may be predetermined and the server 220 and the client 210 may share a predetermined first parameter and a second parameter can do.

If the parameter indicates a playback information request, the server 220 may respond to the playback information of the file. For example, referring to FIG. 3, the server 320 may receive a request packet including a file 1 URL and a first indicator from the client 310. Here, the first indicator may be a predetermined character or string, for example, 'r'. In the request packet, the file 1 URL and the first indicator may be separated by a predetermined code, for example, '?'. The server 320 may determine whether or not the parameter included in the request packet includes the first indicator.

If the parameter contained in the request packet includes a first indicator, the server 320 determines the size of the fragment (chunk size), the number of fragments (number of chunks), and the size of the fragment You can respond to the file list. The file list may include the resolution of the first file and the URL and resolution of at least one file that stores content at a resolution different from the first resolution of the content stored in the first file. For example, the file list may include a first resolution (file 1 resolution) of contents stored in the first file, a URL (file 2URL) of a second file storing contents having a second resolution different from the first resolution, (File 2 resolution), and the like. When there are a plurality of files storing contents having a resolution different from the first resolution, the file list may include URLs and resolutions of a plurality of files.

The server 320 may search for at least one file storing contents of a resolution different from the first resolution in the directory where the first file corresponding to the file 1 URL is stored. For example, if the files shown in Table 1 are stored in the directory in which the first file is stored and the first file is 'music video .mp4', the server 320 transmits 'music video_720p.mp4' Video480p.mp4, and music video_360p.mp4.

Music Video .mp4
Music video_720p.mp4
Music video_480p.mp4
Music video_360p.mp4

In this case, the server 320 may generate a response packet as shown in Table 2, and may transmit a response packet to the client 310.

2097152 97 1080 URL2 720 URL3 480 URL4 360

Here, the first element of the response packet is the chunk size, the second element is the number of chunks, the third element is the file 1 resolution, the fourth element is the file 2URL, the fifth element is the file 2 resolution, Is the file 3URL, the seventh element is the file 3 resolution, the eighth element is the file 4URL, and the ninth element is the file 4 resolution. The chunk size can be in bytes.

In some cases, for a uniform data structure, the file list may include URLs and resolutions of all files corresponding to the same content. For example, the file list may include the URL of the first file, the resolution of the first file, and the URL and resolution of the at least one file that stores content at a resolution different from the resolution of the first file. In this case, the server 320 may generate a response packet as shown in Table 3, and may transmit the response packet to the client 310.

2097152 97 URL1 1080a URL2 720 URL3 480 URL4 360

Here, the first element of the response packet is the size of the chunk, the second element is the number of chunks, the third element is the file 1URL, the fourth element is the file 1 resolution, the fifth element is the file 2URL, File 2 resolution, the seventh element is file 3URL, the eighth element is file 3 resolution, the ninth element is file 4URL, and the tenth element is file 4 resolution. The chunk size can be in bytes. A predefined character or string, e.g., 'a', may be appended to the end of the file 1 resolution to indicate that the resolution of the currently requested file (first file) is 1080 (file 1 resolution).

Each file can contain a resolution in the file name. For example, the server 320 can encode 'music video .mp4' at a new resolution when the upload of the original music video file 'music video .mp4' is completed. At this time, the server 320 can determine a file name of a new resolution by adding a new resolution to the file name of the original image file. In this case, the server 320 may obtain the resolution of the content stored in the file based on the file name.

As another example, referring to FIG. 4, the server 420 may receive a request packet including a file URL and a second indicator from the client 410. Here, the second indicator may be a predetermined character or string, for example, 'i'. In the request packet, the file URL and the second indicator may be separated by a predetermined code, for example, '?'. The server 420 may determine whether the parameter included in the request packet includes the second indicator. If the parameters contained in the request packet include a second indicator, the server 420 can respond to the size (chunk size) of the fragment that divides the file corresponding to the file URL and the number of chunks (the number of chunks) have.

For example, if the request packet is 'file 3URL? I', the server 420 may generate a response packet as shown in Table 4 and send the response packet to the client 410.

1048576 86

Here, the first element of the response packet is the size of the chunk, and the second element is the number of chunks. The chunk size can be in bytes. Referring to Table 1, the sizes of the chunks for dividing the respective files can be set to be different from each other. However, the embodiments are not limited such that chunk sizes for dividing the respective files are set to be different from each other. For example, the sizes of the chunks for dividing each file may be set equal to each other.

Referring again to FIG. 2, if the parameter indicates a data request, the server 220 may respond to the data in the address range corresponding to the parameter in the file corresponding to the file URL. 5, the server 520 may receive a request packet including a file URL and an index from the client 510. [ Here, the index may be an integer equal to or greater than zero. The file URL and index in the request packet can be separated by a predetermined code, for example, '?'. The server 520 may determine whether the parameters included in the request packet include an index. If the parameter included in the request packet includes an index, the server 520 may respond to the data in the address range corresponding to the in-file index corresponding to the file URL.

For example, if the request packet is a 'file URL? N', the server 520 may obtain the size of the fragment that divides the file corresponding to the file URL. If the size of the chunk for the file is 2097152 bytes, the server 520 can transmit data as shown in Table 5 to the client 510. The data in Table 5 may be referred to as chunk-n.

[(2097152) * n, (2097152) * (n + 1) -1]

Here, [first byte address, second byte address] is data from the first byte address to the second byte address.

As another example, a request packet including a file URL and an index may include a header. The header may contain an address range parameter. The header may be an http header. The server 520 may transmit the piece of data of the piece corresponding to the index to the client 510 using the address range parameter included in the header of the request packet. For example, if the chunk size for the file corresponding to the file URL included in the request packet is 2097152 bytes, the index included in the request packet is n, and the address range parameter of the request packet is (start range, end range) , The server 520 can transmit data as shown in Table 6 to the client 510. [

[(2097152) * n + start range, (2097152) * n + end range]

Here, units of start range and end range may be bytes. The server 520 may include a cache server. The cache server may cache fragmented data based on the file URL and index. In this case, even if the address range parameter included in the header of the request packet is different, fragment data cached to the cache server can be utilized if the file URL and index included in the request packet are the same.

As another example, referring to FIG. 6, the server 620 may receive a request packet including a file URL and an address from the client 610. Here, the address may be a byte address. The file URL and address in the request packet can be separated by a predetermined code, for example, '?'. To distinguish the address from the index, a predefined character or string, for example 'r', may be appended to the address. The server 620 may determine whether the parameters included in the request packet include an address. If the parameter included in the request packet includes an address, the server 620 may respond to the data in the address range corresponding to the address in the file corresponding to the file URL.

For example, if the request packet is a 'file URL? Address r', the server 620 may transmit data as shown in Table 7 to the client 610.

[Address, end of file]

Here, [address, file end] is the data from the address to the end of the file.

7, the server 720 may receive a request packet including a file URL and a plurality of addresses, e.g., a first address and a second address, from the client 710. [ Here, the plurality of addresses may each be a byte address. The file URL and the plurality of addresses in the request packet can be separated by a predetermined code, for example, '?'. Further, in order to distinguish a plurality of addresses from each other, a predetermined character or string, e.g., 'r', may be added between a plurality of addresses. The server 720 may determine whether the parameter included in the request packet includes a plurality of addresses. If the parameter included in the request packet includes a plurality of addresses, the server 720 may respond to data in the address range corresponding to the plurality of addresses in the file corresponding to the file URL.

For example, if the request packet is a 'file URL? Address 1r address 2', the server 720 may transmit data as shown in Table 8 to the client 710.

[Address1, Address2]

Here, [address 1, address 2] is data from the first address to the second address.

8 is a diagram illustrating a basic operation of a client according to an embodiment. Referring to FIG. 8, a client 810 according to an exemplary embodiment may obtain a URL of a first file to be played through a streaming service, for example, 'file 1 URL'. The client 810 may send a request packet requesting the first fragment of the first file, e.g., 'file 1URL? 0', to the server 820. Also, the client 810 may transmit a request packet requesting the playback information of the first file, for example, 'file 1URL? R' to the server 820.

The client 810 can receive a response packet including the reproduction information of the first file from the server 820. [ For example, the playback information of the first file may include a chunk size, a number of chunks, and a file list. The file list may include a file 1 resolution, a file 2URL, and a file 2 resolution. The client 810 can extract the reproduction information of the first file from the response packet.

The client 810 may receive a response packet including the first piece of the first file, e.g., 'chunk-0', from the server 820. [ The client 810 can reproduce 'chunk-0'. For example, the client 810 may input 'chunk-0' included in the response packet into the buffer. Data input to the buffer can be reproduced through a demux and / or decoder.

The client 810 can check the remaining amount of the buffer. For example, it can be determined whether the remaining amount of the buffer is equal to or less than a predetermined threshold value. The predetermined threshold value may be a byte unit or a time unit. When the predetermined threshold value is time unit, the time unit threshold value can be converted into the byte unit threshold value based on the resolution of the content being reproduced.

If the remaining amount of the buffer is less than or equal to the predetermined threshold value, the client 810 can send a request packet to the server 820 requesting the next fragment of the first file. For example, the client 810 may calculate an index for the next piece by adding one to the index of the piece currently playing. If the index of the currently playing piece is zero, the client 810 may send 'file 1URL? 1' to the server 820.

The client 810 may receive a response packet containing the next fragment, e.g., 'chunk-1', from the server 820. The client 810 can reproduce 'chunk-1'. For example, the client 810 can input 'chunk-1' included in the response packet into the buffer. Data input to the buffer can be reproduced through a demux and / or decoder.

9 to 11 are diagrams for explaining an operation of obtaining key frame information according to an embodiment. A client according to an exemplary embodiment may obtain key frame information of a first file to be played through a streaming service. The content stored in the first file is composed of a plurality of frames. A plurality of frames may be classified into a frame completely containing information of the screen and a frame referring to another frame. A frame that fully captures information on the screen may be referred to as a key frame. A frame referring to another frame does not completely carry the information of the frame of the frame, and therefore can have a smaller capacity than the key frame.

The key frame information of the first file may include information on key frames among a plurality of frames constituting the content stored in the first file. For example, key frame information may include the index, byte address, and timestamp of each of the key frames.

In one example, the first file may store key frame information. For example, if the first file has the mp4 file format, the first file may store the key frame information. In this case, the client can obtain the key frame information by receiving the data of the address range storing the key frame information from the server.

9, the client 910 may send a request packet requesting the first fragment of the first file, e.g., 'file 1URL? 0', to the server 920. The client 910 may receive a response packet including the first piece of the first file, e.g., 'chunk-0', from the server 920. [ The client 910 may extract the offset address of the key frame information from the first piece of the first file.

The client 910 may determine whether or not the data of the offset address is included in the first fragment by determining whether the offset address is included in the address range of the first fragment. If the offset address is contained within the address range of the original fragment, the client 910 may obtain the key frame information from the already received original fragment.

If the offset address is not included in the address range of the first fragment, the client 910 may send a request packet requesting data beyond the offset address, e.g., 'file 1URL? Offset address r' to the server 920 . The client 910 may receive a response packet including data after the offset address, e.g., [offset address, end of file 1]. The client 910 may extract the key frame information from the response packet.

As another example, the first file may not store key frame information. For example, if the first file has the flv file format, the first file may not store the key frame information. In this case, the client may generate the key frame information during playback of the first file.

10, the client 1010 may send a request packet requesting the first piece of the first file, for example, 'file 1URL? 0' to the server 1020. The client 1010 may receive a response packet including the first piece of the first file, e.g., 'chunk-0', from the server 1020. [ The client 1010 can reproduce 'chunk-0'. For example, the client 1010 may input 'chunk-0' included in the response packet into the buffer. Data input to the buffer can be reproduced through a demux and / or decoder.

The client 1010 can extract key frames included in 'chunk-0' while 'chunk-0' is reproduced. The client 1010 may generate key frame information for the first file based on the extracted key frames. For example, referring to FIG. 11, a client 1010 may generate a search table 1100 that includes key frame information.

Although not shown in the drawing, the client 1010 can generate key frame information during playback of other pieces than the original piece. For example, the client 1010 may continuously update the search table 1100 while the content stored in the first file is played back.

12 to 14 are diagrams for explaining a resolution changing operation according to an embodiment. Referring to FIG. 12, a client 1210 according to an exemplary embodiment may obtain a URL of a first file to be played through a streaming service, for example, 'file 1URL'. Client 1210 may send a request packet requesting the first fragment of the first file, e.g., 'file 1URL? 0', to server 1220. In addition, the client 1210 may transmit a request packet requesting playback information of the first file, for example, 'file 1URL? R' to the server 1220.

The client 1210 may receive a response packet including the playback information of the first file from the server 1220. [ For example, the reproduction information of the first file may include a chunk size, a number of chunks, and a file list. The file list may include a file 1 resolution, a file 2URL, and a file 2 resolution. The client 810 can extract the reproduction information of the first file from the response packet.

The client 1210 may receive a response packet including the first piece of the first file, e.g., 'file 1 chunk-0', from the server 1220. The client 1210 can reproduce 'file 1 chunk-0'. For example, the client 810 may input 'file 1 chunk-0' included in the response packet into the buffer. Data input to the buffer can be reproduced through a demux and / or decoder.

Client 1210 may receive a resolution change input. For example, the client 1210 may provide the user with a resolution and / or a changeable resolution of the currently playing content through a predetermined interface. The client 1210 may receive the resolution change input through the interface.

In some cases, the client 1210 can automatically determine whether to change the resolution. For example, the client 1210 can automatically determine whether to change the resolution based on communication status, buffering, communication cost, and the like.

Hereinafter, an embodiment of changing from the first resolution to the second resolution will be described. The client 1210 may transmit a request packet requesting playback information of the second file, for example, 'file 2URL? I' to the server 1220. Since the client 1210 already has the resolution list, it can request the reproduction information of the second file using the second indicator, for example, 'i'. The client 1210 may receive a response packet including the playback information of the second file from the server 1220. [ For example, the playback information of the second file may include a chunk size and a number of chunks.

The client 1210 may send a request packet requesting the first piece of the second file, e.g., 'file 2URL? 0' to the server 1220. The client 1210 may receive a response packet including the first piece of the second file, e.g., 'file 2 chunk-0', from the server 1220. Although not shown in the drawing, the client 1210 can obtain the key frame information of the second file. For example, the client 1210 may obtain the key frame information of the second file based on the above-described embodiment with reference to FIG.

The client 1210 can detect the key frame corresponding to the current playback time based on the key frame information of the second file. For example, the client 1210 may detect a key frame that is closest to a frame after a predetermined time, for example, one second, since the current playback time.

The client 1210 may transmit a request packet requesting data after the detected key frame address, for example, 'file 2URL? Key frame address r corresponding chunk end address' to the server 1220. The 'chunk end address' is the end address of the chunk to which the detected key frame belongs, and the client 1210 can calculate the end address of the chunk to which the detected key frame belongs using the playback information of the second file. Although not shown in the figure, the client 1210 transmits a request packet requesting a fragment to which the detected key frame belongs, for example, 'file 2URL? Corresponding chunk index' to the server 1220, You can request data at [keyframe address, end of chunk] using the address range parameter. According to another embodiment, client 1210 may request data at [keyframe address, end of file] by sending 'file 2URL? Key frame address r' to server 1220.

The client 1210 may receive a response packet including data after the key frame address, for example, [key frame address, corresponding chunk end address]. The client 1210 can reproduce the second file having the new resolution by inputting the data after the key frame address into the buffer.

Referring to FIG. 13, the client 1310 according to another embodiment may receive a resolution change input during playback of the first file. For example, the client 1310 may provide the user with a resolution and / or a changeable resolution of the currently playing content through a predetermined interface. The client 1310 may receive the resolution change input through the interface. In some cases, the client 1310 can automatically determine whether to change the resolution. For example, the client 1310 can automatically determine whether to change the resolution based on the communication status, buffering status, communication cost, and the like.

Hereinafter, an embodiment of changing from the first resolution to the second resolution will be described. The client 1310 may transmit a request packet requesting playback information of the second file, for example, 'file 2URL? I' to the server 1320. Since the client 1310 already has the resolution list, it can request the reproduction information of the second file using the second indicator, for example, 'i'. The client 1310 may receive a response packet including the reproduction information of the second file from the server 1320. [ For example, the playback information of the second file may include a chunk size and a number of chunks.

Client 1310 may send a request packet requesting the first fragment of the second file, e.g., 'file 2URL? 0' to server 1320. Client 1310 may receive a response packet containing the first piece of the second file, e.g., 'file 2 chunk-0', from server 1320.

At this time, the second file may not store the key frame information. In this case, the client 1310 can estimate the piece corresponding to the current playback time from the pieces of the second file, based on the current playback time and the total playback time. For example, the client 1310 can estimate the piece corresponding to the current playback time from the pieces of the second file, using the ratio of the current playback time to the total playback time.

The client 1310 may send a request packet requesting data of the estimated fragment, e.g., 'file 2URL? M' to the server 1320. Here, 'm' is the index of the estimated fragment. The client 1310 may receive the response packet including the estimated piece of data, e.g., 'file 2 chunk-m'. The client 1310 can determine whether the estimation is successful by using the estimated pieces of data. For example, the client 1310 can determine the success or failure of the estimation by comparing the time of the first frame in the estimated fragment with the current playback time.

If the estimate is determined to be failure, the client 1310 may estimate a new fragment. If it is determined that the estimation is successful, the estimated key frames in the fragment can be extracted. The client 1310 can detect the key frame closest to the current playback time. The client 1310 can input the data after the detected key frame into the buffer.

14, a client 1410 according to one embodiment may receive fragments from a server 1420 using various bit rates. As described above, according to embodiments, pieces are not required to start with a key frame, and further, the pieces may not contain a key frame. Accordingly, the server 1420 does not have to encode according to the fragment, and the server 1420 can transmit general image files such as mp4 and flv by dividing them by capacity. Since the pieces transmitted between the server 1420 and the client 1410 start with a key frame or a condition including a key frame is not required, the embodiments can be applied not only to a closed GOP but also to an open GOP (Open GOP) .

The client 1410 can download the pieces in advance by the size of the buffer. The client 1410 may store the reproduced fragments so that when the frames belonging to the stored fragments are reproduced again, the fragments may not be duplicated and downloaded.

FIGS. 15 to 17 are diagrams for explaining a search operation according to an embodiment. The search operation is an operation for randomly accessing the contents. Referring to FIG. 15, a client 1510 according to an embodiment may transmit a request packet requesting an nth piece of a first file, for example, 'file 1URL? N' to the server 1520. The client 1510 may receive a response packet including the nth piece of the first file, e.g., 'chunk-n', from the server 1520. Client 1510 may enter 'chunk-n' into the buffer. Data input to the buffer can be reproduced through a demux and / or decoder.

The client 1510 may receive the search input during 'chunk-n' playback. For example, the client 1510 may receive the search input via a predetermined interface. The search input may include a search time.

The client 1510 can detect the key frame corresponding to the search time based on the key frame information of the first file. For example, the client 1510 may detect the key frame closest to the frame of the search time.

The client 1510 may transmit a request packet requesting data after the detected key frame address, for example, 'file 1URL? Key frame address r corresponding chunk end address' to the server 1520. The 'chunk end address' is the end address of the chunk to which the detected key frame belongs, and the client 1510 can calculate the end address of the chunk to which the detected key frame belongs using the playback information of the first file. Although not shown in the figure, the client 1510 transmits a request packet requesting a fragment to which the detected key frame belongs, for example, 'file 1URL? Corresponding chunk index' to the server 1520, You can request data at [keyframe address, end of chunk] using the address range parameter.

The client 1510 may receive a response packet including data after the key frame address, for example, [key frame address, corresponding chunk end address]. The client 1510 can search for and reproduce the first file by inputting the data after the key frame address into the buffer.

Referring to FIG. 16, the client 1610 according to another embodiment may transmit 'file 1URL? N' to the server 1620. The client 1610 may receive a response packet including 'chunk-n' from the server 1620. The client 1610 can reproduce 'chunk-n'.

The client 1610 may receive the search input during 'chunk-n' playback. The client 1610 can detect the key frame corresponding to the search time based on the key frame information of the first file. For example, the client 1610 may detect a key frame closest to the frame of the search time.

The client 1610 may send a request packet requesting data of the fragment to which the detected key frame belongs, for example, 'file URL? K' to the server 1620. Here, 'k' is the index of the fragment to which the detected key frame belongs. The client 1610 may receive the response packet including the data of the fragment to which the detected key frame belongs, for example, 'file 1 chunk-k'. The client 1610 can search for and reproduce the first file by inputting the data after the key frame address into the buffer.

The search operation of FIG. 16 can increase the efficiency of the cache server in comparison with the search operation of FIG. 15, and the search operation of FIG. 15 can reduce the amount of actually transmitted data as compared with the search operation of FIG. The embodiments can operate in accordance with either the search operation of FIG. 15 and the search operation of FIG. 16, taking into account the trade-off relationship between the efficiency of the cache server and the amount of data actually transferred.

Referring to FIG. 17, a client 1710 according to another embodiment may receive a search input during reproduction of 'chunk-n'. The search input may include a search time. The first file currently being played may not store the key frame information. In this case, the client 1710 can generate the key frame information according to the above-described embodiment through FIGS. 10 and 11. FIG. However, the key frame corresponding to the search time may not yet be included in the key frame information.

The client 1710 can estimate the piece corresponding to the current playback time among pieces of the first file based on the current playback time and the total playback time. For example, the client 1710 can estimate a piece corresponding to the current playback time of the pieces of the first file, using the ratio of the current playback time to the total playback time.

The client 1710 may send a request packet requesting data of the estimated fragment, e.g., 'file 1URL? M' to the server 1720. Here, 'm' is the index of the estimated fragment. The client 1710 may receive the response packet including the estimated piece of data, for example, 'file 1 chunk-m'. The client 1710 can determine whether the estimation is successful by using the estimated piece of data. For example, the client 1710 can determine the success or failure of the estimation by comparing the time of the first frame in the estimated fragment with the current playback time.

If the estimate is determined to be failure, the client 1710 may estimate a new slice. If it is determined that the estimation is successful, the estimated key frames in the fragment can be extracted. The client 1710 can detect a key frame closest to the current playback time. The client 1710 may input the data after the detected key frame into the buffer.

18 and 19 are diagrams illustrating operations of a client using a plurality of URL streams. Referring to FIG. 18, a client according to an exemplary embodiment may perform a resolution change operation and / or a search operation using a plurality of URL streams. Hereinafter, a case where a client uses two URL streams will be described.

Each of the first url stream and the second url stream may generate and transmit a request packet to the server and process the response packet received from the server. The data of the first url stream may be reproduced through the first demux and the first decoder. The data of the second url stream can be reproduced through the second demux and the second decoder.

The client includes a signal EN_DEMUX_1 for controlling the first demux, a signal EN_DECODER_1 for controlling the first decoder, a signal EN_DEMUX_2 for controlling the second demux, a signal EN_DECODER_2 for controlling the second decoder, And a signal (MUX_OUT) for controlling the mux may be used to control the data flow of the data of the first url stream and the data of the second url stream.

For example, referring to FIG. 19, at the start of the streaming service, the client can sequentially play back the first piece of the first file using the first url stream. At this time, the client can receive the reproduction information of the first file using the second url stream.

Upon input of the resolution change, the client can detect the key frame corresponding to the current playback time among the key frames of the second file by using the second url stream while playing the first file using the first url stream. The client can control the data flow of the first url stream and the data stream of the second url stream at the time the detected key frame is reproduced, for resolution change.

For example, the client may switch off the data flow of the first url stream and switch on the data flow of the second url stream. Optionally, the client can control the data flow of the first url stream and the data flow of the second url stream to be switched on together for a certain time, for example 30 ms, taking into account the delay of the demux and / or decoder .

The client may then use the second url stream to play the data after the detected key frame. The client may clear the buffer for the first url stream. Although not shown in the figure, if additional resolution change inputs are received, the client may process additional resolution change inputs by changing only the roles of the first url stream and the second url stream in the operations described above.

The embodiments described above may be implemented in hardware components, software components, and / or a combination of hardware components and software components. For example, the devices, methods, and components described in the embodiments may be implemented within a computer system, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, such as an array, a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to execution of the software. For ease of understanding, the processing apparatus may be described as being used singly, but those skilled in the art will recognize that the processing apparatus may have a plurality of processing elements and / As shown in FIG. For example, the processing unit may comprise a plurality of processors or one processor and one controller. Other processing configurations are also possible, such as a parallel processor.

The software may include a computer program, code, instructions, or a combination of one or more of the foregoing, and may be configured to configure the processing device to operate as desired or to process it collectively or collectively Device can be commanded. The software and / or data may be in the form of any type of machine, component, physical device, virtual equipment, computer storage media, or device , Or may be permanently or temporarily embodied in a transmitted signal wave. The software may be distributed over a networked computer system and stored or executed in a distributed manner. The software and data may be stored on one or more computer readable recording media.

The method according to an embodiment may be implemented in the form of a program command that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions to be recorded on the medium may be those specially designed and configured for the embodiments or may be available to those skilled in the art of computer software. Examples of computer-readable media include magnetic media such as hard disks, floppy disks and magnetic tape; optical media such as CD-ROMs and DVDs; magnetic media such as floppy disks; Magneto-optical media, and hardware devices specifically configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Examples of program instructions include machine language code such as those produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

Although the preferred embodiments of the present invention have been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, additions and substitutions are possible, without departing from the scope and spirit of the invention as disclosed in the accompanying claims. For example, it is to be understood that the techniques described may be performed in a different order than the described methods, and / or that components of the described systems, structures, devices, circuits, Lt; / RTI > or equivalents, even if it is replaced or replaced. Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

Claims (20)

A method of operating a client for a streaming service,
Transmitting a first request packet including a first parameter indicating a file URL and a playback information request;
Receiving a first response packet including playback information of a file corresponding to the file URL;
Sending a second request packet comprising a file URL and a second parameter indicating a data request;
Receiving a second response packet including data in an address range corresponding to the second parameter in the file;
Extracting key frames of the file from the second response packet; And
Generating key frame information of the file based on the key frames
Gt; a < / RTI > client.
The method according to claim 1,
Setting the first parameter to a predetermined first indicator;
Extracting a resolution of the content stored in the file from the first response packet, a URL of a second file storing a content having a second resolution different from the resolution, and the second resolution;
Extracting at least one of a size of the first piece and a number of the first pieces that divide the file from the first response packet; And
Extracting at least one of a size of a second piece dividing the second file from the first response packet and a number of the second pieces
≪ / RTI >
The method according to claim 1,
Checking the remaining amount of the buffer;
Setting the second parameter to an index of a piece to be reproduced next when the remaining amount of the buffer becomes less than a threshold value; And
Inputting the data of the second response packet into the buffer
≪ / RTI >
The method according to claim 1,
Receiving a resolution change input; And
Setting the file URL to a URL of a second file corresponding to a new resolution included in the resolution change input
≪ / RTI >
The method according to claim 1,
Receiving a resolution change input;
Setting the file URL to a URL of a second file corresponding to a new resolution included in the resolution change input;
Estimating a piece corresponding to the current playback time based on a current playback time and a total playback time;
Setting the second parameter to an index of the estimated fragments;
Detecting a key frame corresponding to the current playback time from the data of the second response packet when the time of the frame included in the second response packet is included in a predetermined range based on the current playback time; And
Inputting data after the detected key frame into the buffer
≪ / RTI >
6. The method of claim 5,
Estimating a new index corresponding to the current playback time if a time of a frame included in the second response packet is not included in the predetermined range based on the current playback time;
Setting a third parameter indicating the data request to the new index;
Sending a third request packet comprising the file URL and the third parameter;
Receiving a third response packet including data in an address range corresponding to the third parameter in the file; And
Detecting a key frame corresponding to the current playback time after the data of the third response packet
≪ / RTI >
The method according to claim 1,
Receiving search time;
Estimating a piece corresponding to the search time based on the search time and the total play time of the file;
Setting the second parameter to an index of the estimated fragments;
Detecting a key frame from data of the second response packet when a time of a frame included in the second response packet is included in a predetermined range based on the search time; And
Inputting data after the detected key frame into a buffer
≪ / RTI >
8. The method of claim 7,
Estimating a new index corresponding to the search time if a time of a frame included in the second response packet is not included in a predetermined range based on the search time;
Setting a third parameter indicating the data request to the new index;
Sending a third request packet comprising the file URL and the third parameter;
Receiving a third response packet including data in an address range corresponding to the third parameter in the file; And
Detecting a key frame from data of the third response packet
≪ / RTI >
The method according to claim 1,
Wherein the client uses the http protocol for communication with the server.
A method of operating a client for a streaming service,
Transmitting a first request packet including a first parameter indicating a file URL and a playback information request;
Receiving a first response packet including playback information of a file corresponding to the file URL;
Sending a second request packet comprising a file URL and a second parameter indicating a data request;
Receiving a second response packet including data in an address range corresponding to the second parameter in the file;
Inputting data of the second response packet into a buffer;
Receiving search time;
Detecting a key frame corresponding to the search time using key frame information of the file;
Setting a third parameter indicating a data request to an index of a fragment to which the detected key frame belongs;
Sending a third request packet comprising the file URL and the third parameter;
Receiving a third response packet including data in an address range corresponding to the third parameter in the file; And
Inputting the data of the third response packet to the buffer
Gt; a < / RTI > client.
11. The method of claim 10,
Wherein the header of the third request packet includes an address range parameter,
The address range parameter
The address indicating at least one of an address of the detected key frame, an address range including the address of the detected key frame, and an offset address corresponding to the address of the detected key frame.
A method of operating a client for a streaming service,
Transmitting a first request packet including a first parameter indicating a file URL and a playback information request;
Receiving a first response packet including playback information of a file corresponding to the file URL;
Sending a second request packet comprising a file URL and a second parameter indicating a data request;
Receiving a second response packet including data in an address range corresponding to the second parameter in the file;
Inputting data of the second response packet into a buffer;
Receiving a resolution change input;
Setting the file URL to a URL of a second file corresponding to a new resolution included in the resolution change input;
Detecting a key frame corresponding to a current playback time based on key frame information of the second file;
Setting a third parameter indicating a data request to an index of a fragment to which the detected key frame belongs; And
Sending a third request packet comprising the file URL and the third parameter;
Receiving a third response packet including data in an address range corresponding to the third parameter in the second file;
Inputting the data of the third response packet to the buffer
≪ / RTI >
13. The method of claim 12,
Wherein the header of the third request packet includes an address range parameter,
The address range parameter
The address indicating at least one of an address of the detected key frame, an address range including the address of the detected key frame, and an offset address corresponding to the address of the detected key frame.
A method of operating a client for a streaming service,
Transmitting a first request packet including a first parameter indicating a file URL and a playback information request;
Receiving a first response packet including playback information of a file corresponding to the file URL;
Setting a second parameter indicating a data request to an initial index; And
Sending a second request packet comprising the file URL and the second parameter;
Receiving a second response packet including data in an address range corresponding to the second parameter in the file;
Extracting an offset address for key frame information of the file from the second response packet;
Extracting the key frame information from the second response packet if data of the offset address is included in the second response packet;
Setting a third parameter indicating the data request to the offset address when the data of the offset address is not included in the second response packet;
Sending a third request packet comprising the file URL and the third parameter;
Receiving a third response packet including data in an address range corresponding to the third parameter in the file; And
Extracting the key frame information from the third response packet
Gt; a < / RTI > client.
A method of operating a server for a streaming service,
Receiving a request packet including a file URL and a parameter;
If the parameter indicates a data request, responding data in an address range corresponding to the parameter in the file corresponding to the file URL; And
If the parameter indicates a request for reproduction information, responding to the reproduction information of the file
Lt; / RTI >
The step of responding to the data
If the parameter includes an index and the header of the request packet includes an address range parameter, responding to the data of the address range corresponding to the index in the file based on the address range parameter
Lt; / RTI >
16. The method of claim 15,
The reproduction information
A resolution of the content stored in the file, a URL of a second file storing a content having a second resolution different from the resolution, and the second resolution.
17. The method of claim 16,
The reproduction information
At least one of a size of the first piece dividing the file and a number of the first pieces, and
At least one of the size of the second piece dividing the second file and the number of the second pieces
Lt; / RTI >
16. The method of claim 15,
Wherein the address range corresponding to the index is determined based on the size of the piece dividing the file.
16. The method of claim 15,
Wherein the server uses the http protocol for communication with the client.
19. A computer program stored in a medium for executing the method of any one of claims 1 to 19 in combination with hardware.

Images