WO2014067566A1

WO2014067566A1 - Method and device for streaming video

Info

Publication number: WO2014067566A1
Application number: PCT/EP2012/071519
Authority: WO
Inventors: Michael Huber; Staffan Pehrson
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2012-10-30
Filing date: 2012-10-30
Publication date: 2014-05-08

Abstract

There is provided a method, in a video device, for streaming video. The method comprises receiving and outputting first video stream at a first quality, and receiving a second video stream which may be selected, the second video stream received at a second quality, the second quality a lower quality than the first quality. The method further comprises receiving a selection of the second video stream, and in response to such a selection: outputting the second video stream at the second quality; and requesting the second video stream at a third quality, the third quality a higher quality than the second quality.

Description

METHOD AND DEVICE FOR STREAMING VIDEO

Technical field

The present application relates to a method in a video device for streaming video, a video device for streaming video, and a computer-readable medium.

Background

IPTV (internet protocol television) is a term used when delivering broadcasted TV services over an IP network, typically a broadband access network.

Currently the predominant IPTV service uses a broadband connection, whereby the previously non-IPTV channels, as well as "new" channels with low penetration, are transmitted over the broadband network from the super head-end down to the end-user's set top box (STB). In order to minimize the bandwidth required for these transmissions it is desirable to use multicast techniques through the network. This means that each STB receives the channel it is currently displaying; in contrast to a broadcast network where all channels are received at the STB, which then tunes into the appropriate multiplex and decodes the appropriate channel. In an IPTV service, when the user switches channel the STB then sends out an IGMP (Internet Group Management Protocol) message to leave the current channel and join the new one. In IGMP version 3 this is done in the same message and in previous versions of IGMP the leave and join are sent in two separate messages.

The multicast group that the STB joins contains streams with mpeg transport streams (mts). An mts contains multiplexed mpeg data (normally MPEG 2 or MPEG 4 part 10) frames. When the STB joins a new channel, certain control elements in the mts need to be found and processed in order to be able to select video and audio flows. Once this is done there are different frames in MPEG, so-called l-frames which contain a full picture, P-frames contain incremental extrapolation information, and B-frames contain interpolation information. Since B and P frames depend on adjacent frames it is necessary that the STB receives a full l-frame before the STB can begin to show a new channel. This means that the average time for switching between channels will depend on the distance in time between l-frames and the location of the control elements. Typically for mpeg-2 the l-frame distance is around 0.5 seconds and for mpeg-4 part 10 it can be up to several seconds.

There are other sources of delay in channel change, some of these are:

Distance between l-frames (as explained above);

The buffer size in the STB and network equipment;

· The time it takes for the IGMP leave/join;

Audio/video delay; and

Time to find necessary control data (mts and conditional access systems). In order to alleviate the problem with channel switching delay in an IPTV system, a number of solutions have been proposed. However, one of the biggest problems with many of today's solutions is that they scale poorly in large networks, especially under heavy load. The server is the weakest point in the chain that can expect heavy load when many users change channels at the same time, which is not unusual, for example at the end of a popular sporting event, or at the start of a commercial break. Another problem with previously proposed solutions is that they require client side modifications (even if the solution isn't supported by the client), or that the network needs two different streams, one for clients that support the solution and one for legacy clients. Some solutions propose using a unicast delivery method to increase the speed of channel change, for example by sending the latest l-frame by unicast. However, a major problem with any solution that uses unicast is that this is a very inefficient use of bandwidth. A practical system is unlikely to be able to support unicast connections to anything more than a small proportion of users. This can be overcome by reducing the number of concurrent users of a particular RTP-switch by placing the RTP-switch either close to, or inside the access node. This is a costly solution. Accordingly, there is a need for an improved method and apparatus for streaming video.

Summary

The methods and apparatus described here use a low quality version of at least one next predicted channel. This is received by the STB at the same time as a current high quality channel. When the user selects a new channel, if the newly selected channel is (one of) the next predicted channel(s), then the STB can immediately begin showing the low quality stream, while requesting and waiting to receive the high quality version of the channel. A user would prefer to watch the selected channel immediately at a low quality than wait several seconds with a blank screen for the selected channel to arrive at a high quality.

Accordingly there is provided a method, in a video device, for streaming video. The method comprises receiving and outputting first video stream at a first quality, and receiving a second video stream which may be selected, the second video stream received at a second quality, the second quality a lower quality than the first quality. The method further comprises receiving a selection of the second video stream, and in response to such a selection: outputting the second video stream at the second quality; and requesting the second video stream at a third quality, the third quality a higher quality than the second quality.

Because the second video stream is being received at the same time as the first video stream, albeit at a lower quality, when the second video stream is selected it can be output very quickly, giving a fast channel change. If a channel other than the second video stream is selected, a conventional channel change is performed. The method may further comprise receiving and outputting the second video at the third quality. The lower quality second video stream may be output until the higher quality video stream is received. The method may further comprise identifying a second video stream which may be selected, the identification made prior to the receipt of or the selection of the second video stream. The identification may comprise the prediction of a most likely next video stream to be selected. It is possible that a selection of a different video stream is received, in which case the video device performs a conventional stream change.

The second video stream may be identified as a video stream associated with a channel number adjacent to a channel number associated with the first video stream. The second video stream may be further identified as a video stream other than the video stream that was output prior to the output of the first video stream.

A plurality of second video streams may be received, and a selection of one of the second video streams is received. The method may further comprise decoding a received video stream prior to its output.

There is further provided a video device, for streaming video, the video device comprising first and second inputs, and an output. The first input is for receiving a first video stream at a first quality and a second video stream which may be selected, the second video stream received at a second quality, the second quality a lower quality than the first quality. The output is for outputting a first video stream at a first quality. The second input is for receiving a selection of the second video stream, and in response thereto: outputting from the output the second video stream at the second quality; and requesting at the first input the second video stream at a third quality, the third quality a higher quality than the second quality.

Because the second video stream is being received at the same time as the first video stream, albeit at a lower quality, when the second video stream is selected it can be output very quickly, giving a fast channel change. If a channel other than the second video stream is selected, a conventional channel change is performed. The first and second inputs may be the same input modules, such as a Wi-Fi input. Alternatively the first input may be a high bandwidth connection such as Wi-Fi or cable, and the second input may be a low bandwidth connection such as an infra-red receiver. The output may be further arranged to output the second video at the third quality. The lower quality second video stream is output until the higher quality video stream is received.

The first input is arranged to receive a plurality of second video streams, and wherein the second input is arranged to receive a selection of one of the second video streams. The video device may further comprise a processor for decoding at least one video stream, wherein the output is arranged to output a decoded video stream. The video device may further comprise a processor arranged to identify at least one second video stream which may be selected, the identification made prior to the receipt of or the selection of the second video stream. The identification may comprise the prediction of a most likely next video stream to be selected. It is possible that a selection of a different video stream is received, in which case the video device performs a conventional stream change.

The processor may identify as the second video stream a video stream that is associated with a channel number adjacent to a channel number associated with the first video stream. The second video stream may be further identified as a video stream other than the video stream that was output prior to the output of the first video stream. The processor may identify as the at least two second video streams the video stream that are associated with channel numbers immediately before and immediately after a channel number associated with the first video stream. The second video stream may be further identified as a video stream other than the video stream that was output prior to the output of the first video stream. The second video stream(s) may be selected from a list of favorite channels. The second video stream may be identified as a channel adjacent to the first video stream on the list of favorite channels. Where two video streams are identified, the second video streams may be identified as the preceding and subsequent channels adjacent to the first video stream on the list of favorite channels.

There is further provided a computer-readable medium, carrying instructions, which, when executed by computer logic, causes said computer logic to carry out any of the methods defined herein.

There is further still provided a computer-readable storage medium, storing instructions, which, when executed by computer logic, causes said computer logic to carry out any of the methods defined herein. 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).

Brief description of the drawings

A method and device for streaming video will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 illustrates the stream switching on a client STB;

Figure 2 illustrates the stream switching by an alternate client STB; Figure 3 illustrates a method described herein;

Figure 4 shows a prediction process for the most likely next channel to be selected; and

Figure 5 illustrates an apparatus for performing the methods described herein. Detailed description

The channel change time can be greatly improved by causing the client, such as an STB, to join and buffer low bitrate versions of the next predicted channel that will be zapped in to by the user. In this way the streams will be ready to view almost instantly when the user selects that channel, albeit at a lower quality. The streams are typically delivered by adaptive streaming, so low quality versions of the streams are ready available from adaptive streaming. Since the low bit rate version of an adaptive stream, the system does not increase the bandwidth needed by a significant amount. And importantly, the system is not subject to sudden spikes in demand for bandwidth usage in the event that that a large proportion of users try to change channel at the same time.

When a user is switching channels there are numerous different ways to predict what the next stream he will join is. One of the simplest is that if a user is pressing channel up, that also the next switch will be channel up.

Therefore it should be quite useful to buffer the one after the one user just joined. This is a simple zapping direction prediction. A further simple example is where the user is switching between two

channels. If a user switches from a first channel to a second channel, then back to the first channel, it should be useful to buffer the second channel for future use. This is a prediction based on switching between a subset of channels.

The prediction of the next channel may be based on user action other than the preceding channel selection procedure. For example, where there are more than 10 channels available, the user needs to enter two digits to select a particular channel. If the user types in numbers to watch a new channel, the first number can be used to predict which channel the user will be switching to and so which channel should be received at low quality for buffering. For example, if the client is outputting channel 1 , then receives an input of key press 4, it is possible that channel 04 is being selected, so the client would start buffering 04. However, the user might input a further digit to select channel 4x where x is 0-9. So upon receiving input of key press "4" the client could buffer all 1 1 channels (04, 40, 41 , 42, 43, 44, 45, 46, 47, 48, 49). This would be feasible if particularly low bitrate versions of the channels were used. Alternatively, the client could determine which of these 1 1 channels is most likely to be selected and begin buffering of low quality versions of the most probable. The most probable channels may be selected by what channels are frequently joined by that client or by what is most popular on the network. More than one predicted next channel may be received at low quality in addition to the currently shown high quality channel. Different rules and algorithms may be used to select which are the most likely predicted next channels. The channel predictions may change according to how much time has elapsed since the last channel change was made. Further channel predictions may change according to the time of day. Channel change history of the client or user account on the client may be used to refine the channel predictions.

The low bitrate streams are one version of the so called ABR (adaptive bitrate streams), those have all the same parameters as the original high quality streams except they have much lower quality and so have a much lower bitrate, requiring less bandwidth. These streams do not cost too much extra bandwidth in the network. The streams may be in all other sense similar, so magic streams here with only l-frames are not required. This advantageously reduces the computation required at the server.

Figure 1 illustrates the stream switching on a client STB. A first video stream 1 10 is being shown at high quality on a display 180. A receiver of the STB receives both the first video stream at high quality 1 10 and a second video stream at low quality 125. The second video stream is an auxiliary stream and has been identified as the most likely next channel to be selected. The above state is illustrated in figure 1 a, which shows the buffer 100 of the STB and the relative size of the buffered streams (the high quality stream takes up more buffer space than the low quality stream). In this state, the buffered first video stream at high quality 1 10 is output to the display 180; and the buffered second video stream at low quality 125 is discarded, or trashed.

The STB then receives an instruction to display the second video stream, this instruction may take the form of a channel selection by a user. This state is illustrated in figure 1 b. Now the output of the buffer immediately switches from the first video stream at high quality 1 10 to the second video stream at low quality 125; and the buffered first video stream is now discarded.

At the time of receiving the selection of the second video stream the STB requests an update of the streams it receives. Such a request may take the form of an IGMP message. Further, the STB identifies a new most likely next selected channel, which is in this case a third video stream. The STB thus updates the streams it receives to include the second video stream at high quality 120 and the third video stream at low quality 135. The low quality version of the second video stream is output to the display 180 until the streams have been updated.

The updated streaming state is illustrated in figure 1 c. Buffer 100 now contains the second video stream at high quality 120 and the third video stream at low quality 135. The third video stream at low quality 135 is discarded. The second video stream at high quality 120 is output to the display 180.

Accordingly, if a channel change selection is made for a channel that was identified as the most likely next selected channel, then the channel change may be performed near instantly to the buffered low quality version of that channel. The low quality version of the channel is shown until the high quality version is received and may be output. Figure 2 illustrates the stream switching by an alternate client STB, where two auxiliary streams may be received and buffered. A second video stream 220 is being shown at high quality on a display 280. A receiver of the STB receives not only this second video stream at high quality 220 but also a first and third video stream both at low quality 215, 235. The first and third video streams have been identified as the two most likely channels to be selected next.

The above state is illustrated in figure 2a, which shows the buffer 200 of the STB and the relative size of the buffered streams (a high quality stream takes up more buffer space than a low quality stream). In this state, the buffered second video stream at high quality 220 is output to the display 280; and the buffered first and third video streams at low quality 215, 235 are discarded, or trashed.

The STB then receives an instruction to display the third video stream. This state is illustrated in figure 2b. Now the output of the buffer immediately switches from the second video stream at high quality 220 to the third video stream at low quality 235. The buffered first and second video streams 215, 220 are now discarded.

At the time of receiving the selection of the third video stream, the STB identifies two new most likely next selected channels, which in this case are the previously output second video stream and a fourth video stream. The STB then requests an update of the streams it receives. Such a request may take the form of an IGMP message. The STB thus requests an update of the streams it receives to include the third video stream at high quality 230 and the second and fourth video streams at low quality 225, 245. The low quality version of the third video stream 235 is output from the buffer 200 to the display 180 until the streams have been updated.

The updated streaming state is illustrated in figure 2c. Buffer 200 now contains the third video stream at high quality 230 and the second and fourth video stream at low quality 225, 245. The second and fourth video streams at low quality 225, 245 are discarded from the buffer 200. The third video at high quality 230 is output to the display 280.

Accordingly, if a channel change selection is made for one of the channels that were identified as the most likely next selected channels, then the channel change may be performed near instantly to the buffered low quality version of that channel. The low quality version of the channel is shown until the high quality version is received and may be output. The method described herein is illustrated at figure 3. At 310 a first video stream is received at a receiver and output to a display. At 320, at least one auxiliary stream is received, in this case a second video stream. The auxiliary streams are identified as the streams most likely to be next selected. In this example only one auxiliary stream is used. A low quality version of the second video stream is received and buffered, this may be the lowest bitrate version of the available adaptive bitrate versions, or it may simply be of lower quality than the first video stream.

At 330, a user channel change command is received, which in this case is a selection of the second video stream. In response to this selection, at 340 the buffered second video stream at low quality is output to the display. At the same time the receiver may request streams to reflect the channel selection. Such a stream updating will at least comprise requesting the second video stream at higher quality, as shown at 350.

Figure 4 is a flow diagram outlining the most likely next channel to be selected prediction process. The process begins at 410 with the receipt of an initiator that triggers the channel prediction process. The trigger may be received from a timer 412, which ensures the prediction process is run periodically, or the trigger may be a channel selection input 415 received from a user input device. At 420 a prediction of the most likely next channels to be selected is performed. This prediction may use any appropriate algorithm, including those disclosed herein by way of example. Inputs to the next channel prediction process may include the most recently received channel selection 415, and the channel selection history 425. At 430 it is determined whether or not the predicted next channels have changed. If the prediction initiator was the timer then it is possible that the predicted next channels will not have changed, and if this is the case the process returns to 410. If the predicted next channels have changed, then the channels that are streamed at low quality are updated 440. The channel that is streamed at high quality may also be updated at 440, particularly where the channel prediction process is initiated by a channel selection 415. Figure 5 illustrates an apparatus for performing the methods described herein. The apparatus of figure 5 may reside within a set top box (STB). At least one input 510 receives video streams 517 and channel selections 515. One input 510 is shown as receiving both video streams 517 and channel selections 515; however, these may be received via separate inputs. A processor 520 receives information from input 510. Further, the processor 520 is arranged to receive instructions which, when executed, causes the processor 520 to carry out the above described methods. The instructions may be stored on a memory 525. The processor is arranged to communicate via at least one output 530, which may include outputting a decoded video stream to a display 580.

It will be apparent to the skilled person that the exact order and content of the actions carried out in the method described herein may be altered according to the requirements of a particular set of execution parameters. Accordingly, the order in which actions are described and/or claimed is not to be construed as a strict limitation on order in which actions are to be performed.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfill the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope

While examples have been given in the context of Adaptive Streaming, these examples are not intended to be the limit of streaming system to which the disclosed method and apparatus may be applied. The principles disclosed herein can be applied to any streaming system which uses a description file. For example, this method and apparatus may be applied to Apple™ Live Streaming, and Microsoft™ Smooth Streaming.

Further, while examples have been given in the context of particular communications standards, these examples are not intended to be the limit of the communications standards to which the disclosed method and apparatus may be applied. For example, while specific examples have been given in the context of IGMP, the principles disclosed herein can also be applied to any IPTV system.

Claims

1 . A method, in a video device, for streaming video, the method comprising:

receiving and outputting first video stream at a first quality;

receiving a second video stream which may be selected, the second video stream received at a second quality, the second quality a lower quality than the first quality;

receiving a selection of the second video stream, and in response thereto:

outputting the second video stream at the second quality; requesting the second video stream at a third quality, the third quality a higher quality than the second quality.

2. The method of claim 1 , further comprising receiving and outputting the second video at the third quality.

3. The method of claim 1 or 2 further comprising, identifying a second video stream which may be selected, the identification made prior to the receipt of or the selection of the second video stream.

4. The method of claim 3, wherein the second video stream is identified as a video stream associated with a channel number adjacent to a channel number associated with the first video stream.

5. The method of any preceding claim, wherein a plurality of second video streams is received, and a selection of one of the second video streams is received.

6. The method of any preceding claim, the method further comprising decoding a received video stream prior to its output.

7. A video device, for streaming video, the video device comprising:

a first input for receiving a first video stream at a first quality and a second video stream which may be selected, the second video stream received at a second quality, the second quality a lower quality than the first quality;

an output for outputting a first video stream at a first quality;

a second input for receiving a selection of the second video stream, and in response thereto:

outputting from the output the second video stream at the second quality; and

requesting at the first input the second video stream at a third quality, the third quality a higher quality than the second quality.

8. The video device of claim 7, wherein the output is further arranged to output the second video at the third quality.

9. The video device of claims 7 or 8, wherein the first input is arranged to receive a plurality of second video streams, and wherein the second input is arranged to receive a selection of one of the second video streams.

10. The video device of claims 7, 8 or 9, the video device further

comprising a processor for decoding at least one video stream, wherein the output is arranged to output a decoded video stream.

1 1 . The video device of any of claims 7 to 10, the video device further comprising a processor arranged to identify at least one second video stream which may be selected, the identification made prior to the receipt of or the selection of the second video stream.

12. The video device of claim 1 1 , wherein the processor identifies as the second video stream a video stream that is associated with a channel number adjacent to a channel number associated with the first video stream.

13. The video device of claim 1 1 , wherein the processor identifies as the at least two second video streams the video stream that are associated with channel numbers immediately before and immediately after a channel number associated with the first video stream.

14. A computer-readable medium, carrying instructions, which, when executed by computer logic, causes said computer logic to carry out any of the methods defined by claims 1 to 6.