WO2019107595A1

WO2019107595A1 - Broadcast receiver and operation method therefor

Info

Publication number: WO2019107595A1
Application number: PCT/KR2017/013807
Authority: WO
Inventors: 박우출; 김현욱; 양진욱; 김용화; 윤상필
Original assignee: 전자부품연구원
Priority date: 2017-11-29
Filing date: 2017-11-29
Publication date: 2019-06-06
Also published as: KR102007669B1; KR20190062818A

Abstract

The present invention pertains to a broadcast receiver, and an operation method therefor. A method for operating a broadcast receiver according to the present invention comprises the steps of: receiving from a multi-channel distribution transmitting server, via multiple cable networks, media files that are encoded using HEVC tiling, and that have different resolutions from one another, and storing the same; indexing a media presentation description (MPD) file that is generated by means of DASH processing of the received media files, and segment files; and transmitting to a client the MPD file and segment files based on moving picture experts group-dynamic adaptive streaming over HTTP-spatial relationship description (MPEG-DASH-SRD) according to a request from the client. The transmission step includes a step of configuring such that an index of a previously transmitted file is referred to to transmit the next file.

Description

Broadcast receiver and its operation method

BACKGROUND OF THE INVENTION 1. Field of the Invention [0002] The present invention relates to a broadcast receiver related to providing contents for Internet broadcasting and a method of operating the same.

With the development of the Internet network, it is becoming possible to transmit high-quality large-capacity media files. However, QoS (Quality of Service) of the Internet network is not guaranteed for high capacity media content streaming service, and it is difficult to provide continuous streaming service to consumers due to limited bandwidth operation.

In order to solve this problem, it was required to develop a streaming technology adaptable to the network environment, and the standardization was carried out under the name of DASH (Dynamic Adaptive Streaming over HTTP) in the Moving Picture Experts Group (MPEG), an international standardization organization.

MPEG-DASH is a standard for seamlessly serving media contents to users in accordance with user environment (network and terminal performance, etc.). The standard scope covered by MPEG-DASH is MPD Media Segmentation technology as a time-based content segmentation technology, access location technology capable of downloading / streaming each time-divided file, file format technology supporting MPEG-DASH, MPD And profiling techniques to change the configuration.

On the other hand, even if the content is provided on the basis of MPEG-DASH in the past, there is a problem that it is difficult to provide continuous contents in the case of providing high-resolution contents.

Accordingly, it is an object of the present invention to provide a broadcast receiver and a method of operating the same that can provide smooth, seamless, or relatively low-latency Internet broadcast contents.

According to an embodiment of the present invention, a broadcast receiver of the present invention includes a first communication circuit for forming a communication channel with a multi-channel broadcast distribution server for providing media files of various resolutions, a second communication circuit A memory for storing the media file and media file fragments processed by dynamic adaptive streaming over HTTP (DASH) processing; and a processing unit electrically connected to the first communication circuit, the second communication circuit, and the memory The processing unit receives and stores the media file through the multiple cable network, performs indexing on the MPD (Media Presentation Description) file and the segment files generated while DASH processing the received media file, According to MPEG-DASH-SRD (Moving Picture Experts Group - Dynamic Adaptive Streaming over H The MPD file and the segment files based on a TTP-Spatial Relationship Description (TTP).

The processing unit may include a cable receiver coupled to the multi-channel distribution transmission server, and the cable receiver may include a buffer for separating and storing the HEVC Tiled-Encoded media files having different resolutions.

The processing unit may be configured to transmit the next file while referring to the index information of the 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 to transmit the MPD file, the segment files, and the index information to the client based on the client ID.

Also, the broadcasting receiver operating method according to various embodiments of the present invention includes receiving and storing media files having different resolutions HEVC Tiled Encoding from a multi-channel distribution transmission server through a multiple cable network, Performing indexing of a MPD (Media Presentation Description) file and segment files generated during DASH processing, a Moving Picture Experts Group (MPEG-DASH-SRD) And transmitting the MPD file and the segment files to the client based on the index of the previously transmitted file, wherein the transmitting includes setting the transmission of the next file by referring to the index of the previously transmitted file.

As described above, according to the broadcast receiver of the present invention and the method of operating the same, the present invention can support seamless content provisioning or relatively low-delay streaming service.

1 is a diagram illustrating an example of a content providing system for Internet broadcasting according to an embodiment of the present invention.

2 is a diagram illustrating an example of a broadcast receiver configuration 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 embodiment of the present invention.

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

5 is a diagram illustrating an example of a method of operating a broadcast receiver according to an 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 embodiment of the present invention.

8 is a diagram illustrating an example of an index manager according to an embodiment of the present invention.

9 is a view showing 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 an Internet broadcast content providing system according to an embodiment of the present invention.

Various embodiments of the invention will now be described with reference to the accompanying drawings. It should be understood, however, that the invention is not intended to be limited to the particular embodiments, but includes various modifications, equivalents, and / or alternatives of the embodiments of the invention. In connection with the description of the drawings, like reference numerals may be used for similar components.

1, a content providing system 10 for Internet broadcasting according to an exemplary embodiment includes a transcoder 12, a multi-channel distribution server 15, a broadcast receiver 13 (or a broadcast receiver, ), And a client 14 (or a client terminal device).

The transcoder 12 divides an image (or a Media file) into a plurality of spaces having the same resolution or a plurality of spaces having different resolutions according to a specified policy and rules Or by a specified time unit. The divided media files (e.g., HEVC Tiled encoded files) may be transmitted to the multi-channel distribution transmission server 15. The multi-channel distribution transmission server 15 can provide the HQ media file, the MQ media file, the full MQ media file, the MetaInfo file, and the like to the broadcast receiver 13 through the multiple cables. The broadcast receiver 13 may perform MPEG-DASHing operations on the received media files and may provide DASHing processed media file fragments to the client 14 (e.g., a display device, an HMD (Head Mounted Device)).

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

The transcoder 12 transmits a specific media file, for example, 360 VR (Virtual Reality) image or live relay image, to the multi-channel distribution transmission server 15 by Tiled Encoding (HEVC) or Encoding (HEVC) . The transcoder 12 may generate Tiled information (MetaInfo) corresponding to the tiled encoded media files and transmit the generated Tiled information (MetaInfo) to the multi-channel distribution transmission server 15 when the media file is transmitted. The transcoder 12 can perform HEVC Tiled Encoding in real time on a high-quality image or perform HEVC Tiled Encoding on a VOD content at a designated time. In this operation, the transcoder 12 divides one image into units of a predetermined size (or space), sequentially performs HEVC tiled encoding on the divided media files, and transmits the HEVC to the multi-channel distribution transmission server 15 . The image transmitted from the transcoder 12 to the multi-channel distribution transmission server 15 includes, for example, HQ (HEVC Tiled Encoded high quality image of 8K level or higher), MQ (HEVC Tiled Encoded medium quality image of 2K or 4K level or higher) FullMQ (2K or 4K class HEVC encoded middle quality image). The MetaInfo (or Tiled information) may include the above-described HQ, Meta information (Tile, Bitrate, FPS, bandwidth, etc.) for the MQ file.

The multi-channel distribution transmission server 15 can receive the Tiled Encoding media files of various resolutions from the transcoder 12. When the initial broadcast receiver 13 is connected, the multichannel distribution server 15 transmits the MetaInfo file to the broadcast receiver 13, and transmits the MetaInfo file to the broadcast receiver 13 according to the schedule set or at the request of the broadcast receiver 13, A media file, and a full MQ media file (TS format) to the broadcast receiver 13 over multiple cables.

The broadcast receiver 13 can receive media files of various resolutions (e.g., HQ, MQ, Full MQ) and MetaInfo files from the multi-channel distribution transmission server 15 through the multiple cable networks. The broadcast receiver may perform a dashing operation on the received media file. The broadcast receiver 13 provides pieces of media files (e.g., MPD files and segment files) on which a dubbing operation has been performed through a streaming service based on MPEG-DASH-SRD (Spatial Relationship Description) can do. Dynamic Adaptive Streaming over HTTP (DASH) processed (or dashed) content can be segmented into a sequence of segments based on HTTP.

The client 14 is connected to the broadcast receiver 13 on the basis of MPEG-DASH, and can request the broadcast receiver 13 to select the image according to the user input. The client 14 may receive media file fragments and indexing information (e.g., Index List) provided by the broadcast receiver 13, and may combine received media file fragments based on indexing information. The MPD file is a Manifest file containing information such as content available to the client 14, alternative bit rates, and URL address values. File. The client 14 may obtain information such as program timing, media-content availability, media type, image quality, minimum and maximum bandwidths, encoded-alternatives available, and DRM while parsing the MPD file. The client 14 can perform streaming through an HTTP GET request after selecting an encoding suitable for the network state or the state of the terminal.

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

The first communication circuit 110 may form a communication channel with which the multi-channel distributed transmission server 15 can communicate. 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 multiple cable networks. The first communication circuit 110 may receive media files of varying quality (or resolution) transmitted by the multi-channel distribution transmission server 15. The first communication circuit 110 may receive MetaInfo for media files of varying quality that the transcoder 12 transmits.

The second communication circuit 120 may form a communication channel with which the client 14 may communicate. 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 the Internet network. The second communication circuit 120 can allocate a channel according to the connection of the client 14 and receive the video request signal from the client 14. [ The second communication circuit 120 may provide the client 14 with indexing information corresponding to media file fragments (e.g., MPD files and segment files) and media file fragments corresponding to the video request signal.

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 of instructions configured to receive a media file from a multi-channel distribution transmission server 15 based on the first communication circuit 110, a medium received from the multi- At least one command set to create a MPD file for a file, at least one command set to perform segmentation on a received media file, media file fragments (e.g., MPD file and segment files) to which a DASHing operation is applied, At least one instruction set to perform the indexing on the client 14, receive the request of the client 14, and store at least one instruction set to transmit the media file fragments and indexing information in response to the received request.

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

3, a processing unit 300 according to an exemplary embodiment includes a cable receiver 401, a Java Native Interface (JNI) 402, a live TS receiver 310 (Live TSReceiver), a live handle thread 320 LiveHandleThread), a dashing module 330 (DashingModule), an MPD manager 350, a segment manager 360, an index manager 370, a file system 340, a dash handle thread 380 (DashHandleThread) 390 (Dash Live Connector).

The broadcast receiver 13 receives the media file segmentally encoded in real time through the broadcast cable network, stores the received media file in the buffer, dashes the image stored in the buffer every predetermined period, generates an index To manage dashing files. The broadcast receiver 13 can provide the client 14 with an MPD file and a segment file corresponding to the time sequence by referring to the Index in response to the request of the client 14. [

The above-described cable receiver 401, JNI 402, live TS receiver 310, live handle thread 320, dashing 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 dashboard connector 390 may be implemented as at least one hardware processor or as at least one software module as described above. The processing unit 300 may support an interactive streaming service (or a 360-degree VR image service) for a real-type VR (Virtual Reality). In this regard, the broadcast receiver 13 receives media data (e.g., HEVC Encoding Files (*. Mp4)) related to the real-time VR streaming service from the multi-channel distribution transmission server 15 or Tiled Encoding (HEVC) Encoding (HEVC) media data can be received.

The cable receiver 401 may form a channel with the multi-channel distribution transmission server 15 and may receive at least one media file from the multi-channel distribution transmission server 15. [ For example, the cable receiver 401 can receive media files of various resolutions (e.g., HQ, MQ, Full MQ) from the multi-channel distribution transmission server 15. The cable receiver 401, which receives an image through a broadcast cable network, can be implemented in a programming language C / C ++.

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

The live TS receiver 310 and the live handle thread 320 may receive the MetaInfo received by the cable receiver 401 from the transcoder 12 and delivered by the JNI 402 and HQ, MQ and FullMQ media files. The dashing module 330 performs dashing on the received media files, and the index manager 370 can perform indexing on DASHed media file fragments. Dash handle thread 380 and dhs live connector 390 form a communication channel with client 14 and provide a Media Presentation description (MPD) file and a Segments file (*) according to the MPEG- gt; m4s < / RTI > Each of the configurations included in the above-described processing unit 300 may be modularized according to a role (function). The processing unit 300 may divide an image into M4S (MPEG Dash Streaming) files and perform a dashing function for generating an MPD file based on MPEG-DASH (ISO_IEC_23009).

The procedure for providing the dubbed 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 separate protocol (application packet) to enable live streaming.

The file system 340 may be set up as a system capable of storing the dossied file.

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

The cable receiving card 400 can receive HQ, MQ, FullMQ, and MetaInfo files transmitted from the multi-channel distribution transmission server 15. The cable reader 420 reads the data received from the cable receiving card 400 and loads the buffered data into the buffer 430 and transmits the data stored in the buffer when the callback function is called.

The broadcasting receiver 13 directly accesses the cable receiving card 400 to read the media file. Therefore, when the SDK (Lib) 410 provided by the cable receiving card manufacturer is configured in the programming language C, the cable receiver 420 ) Can have a library form provided by the programming language C / C ++. The broadcast receiver 13 can load and operate the cable reader 420 or the like using the JNI 402. [

The cable reader 420 may be a thread function module that is invoked upon initialization of the broadcast receiver (or low latency live streaming server). (Lib) 410 provided by a vendor (cable receiving card manufacturer) to read the data received through the cable, check the read data, and load the data in the HQ, MQ, FullMQ, MetaInfo buffer 430 . The cable reader 420 can receive only one time on the initial connection when the received data is MetaInfo.

The buffer 430 may store media files of various resolutions (e.g., HQ, MQ, Full MQ files) and a MetaInfo file. If the size (size, number of data) of the buffer 430 is greater than the specified size, the cable reader 420 may store the media file in the temporary file system 440.

The reception data loader 450 is a function for calling the broadcast receiver 13 through the JNI 402 through a callback and reads the data stored in the buffer 430 and the temporary file system 440 to read the data stored in the buffer 430 and the temporary file system 440, To the live TS receiver 310.

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 for each set interval to load the data and indexes and dashes the loaded data to a live subthread, Lt; / RTI >

The live handle thread 320 generates the m4s and mpd files by dying the media file through the dashing module 330 and performs indexing (or index assignment) based on the timestamp obtained in the process of receiving the media file . The live handle thread 320 adds the delegated result to the

caches

353, 363, and 373 of the MPD manager 350, the segment manager 360, and the index manager 370, To cache in the memory.

The

caches

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

With respect to the operation method of the broadcast receiver 13, when the broadcast receiver 13 is executed, in step 501, the live TS receiver 310 can be executed. In operation 503, when the live TS receiver 310 is executed, the cable receiver 401 can execute the cable reader 420.

The live TS receiver 310 calls the reception data loader 450 of the cable receiver 401 in step 507 and loads the loaded media files into the buffer 430 can do.

In step 509, a live handle thread 320 may be created and executed. In step 511, index creation and de-loading of the 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, manage the index storage for the MPD file and the segment files Can be performed. In step 509, when a request for a next media file to be dubbed occurs, the broadcast receiver 13 (or the processing unit 300) branches to step 505 and repeats the following process.

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

Referring to FIG. 5, the media data dashing and indexing results may be displayed in 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, a second screen 503 for outputting an original file list, 3 screen 505. [0156] Fig. 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 Output.

In this regard, the broadcast receiver 13 may include a display, and may output at least one screen of a dying and indexed result screen. In addition, the broadcast receiver 13 may include at least one input device for receiving user input related to screen control.

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 can load the dashed MPD file in the MPD cache 353. [ Here, if the MPD cache 353 is Full, the MPD manager 350 deletes the old MPD file from the MPD cache 353, and loads the new MPD file into the MPD cache 353. The MPD manager 350 also sends the MPD file required by the client 14 to the MPD cache 353 or a specified file such as the multichannel distribution transmission server 15 and provided to the memory 140 (Stored in the original file).

The MPD cache 353 may comprise a key / value hash map (HashMap). For example, Key is the Index of the corresponding MPD, Value is the contents of the MPD file, and may be a Byte Array (byte []).

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

In connection with the MPD file search, the MPD manager 350 can check the next index of the MPD index that was last transmitted to the client 14 that requested the MPD file through the index manager 370. The index manager 370 can determine that the existing index is the latest index if the next index does not exist. The MPD manager 350 first searches the MPD cache 353 for an MPD file and if not, reads the MPD file from a file (e.g., the original file stored in memory) and returns it to the dash handle thread 380 have.

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 segmented files (Segment Files) into the segment cache 363. The segment manager 360 may delete the segment data corresponding to the old index in the segment cache 363 when the segment cache 363 is full and load the currently dashed segment files. The segment manager 360 may also request the segment files from the client 14 to load the necessary segment files from the segment cache 363 or from a file such as a source file stored in memory and provide them to the client 14 .

The segment cache 363 may be configured with a key / value hash map (HashMap). Key is an index and Value is a hash map structure in the form of a key / value. The structure is a filename, and a value is a byte array (byte []) structure as in a segment data structure Of data structure.

The segment manager 360 can search for the caching of the segment file using the second index list 361. [ The segment manager 360 defines the corresponding index of the last address of the second index list 361 as Delete Ptr and if the segment cache 363 is Full, the segment manager 360 stores the key / value cache data corresponding to the index of the Delete Ptr as a hash You can delete it from the map.

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

The index manager 370 can create and manage timestamp-based indexes. In this regard, the index manager 370 may generate the client index map 371 and manage the third index list 373 (e.g., the last index) by client ID.

With respect to the MPD file search, the index manager 370 can select the latest index if no client ID exists in the client index map. The index manager 370 can request the MPD manager 350 of the MPD file of the selected index.

With respect to the segment file search, the index manager 370 can check whether or not there is an index in the URI, and if the index exists, request the segment manager 360 of the index file. If the index does not exist, the index manager 370 can check the currently requested index in the client index map (ClientIndexMap) based on the client ID, and request the segment manager 360 for the segment file of the corresponding index.

When the index manager 370 requests a segment file, the segment manager 360 may perform a segment cache 363 search. When searching for the segment cache 363, the segment manager 360 can search the segment list based on the index and retrieve the segment data based on the segment filename (Segments filename). The segment manager 360 may read the segment file from the file (e.g., the original file stored in the memory, before performing the DASH operation) and return it (e.g., deliver it to the index manager) if the search result does not exist .

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 dhs live connector 391 can perform a role of receiving an HTTP connection request from the client 14. [ The dhs live connector 391 may create a dhs live connection thread 393 at the time of HTTP connection, and may transmit and execute the HTTP connection to the dhs live connection thread 393. The dhs live connector 391 may receive at least one connection request to the extent that the system allows, in the same structure as the multi-thread socket.

The dash live connection thread 393 is a sub-thread generated by the dash connector module 391 and may include a thread that parses an HTTP URI to perform a corresponding work. The dhs live connection thread 393 may operate functions such as run (), parseURI (), sendClientID (), sendMPD (), sendSegment (), sendIndexList (), and so on. The run () method is the core method of the thread. It can determine whether client ID generation and transmission, MPD transmission, segment transmission, and index list transmission are performed according to the parsed URI message. parseURI () can parse an HTTP URI and provide it to run (). sendCientID () may receive the client ID, MPD, segment file, index list, etc. from run () and may send the received information to the client 14. sendClientID (), sendMPD (), sendSegment (), and sendIndexList () can perform Client ID transfer, MPD file transfer, segment file transfer and index list transfer respectively.

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

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

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

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

When the broadcast receiver 13 receives a message requesting a segment file from the client 14, the broadcast receiver 13 may transmit the segment file to the client 14 in step 1011. [ Upon reception of the segment file, the client 14 may request the broadcast receiver 13 of the last segment file (e.g., (N) Segment file) of the continuous segment files in step 1013. [ The broadcasting receiver 13 may transmit the corresponding segment file to the client 14 in step 1015. [ In the above-described operation, the broadcast receiver 13 can perform transmission of the next file based on the last index information of the previously transmitted file (e.g., MPD file or segment files).

When the reception of the segment files is completed, the client branches to step 1005 and repeats the following operations according to the user input or according to the scheduled process.

The embodiments disclosed in the above-mentioned document are presented for the description and understanding of the disclosed contents, and do not limit the scope of the present invention. Accordingly, the scope of this document should be interpreted to include all modifications based on the technical idea of the present invention or various other embodiments.

[Description of Symbols]

12: Transcoder

13: Broadcast receiver

14: Client

15: Multiple broadcast channel distribution server

110: first communication circuit

120: Second communication circuit

140: Memory

300: Processing unit

Claims

A first communication circuit forming a communication channel with a multi-channel broadcast distribution server providing media files of various resolutions;

A second communication circuit forming a communication channel with the client terminal;

A memory for storing media file and media file fragments processed by dynamic adaptive streaming over HTTP (DASH) processing of the media file;

And a processing unit electrically connected to the first communication circuit, the second communication circuit, and the memory,

The processing unit

Receiving and storing the media file through the multiple cable network,

Indexing the MPD (Media Presentation Description) file and the segment files generated while DASH processing the received media file,

And to transmit the MPD file and the segment files to the client based on MPEG-DASH-SRD (Dynamic Adaptive Streaming over HTTP) according to the client request.
The method according to claim 1,

The processing unit

A cable receiver coupled to the multi-channel distribution transmission server;

And a buffer for separating and storing HEVC Tiled Encoded media files of different resolutions received by the cable receiver.
The method according to claim 1,

The processing unit

And to transmit the next file while referring to the index information of the previously transmitted file while transmitting the MPD file and the segment files to the client.
The method according to claim 1,

The processing unit

And generate the index information based on time stamp information related to reception of the media file.
The method according to claim 1,

The processing unit

And generates a client ID according to the client request, and transmits the MPD file, the segment files, and the index information to the client based on the client ID.
Receiving and storing HEVC Tiled Encoded media files having different resolutions from a multi-channel distribution transmission server through a multiple cable network;

Performing indexing on a MPD (Media Presentation Description) file and segment files generated while DASH processing the received media file;

And transmitting the MPD file and the segment files to the client based on MPEG-DASH-SRD (Dynamic Adaptive Streaming over HTTP - Spatial Relationship Description) according to the client request,

The transmitting step

And setting the transmission of the next file by referring to the index of the previously transmitted file.