WO2016110324A1 - Procédé et appareil améliorés de trick-play en diffusion en continu abr - Google Patents

Procédé et appareil améliorés de trick-play en diffusion en continu abr Download PDF

Info

Publication number
WO2016110324A1
WO2016110324A1 PCT/EP2015/050171 EP2015050171W WO2016110324A1 WO 2016110324 A1 WO2016110324 A1 WO 2016110324A1 EP 2015050171 W EP2015050171 W EP 2015050171W WO 2016110324 A1 WO2016110324 A1 WO 2016110324A1
Authority
WO
WIPO (PCT)
Prior art keywords
stream
recorded
live video
video stream
live
Prior art date
Application number
PCT/EP2015/050171
Other languages
English (en)
Inventor
Jan-Erik LINDQUIST
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
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 Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/EP2015/050171 priority Critical patent/WO2016110324A1/fr
Publication of WO2016110324A1 publication Critical patent/WO2016110324A1/fr

Links

Classifications

    • 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/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • 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/27—Server based end-user applications
    • H04N21/274—Storing end-user multimedia data in response to end-user request, e.g. network recorder
    • H04N21/2747—Remote storage of video programs received via the downstream path, e.g. from the server
    • 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
    • H04N21/4333—Processing operations in response to a pause request
    • 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/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47217—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for controlling playback functions for recorded or on-demand content, e.g. using progress bars, mode or play-point indicators or bookmarks
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Definitions

  • the present application relates to a method in a client device arranged to receive adaptive bitrate streams of live video and recorded video, a client device, a method in a server arranged to deliver live video streams and recorded video streams, a server, a computer- readable medium, and a computer-readable storage medium.
  • IPTV Internet Protocol Television
  • telecom service providers can compete with TV offerings from cable operators, satellite-TV operators, and other terrestrial service providers.
  • IPTV also helps providers retain existing customers and prevent churn by introducing a bundled offering of Internet, voice, and IPTV services, sometimes referred to as "triple play”.
  • IPTV IPTV Service Providers
  • Common web browser applications such as Mozilla's Firefox and Microsoft's Internet Explorer, enable users to view specific Internet pages and other file locations accessible by the browser. Each such file location is typically identified by a Uniform Resource Identifier (URI) or similar address.
  • URI Uniform Resource Identifier
  • URI will be used to represent a file location address although any other type of address may be used.
  • IPTV is a technology for receiving and displaying multimedia streams at user IPTV devices, each stream being encoded in a series of IP data packets.
  • a user IPTV device can be a Set-Top Box (STB) or a TV having similar STB capabilities.
  • STB User Equipment
  • IMS IP Multimedia System
  • STB will be used to represent any user IPTV device capable of receiving multimedia streams and displaying the media as TV programs.
  • TV program is used for any media item delivered from an IPTV provider, such as movies, shows, news and documentaries.
  • Adaptive bitrate streaming has become a very important method for delivering video to a client over an internet protocol (IP) connection.
  • IP internet protocol
  • Adaptive bitrate streaming works by detecting the bandwidth available to a client and also the client processing capacity.
  • the video stream is available in a plurality of quality levels, at a range of bitrates. A quality level is selected that is suitable for the client. Further, if the available bandwidth or client processing capacity changes, a different video stream quality level may be selected. In this way the streaming adapts to the client.
  • ABR adaptive bitrate streaming
  • Adaptive bitrate streaming is available in a number of protocols, including: MPEG- DASH, Adobe Dynamic Streaming for Flash, Apple HTTP Live Streaming (HLS), Microsoft Smooth Streaming, QuavStreams Adaptive Streaming over HTTP, and upLynk.
  • MPEG- DASH Adobe Dynamic Streaming for Flash
  • HLS Apple HTTP Live Streaming
  • Microsoft Smooth Streaming QuavStreams Adaptive Streaming over HTTP
  • upLynk upLynk
  • Adaptive bitrate streaming requires that source content is encoded at multiple bitrates, then each of the different bitrate streams are segmented into small multi-second parts, sometimes referred to as video chunks.
  • a manifest file is sent to the streaming client, and this describes the available streams at differing bitrates, and gives the address of the segments. From the manifest, the client is able to identify which of the available streams it should retrieve, and also how to obtain the segments it needs to obtain that stream.
  • the client When starting a stream, the client requests the segments from the lowest bitrate stream. If the client finds the download speed is greater than the bitrate of the segment downloaded, then it will request the next higher bitrate segments. Later, if the client finds the download speed for a segment is lower than the bitrate for the segment, and therefore the network throughput has deteriorated, then it will request a lower bitrate segment.
  • the segment size can vary depending on the particular implementation, but they are typically between two and ten seconds.
  • the program resumes at the point or position where it was paused, to provide a seamless transition of the program at the intermission between the live stream and the network trick-play stream.
  • the program is typically resumed with a gap or missing part between the pause position in the live program and the restart position in the recorded program. This difference is perceived by the user as a "jump" from the paused program to the resumed program, particularly when a still image from the pause point is displayed before playback is resumed.
  • the length of this gap or jump may vary unpredictably, e.g. from less than a second to several seconds, and is therefore unknown to the user.
  • HLS One characteristic of ABR which causes the above problems is demonstrated by HLS, wherein the client must buffer some content before playback can begin. In HLS the client must buffer, and so cannot play, the most recent 3 segments in the manifest.
  • each segment has a duration of 10 seconds
  • IGMP Internet Group Management Protocol
  • the manifest is updated at fixed intervals of 1 segment, i.e. 10 seconds. This means that different clients connecting at different points during that period of 10 seconds will start viewing at different points, and have their video content played back at different offsets from the live content.
  • this problem has been addressed by measuring the different timing offsets experienced by each client. This can be approximated using the system clock to determine a position of the live content. However, this approximation is not accurate which is detrimental to the user experience; for example, in such a system it is possible to use network time-shift to view recorded content that is ahead of the live content.
  • There are alternative ways to address this problem For example by buffering more of the live ABR stream segments in the Content Delivery Network, meaning that a client can simply select different segments form the "live" stream. However, such a buffer must have a limit, like 30 minutes, and this would thus not work with programs or trick play operations that go beyond that limit. Also, where most users are not using trick- play, this is inefficient.
  • This method and apparatus described herein does not try to address how different clients may view content at different points in time but instead provides an accurate transition between live and network time-shift or recorded content. Accordingly, there is provided an improved method and apparatus for trick-play in ABR streaming.
  • a method in a client device arranged to receive adaptive bitrate streams of live video and recorded video.
  • the method comprises receiving a live video stream of a program from a server, and in response to receiving a pause instruction from a user, identifying a time indicator present in the live video stream, and ending the live video stream.
  • the method further comprises requesting a recorded stream of the program using the identified time indicator in response to receiving a play instruction from a user.
  • the live video stream and the recorded stream are adaptive bitrate streams.
  • the recorded stream may be created from the live video stream.
  • the live video stream and the recorded video stream include the same time indicators.
  • the time indicators in the live video stream and the recorded video stream may occur at the same locations with respect to the video content in the streams.
  • the identified time indicator may be used to calculate which particular segment from the recorded stream contains the same content from the live stream when the pause instruction was received, and wherein that particular segment of the recorded stream is requested.
  • the identified segment is requested initially, with the following segments subsequently requested to continue playback.
  • the process of requesting a recorded stream of the program using the identified time indicator may comprise requesting a manifest of the recorded stream.
  • the manifest of the recorded stream may include the same time indicators as included in the live video stream.
  • the recorded stream may have finite length, and upon reaching the end of the recorded stream the client may revert back to the live video stream.
  • the recorded stream may be the length of the program.
  • the live video stream reverted to may be the same one that was being received when the pause instruction was received.
  • the method may further comprise receiving a seek forward instruction, and in response thereto the client plays back the recorded stream at increased speed.
  • the recorded stream is of finite length, then upon reaching the end of the recorded stream in seek forward the client reverts back to the live video stream.
  • the client reverts back to the live video stream.
  • the live video stream may be delivered via a content delivery network.
  • the client may be arranged to output received video.
  • a client device comprising a receiver, a user interface, and a processor.
  • the receiver is arranged to receive adaptive bitrate streams of live video and recorded video.
  • the user interface is arranged to receive instructions from a user.
  • the processor is arranged to: in response to receiving a pause instruction from a user during the receipt of a live video stream of a program from a server, identifying a time indicator present in the live video stream, and ending the live video stream; and in response to receiving a play instruction from a user, requesting a recorded stream of the program using the identified time indicator.
  • the live video stream and the recorded stream are adaptive bitrate streams.
  • the recorded stream may be created from the live video stream.
  • the live video stream and the recorded video stream include the same time indicators.
  • the time indicators in the live video stream and the recorded video stream may occur at the same locations with respect to the video content in the streams.
  • the processor may be further arranged to identify the time indicator used to calculate which particular segment from the recorded stream contains the same content from the live stream when the pause instruction was received, and wherein that particular segment of the recorded stream is requested.
  • the identified segment is requested initially, with the following segments subsequently requested to continue playback.
  • Requesting a recorded stream of the program using the identified time indicator may comprise requesting a manifest of the recorded stream.
  • the manifest of the recorded stream may include the same time indicators as included in the live video stream.
  • the client calculates which segment from the recorded stream contains the location in the content at which the pause instruction was received by comparing the time indicator from the live video stream with the time indicator in the manifest of the recorded video stream.
  • the client device may further comprise an output for outputting content received via an adaptive bitrate stream.
  • the method comprises delivering at least one live video stream, the live video stream including a plurality of time indicators.
  • the method further comprises generating at least one recorded stream corresponding to at least one delivered live video stream, the recorded stream including the same time indicators as the video stream, and at the same content locations.
  • the time indicator may be a time stamp.
  • the time stamps are indicative of a stream clock.
  • the time stamps may indicate a time index within a program that is carried on a television channel that comprises the content within the live or recorded stream.
  • the timestamp may be included in the manifest of a live or recorded adaptive bitrate stream.
  • the timestamp may be included in a segment of a live or recorded adaptive bitrate stream.
  • a server comprising a receiver, an output, and a processor.
  • the receiver is arranged to receive content for streaming.
  • the output is arranged to deliver a live video stream, the live video stream including a plurality of time indicators.
  • the processor is arranged to generate a recorded stream corresponding to the output live video stream, the recorded stream including the same time indicators as the video stream, and at the same content locations.
  • the computer program product may be in the form of a non- volatile memory or volatile memory, e.g. an EEPROM (Electrically Erasable Programmable Read-only Memory), a flash memory, a disk drive or a RAM (Random- access memory).
  • EEPROM Electrically Erasable Programmable Read-only Memory
  • flash memory e.g. a flash memory
  • disk drive e.g. a disk drive
  • RAM Random- access memory
  • a user terminal comprising a processor and memory, said memory containing instructions executable by said processor whereby said user terminal is operative to: receive an adaptive bitrate stream of a live video stream of a program from a server; in response to receiving a pause instruction from a user, identify a time indicator present in the live video stream, and ending the live video stream; in response to receiving a play instruction from a user, request a recorded stream of the program using the identified time indicator.
  • the device is adapted to store a message e.g. in a memory such as a flash drive or a hard disk of the device.
  • Figure 1 illustrates a problem with timing in the delivery of ABR streams
  • Figure 2 illustrates a simple trick-play operation performed according to the method and apparatus described herein;
  • Figure 3 is a messaging diagram showing the interaction between a client, a media player, a media gateway, and a media server;
  • Figure 4 illustrates the contents of a manifest file for an ABR stream
  • Figure 5 illustrates a method that is performed in the client
  • Figure 6 illustrates a client device arranged to perform the method described herein
  • Figure 7 illustrates a method that is performed in the server
  • Figure 8 illustrates a server for performing the methods described herein. Detailed description
  • Figure 1 illustrates a problem with timing in the delivery of ABR streams.
  • Three clients A, B and C join a live stream at different times.
  • a client shall not play back the most recent segments in the manifest. In this example the most recent 3 segments cannot be played, and each segment is 10 seconds long.
  • a client When a client initially accesses the live stream, it checks the manifest and downloads the three most recent segments to generate a buffer. It then begins playback of the first downloaded segment, at the start of that segment.
  • the live stream 120 is illustrated with a plurality of segments 2032, 2033 and so on. In this figure the availability of these segments is used as a reference axis to indicate a current time, although this is somewhat arbitrary.
  • Client A joins at a time soon after segment 2035 being made available.
  • Client A checks the current manifest, ignores the latest three segments (2035, 2034 and 2033) and begins streaming 121 with segment 2032, resulting in a 32 second playback delay.
  • Client B joins at a time shortly before segment 2036 is made available, but also begins streaming 122 with segment 2032, resulting in a 38 second playback delay.
  • Client C joins at a time in the middle of the period between segment 2036 being made available and segment 2037 being made available.
  • Client C checks the current manifest, ignores the latest three segments (2036, 2035 and 2034) and begins streaming 123 with segment
  • FIG. 20 illustrates a simple trick-play operation performed according to the method and apparatus described herein.
  • the live stream 220 is used as a reference axis to indicate a current time, and client A joins at a time soon after segment 2035 has been made available, and so begins playback 221 with segment 2032, resulting in a 32 second playback delay.
  • Live stream 220 includes time indicators, which are time stamps. Client A uses these time indicators to identify when in the playback of the live stream 221 the pause instruction is received. This time is recorded by the client and the playback of the live stream 221 is stopped, and further the downloading of segments of stream 221 is stopped. Sometime later, during the transmission of segment 2040 on time axis 220, client A receives a play instruction. Client a uses the recorded time indicator to identify when in the recorded stream 231 playback should begin. This is possible because the recorded stream includes the same time indicators as the live stream 221. Client A thus retrieves the appropriate segment and begins playback of the recorded stream 231 at the same point in time that the live stream playback 221 was paused, that is near the start of segment 2034. The details of how this is achieved are described with reference to figure 3.
  • Figure 3 is a messaging diagram showing the interaction between a client 301, a media player 302, a media gateway (MSMW) 307 and a media server 309 when implementing a pause operation in accordance with that described herein.
  • Media player 302 is a function within the client 301.
  • the media gateway 307 enables multimedia communications across a network facilitating communication with the media server 309.
  • the client 301 requests from the media gateway 307 live playback information for a particular television channel, in this case CNN.
  • the media gateway 307 returns the address (URI) of the manifest for the channel, and at 313 the client 301 begins playback by instructing the media player 301 by passing the manifest address to it.
  • Media player 302 requests the manifest file at 314 and receives it form the media server 309 at 315.
  • Media player 302 reads the received manifest and selects a segment to begin streaming.
  • the media player 302 requests a segment and at 317 the media player 302 receives the segment from media server 309.
  • Media playback continues with the media player 302 repeatedly requesting and receiving both manifest files and segments from the media server 309.
  • the client 301 receives a pause instruction.
  • the client 301 requests from the media player 302 a current position from a series of time indicators in the received stream.
  • the media player 302 returns an absolute time of the playback position in the stream at the pause position to the client 301.
  • the streaming of the live media content in this case the CNN channel is stopped.
  • the client 301 receives a play or resume instruction.
  • the client 301 requests from the media gateway 307 time-shift playback info for the relevant content, in this case the CNN channel.
  • the client 301 receives from the media gateway 307 the manifest for the recorded stream of the CNN channel.
  • the client 301 looks at the time indicators in the received manifest file for the recorded stream. The client uses the time indicators to calculate which segment from the recorded stream contains the same content from the live stream when the pause instruction was received. At 334 and 335 the client 301 passes the play position and the manifest address respectively to the media player 302.
  • media player 302 requests the manifest file at 336 indicated to it by the client 301 and it receives the manifest file from the media server 309 at 337.
  • Media player 302 reads the received manifest and identifies the pause (or resume) position and retrieves the appropriate segment to begin streaming.
  • the media player 302 requests the segment and at 339 the media player 302 receives the segment from media server 309. Playback begins not necessarily from the start of the received segment but from the time indicated in the segment that corresponds to the pause (or resume) position. After this, media playback continues with the media player 302 repeatedly requesting and receiving both manifest files and segments from the media server 309.
  • the user may seek forward and seek backward while the recorded stream is being received. Once the end of the recorded stream is reached, when seeking forward, there is an automatic transition back to the live stream. This transition is desirable for network resource efficiency.
  • the live content stream is available in multiple servers as part of a CDN while the recorded stream, the network time-shifting asset, is likely located in just one location.
  • time indicators are part of the ABR stream. However, these may be implemented in either the manifest or the video chunks. In either location they are able to uniquely identify the time within the content of the stream.
  • Figure 4 illustrates the contents of a manifest file 400 for an ABR stream incorporating time indicators as described herein.
  • the manifest 400 contains three time stamps 411, 412, and 413.
  • each time stamp indicates an absolute time in respect of the content at the start of a segment in the stream of that content.
  • FIG. 5 illustrates a method that is performed in the client.
  • the client device is arranged to receive adaptive bitrate streams of live video and recorded video.
  • the method comprises receiving 510 a live video stream of a program from a server.
  • the client device receives a pause instruction from a user, and in response thereto at 530 the client device identifies a time indicator present in the live video stream. Further, at 530 the client device ends the live video stream, also in response to the pause instruction received at 520.
  • the client device receives a play instruction from the user.
  • the client device requests a recorded stream of the program using the identified time indicator.
  • the timing offset at the client is rendered unimportant. This arrangement gives a good user experience with pause, play and other trick-play functions operating as the user should expect. Further, the user experience is provided with minimal additional resources required by the service provider.
  • the live video stream and the recorded stream are adaptive bitrate streams.
  • the recorded stream is typically created from the live video stream.
  • pre-encoded content that is transmitted in the live stream may be adapted from the pre-encoded form to render it suitable for live streaming.
  • a similar adaptation may be performed to render the same content suitable network trick-play, instead of recording the output live stream.
  • the recorded stream may have a finite length, such that at some point during playback the client will reach the end of the recorded stream.
  • the recorded stream could be the length of the program broadcast during that time.
  • the client Upon reaching the end of the recorded stream the client will revert back to the live video stream. And in that situation the live video stream that is reverted to is the same one that was being received when the pause instruction was received.
  • a seek forward instruction will cause the client to play back the recorded stream at increased speed. Again, where the recorded stream is of finite length, and upon reaching the end of the recorded stream in seek forward the client will revert back to the live video stream. Alternatively, if during seek forward the client catches up with the live video stream in seek forward before it reaches the end of the recorded stream, the client will revert back to the live video stream.
  • the client device is arranged to output the received video streams. These may be output via video connection such as HDMI or DisplayPort. These may be output on a screen that is part of the client device.
  • FIG. 6 illustrates a client device 600 arranged to perform the method described herein.
  • the client device 600 comprises a receiver 610, a processor 620, a memory 625, an output 630, and a user interface 640.
  • the receiver 610 is arranged to receive adaptive bitrate streams of live video and recorded video.
  • User interface 640 is arranged to receiving instructions from a user.
  • the processor 620 is arranged to: in response to receiving a pause instruction from a user during the receipt of a live video stream of a program from a server, identifying a time indicator present in the live video stream, and ending the live video stream.
  • the processor 620 is further arranged to, in response to receiving a play instruction from a user, requesting a recorded stream of the program using the identified time indicator.
  • Output 630 is arranged to output content received via an adaptive bitrate stream. .
  • FIG. 7 illustrates a method that is performed in the server.
  • the server is arranged to deliver live video streams and recorded video streams.
  • the method comprises receiving 710 live video content for output, and generating 720 a live video stream, the live video stream including 730 a plurality of time indicators.
  • the method further comprises generating 740 at least one recorded stream corresponding to at least one delivered live video stream, the recorded stream including the same time indicators as the video stream, and at the same content locations.
  • the time indicator may be a time stamp.
  • the time stamps may be indicative of a stream clock.
  • the timestamp may be included in the manifest of a live or recorded adaptive bitrate stream. Alternatively, the timestamp may be included in a content chunk of a live or recorded adaptive bitrate stream.
  • FIG. 8 illustrates a server 800 for performing the methods described herein.
  • the server 800 comprises a receiver 810, an output 830, a processor 830, a memory 835 and storage 840.
  • the receiver 810 is arranged to receive content for streaming.
  • the output 820 is arranged to deliver a live video stream, the live video stream including a plurality of time indicators.
  • the processor 830 is arranged to generate a recorded stream corresponding to the output live video stream, the recorded stream including the same time indicators as the video stream, and at the same content locations.
  • the generated recorded stream may be stored in storage 840, for later streaming.
  • the processor 830 may be arranged to receive instructions which, when executed, causes the processor 830 to carry out the above described method.
  • the instructions may be stored on the memory 835.
  • the method may also be embodied in a set of instructions, stored on a computer readable medium, which when loaded into a computer processor, Digital Signal
  • DSP DSP
  • DSP Data Processing Processor
  • the method may be embodied as a specially programmed, or hardware designed, integrated circuit which operates to carry out the method on video data loaded into the said integrated circuit.
  • the integrated circuit may be formed as part of a general purpose computing device, such as a PC, smartphone or tablet, and the like, or it may be formed as part of a more specialized device, such as a games console, mobile phone, portable computer device or hardware video encoder.
  • One exemplary hardware embodiment is that of a Field Programmable Gate Array (FPGA) programmed to carry out the described method, located on a daughterboard of a rack mounted video encoder, for use in, for example, a television studio or satellite or cable TV head end.
  • FPGA Field Programmable Gate Array
  • Another exemplary hardware embodiment is that of a device containing an Application Specific Integrated Circuit (ASIC) arranged to perform a method described herein.
  • the client device may be a user apparatus.
  • the client device may be any kind of personal computer such as a television, a smart television, a set-top box, a games-console, a home- theatre personal computer, a tablet, a smartphone, a laptop, or even a desktop PC.
  • a live video stream does not necessarily comprise video of a live scene or live action content.
  • a live video stream comprises video in a live stream, and only requires that the stream is delivered via adaptive bit rate streaming to a plurality of users.
  • a recorded video stream is similar to a video-on-demand service, and may be provided as such. Alternatively, the recorded video stream may be provided solely for trick-play and so would not be available in other circumstances such as on-demand.

Abstract

L'invention concerne un procédé dans un dispositif client conçu pour recevoir des flux à débit binaire adaptatif de vidéo en direct et de vidéo enregistrée. Le procédé comprend la réception d'un flux vidéo en direct d'un programme depuis un serveur et, en réponse à la réception d'une instruction de pause d'un utilisateur, l'identification d'un indicateur temporel présent dans le flux vidéo en direct et la terminaison du flux vidéo en direct. Le procédé comprend en outre, en réponse à la réception d'une instruction de lecture depuis un utilisateur, la demande d'un flux enregistré du programme au moyen de l'indicateur temporel identifié.
PCT/EP2015/050171 2015-01-07 2015-01-07 Procédé et appareil améliorés de trick-play en diffusion en continu abr WO2016110324A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2015/050171 WO2016110324A1 (fr) 2015-01-07 2015-01-07 Procédé et appareil améliorés de trick-play en diffusion en continu abr

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2015/050171 WO2016110324A1 (fr) 2015-01-07 2015-01-07 Procédé et appareil améliorés de trick-play en diffusion en continu abr

Publications (1)

Publication Number Publication Date
WO2016110324A1 true WO2016110324A1 (fr) 2016-07-14

Family

ID=52354958

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/050171 WO2016110324A1 (fr) 2015-01-07 2015-01-07 Procédé et appareil améliorés de trick-play en diffusion en continu abr

Country Status (1)

Country Link
WO (1) WO2016110324A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106572358A (zh) * 2016-11-11 2017-04-19 青岛海信宽带多媒体技术有限公司 一种直播时移方法及客户端
EP3293977A1 (fr) * 2016-09-12 2018-03-14 Funai Electric Co., Ltd. Dispositif d'informations
EP3490261A1 (fr) * 2017-11-28 2019-05-29 Vestel Elektronik Sanayi ve Ticaret A.S. Fonction de reprise à base d'hôte pour des services de vidéo à la demande

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012118420A1 (fr) * 2011-03-01 2012-09-07 Telefonaktiebolaget Lm Ericsson (Publ) Procédés et appareils pour reprendre un contenu multimédia mis en pause
US20120311094A1 (en) * 2011-06-03 2012-12-06 David Biderman Playlists for real-time or near real-time streaming
US20140137171A1 (en) * 2010-08-17 2014-05-15 Huawei Technologies Co., Ltd. Method and Apparatus for Supporting Time Shift Playback in Adaptive HTTP Streaming Transmission Solution
US20140165120A1 (en) * 2012-12-11 2014-06-12 Morega Systems Inc. Client device with video playlist translation via client-side proxy and methods for use therewith
WO2014126677A1 (fr) * 2013-02-12 2014-08-21 Azuki Systems, Inc. Enregistreur vidéo personnel de réseau over the top

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140137171A1 (en) * 2010-08-17 2014-05-15 Huawei Technologies Co., Ltd. Method and Apparatus for Supporting Time Shift Playback in Adaptive HTTP Streaming Transmission Solution
WO2012118420A1 (fr) * 2011-03-01 2012-09-07 Telefonaktiebolaget Lm Ericsson (Publ) Procédés et appareils pour reprendre un contenu multimédia mis en pause
US20120311094A1 (en) * 2011-06-03 2012-12-06 David Biderman Playlists for real-time or near real-time streaming
US20140165120A1 (en) * 2012-12-11 2014-06-12 Morega Systems Inc. Client device with video playlist translation via client-side proxy and methods for use therewith
WO2014126677A1 (fr) * 2013-02-12 2014-08-21 Azuki Systems, Inc. Enregistreur vidéo personnel de réseau over the top

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3293977A1 (fr) * 2016-09-12 2018-03-14 Funai Electric Co., Ltd. Dispositif d'informations
US10306276B2 (en) 2016-09-12 2019-05-28 Funai Electric Co., Ltd. Information device
CN106572358A (zh) * 2016-11-11 2017-04-19 青岛海信宽带多媒体技术有限公司 一种直播时移方法及客户端
EP3490261A1 (fr) * 2017-11-28 2019-05-29 Vestel Elektronik Sanayi ve Ticaret A.S. Fonction de reprise à base d'hôte pour des services de vidéo à la demande

Similar Documents

Publication Publication Date Title
US9503765B2 (en) Averting ad skipping in adaptive bit rate systems
US8826349B2 (en) Multicast adaptive stream switching for delivery of over the top video content
US10291681B2 (en) Directory limit based system and method for storing media segments
US9721254B2 (en) Method and apparatus for providing streaming media programs and targeted advertisements using multiple advertisement version segments
US9510025B1 (en) Live consecutive ad insertion
US20140129618A1 (en) Method of streaming multimedia data over a network
US9756369B2 (en) Method and apparatus for streaming media data segments of different lengths wherein the segment of different length comprising data not belonging to the actual segment and beginning with key frames or containing key frames only
US20170238040A1 (en) Method, computer program product and server for streaming media content from a server to a client
US11539777B2 (en) Streaming and downloading of content
CN113141522B (zh) 资源传输方法、装置、计算机设备及存储介质
CN106789976A (zh) 媒体文件的播放方法、服务端、客户端及系统
US10687106B2 (en) System and method for distributed control of segmented media
JP2015534312A (ja) レンダリング時の制御
CN113923502B (zh) 直播视频播放方法及装置
US10015219B2 (en) Multicasting adaptive bitrate streams
WO2016110324A1 (fr) Procédé et appareil améliorés de trick-play en diffusion en continu abr
US20170006324A1 (en) Network pvr
US20170142179A1 (en) Delivery of media content segments in a content delivery network
KR20160125157A (ko) Http 기반 무버퍼링 영상전송 방법을 이용한 실시간 스트리밍 시스템
CN112823527B (zh) 在能够运行一个自适应流传输会话的设备处实现的方法以及对应的设备
EP4195626A1 (fr) Envoi d'un contenu de média en tant que flux de média à un système client
KR20110119490A (ko) 라이브 컨텐츠의 효과적인 재생방법
KR20200018890A (ko) 무선 스트리밍 방법

Legal Events

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

Ref document number: 15700433

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15700433

Country of ref document: EP

Kind code of ref document: A1