KR102007669B1 - Video on demand Server device for internet broadcasting and operating method thereof - Google Patents

Abstract

The present invention relates to a broadcast receiver and a method of operating the same. A method of operating a broadcast receiver according to the present invention includes receiving and storing media files having different resolutions HEVC Tiled Encoded from a multi-channel distribution transmission server through a multi-cable network, and MPDs generated while DASH processing the received media files. (Media Presentation Description) Indexing files and segment files, MPD files and segment files based on a Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP-Spatial Relationship Description (MPEG-DASH-SRD) according to a client request. Sending to the client. The transmitting may include setting to transmit the next file by referring to the index of the previously transmitted file.

Description

Broadcast receiver and its operation {Video on demand Server device for internet broadcasting and operating method

The present invention relates to a broadcast receiver related to providing content for internet broadcasting and a method of operating the same.

With the development of the Internet network, it is possible to transfer high quality large media files. However, the quality of service (QoS) of the internet network is not yet guaranteed for large media content streaming service, and it is difficult to provide a seamless streaming service to consumers due to limited bandwidth operation.

To solve this problem, it was required to develop a streaming technology capable of adaptively adapting to a network environment, and standardization was carried out under the name of Dynamic Adaptive Streaming over HTTP (DASH) from the international standardization organization Moving Picture Experts Group (MPEG).

MPEG-DASH is a standard for seamlessly serving media contents to users in accordance with the user environment (network and terminal performance, etc.). The standardized scope covered by MPEG-DASH includes MPD (description of media content consumption, combination, and other information). Media Presentation Description), Media Segmentation, a time-based content segmentation technology, Access location technology for downloading / streaming each time-divided file, File format technology supporting MPEG-DASH, MPD according to digital media consumption and storage format Examples include profiling techniques that allow configuration changes.

Korea Patent Registration No. 10-1764317 (registered on July 27, 2017)

On the other hand, even if the content is provided on the basis of the conventional MPEG-DASH, in the case of providing a high-resolution content, it is difficult to provide a seamless content.

Accordingly, an aspect of the present invention is to provide a broadcast receiver and a method of operating the same, which can provide more smooth, seamless or relatively low latency Internet broadcasting content.

According to an embodiment of the present invention, a broadcast receiver includes a first communication circuit forming a communication channel with a multi-channel broadcast distribution server providing a media file of various resolutions, and a second communication circuit forming a communication channel with a client terminal. And a memory configured to store the media file and pieces of media file processed by the DASH (Dynamic Adaptive Streaming over HTTP) process, the first communication circuit, the second communication circuit, and a processing unit electrically connected to the memory. The processing unit receives and stores the media file through a multi-cable network, performs indexing on a media presentation description (MPD) file and segment files generated while DASH processing the received media file, and requests the client. Moving Picture Experts Group-Dynamic Adaptive Streaming over H according to MPEG-DASH-SRD The MPD file and the segment files may be configured to be transmitted to the client based on a spatial relationship description (TTP).

The processing unit may include a cable receiver connected to the multi-channel distribution transmission server, and the cable receiver may include a buffer for dividing and storing the received HEVC tiled encoded media files having different resolutions.

The processing unit may be configured to transmit a next file by referring to index information of a previously transmitted file while transmitting the MPD file and the segment files to the client.

The processing unit may be configured to generate the index information based on time stamp information related to the reception of the media file.

The processing unit may be configured to generate a Client ID according to the client request, and transmit the MPD file, the segment files, and the index information to the client based on the Client ID.

Also, a method of operating a broadcast receiver according to various embodiments of the present disclosure may include receiving and storing media files having different resolutions encoded by HEVC tiled encoding from a multi-channel distribution transmission server through a multi-cable network, and storing the received media file. Indexing MPD (Media Presentation Description) files and segment files generated during DASH processing; Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP-Spatial Relationship Description (MPEG-DASH-SRD) according to the client request And transmitting the MPD file and the segment files to the client based on the setting, and the transmitting may include setting to transmit the next file with reference to the index of the previously transmitted file.

As described above, according to the broadcast receiver and its operation method of the present invention, the present invention can support to provide seamless content or relatively low latency streaming service.

1 is a view showing an example of a system for providing content for internet broadcasting according to an embodiment of the present invention.
2 is a diagram illustrating an example of a configuration of a broadcast receiver according to an embodiment of the present invention.
3 is a diagram illustrating an example of a configuration of a processing unit according to an exemplary embodiment.
4 is a diagram illustrating an example of a cable receiver configuration of a broadcast receiver according to an embodiment of the present invention.
5 is a diagram illustrating an example of a broadcast receiver operating method according to an exemplary embodiment of the present invention.
6 is a diagram illustrating an example of an MPD manager according to an embodiment of the present invention.
7 is a diagram illustrating an example of a segment manager according to an exemplary embodiment.
8 is a diagram illustrating an example of an index manager according to an exemplary embodiment.
9 is a diagram illustrating an example of a dash live connector according to an embodiment of the present invention.
10 is a diagram illustrating a signal flow between a broadcast receiver and a client in a system for providing content for internet broadcasting according to an embodiment of the present invention.

Hereinafter, various embodiments of the present invention will be described with reference to the accompanying drawings. However, it is not intended to limit the present invention to specific embodiments, but it should be understood to include various modifications, equivalents, and / or alternatives of the embodiments of the present invention. In connection with the description of the drawings, similar reference numerals may be used for similar components.

1 is a view showing an example of a system for providing content for internet broadcasting according to an embodiment of the present invention.

Referring to FIG. 1, the system for providing content for internet broadcasting 10 according to an exemplary embodiment may include a transcoder 12, a multi-channel distribution transmission server 15, a broadcast receiver 13 (or a broadcast receiver, or an internet broadcasting server device). ), Client 14 (or client terminal device).

In the above-described Internet broadcasting content providing system 10, the transcoder 12 divides an image (or media file) into a plurality of spaces of the same resolution or a plurality of spaces of different resolutions according to a specified policy and rule. It can be divided by or by a specified time unit. The divided media files (eg HEVC tiled encoded files) may be transmitted to the multi-channel distribution transmission server 15. The multi-channel distribution transmission server 15 may provide the broadcast receiver 13 with an HQ media file, an MQ media file, a Full MQ media file, a MetaInfo file, etc. through multiple cables. The broadcast receiver 13 may perform an MPEG-DASHing operation on the received media files, and provide DASHing processed media file pieces to the client 14 (eg, a display device or a head mounted device (HMD)).

The broadcast receiver 13 performs indexing on the generated MPD file and segment files and manages the indexed media file fragments (eg, MPD file and segment files) in response to the client 14 request. 14) can be provided. As described above, the Internet broadcasting content providing system 10 transmits pieces of media file (or data chunks) based on MPEG-DASH-SRD (Spatial Relationship Description) to the client 14 according to a specified policy or rule. By reducing the load on the data transmission, it is possible to support low latency live streaming or seamless live streaming service.

The transcoder 12 transmits a specific media file such as a 360 VR (Virtual Reality) image or a live relay image to the multi-channel distributed transmission server 15 by tiled encoding (HEVC) or encoding (HEVC). Can be. The transcoder 12 may create tiled information (MetaInfo) corresponding to tiled encoded media files, and transmit the generated tiled information (MetaInfo) to the multi-channel distribution transmission server 15 together with the media file transmission. The transcoder 12 may perform HEVC Tiled Encoding on a high quality image in real time or HEVC Tiled Encoding at a designated time for VOD content. In this operation, the transcoder 12 may divide one image into units of a predetermined size (or space), perform HEVC tiled encoding on the divided media file, and transmit the same to the multi-channel distribution transmission server 15. . The image transmitted by the transcoder 12 to the multi-channel distributed transmission server 15 may include, for example, HQ (high quality image HEVC tiled encoded at least 8K), MQ (heavy quality image encoded at 2K or 4K or higher in HEVC), It may include FullMQ (HEVC encoded medium quality video of 2K or 4K). MetaInfo (or tiled information) may include Meta information (Tile, Bitrate, FPS, bandwidth, etc.) for the above-described HQ and MQ files.

The multi-channel distribution transmission server 15 may receive tiled encoding media files of various resolutions from the transcoder 12. When the first broadcast receiver 13 is connected, the multi-channel distribution transmission server 15 transmits the MetaInfo file to the broadcast receiver 13, and according to the set schedule or the request of the broadcast receiver 13, the HQ media file, MQ At least one of the media file and the full MQ media file (TS format) may be transmitted to the broadcast receiver 13 through multiple cables.

The broadcast receiver 13 may receive media files and MetaInfo files of various resolutions (eg, HQ, MQ, Full MQ) from the multi-channel distribution transmission server 15 through a multi-cable network. The broadcast receiver may perform a dashing operation on the received media file. The broadcast receiver 13 provides media file fragments (eg, MPD file and segment files) on which the desing operation is performed through a streaming service based on MPEG-DASH-Spatial Relationship Description (MPD-DASH-SRD) according to the client 14's request. can do. Dynamic Adaptive Streaming over HTTP (DASH) processed (or Dashing) content may be divided into a sequence of segments based on HTTP.

The client 14 may be connected to the broadcast receiver 13 on the basis of MPEG-DASH and request the broadcast receiver 13 for a selected image according to a user input. The client 14 may receive media file fragments and indexing information (eg, Index List) provided by the broadcast receiver 13, and output the combined media file fragments based on the indexing information. The MPD file is a manifest that contains information such as the content available to the client 14, alternative bit rates provided, and URL address values. May correspond to a file. While parsing the MPD file, the client 14 may obtain information such as program timing, media-content availability, media type, image quality, minimum and maximum bandwidths, usable encoded-alternatives, DRM, and the like. The client 14 may select the encoding according to the network state or the state of the terminal and perform streaming through the HTTP GET Request.

2 is a diagram illustrating an example of a configuration of a broadcast receiver according to an embodiment of the present invention.

2, the broadcast receiver 13 according to an embodiment may include a first communication circuit 110, a second communication circuit 120, a memory 140, and a processing unit 300 (eg, a controller, at least one). Processor, or at least one processing module).

The first communication circuit 110 can form a communication channel that can communicate with the multi-channel distributed transmission server 15. The first communication circuit 110 may include at least one of a wired communication interface or a wireless communication interface. For example, the first communication circuit 110 may form a communication channel through a multiple cable network. The first communication circuit 110 may receive media files of various qualities (or resolutions) transmitted by the multi-channel distributed transmission server 15. The first communication circuit 110 may receive MetaInfo for media files of various qualities transmitted by the transcoder 12.

The second communication circuit 120 can form a communication channel that can communicate with the client 14. The second communication circuit 120 may include at least one of a wired communication interface or a wireless communication interface. For example, the second communication circuit 120 may form a communication channel through an internet network. The second communication circuit 120 may allocate a channel according to the connection of the client 14 and receive an image request signal from the client 14. The second communication circuit 120 may provide the client 14 with media file fragments (eg, MPD file and segment files) corresponding to the image request signal and indexing information corresponding to the media file fragments.

The memory 140 may store various programs or various commands necessary for operating the broadcast receiver 13. For example, the memory 140 may include at least one instruction configured to receive a media file from the multi-channel distributed transmission server 15 based on the first communication circuit 110, the media received from the multi-channel distributed transmission server 15. At least one instruction set to create an MPD file for the file, at least one instruction set to perform segmentation on a received media file, media file fragments to which a DASHing operation has been applied (e.g., MPD file and segment files) At least one instruction configured to perform indexing on the client, at least one instruction configured to receive a request from the client 14 and to transmit media file fragments and indexing information in response to the received request.

The processing unit 300 may perform processing of commands related to the operation of the broadcast receiver 13 and storage management and transmission of data (for example, media file fragments or data chunks). The processing unit 300 may be implemented by at least one processor or may be implemented by at least one software module and operated by a designated processor.

3 is a diagram illustrating an example of a configuration of a processing unit according to an exemplary embodiment.

Referring to FIG. 3, the processing unit 300 according to an embodiment may include a cable receiver 401, a JNI 402 (Java Native Interface), a live TS receiver 310 (LiveTSReceiver), and a live handle thread 320 ( LiveHandleThread), Dashing Module 330 (DashingModule), MPD Manager 350, Segment Manager 360, Index Manager 370, File System 340, Dash Handle Thread 380 (DashHandleThread), Dash Live Connector ( 390) (Dash Live Connector).

The broadcast receiver 13 receives a media file encoded in real time through a broadcast cable network, stores the received media file in a buffer, and dashes the image loaded in the buffer at regular intervals, and generates an index. To manage the dashed files. The broadcast receiver 13 may provide the client 14 with the MPD file and the segment file in chronological order by referring to the index according to the request of the client 14.

The above-described cable receiver 401, JNI 402, live TS receiver 310, live handle thread 320, desing module 330, MPD manager 350, segment manager 360, index manager 370. At least one of the file system 340, the dash handle thread 380, and the dash live connector 390 may be implemented with at least one hardware processor or at least one software module as mentioned above. The above-described processing unit 300 may support an interactive streaming service (or 360-degree VR video service) for realistic VR (Virtual Reality). In this regard, the broadcast receiver 13 transmits the media data related to the real-time VR streaming service (eg HEVC Encoding Files (* .mp4)) or the live relay image from the multi-channel distribution transmission server 15 to tiled encoding (HEVC) or Encoded (HEVC) media data can be received.

The cable receiver 401 may establish a channel with the multi-channel distributed transmission server 15 and receive at least one media file from the multi-channel distributed transmission server 15. For example, the cable receiver 401 may receive media files of various resolutions (eg, HQ, MQ, Full MQ) from the multi-channel distributed transmission server 15. The cable receiver 401 may receive an image through a broadcast cable network. The cable receiver 401 may be implemented with a programming language C / C ++.

The JNI may be disposed between the cable receiver 401 and the live TS receiver 310 to perform interfacing regarding media file delivery of the cable receiver 401 and the live TS receiver 310.

Live TS receiver 310 and live handle thread 320 may receive MetaInfo, HQ, MQ and FullMQ media files that cable receiver 401 receives from transcoder 12 and delivered by JNI 402. The desing module 330 may perform dashing on the received media files, and the index manager 370 may perform indexing on the dashed media file pieces. The dash handle thread 380 and the dash live connector 390 establish a communication channel with the client 14, and in accordance with the request of the client 14, a Media Presentation description (MPD) file and a segment file (* .m4s) may be provided to the client 14. Each component included in the above-described processing unit 300 may be modularized according to a role (function). The processing unit 300 may divide the image into an M4S (MPEG Dash Streaming) file, and the Dashing function for generating the MPD file may be performed based on MPEG-DASH (ISO_IEC_23009).

The procedure of providing the dashed M4S file and the MPD file to the client 14 is performed based on MPEG-DASH (ISO_IEC_23009), and the HTTP URI requested from the client 14 to the broadcast receiver 13 conforms to the HTTP GET protocol. It can be operated based on a protocol (application packet) separately to enable live streaming.

File system 340 may be set to a system that can store the hashed file.

4 is a diagram illustrating an example of a cable receiver configuration of a broadcast receiver according to an embodiment of the present invention.

3 and 4, the cable receiver 401 of the broadcast receiver 13 includes an SDK (Lib) 410 and a cable reader for receiving a media file from the cable reception card 400 corresponding to the first communication circuit. 420 may include a cable reader, a buffer 430, a temporary file system 440, and a receive data loader 450.

The cable reception card 400 may receive HQ, MQ, FullMQ, MetaInfo files transmitted from the multi-channel distribution transmission server 15. The cable reader 420 may read data received by the cable reception card 400, load the data in the buffer 430, and transfer data loaded in the buffer when the callback function is called.

Since the broadcast receiver 13 directly accesses the cable reception card 400 to read a media file, when the SDK (Lib) 410 provided by the cable reception card manufacturer is configured in the programming language C, the cable reader 420 ) May have the form of a library prepared in the programming language C / C ++. The broadcast receiver 13 may load and operate the cable reader 420 using the JNI 402.

The cable reader 420 may be a thread function module that is called upon initialization of a broadcast receiver (or a low latency live streaming server). Using the SDK (Lib) 410 provided by the vendor (cable receiving card manufacturer), the data received by the cable is read out, and the read data is checked and loaded into the HQ, MQ, FullMQ, MetaInfo buffer 430. Can be. When the data received is MetaInfo, the cable reader 420 may receive only one time at the time of initial connection.

The buffer 430 may store media files (eg, HQ, MQ, Full MQ files) and MetaInfo files of various resolutions. When the size (size, number of data) of the buffer 430 is larger than the designated size, the cable reader 420 may store the media file in the temporary file system 440.

The reception data loader 450 is a function called by the broadcast receiver 13 through the JNI 402 as a callback. The received data loader 450 reads the data loaded in the buffer 430 and the temporary file system 440, It may deliver to the live TS receiver 310.

5 is a diagram illustrating an example of a broadcast receiver operating method according to an exemplary embodiment of the present invention.

3 to 5, the live TS receiver 310 may be a thread that is generated and operated in the initialization process of the broadcast receiver 13. The live TS receiver 310 calls the receive data loader 450 of the cable receiver 401 at a set interval to load data, and a sub-thread, for example, a live handle thread 320, which will index and load the loaded data. Can be generated.

The live handle thread 320 generates the m4s and mpd files by desing the media file through the desing module 330, and performs indexing (or index allocation) based on the time stamp obtained in the process of receiving the media file. Can be. The live handle thread 320 adds the hashed result to the caches 353, 363, and 373 of the MPD manager 350, the segment manager 360, and the index manager 370, so that the hashing file corresponds to the latest indexing. Can be cached in memory.

The caches 353, 363, and 373 are designed in a FIFO (First in First out) structure, and Size (number of data, memory size) can be adjusted through Properties.

In relation to the operating method of the broadcast receiver 13, when the broadcast receiver 13 is executed, in operation 501, the live TS receiver 310 may be executed. In operation 503, when the live TS receiver 310 is executed, the cable receiver 401 may execute the cable reader 420.

After waiting for the specified interval time in step 505, the live TS receiver 310 calls the receive data loader 450 of the cable receiver 401 and loads the authored media files into the buffer 430 in step 507. can do.

In operation 509, the live handle thread 320 may be created and executed. In operation 511, indexing and desing of load data may be performed. In step 513, the index manager 370, the segment manager 360, and the MPD manager 350 are operated to store and manage the MPD file, store and manage the segment files, and manage index storage for the MPD file and the segment files. Can be performed. In operation 509, when a request for a next media file to be generated occurs, the broadcast receiver 13 (or the processing unit 300) may branch to step 505 to repeatedly perform the following process.

5 is a diagram illustrating a result of desing and indexing media data according to an embodiment of the present invention.

Referring to FIG. 5, media data desing and indexing results may be displayed on various screens as shown. For example, the broadcast receiver 13 may include a first screen 501 for outputting an indexing list, a second screen 503 for outputting an MPD file list, and a first file list for outputting an original file list according to a user input or a specified job processing result. At least one of the three screens 505 may be output. Alternatively, the broadcast receiver 13 may display one screen including at least one of a first area including an index list, a second area including an MPD file list, and a third area including an original file list according to a setting. You can also output

In this regard, the broadcast receiver 13 may include a display and output at least one screen of the resulted and indexed result screens. In addition, the broadcast receiver 13 may include at least one input device in order to receive a user input related to screen control.

6 is a diagram illustrating an example of an MPD manager according to an embodiment of the present invention.

Referring to FIG. 6, the MPD manager 350 according to an embodiment may include a first index list 351 and an MPD cache 353.

The MPD manager 350 may load the dashed MPD file into the MPD cache 353. Here, when the MPD cache 353 is full, the MPD manager 350 may delete the old MPD file from the MPD cache 353 and load the new MPD file into the MPD cache 353. In addition, the MPD manager 350 may provide the MPD file required by the MPD cache 353 or a designated file (for example, the multi-channel distribution transmission server 15) to the memory 140 when the client 14 requests the MPD file. It can be provided by loading from saved original file).

The MPD cache 353 may be configured as a hash map of a key / value type. For example, a key is an index of a corresponding MPD, a value is a content of an MPD file, and may be a byte array (byte []).

The MPD manager 350 may search for caching of the MPD file using the first index list 351. The MPD manager 350 defines a corresponding index of the last address of the first index list 351 as Delete Ptr, and hashes key / value Cache Data corresponding to the index of the Delete Ptr when the MPD cache 353 is Full. You can delete it from the map.

In relation to the MPD file search, the MPD manager 350 may check the next index of the MPD index that was last transmitted to the client 14 requesting the MPD file through the index manager 370. The index manager 370 may determine the existing index as the latest index when the next index does not exist. The MPD manager 350 may first search for the MPD file in the MPD cache 353, and if it does not exist, read the MPD file from the file (eg, the original file stored in memory) and return it to the dash handle thread 380. have.

7 is a diagram illustrating an example of a segment manager according to an exemplary embodiment.

Referring to FIG. 7, the segment manager 360 according to an embodiment may include a second index list 361, a segment cache 363, and a segment structure 365.

The segment manager 360 may load the dashed segment files into the segment cache 363. When the segment cache 363 is full, the segment manager 360 deletes the segment data corresponding to the old index into the segment cache 363 and loads the currently segmented segment files. In addition, when the segment manager 360 requests segment files from the client 14, the segment manager 360 may load necessary segment files from the segment cache 363 or a file (eg, an original file stored in memory) and provide the segment 14 to the client 14. .

The segment cache 363 may be configured as a hash map of a key / value type. Key is an index, and Value has a hash map structure of Key / Value type again. As in the segment data structure, Key is a Filename and Value is a Byte Array (byte []) structure. It can have a data structure of.

The segment manager 360 may search whether the segment file is caching using the second index list 361. The segment manager 360 defines a corresponding index of the last address of the second index list 361 as Delete Ptr. When the segment cache 363 is Full, the segment manager 360 hashes the key / value Cache Data corresponding to the index of the Delete Ptr. You can delete it from the map.

8 is a diagram illustrating an example of an index manager according to an exemplary embodiment.

Referring to FIG. 8, an index manager 370 according to an embodiment may include a client index map 371 and a third index list 373.

The index manager 370 may generate and manage a time stamp-based index. In this regard, the index manager 370 may generate the client index map 371 and manage the third index list 373 (eg, the last index) for each client ID.

In relation to the MPD file search, the index manager 370 may select a recent index when the client ID does not exist in the client index map. The index manager 370 may request the MPD manager 350 for the MPD file of the selected index.

In relation to the segment file search, the index manager 370 may check whether the index exists in the URI, and if the index exists, request the segment manager 360 to request a segment file of the index. If the index does not exist, the index manager 370 may check the index currently requested by the client index map (ClientIndexMap) based on the Client ID, and may request the segment file of the index file from the segment manager 360.

When the index manager 370 requests the segment file, the segment manager 360 may perform a segment cache 363 search. When searching for the segment cache 363, the segment manager 360 may search the segment list based on the index and search the segment data based on the segment file name. If there is no search result, the segment manager 360 may read a segment file from a file (eg, an original file stored in memory and a file before performing a DASH operation), and return the segment file to the index manager (for example, deliver it to the index manager). .

9 is a diagram illustrating an example of a dash live connector according to an embodiment of the present invention.

Referring to FIG. 9, the dash live connector 390 according to an embodiment may include a dash live connection thread 393 and a dash live connector 391.

The dash live connector 391 may serve to receive an HTTP connection request from the client 14. The dash live connector 391 may generate a dash live connection thread 393 when transmitting an HTTP connection, and deliver and execute an HTTP connection to the dash live connection thread 393. The dash live connector 391 may receive at least one connection request in the same structure as that of the multithreaded socket.

The hash live connection thread 393 is a sub thread generated by the hash connector module 391, and may include a thread for parsing an HTTP URI and performing a corresponding work. The dash live connection thread 393 may operate functions such as run (), parseURI (), sendClientID (), sendMPD (), sendSegment (), and sendIndexList (). run () is a thread's core method, which can determine whether to generate and send a client ID, send an MPD, send a segment, or send an index list based on a parsed URI message. parseURI () can parse and provide an HTTP URI to run (). sendCientID () may receive a client ID, an MPD, a segment file, an index list, and the like from run (), and transmit the received information to the corresponding client 14. sendClientID (), sendMPD (), sendSegment (), and sendIndexList () can each transmit Client ID, MPD file, segment file, and index list.

10 is a diagram illustrating a signal flow between a broadcast receiver and a client in a system for providing content for internet broadcasting according to an embodiment of the present invention.

Referring to FIG. 10, in relation to a signal flow between the broadcast receiver 13 and the client 14 according to an embodiment, in operation 1001, the client 14 may request a client ID from the broadcast receiver 13. For example, the client 14 may send a http: // {ip_address}: {dash_live_port} / GET_CLIENT_ID message to the broadcast receiver 13. In response, the broadcast receiver 13 may generate a Client ID corresponding to the client 14 and transmit the Client ID to the client 14 in step 1003. For example, the broadcast receiver 13 may deliver the af074e8c-2702-40b1-b0c8-657216394e24 value to the client 14.

The client 14 may request the MPD file from the broadcast receiver 13 in step 1005. In this regard, the client 14 may transmit a message including http: // {ip_address}: {dash_live_port} / GET_MPD? Client_id = af074e8c-2702-40b1-b0c8-657216394e24 to the broadcast receiver 13.

The broadcast receiver 13 may transmit the MPD file requested by the client 14 to the client 14 in step 1007.

The client 14 may request consecutive segment files from the broadcast receiver 13 in step 1009. In this regard, the client 14 may send a message to the broadcast receiver 13 including http: // {ip_address}: {dash_live_port} / {segment_file_name}? Cleint_id = af074e8c-2702-40b1-b0c8-657216394e24. .

When the broadcast receiver 13 receives a message for requesting a segment file from the client 14, the broadcast receiver 13 may transmit the corresponding segment file to the client 14 in step 1011. When the client 14 receives the segment file, in step 1013, the client 14 may request the broadcast receiver 13 for the last segment file (eg, an (N) segment file) of the consecutive segment files. The broadcast receiver 13 may transmit the corresponding segment file to the client 14 in step 1015. In the above-described operation, the broadcast receiver 13 may perform transmission of the next file based on the last index information of the previously transmitted file (for example, MPD file or segment files).

When the reception of the segment files is completed, the client may branch to step 1005 according to user input or according to a scheduled process to repeatedly perform the following operation.

The embodiments disclosed in the above-described document are presented for the purpose of explanation and understanding of the disclosure, and are not intended to limit the scope of the invention. Accordingly, the scope of the present disclosure should be construed as including all changes or various other embodiments based on the technical spirit of the present disclosure.

12: transcoder
13: broadcast receiver
14: Client
15: multicast channel distribution server
110: first communication circuit
120: second communication circuit
140: memory
300: processing unit

Claims (6)

First communication circuitry for establishing a communication channel with a multi-channel broadcast distribution server providing media files of various resolutions;
Second communication circuitry forming a communication channel with a client terminal;
A memory for storing the media file and pieces of media file obtained by processing the media file with DASH (Dynamic Adaptive Streaming over HTTP);
And a processing unit electrically connected to the first communication circuit, the second communication circuit, and the memory.
The processing unit
Receive and store the media files through multiple cable networks,
Indexing the media presentation description (MPD) file and segment files generated while DASHing the received media file,
In response to a client request, the MPD file and the segment files are transmitted to the client based on a Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP-Spatial Relationship Description (MPEG-DASH-SRD),
A broadcast receiver configured to transmit a next file by referring to index information of a previously transmitted file while transmitting the MPD file and the segment files to the client. The method of claim 1,
The processing unit
A cable receiver connected to the multi-channel distribution transmission server;
And a buffer for dividing and storing the HEVC tiled encoded media files having different resolutions received by the cable receiver. delete The method of claim 1,
The processing unit
And a broadcast receiver configured to generate index information based on time stamp information associated with receiving the media file. The method of claim 1,
The processing unit
And generating a Client ID according to the client request, and transmitting the MPD file, the segment files, and the index information to the client based on the Client ID. Receiving and storing media files having different resolutions HEVC Tiled Encoded from a multi-channel distribution transmission server through a multi-cable network;
Indexing the media presentation description (MPD) file and the segment files generated while DASHing the received media file;
And transmitting the MPD file and the segment files to the client based on MPEG-DASH-SRD (Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP-Spatial Relationship Description).
The transmitting step
And transmitting the next file by referring to the index of the previously transmitted file.

Images