WO2017150753A1 - Procédé de traitement de données ott basé sur une mise en mémoire tampon adaptative dynamique - Google Patents

Procédé de traitement de données ott basé sur une mise en mémoire tampon adaptative dynamique Download PDF

Info

Publication number
WO2017150753A1
WO2017150753A1 PCT/KR2016/002220 KR2016002220W WO2017150753A1 WO 2017150753 A1 WO2017150753 A1 WO 2017150753A1 KR 2016002220 W KR2016002220 W KR 2016002220W WO 2017150753 A1 WO2017150753 A1 WO 2017150753A1
Authority
WO
WIPO (PCT)
Prior art keywords
media
channel
file
player
current
Prior art date
Application number
PCT/KR2016/002220
Other languages
English (en)
Korean (ko)
Inventor
김인기
강민구
한경식
Original Assignee
주식회사 큐버
한신대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 큐버, 한신대학교 산학협력단 filed Critical 주식회사 큐버
Publication of WO2017150753A1 publication Critical patent/WO2017150753A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations

Definitions

  • the present invention relates to an OTT data processing technique with adaptive buffering for transmission at a video bitrate that dynamically optimizes HLS.
  • the video stream between the multi-layer bit rate and the bandwidth regulator is adjusted through metering for client bandwidth capacity.
  • the channel zapping delay time when the media channel is switched by additionally setting a buffer in the conventional HLS and each buffer continuously buffers the previous channel and the next channel relative to the current channel.
  • Broadcasting can be broadly classified into traditional RF based broadcasting and Internet protocol based IP broadcasting.
  • RF-based broadcasting is a technology that provides a broadcasting service, and is divided into satellite broadcasting, terrestrial broadcasting, and cable broadcasting according to the type of transmission media.
  • the standards for each are DVB-S / S2, ATSC, DVB-T / It is divided into T2, DVB-C, and ISDB.
  • Such RF-based broadcasting has a transmission infrastructure that has been transmitting digital broadcasting stably for a long time.
  • Due to the limited frequency band it is difficult to add additional broadcasting services and additional services.
  • 4K UHD broadcasting has recently begun, the frequency occupied by one broadcasting channel becomes very large, and the frequency is shortly used up to 32Mbps.
  • the quality of broadcasting channels is changing to higher quality, the shortage of frequencies is expected to intensify.
  • IP broadcasting based on the Internet Protocol is a technology for providing a broadcasting service through the Internet, and again, multicast-based IPTV (Internet Protocol Television) and one-way broadcasting based over-the-top (OTT).
  • IPTV Internet Protocol Television
  • OTT over-the-top
  • IPTV Internet Protocol Television
  • Can be subdivided into IPTV uses a managed network and is serviced at a bandwidth within 100 Mbps.
  • OTT serves broadcast and VOD over unmanaged networks and uses one-way broadcast.
  • OTT OTT was to provide premium video services such as movies and broadcast programs through third-party providers provided through IP networks (public networks), rather than existing telecommunications and broadcasting companies, for example, Netflix. .
  • IP networks public networks
  • Netflix existing telecommunications and broadcasting companies
  • multimedia content such as data, advertisement, and e-commerce is included as a service area.
  • OTT has the advantage of increasing the channel indefinitely.
  • the method of providing a broadcast stream in OTT that is, the streaming transmission method is HTTP, HLS, RTP, RTSP, but HLS is the most widely used.
  • HTTP Live Streaming is Apple's protocol for iOS 3.0 and QuickTime X in 2009.
  • HLS streaming data is stored in an MPEG-2 Transport Stream (TS), which is divided into pieces of time and transmitted to a media player, and information about which file to play is transmitted to the media player through an m3u8 file.
  • TS MPEG-2 Transport Stream
  • HLS became widespread as the number of iPhone and iPad users increased, and the standard was simple and the Internet Engineering Task Force (IETF) standardization made it easier for non-Apple companies to support HLS.
  • IETF Internet Engineering Task Force
  • Adobe supported HLS in Flash Media Server 4.0, Microsoft supported HLS in IIS Media Server 4.0, and Google Android began supporting HLS in version 2.0 of Honeycomb.
  • OTT services can be implemented on most operating systems, including iOS, Linux, Android, and HTM5.
  • OTT uses a one-way broadcasting scheme and operates in an unmanaged network
  • QoS cannot be guaranteed and buffering or dropping may occur. Since this can be a limitation to stable service, it is important to optimize the buffering algorithm to improve the dropout and channel switching speed.
  • the present invention proposes a method for reducing the buffering time and providing a stable service by optimizing the dynamic buffering algorithm based on the HLS-based adaptive streaming.
  • a stable streaming service can be implemented in a mobile device and a PC.
  • Hyoung-Gook Kim "Enhanced Timing Recovery Using Active Jitter Estimation for Voice-Over IP Networks," KSII Transactions on Internet and Information Systems Vol. 6, No. 4, Apr. 2012
  • each buffer can reduce the channel zapping delay when switching media channels by continuously buffering the previous and next channels relative to the current channel. It is to provide OTT data processing technology.
  • the OTT data processing method based on the dynamic adaptive buffering according to the present invention provides an initial bit rate of an image corresponding to a network bandwidth to an HLS server and provides streaming of a media file for current content according to the initial bit rate.
  • a first step of receiving and reproducing A second step of detecting a dynamic bit rate corresponding to the network bandwidth of the corresponding time point and providing the HLS server to the media file according to the detected dynamic bit rate; A third step of identifying next play candidate media data for the current media file; Receiving, by the HLS server, multiple streaming of the next play candidate media data; A fifth step of performing dynamic buffering on next playback candidate media data provided through multiple streaming; And identifying a change request of the media file, ending the playback of the current media file and switching to the next playback candidate media data playback operation by utilizing the media file data which has been subjected to the above dynamic buffering.
  • the next play candidate media data may include a media file of contents provided in an adjacent media channel to be displayed by channel up / down operation according to the organization of the OTT broadcast.
  • the first step includes creating and pre-pairing the current media player (mp_cur)
  • the fourth step includes creating one or more switching media players for the adjacent media channel while creating the current media player (mp_cur). Generating and switching the address of the next play candidate media data per adjacent media channel; and setting a data source URL for the media player
  • the fifth step is to set a pre-pair for the switched media player and switch on detecting an onPreapared call. Registering the media player as the next media flare for the current media player (mp_cur) and playing the broadcast content of the current media channel through the current media player (mp_cur), wherein the sixth step identifies the channel switching input Switch media player corresponding to the channel switch input. The operation may be performed by playing the contents of the adjacent media channel.
  • the adjacent media channel is configured to include a channel down media channel and a channel up media channel for the current media channel, and the switching media player selects the first switching media player (mp_chdown) and the channel up media channel for the channel down media channel. And a second switching media player (mp_chup) for the second step.
  • the channel switching input is a channel-down button manipulation in step 6
  • the first switching media player (mp_chdown) is operated to play broadcast contents of the channel down media channel.
  • the second switching media player mp_chup may be operated to play broadcast content of the channel-up media channel.
  • the next play candidate media data may include media files of contents arranged in the following order in the current media channel, subsequent TS files of the current media file in the current media channel, and advertisements or PPLs to be inserted in the middle of the current contents according to OTT broadcasting. It may comprise one or more of the images.
  • the third step may include identifying one or more subsequent TS files following the current TS file in the current media file as next play candidate media data
  • the fourth step may include a plurality of steps within a network bandwidth allowance.
  • the first step may include generating a first media player (Player 0) and playing a media file of the current content
  • the fourth step may generate a second media player (Player 1) and a next playback candidate. And setting an address of the media data to a data source URL for the second media player (Player 1), and if the fifth step is to set a pre-pair for the second media player (Player 1) and detect an onPreapared call And registering the second media player (Player 1) as the next media player for the first media player (Player 0), wherein the sixth step is the playback of the current content by the first media player (Player 0). When this is completed, the second media player Player 1 is automatically started.
  • the computer-readable recording medium is a computer program for executing the above-described dynamic adaptive buffering-based OTT data processing method.
  • the present invention it is possible to obtain an advantage of implementing a stable OTT broadcast service by shortening the buffering time by optimizing a dynamic buffering algorithm based on HLS-based adaptive streaming.
  • the channel zapping delay time can be reduced when switching media channels through multi-channel dynamic buffering.
  • FIG. 2 is a diagram illustrating a concept of implementing adaptive bit rate streaming in response to network bandwidth change in HLS.
  • Figure 3 is a comparison table showing the technical features of the HLS compared with other technical standards.
  • FIG. 5 is a diagram conceptually illustrating a correspondence relationship between an m3u8 file and a stream segment in HLS.
  • FIG. 6 is a diagram illustrating an example in which m3u8 file changes over time in HLS.
  • FIG 8 illustrates the concept of streaming one piece of content over multiple file transfer sessions in dynamic buffering.
  • FIG. 9 is a flowchart illustrating a processing process of single channel dynamic buffering.
  • 10 and 11 are flowcharts illustrating a processing process of multichannel dynamic buffering.
  • FIG. 13 is a diagram illustrating a test result of channel zapping delay time according to a change of network bandwidth for performance evaluation of dynamic buffering.
  • FIG. 14 is a view showing a test result of the channel zapping delay time according to the change of the video bit rate for the performance evaluation of dynamic buffering.
  • HLS-based adaptive streaming (HLS Adaptive Streaming) used in OTT.
  • HLS-based adaptive streaming consists of five steps.
  • HLS transmits video data in stream segments, that is, H.265 MPEG-2 TS video, in order to implement adaptive bit rate live and VOD video transmission.
  • a stream segment is conceptually a number of TS files that are chopped up.
  • TS means an MPEG-2 transport stream.
  • HLS provides information on the configuration of these stream segments in an m3u8 file.
  • m3u is called a multimedia playlist and is a file that manages a playlist of multimedia files.
  • An m3u8 file is a UTF-8 encoded m3u file that is an index file that provides information to the media player to identify which segments of which stream are available in HLS. The method of using m3u8 in the HLS will be described later with reference to FIGS. 4 to 6.
  • the media player automatically selects the most suitable stream from the manifest file based on the current available communication speed and its processing power, downloads the segment file and adds it to the video playback buffer.
  • the HLS server 200 is a combination of the Media Origin Server 220 and the HTTP Cache Server 210 in FIG. 1 and receives an HTTP request from a client device (video player, media player; 100). It serves to provide an HTTP response to the player. Specifically, the request is received from the player according to the HTTP format, and the requested file is found and included in the response message as it is provided to the player.
  • FIG. 2 is a diagram illustrating a concept of implementing adaptive bit rate streaming in response to a network bandwidth change in HLS.
  • HLS supports adaptive bit rate streaming, which detects the network speed that is being placed while the user is moving and selects and plays appropriate content.
  • adaptive bitrate streaming is applied, video playback continues without failure even if the user's network environment changes.
  • a user moves to a mobile communication network (eg, LTE) environment while using a streaming service for live broadcasting in a wireless LAN (Wi-Fi) environment.
  • a mobile communication network eg, LTE
  • Wi-Fi wireless LAN
  • the video data is not properly received from the moment the user enters the mobile communication network environment, and the buffering occurs continuously or the normal screen display fails due to lack of data.
  • the mobile service when the mobile network environment is detected, the mobile service automatically switches to the live service of the mobile communication network environment, so that the quality and resolution of the playback screen may be degraded. .
  • 3 is a comparison table showing the technical features of the HLS compared to other technical standards.
  • HLS transfers data over the HTTP protocol, which provides several advantages over other technical specifications that use Real-Time Streaming Protocol (RTSP), Real-time Transport Protocol (RTP), Real-Time Messaging Protocol (RTMP), and others.
  • RTSP Real-Time Streaming Protocol
  • RTP Real-time Transport Protocol
  • RTMP Real-Time Messaging Protocol
  • HLS has advantages: reduced infrastructure costs, cache capabilities in the Content Delivery Network (CDN) and other HTTP caching infrastructures, reduced risk of being blocked by proxies and firewalls, real-time optimization based on client estimation, and high reliability of the format itself. , Ease of implementation of the HTML5 player, and the like.
  • CDN Content Delivery Network
  • HTTP caching infrastructures reduced risk of being blocked by proxies and firewalls
  • real-time optimization based on client estimation and high reliability of the format itself.
  • Ease of implementation of the HTML5 player and the like.
  • the technical characteristics of the HLS is shown in FIG. 3 in comparison with other adaptive bit rate video service technology, 3GPP / MPEG DASH.
  • FIG. 4 is a diagram conceptually illustrating a method of using an m3u8 file in the HLS.
  • the m3u format is a technology originally used in the field of audio streaming that is a multimedia playlist file that stores a list of MP3 files for continuous playback in a media player. Each line is a very simple structure describing the path of a file to be played.
  • the m3u format had a limitation that only the Latin-1 character set could be written. Since the m3u format simply lists the files, the media player could not know the information about the file to play from the m3u file. Accordingly, the m3u format has been extended to define the m3u8 format for use in streaming services.
  • the m3u8 format can use the UTF-8 character set, and it is possible to use the various directives to provide the media player with information about the file being played.
  • HLS uses m3u8 file, which is briefly described as follows.
  • the first line of the m3u8 file must begin with # EXTM3U.
  • the # EXTM3U directive tells the media player that the file uses the m3u8 format.
  • An example of an m3u8 file used by the HLS is disclosed on the left side of FIG. 4, and an example of a stream segment managed by the m3u8 file is disclosed on the right side of FIG. 4.
  • the # EXT-X-TARGETDURATION directive has a syntax of '# EXT-X-TARGETDURATION: ⁇ time: seconds>' and indicates the maximum playback time of each file listed in the file list.
  • the # EXT-X-MEDIA-SEQUENCE directive has the syntax "# EXT-X-MEDIA-SEQUENCE: ⁇ serial number of first file>" and specifies the serial number of the file that the media player should play first. 4 shows that the 0 file must be played first among three files (0, 1, 2).
  • the #EXTINF directive has the syntax '#EXTINF: ⁇ time: seconds>, ⁇ title>' and specifies the playback time and title of the content specified after the directive.
  • Fig. 4 the titles of three TS files are presented and the playback time is 2 seconds.
  • FIG. 5 is a diagram conceptually illustrating a correspondence relationship between an m3u8 file and a stream segment for supporting adaptive bit rate streaming in HLS.
  • HLS can provide information about TS files of multiple bitrates simultaneously.
  • a representative index file (main index file) representing a whole is provided in an m3u8 format, and an alternate index file corresponding to a playlist file for each bit rate under the representative index file is m3u8. In format.
  • a replacement index file is shown corresponding to three bit rates.
  • the replacement index file indicates TS files corresponding to respective bit rates, that is, stream segments.
  • the bit rate of the m3u8 file that comes first in the representative index file has the most optimal bit rate value in the streaming service.
  • the media player requests low bit rate data, such as 128 kbps, at the start of video playback, so that the media player will play low quality video for a while, even if the network bandwidth of the media player is sufficient to play high quality video.
  • FIG. 6 is a diagram illustrating an example in which m3u8 file is changed over time in the HLS.
  • the m3u8 file is continuously changed every time a segment file (TS file) is generated in the HLS server 200.
  • TS file segment file
  • TS file is created 5 times after 2 seconds. You can add a line to the TS file number 5 at the end of the m3u8 file. However, if the line adds the content specified in the m3u8 file, the media player requesting streaming after TS file 5 is created will request 4, 4, or 4 TS files for content playback.
  • This increases the waiting time for the initial start and increases the time difference between the actual video and the video playing on the media player.
  • a user who requests streaming at an unlucky timing has a problem of waiting for video playback for a considerably long time.
  • the m3u8 file is requested, and the TS files recorded in the m3u8 file are requested and provided to the HLS server 200.
  • the media player starts playing the first TS file.
  • the file segment-000002.ts which is the first TS file, is played.
  • the media player plays the next TS file by referring to the playlist of the m3u8 file when the playing of the TS file currently being played is completed, and simultaneously obtains the updated playlist by requesting the m3u8 file from the HLS server 200.
  • the media player acquires the updated m3u8 file while playing the next TS file, the segment-000003.ts file, in the playlist.
  • the updated m3u8 file there are TS files with serial numbers of 3, 4, and 5.
  • the media player plays TS files continuously to provide a seamless picture as if the user plays a single video file.
  • the HLS server 200 generates a TS file so that video data included in each divided TS file does not overlap in time or excessively space time.
  • Steps S100 to S140 First, the client device 100 requests the HLS server 200 to check a bit rate, and correspondingly, the HLS server 200 sends a client a bit rate check packet for a currently connected broadcast service. Transmit to the device 100.
  • the client device 100 In response to the bit rate check packet from the HLS server 200, the client device 100 detects an initial bit rate of an appropriate image in consideration of the current network bandwidth and provides the result to the HLS server 200. Correspondingly, the HLS server 200 streams the media file for the current content according to the corresponding initial bit rate provided from the client device 100. The client device 100 plays the current content by using the video data received through streaming.
  • Step S150 to S170 the network bandwidth can be changed at any time
  • the client device 100 detects the appropriate dynamic bit rate along the network bandwidth at that time, and sends the detected dynamic bit rate to the HLS server 200. to provide.
  • the HLS server 200 streams the media file of the current content according to the detected dynamic bit rate.
  • Step S180 The client device 100 checks the media file currently being played and confirms next play candidate media data for it.
  • the next play candidate media data may refer to a next content video file to be presented next to a content currently playing in a current media channel or a subsequent TS file of the current content.
  • the next play candidate media data may mean a broadcast content image file currently provided in another media channel.
  • the next content image file of the current media channel includes a media file of the content arranged in the next order of the current content in the broadcast schedule, an advertisement or a PPL image to be inserted in the middle of the current content.
  • a subsequent TS file of the current content refers to a TS file that is arranged after the TS file currently being used for the current screen display among the series of TS files (stream segments) constituting the current content and is to be used later.
  • the broadcast content video file of another media channel includes a media file of content provided in an adjacent media channel to be displayed by a channel up / down operation in a broadcast schedule.
  • Steps S190 and S200 Then, the client device 100 requests the HLS server 200 to multi-stream the next play candidate media data, and correspondingly, the HLS server 200 responds to the next play candidate media. Provide multiple streaming of data to the client device 100. In this case, a plurality of file transfer sessions are established between the HLS server 200 and the client device 100, and multiple streaming is performed through these sessions.
  • Step S210 The client device 100 performs dynamic buffering on the next play candidate media data provided through the multi-streaming from the HLS server 200. This dynamic buffering is performed as a background process for the current media file playback task.
  • the dynamic buffering operation performed when the next playback candidate media data is the next content video file or the subsequent TS file of the current content in the media channel currently being viewed is referred to herein as single channel dynamic buffering.
  • Single channel dynamic buffering will be described later with reference to FIG. 9, and the processing process performed when the next playback candidate media data is a subsequent TS file of the current content will be described in detail later with reference to FIG.
  • multichannel dynamic buffering the dynamic buffering operation performed when the next playback candidate media data is a broadcast content video file of a different media channel.
  • Multichannel dynamic buffering will be described later with reference to FIGS. 10 and 11.
  • Step S220 When the client device 100 identifies the change request of the media file, the client device 100 ends the playback of the current media file and performs the above dynamic buffering, and then switches to the playback operation of the playback candidate media data.
  • the client device 100 terminates the playback of the current media file and starts the playback operation of the next playback candidate media data so that channel switching is performed.
  • the client device 100 detects a request for content change by an end event of a content that is currently being viewed or a content temporary change event (for example, play of an intermediate advertisement), the client device 100 ends the playback of the current content and outputs the next play candidate media data. To start playing.
  • the client device 100 when the client device 100 detects the end (completion) of playback of the current TS file for the current content, the client device 100 starts playback of a TS file that is next to the current TS file among subsequent TS files.
  • the term 'dynamically buffering means that the streaming and buffering of the media file is performed for the other content that may be played back in addition to the content currently being viewed on the client device 100 according to the situation at that time. Indicates that it is done in advance. In addition, it indicates that streaming and buffering are performed in advance not only for the TS file currently required in one content but also for the TS file that is considered to be needed in the future.
  • the term 'simultaneously' or 'at once' in the present specification does not mean physically the same time, it means that a variety of things are not done sequentially and other things are performed before the previous one is finished.
  • FIG. 8 is a diagram illustrating a concept of streaming one content through a plurality of file transfer sessions in dynamic buffering.
  • Steps S300 and S310 First, the client device 100 requests an m3u8 file for the corresponding media channel for which the user is watching the content to the HLS server 200, and correspondingly, the HLS server 200 sends a request to the HLS server 200.
  • the m3u8 file for the media channel is provided to the client device 100.
  • the HLS server 200 provides the m3u8 file for the media channel to the client device 100 and utilizes it in the related art.
  • Steps S320 and S330 The client device 100 and the HLS server 200 simultaneously establish a plurality of file transfer sessions within the limits allowed according to the network bandwidth while referring to the m3u8 file. These file transfer sessions are for streaming TS files for the media file of the content currently being viewed.
  • a condition for simultaneously streaming a plurality of TS files is established.
  • the HLS server 200 simultaneously transmits a plurality of TS files through respective file transfer sessions, thereby allowing the client device 100 not only to download TS files for the content but also to expect TS files to be needed in the future. Stream in advance.
  • the client device 100 establishes four file transfer sessions and receives streaming files from the HLS server 200 at the same time as the 000002.ts file and the 000005.ts file.
  • Step S340 The client device 100 receives a plurality of TS files at the same time (in parallel) with respect to the media file of the content currently being viewed, and buffers them in the buffer memory 150.
  • TS files currently needed among the plurality of TS files provided at the same time are put in the basic buffering space to play the current contents, and TS files received in advance that are expected in the future are put in the dynamic buffering space for future contents playback.
  • the buffer memory 150 is logically divided into a plurality of areas and managed.
  • Step S350 If the client device 100 detects that the current TS file has been completed, the client device 100 starts to play the next TS file among the subsequent TS files.
  • the dynamic playback of the TS file which is expected to be required in the future, is performed in advance with respect to the content currently being viewed, so that the playback of the content does not occur. In other words, even if the network bandwidth suddenly becomes poor, content playback is not interrupted and a smooth playback can be obtained.
  • 9-12 illustrate a processing process for dynamic buffering in accordance with the present invention.
  • the present invention proposes an optimization technique for adaptive buffering through a dynamic buffering framework, and proposes single channel dynamic buffering and multichannel dynamic buffering.
  • 9 shows a process of processing single channel dynamic buffering between content files in one media channel
  • FIGS. 10 and 11 show a process of processing multichannel dynamic buffering performed between adjacent media channels.
  • single-channel dynamic buffering proposes a buffering technique for seamless media conversion in dynamically playing multiple media streams in the same media channel.
  • Single-channel dynamic buffering provides the effect of smoothing media transitions, which can be applied to the situation where an advertisement is dynamically inserted during an on-demand broadcast as well as the situation where one broadcast content is finished and the next broadcast content is passed.
  • multi-channel dynamic buffering achieves fast channel switching by minimizing the time required for buffering the content file when channel switching occurs between different media channels due to channel up / down user manipulation.
  • Media switching by user manipulation e.g. channel up / down, channel button input, etc.
  • Multi-channel dynamic buffering can be used as a model to improve service and efficiently manage network bandwidth through fast switching between channels in OTT service operating multiple media channels.
  • the OTT service uses an open network with no QoS guarantees, so there is no guarantee of network bandwidth. Accordingly, the OTT service currently in operation has been found to take up to 3 ⁇ 4 seconds to switch media channels, the application of multi-channel dynamic buffering can be used to quickly switch between media channels can solve the conventional problem .
  • FIG. 9 is a flowchart illustrating a processing process of single channel dynamic buffering.
  • a first media player Player 0 is created and content is played.
  • Player 0 Create a first media player (Player 0) for the current media channel, set the data source URL, set the display, and set the preparation. Then, a media playback related listener is registered with the first media player, the media format of the audio / video is set, and content playback starts.
  • the media streaming HLS address of the m3u8 format is required for media setting in the media player, and the HLS server 200 is required for media streaming. Also, for dynamic buffering, there must be a media address for each bit rate, which is defined in the m3u8 file.
  • This first step is represented by a pseudo code:
  • a second media player Player 1 is created and pre-set.
  • a second media player Player 1 for playing next content in the current media channel is created and set.
  • the second media player Player 1 communicates with the HLS server 200 to perform dynamic buffering for the next content.
  • a time point for generating the second media player Player 1 may be selected in consideration of the performance of the client device.
  • the second media player Player 1 is registered as the next media flare for the first media player Player 0.
  • the media pre-pair is completed among the media listeners registered for the second media player Player 1 to detect the onPreapared call.
  • the second media player Player 1 is registered as a media player to play the next content with respect to the first media player Player 0 currently playing content.
  • This third step is represented by a pseudo code:
  • This fourth step is represented by a pseudo code:
  • 10 and 11 are flowcharts illustrating a processing process of multichannel dynamic buffering.
  • Multi-channel dynamic buffering enables fast channel switching by reducing the initial buffering time immediately after switching channels when switching media channels by user operation such as channel up / down by dynamically buffering media files to be played for multiple media channels in advance. To provide.
  • a current media channel refers to a channel that the user is currently watching
  • a channel-down media channel refers to a channel-down button operation when the user inputs a CH-DOWN button operation.
  • the channel-up media channel refers to a channel to be moved when the user inputs a CH-UP button operation.
  • the concept of multi-channel dynamic buffering is to dynamically buffer the channel-down media channel and the channel-up media channel adjacent to the current media channel in advance so as to respond quickly when a media channel change occurs.
  • the user's UX can be improved by quickly switching between channels in an OTT broadcasting service that operates a plurality of media channels.
  • the network bandwidth may not be good at the instant of channel switching, the operation efficiency of the network bandwidth may be improved.
  • two transition media players are created in advance in addition to the current media player (mp_cur) that plays the broadcast content currently being watched, and one of the transition media players according to the channel up / down situation ( Registers mp_chdown or mp_chup as the next media player to play content after the current media player (mp_cur). This enables natural content playback when switching channels.
  • the buffering of the switching media player (mp_chdown, mp_chup) is performed before the next media player (mp_chdown or mp_chup) starts playing content. It is performed in advance. Since the buffering of the content file is performed in advance, the screen cutout caused by the buffering is minimized immediately after the channel change.
  • a current media player (mp_cur) is created and prepared for the current media channel being broadcasted.
  • mp_cur For the current media channel, set the data source URL, set the display, and set the pair. Then, a media playback related listener is registered for the current media player (mp_cur), the media method of audio / video is set, and content playback starts.
  • the media streaming HLS address of the m3u8 format is required for media setting, and the HLS server 200 is required for media streaming. Also, for dynamic buffering, there must be a media address for each bit rate, which is defined in the m3u8 file.
  • a transition media player (mp_chdown, mp_chup) is created and configured for a media channel adjacent to the current media channel.
  • a conversion media player for playing content in a channel down media channel and a channel up media channel is also created and set to a pre-pair state. That is, it creates a switching media player (mp_chdown, mp_chup), sets a data source URL, sets a display, and sets a pair. Then, register a media playback-related listener for the switching media player and set the media format of the audio / video.
  • the process of creating a conversion media player and setting up a pair is performed by multitasking at the time of creating the current media player (mp_cur), and is performed after the current media player (mp_cur) starts playing the content of the current media channel. It does not have to be.
  • transition media players mp_chdown and mp_chup are registered as the next media players for the current media player mp_cur.
  • This third step is represented by a pseudo code:
  • a fourth step the broadcast content for the current media channel is played through the current media player (mp_cur), which is generated earlier.
  • the fourth step is expressed as a pseudo code as follows.
  • a channel switching input eg, a user's channel up / down button manipulation
  • content switching is performed to the switching media player (mp_chdown or mp_chup) correspondingly.
  • the switching media player (mp_chdown or mp_chup) previously registered by setNextMediaPlayer is automatically played.
  • the switching media player (mp_chup) for the channel-up media channel is played.
  • the switching media player (mp_chdown) for the channel-down media channel is played. do. Since dynamic buffering of the next content for these switching media players has already been performed, channel switching can be achieved immediately without delay.
  • This fifth step is represented by a pseudo code:
  • the channel channeled media channel is set as the current channel through the above process, and the current media player (mp_cur) and the switched media player (mp_chdown and mp_chup) are reset.
  • the media channel that the switching is completed and newly viewed by the user is used as the current channel again, and the processes of FIGS. 10 and 11 are performed based on this.
  • FIG. 12 is a diagram illustrating simulation conditions for performance evaluation of dynamic buffering.
  • the channel zapping time is significantly improved compared to the prior art by applying the multi-channel dynamic buffering of the present invention.
  • the channel zapping delay time is maintained at a constant level (eg, less than 1 second).
  • the channel zapping delay time increases significantly.
  • FIG. 13 is a diagram illustrating a test result of channel zapping delay time according to a change in network bandwidth for performance evaluation of dynamic buffering. To this end, we fixed the bit rate of each video to 6 Mbps and measured the channel zapping delay time while adjusting the network bandwidth in the WLAN router.
  • channel zapping latency is always excellent without being affected by network bandwidth.
  • FIG. 14 is a diagram illustrating a test result of channel zapping delay time according to a change of an image bit rate for performance evaluation of dynamic buffering.
  • the channel zapping delay time was measured while changing the bit rate of the image while fixing the network bandwidth of the WLAN router to 20 Mbps.
  • channel zapping delay time As a result of the measurement, the effect of improving the channel zapping delay time according to the present invention was confirmed. As the bit rate of the image increases, the effect of improving the performance increases. In addition, according to the present invention, channel zapping delay time was always excellent without being affected by the video bit rate.
  • the invention can also be embodied in the form of computer readable codes on a computer readable recording medium.
  • the computer-readable recording medium includes all kinds of recording devices in which data that can be read by a computer system is stored.
  • Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, and the like, which may be implemented in the form of a carrier wave (eg, transmission over the Internet). .
  • the computer readable recording medium can also store and execute computer readable code in a distributed manner over networked computer systems. And functional programs, codes, and code segments for implementing the present invention can be easily inferred by programmers in the technical field to which the present invention belongs.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

La présente invention se rapporte à une technologie de traitement de données OTT avec une mise en mémoire tampon adaptative pour une transmission à un débit binaire vidéo qui optimise de façon dynamique un HLS. La présente invention lit une capacité de largeur de bande de client de sorte à commander un flux vidéo entre un débit binaire multicouche et un dispositif de réglage de largeur de bande. En particulier, un schéma de mise en mémoire tampon dynamique multicanal de la présente invention configure en outre une mémoire tampon pour un HLS existant et chaque mémoire tampon met en mémoire tampon en continu, à l'avance, un canal relativement précédent et un canal relativement ultérieur d'un canal actuel. Par conséquent, la présente invention peut de manière avantageuse réduire un temps de retard de zapping de canal pendant une commutation de canal multimédia.
PCT/KR2016/002220 2016-03-04 2016-03-05 Procédé de traitement de données ott basé sur une mise en mémoire tampon adaptative dynamique WO2017150753A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2016-0026673 2016-03-04
KR1020160026673A KR101780247B1 (ko) 2016-03-04 2016-03-04 동적 적응 버퍼링 기반의 ott 데이터 처리 방법

Publications (1)

Publication Number Publication Date
WO2017150753A1 true WO2017150753A1 (fr) 2017-09-08

Family

ID=59744129

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/002220 WO2017150753A1 (fr) 2016-03-04 2016-03-05 Procédé de traitement de données ott basé sur une mise en mémoire tampon adaptative dynamique

Country Status (2)

Country Link
KR (1) KR101780247B1 (fr)
WO (1) WO2017150753A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102195516B1 (ko) * 2018-11-01 2020-12-29 카테노이드 주식회사 방송 서비스 제공 장치, 방송 서비스 수신 장치 및 이를 이용한 방송 서비스 송수신 시스템

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010085043A2 (fr) * 2009-01-22 2010-07-29 에스케이 텔레콤주식회사 Système et procédé de transmission d'images
WO2012011743A2 (fr) * 2010-07-20 2012-01-26 한국전자통신연구원 Appareil et procédé de fourniture de contenus diffusés en continu
WO2012039576A2 (fr) * 2010-09-20 2012-03-29 ㈜휴맥스 Procédé de traitement destiné à être mis en oeuvre en présence d'un commutateur d'expression au cours d'une transmission http en continu
US20140013376A1 (en) * 2012-07-05 2014-01-09 Motorola Mobility Llc Methods and devices for efficient adaptive bitrate streaming
WO2014069905A1 (fr) * 2012-10-31 2014-05-08 삼성전자 주식회사 Procédé et appareil pour la transmission et la réception de segments de contenu multimédia au moyen d'un procédé de diffusion en continu à débit adaptatif

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9398061B2 (en) * 2014-05-14 2016-07-19 Google Inc. Simulating broadcast television channel surfing for on-demand content

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010085043A2 (fr) * 2009-01-22 2010-07-29 에스케이 텔레콤주식회사 Système et procédé de transmission d'images
WO2012011743A2 (fr) * 2010-07-20 2012-01-26 한국전자통신연구원 Appareil et procédé de fourniture de contenus diffusés en continu
WO2012039576A2 (fr) * 2010-09-20 2012-03-29 ㈜휴맥스 Procédé de traitement destiné à être mis en oeuvre en présence d'un commutateur d'expression au cours d'une transmission http en continu
US20140013376A1 (en) * 2012-07-05 2014-01-09 Motorola Mobility Llc Methods and devices for efficient adaptive bitrate streaming
WO2014069905A1 (fr) * 2012-10-31 2014-05-08 삼성전자 주식회사 Procédé et appareil pour la transmission et la réception de segments de contenu multimédia au moyen d'un procédé de diffusion en continu à débit adaptatif

Also Published As

Publication number Publication date
KR20170103575A (ko) 2017-09-13
KR101780247B1 (ko) 2017-09-20

Similar Documents

Publication Publication Date Title
WO2013089437A1 (fr) Dispositif et procédé pour recevoir un contenu multimédia
WO2011071290A2 (fr) Procédé et appareil de diffusion en continu fonctionnant par insertion d'un autre contenu dans un contenu principal
WO2011059291A2 (fr) Procédé et appareil permettant de transmettre et de recevoir des données
WO2012060581A2 (fr) Procédé d'émission/réception de contenu multimédia et dispositif d'émission/réception l'utilisant
WO2011152675A2 (fr) Procédé et appareil de transmission en continu adaptative sur la base de plusieurs éléments pour déterminer une qualité de contenu
WO2011059272A2 (fr) Procédé et appareil permettant d'offrir un service trick play
WO2011105811A2 (fr) Procédé et appareil pour transmettre et recevoir des données
WO2013055191A2 (fr) Appareil et procédé pour la configuration d'un message de contrôle dans un système de radiodiffusion
WO2012177041A2 (fr) Procédé de transmission et de réception de contenu multimédia et appareil de transmission et de réception utilisant ce procédé
WO2012011724A2 (fr) Procédé de transmission/réception de fichiers multimédia et dispositif de transmission/réception correspondant
WO2013141666A1 (fr) Procédé de transmission et procédé de réception hybrides pour un contenu vidéo svc empaqueté dans un mmt
WO2011059273A2 (fr) Procédé et appareil de diffusion adaptative en flux qui utilise la segmentation
WO2011083934A2 (fr) Procédé de connexion d'une communication vidéo à un autre dispositif, appareil de communication vidéo et appareil d'affichage de celui-ci
WO2012030178A2 (fr) Procédé et dispositif pour fournir un flux de données de contenu
WO2012011735A2 (fr) Procédé et appareil permettant de transmettre et de recevoir un contenu basé sur un mécanisme de diffusion en flux adaptatif
WO2012047028A2 (fr) Appareil et procédé de fourniture de contenu multimédia en temps réel
WO2015012605A1 (fr) Procédé et appareil de codage de contenu tridimensionnel
WO2013025035A2 (fr) Dispositif d'émission, dispositif de réception et procédé d'émission-réception correspondant
WO2012033319A2 (fr) Appareil et procédé pour fournir un contenu en flux continu
WO2011115454A2 (fr) Procédé et appareil pour diffuser en continu de manière adaptative un contenu comportant plusieurs chapitres
WO2012011722A2 (fr) Procédé de transmission/réception d'un flux de transport multimédia et dispositif de transmission/réception correspondant
WO2017209574A1 (fr) Procédé et dispositif de fourniture d'un contenu multimédia
WO2017024876A1 (fr) Procédé et dispositif de diffusion de programme de télévision
WO2011115426A2 (fr) Procédé permettant une découverte de services iptv et récepteur iptv utilisant ce dernier
WO2017200209A1 (fr) Émetteur-récepteur de signaux de diffusion et procédé d'émission/de réception

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16892766

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 16892766

Country of ref document: EP

Kind code of ref document: A1