JP6626696B2 - Receiving device, manifest updating method, and program - Google Patents

Description

  The present invention relates to a receiving device that receives live streaming, a manifest updating method, and a program.

  In recent years, a moving image distribution service by streaming has become widespread on the Internet. For example, a VOD (Video On Demand) service that receives content selected from a distribution server at the timing requested by a user, or a live streaming of a sport or event is performed. In addition, broadcast-type live streaming, which distributes programs one after another according to the schedule, is expected to become popular in the future.

  In streaming video distribution on the Internet in recent years, a transition from a streaming distribution method using a dedicated server and a dedicated protocol to a streaming distribution method using a general-purpose Web server using the HTTP protocol has been progressing. Mainstream in distribution. As such a streaming distribution system (adaptive streaming) based on the HTTP protocol, an original technology by an IT vendor is widespread, and MPEG-DASH (ISO / IEC23009-1) which is an international standard intended to unify these streaming systems. ) Was formulated.

  Both technologies have the same basic concept. The web server divides a stream of video content encoded with one or more qualities (screen size and bit rate) into files of several seconds to several tens of seconds each. A manifest file that describes objects (segments) and attributes and URLs of the moving image contents is prepared. The receiving terminal receives the segments one after another according to the URL described in the manifest file, and connects and reproduces the segments with one moving image content (for example, see Non-Patent Document 1).

  FIG. 6 shows the concept of the streaming distribution system based on the HTTP protocol. In FIG. 6, the content encoded by the live encoder is divided according to the progress of time, and segments 1 to 6 are sequentially generated (for example, see Non-Patent Document 2). Similarly, the contents of the manifest file are updated as segments are generated. Segments registered in the manifest file are registered in such a manner that URLs of segments 1 to 3 are registered in the leftmost manifest file, and URLs of segments 2 to 4 are registered in the next manifest file. URLs slide sequentially by a certain number.

  The segment and the manifest file are sequentially supplied to the Web server. The receiving terminal receives the manifest file from the Web server, and sequentially receives the segments registered in the manifest file using the HTTP protocol. The receiving terminal can receive the live streaming by receiving the updated manifest file and repeating the process of receiving the newly registered segment.

  In addition, when updating the manifest file, by adding segments that are sequentially generated without deleting temporally past segments from the manifest file, it is possible to play back to the beginning of the program while it is live streaming In addition, a service that enables a user to seek to an arbitrary playback position in the past and view the content is also widespread.

  In order to continuously watch live streaming, it is necessary to appropriately obtain an updated manifest file. For such an update of the manifest file, a subsequent request is transmitted to the server, and if the playlist file (manifest file) received as a response is different from the playlist file received last time, the playlist is updated after the first period. A method is known in which a subsequent request for a file is transmitted to a server, and if they do not differ, a subsequent request is transmitted to the server after a second period (for example, see Patent Document 1). This method is intended to always obtain a manifest file in which the latest segments are described.

JP-T-2012-514276A

“Technical Overview of Next-Generation Video Distribution Technology“ MPEG-DASH ”and Standardization / Related Technology Trends”, Journal of the Institute of Image Information and Television Engineers, Vol. 67, No. 2, 2013, pp. 109-115. RGB Networks, "Comparing Adaptive HTTP Streaming Technologies" November 2011 <URL: http://www.bogotobogo.com/VideoStreaming/Files/iis8/RGB#Adaptive#HTTP#Streaming#Comparison#1211-01.pdf>

  Depending on the user's viewing method, the latest segment information may not always be needed. For example, there is a case where the user watches the program retrospectively, or a case where the user views the program with a certain delay (for example, one hour) from the latest segment. However, in the conventional method, even in such a case, the manifest file is frequently updated, so that the load on the network and the distribution server due to the update of the manifest file is large.

  An object of the present invention, which has been made in view of such circumstances, is to provide a streaming receiving apparatus and a manifest updating method capable of reducing the update load of a manifest file in live streaming.

In order to solve the above problems, a receiving device according to the present invention is a receiving device that receives live streaming, a manifest obtaining unit that obtains and updates a manifest file, and a current playback time or a newly designated playback. A playback control unit that outputs a time, and determines a live playback reference time that is a playback time retroactive by a fixed delay time from the playback end time of the latest segment described in the manifest file, and the playback time is the live playback. If it is before the reference time, the update cycle of the manifest file is set to a long time, and if the playback time is after the live playback reference time, the update cycle of the manifest file is set to a short time. And a manifest update control unit.

Furthermore, in the receiving device according to the present invention, when the update cycle is set to a long time during a seek operation, the manifest acquisition unit acquires the latest manifest file, and the manifest update control unit includes the latest update file. and determining said live playback reference time based on the manifest file of.

Further, in order to solve the above problem, a manifest updating method according to the present invention is a manifest updating method in a receiving device that receives live streaming, wherein a step of acquiring and updating a manifest file, Outputting the playback time specified in the step (a), and determining a live playback reference time that is a playback time retroactive by a certain delay time from the playback end time of the latest segment described in the manifest file, and wherein the playback time is If it is before the live playback reference time, the update cycle of the manifest file is set to a long time, and if the playback time is after the live playback reference time, the update cycle of the manifest file is set to a short time. And setting to

  Further, in order to solve the above problem, a program according to the present invention causes a computer to function as the receiving device.

  According to the present invention, when the viewing method does not necessarily require the latest segment information, by setting the update period of the manifest file to a long period, the load on the network and the distribution server due to the update of the manifest file is reduced. It becomes possible to reduce.

FIG. 2 is a diagram illustrating a configuration example of a receiving device according to an embodiment of the present invention. It is a figure showing an example (excerpt) of a manifest file. 6 is a flowchart illustrating an operation of the receiving device according to an embodiment of the present invention from application activation to reproduction start. 6 is a flowchart illustrating an operation during reproduction of the receiving device according to the embodiment of the present invention. 6 is a flowchart illustrating a seek operation of the receiving device according to the embodiment of the present invention. FIG. 2 is a diagram illustrating the concept of a streaming distribution system based on the HTTP protocol.

  Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

  First, the manifest file prepared in the distribution server will be described. In the present embodiment, as an example, the manifest file is in an MPD (Media Presentation Description) format of MPEG-DASH (ISO / IEC23009-1).

  FIG. 2 shows an example (excerpt) of the manifest file. The MPD format has a hierarchical structure in the order of Period, AdaptationSet, and Representation.

  Period indicates a section that divides the program in the time direction (one or more). Period consists of one or more AdaptationSets. In the example of FIG. 2, there is one AdaptationSet.

  The AdaptationSet indicates information of media components (video, audio, text, etc.), and can include a plurality of components having different parameters (bit rate, screen size, number of audio channels, etc.) in the same media. In the example of FIG. 2, there is one component.

  Representation indicates information of each media component included in the AdaptationSet, and is composed of one or more segments.

SegmentTemplate included in AdaptationSet indicates information on a template of a URL of a segment. The SegmentTimeline indicates a list in which the start time and the duration of each segment included in the MPD file are associated. Specifically, the <S> tag in the sixth to twelfth lines in FIG. 2 indicates the time information of the segment, the value of t indicates the reproduction start time of the segment, and the value of d indicates the duration of the segment. . Based on the timescale (90000) of the AdaptationSet, the start time and the duration are calculated as follows. From this, it can be seen that segments from 0 seconds to 60.06 seconds exist in this MPD file, and the duration of each segment is 2.002 seconds.
6th line: start time = t / timescale = 0, duration = d / timescale = 2.002,
Line 7: Start time = t / timescale = 2.002, duration = d / timescale = 2.002,
8th line: start time = t / timescale = 4.004, duration = d / timescale = 2.002,
12th line: start time = t / timescale = 58.058, duration = d / timescale = 2.002

  As described above, the URL of the segment at a certain playback time is obtained by extracting the <S> tag including the playback time, and extracting the template “live #” extracted from the media value in the fourth line by the extracted <S> tag t. v1 # $ Time $ .mp4 ”can be obtained by replacing $ Time $.

  minimumUpdatePeriod indicates the minimum delay time from when the manifest file is acquired to when the next manifest file is requested, and gives an index for updating the manifest of the receiving apparatus. In the example of FIG. 2, the minimumUpdatePeriod is 2 seconds.

  suggestedPresentationDelay indicates the recommended value of the fixed delay time from the current time. In other words, it indicates that it is recommended to play back from the segment whose playback time is earlier than the latest segment existing in the MPD file by suggestedPresentationDelay seconds. In the example of FIG. 2, suggestedPresentationDelay is 20 seconds.

  The manifest file includes a plurality of segments obtained by dividing the sequentially generated data stream, information indicating the location of a newly generated segment among the divided segments, and the location of the expired segment. Is updated by deleting the information indicating.

(Configuration of receiving device)
Next, an example of the configuration of a receiving device according to an embodiment of the present invention will be described with reference to FIG. The receiving device 1 and the distribution server 2 are connected via the Internet. The receiving device 1 receives content composed of a plurality of segments from the distribution server 2 for each segment, and performs streaming reproduction.

  The distribution server 2 is a server that distributes the manifest file and the segment of the URL specified by the receiving device 1, and can be, for example, a general Web server.

  The receiving device 1 communicates with a manifest acquisition unit 11, a manifest update control unit 12, a segment acquisition unit 13, a buffer 14, a reproduction / display unit 15, a reproduction control unit 16, a reproduction control user I / F 17, An I / F 18 is provided to receive live streaming.

  The manifest acquisition unit 11 acquires and updates a manifest file of desired content from the distribution server 2 according to an instruction from the manifest update control unit 12, and outputs the acquired manifest file to the manifest update control unit 12.

  The manifest update control unit 12 generates a segment URL list in which reproduction times are associated with segment URLs based on the manifest file input from the manifest acquisition unit 11, and outputs the segment URL list to the segment acquisition unit 13 and the reproduction control unit 16. I do.

  Further, the manifest update control unit 12 determines the live reproduction reference time based on the time information of the segment described in the manifest file. Here, the live reproduction reference time is a reference time for stably performing live reproduction, and refers to a reproduction time that is a predetermined delay time earlier than the reproduction end time of the latest segment in the segment URL list. The live playback reference time may be a playback time that is set back from the playback end time by the time specified in suggestedPresentationDelay shown in FIG. 2 or a playback time that is set back by a separately set delay time.

  Also, the manifest update control unit 12 compares the live reproduction reference time with the reproduction time (current reproduction time or reproduction request time) input from the reproduction control unit 16, and determines that the reproduction time is earlier than the live reproduction reference time. In some cases, the update period of the manifest file is set to a long period, and when the reproduction time is after the live reproduction reference time, the update period of the manifest file is set to a short period. In the following description, a mode in which the update cycle of the manifest file is set to a long term is called a long-term mode, and a mode in which the update cycle of the manifest file is set to a short term is called a short-term mode.

  In this way, the short-term mode is set when the manifest file needs to be updated frequently. The update cycle of the short-term mode may use the reference value specified in minimumUpdatePeriod shown in FIG. 2 as it is, or may set it separately based on the reference value. On the other hand, if it is not necessary to update the manifest file frequently, the long-term mode is set. The update cycle of the long-term mode may be a multiple (for example, 10 times) of the update interval of the short-term mode, or a value longer than that of the short-term mode may be set separately.

  Further, the manifest update control unit 12 determines whether or not to update the manifest file based on the set manifest update period, and instructs the manifest acquisition unit 11 to update the manifest when the update is determined.

  The segment acquisition unit 13 determines the segment to be acquired based on the segment URL list input from the manifest update control unit 12, the reproduction start time information input from the reproduction control unit 16, and the state of the segments stored in the buffer 14. The URL is extracted, and a request including the URL is transmitted to the distribution server 2. Then, a segment is obtained as a response to the request and inserted into the buffer 14.

  The reproduction / display unit 15 sequentially inputs segments from the buffer 14 based on a reproduction instruction from the reproduction control unit 16, reproduces and displays the input segments, and controls the current reproduction time as the current reproduction time. Output to the unit 16.

  The reproduction control unit 16 outputs the current reproduction state (reproducing, stopped) and the current reproduction time input from the reproduction / display unit 15 to the manifest update control unit 12 and the reproduction control user I / F 17. When a command to start and stop playback is input from the playback control user I / F 17, the playback / display unit 15 is instructed to start and stop playback.

  Further, upon input of a seek (reproduction time change) command from the reproduction control user I / F 17, the reproduction control unit 16 obtains a reproduction request time, which is a newly designated reproduction time, and outputs it to the manifest update control unit 12. Further, the reproduction start time is determined based on the live reproduction reference time and the segment URL list input from the manifest update control unit 12, and reproduction start time information indicating the reproduction start time is output to the segment acquisition unit 13.

  The reproduction control user I / F 17 has a function of controlling reproduction by a user operation. A playback start / stop button is provided, the start time and end time of the content are displayed, and the current playback time is graphically displayed based on the current playback time information input from the playback control unit 16. Good.

  For example, at the bottom of the playback screen, the start time of the content is displayed as a horizontal bar with the left end and the end time is the right end, and a knob-shaped operation part is arranged so as to overlap with it, and as the playback of the operation part on the knob progresses By moving from the left end to the right end, the user can grasp at a glance which part of the entire reproduction time is currently being reproduced. By moving the knob by a user operation such as a mouse, an arbitrary reproduction position may be designated. By a user operation, a playback request time according to a playback start command, a stop command, and a seek command is output to the playback control unit 16.

(Application startup operation)
Next, the operation of the receiving device 1 from application start to reproduction start will be described with reference to the flowchart of FIG.

  First, when the viewing application is started by a user operation (step S001), the manifest update control unit 12 sets the manifest update cycle to the short-term mode (step S002). Subsequently, the manifest acquisition unit 11 acquires a manifest file of the desired content from the distribution server 2 (Step S003).

  Subsequently, the manifest update control unit 12 analyzes the acquired manifest file, generates a segment URL list, and sets a live reproduction reference time (step S004).

  Subsequently, the playback control unit 16 sets the playback start time to the live playback reference time (step S005).

  Subsequently, the segment acquisition unit 13 extracts the URL of the segment including the reproduction start time set in step S005 from the segment URL list, and transmits a request including the URL to the distribution server 2 (step S006). Then, the segment received as a response to the request is inserted into the buffer 14 (step S007).

  Subsequently, the reproduction / display unit 15 starts reproduction of the acquired segment (step S008).

(Playback operation)
Next, an operation during reproduction in the receiving device 1 will be described with reference to the flowchart in FIG.

  First, the manifest update control unit 12 confirms whether or not the manifest update cycle is in the long-term mode and the current reproduction time is after the live reproduction reference time (step S101). If the current playback time is after the live playback reference time (step S101-YES), it is necessary to acquire a new segment early, so the manifest update cycle is set to the short-term mode (step S102). If the current playback time is earlier than the live playback reference time (step S101-NO), step S102 is bypassed.

  Subsequently, the manifest update control unit 12 confirms whether or not a time equal to or longer than the manifest update cycle has elapsed since the last acquisition of the manifest file (step S103). If step S103 is NO, steps S104 and S015 are bypassed.

  On the other hand, if step S103 is YES, the manifest acquisition unit 11 acquires an updated manifest file from the distribution server 2 (step S104). Subsequently, the manifest update control unit 12 analyzes the acquired manifest file, updates the segment URL list, and updates the live reproduction reference time (step S105).

  Next, it is confirmed whether or not a segment having a buffer specified value (for example, 5 seconds) or more exists in the buffer 14 (step S106). This is because no segment has been inserted into the buffer 14 at the stage when the manifest file is first obtained. Here, the buffer specified value is a playback time length of a segment in the buffer 14 received earlier than the current playback time in order to continue stable viewing. If step S106 is YES, the processing of steps S107 and S018 is bypassed.

  On the other hand, when step S106 is NO, the segment acquisition unit 13 extracts the URL of the segment following the last segment stored in the buffer 14 from the segment URL list, and transmits a request including the URL to the distribution server 2. (Step S107). Then, the segment received as a response to the request is inserted into the buffer 14 (step S108).

  Subsequently, when there is no instruction to end the reproduction (step S109-NO), the process returns to step S101, and when there is an instruction to end the reproduction (step S109-YES), the reproduction processing is ended.

(Seek operation)
Next, the seek operation of the receiving device 1 according to the present invention will be described with reference to the flowchart of FIG.

  First, when the user performs a seek operation in the reproduction control user I / F 17, the reproduction control unit 16 acquires a reproduction request time (step S201). Subsequently, the manifest update control unit 12 confirms whether or not the manifest update cycle is the long-term mode (step S202). When the manifest update cycle is the short-term mode (step S202—NO), the processing of steps S204 and S205 is bypassed.

  On the other hand, if the manifest update cycle is the long-term mode (step S202—YES), the acquired manifest file may not be the latest, so the manifest acquiring unit 11 updates the latest manifest file from the distribution server 2. A manifest file is obtained (Step S204). Then, the acquired manifest file is analyzed by the manifest update control unit 12, and the segment URL list and the live reproduction reference time are determined (updated) based on the segment time information (step S205).

  Subsequently, the manifest update control unit 12 checks whether or not the reproduction request time is earlier than the live reproduction reference time (step S203). If the reproduction request time is earlier than the live reproduction reference time (step S203-YES), the manifest update cycle is set to the long-term mode (step S206). On the other hand, if the reproduction request time is after the live reproduction reference time (step S203-NO), the manifest update mode is set to the short-term mode (step S207), and the reproduction request time is set to the live reproduction reference time (step S207). Step S208).

  Subsequently, the reproduction control unit 16 checks whether or not the URL of the segment including the reproduction request time exists in the segment URL list (step S209). If step S209 is YES, the reproduction start time is set to the reproduction request time (step S210). On the other hand, if step S209 is NO, the reproduction start time is set to the reproduction time of the oldest segment in the segment URL list (step S211).

  Subsequently, the segment acquisition unit 13 extracts the URL of the segment including the reproduction start time from the segment URL list, and transmits a request including the URL to the distribution server 2 (step S212). Then, the segment is received from the distribution server 2 as a response to the request, and inserted into the buffer 14 (step S213).

  Subsequently, the reproduction / display unit 15 starts reproduction of the acquired segment (step S214).

  As described above, when the viewing method does not necessarily require the latest segment information, that is, when the current playback time or the playback request time by the seek is earlier than the live playback reference time, the manifest file update cycle Makes it possible to reduce the load on the network and the distribution server 2 caused by updating the manifest file.

  Note that a computer can be suitably used to function as the above-described receiving device 1, and such a computer stores a program describing processing contents for realizing each function of the receiving device 1 in a storage unit of the computer. The program can be realized by reading and executing the program by the CPU of the computer. This program can be recorded on a computer-readable recording medium.

  Although the above embodiments have been described as representative examples, it will be apparent to those skilled in the art that many changes and substitutions can be made within the spirit and scope of the present invention. Therefore, the present invention should not be construed as being limited by the above-described embodiments, and various modifications and changes can be made without departing from the scope of the claims. For example, with respect to the constituent blocks or processing steps described in the embodiments, it is possible to combine a plurality into one or divide one into a plurality.

DESCRIPTION OF SYMBOLS 1 Receiving device 2 Distribution server 11 Manifest acquisition unit 12 Manifest update control unit 13 Segment acquisition unit 14 Buffer 15 Playback / display unit 16 Playback control unit 17 Playback control user I / F
18 Communication I / F

Claims (4)

A receiving device for receiving live streaming,
A manifest acquisition unit for acquiring and updating a manifest file,
A playback control unit that outputs the current playback time or a newly designated playback time,
Determine a live playback reference time that is a playback time that is a predetermined delay time earlier than the playback end time of the latest segment described in the manifest file, and when the playback time is earlier than the live playback reference time, A manifest update control unit that sets the update cycle of the manifest file to a long term, and sets the update cycle of the manifest file to a short term when the playback time is after the live playback reference time,
A receiving device comprising: The manifest acquisition unit acquires the latest manifest file when the update cycle is set to a long time during a seek operation,
The manifest update control unit, and determines the live playback reference time based on the latest manifest file, the receiving apparatus according to claim 1. A method for updating a manifest in a receiving device that receives live streaming,
Obtaining and updating the manifest file;
Outputting the current playback time or a newly designated playback time;
Determine a live playback reference time that is a playback time that is a predetermined delay time earlier than the playback end time of the latest segment described in the manifest file, and when the playback time is earlier than the live playback reference time, Setting the update cycle of the manifest file to a long time, and when the playback time is after the live playback reference time, setting the update cycle of the manifest file to a short time;
A manifest updating method comprising:   A program for causing a computer to function as the receiving device according to claim 1.

Images