WO2006100268A2 - Procede d'envoi de commande a un serveur de flux de donnees numeriques et appareil implementant le procede - Google Patents

Procede d'envoi de commande a un serveur de flux de donnees numeriques et appareil implementant le procede Download PDF

Info

Publication number
WO2006100268A2
WO2006100268A2 PCT/EP2006/060956 EP2006060956W WO2006100268A2 WO 2006100268 A2 WO2006100268 A2 WO 2006100268A2 EP 2006060956 W EP2006060956 W EP 2006060956W WO 2006100268 A2 WO2006100268 A2 WO 2006100268A2
Authority
WO
WIPO (PCT)
Prior art keywords
stream
value
receiver
delta
time
Prior art date
Application number
PCT/EP2006/060956
Other languages
English (en)
Other versions
WO2006100268A3 (fr
Inventor
Jean-Claude Colmagro
Benoit Mercier
Thierry Querre
Original Assignee
Thomson Licensing
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 Thomson Licensing filed Critical Thomson Licensing
Priority to BRPI0608622-5A priority Critical patent/BRPI0608622A2/pt
Priority to EP06725239.5A priority patent/EP1862009B1/fr
Priority to CN2006800097458A priority patent/CN101151901B/zh
Priority to US11/886,819 priority patent/US8677442B2/en
Priority to JP2008502408A priority patent/JP4719789B2/ja
Publication of WO2006100268A2 publication Critical patent/WO2006100268A2/fr
Publication of WO2006100268A3 publication Critical patent/WO2006100268A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests
    • 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/21—Server components or server architectures
    • H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
    • H04N21/2225—Local VOD servers
    • 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/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • 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/47202—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 requesting content on demand, e.g. video on demand
    • 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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • 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

Definitions

  • the present invention relates to the field of receiver control of an on-demand content server. More particularly, in the case where the server broadcasts its content in the form of a digital data stream via an IP network.
  • RTSP Real Time Streaming Protocol
  • RTSP rendering program
  • Trick Modes special modes of rendering programs
  • These modes are used to bring commands that users are used to on a VCR, viewing programs broadcast over IP.
  • These modes include fast forward and reverse, as well as positioning at previously marked locations in the program.
  • Play involved in particular playback modes, require a parameter giving the time reference of the range of the program that is desired by a gap between a start reference and an end reference.
  • the RTSP client must therefore be able to know precisely the current time location in the file played.
  • Some servers for example Oracle servers, send mixed temporal descriptors to the program, but this mechanism is not adopted by all servers.
  • Another way is for the client to use the RTSP "GET PARAMETER" command to get the server current time reference. This solution requires the time to send the request and return the response. This is still the most commonly used method.
  • MPEG-2 System ISO / IEC, 1994.
  • each entity at the level of the elementary streams for example an image for a video stream is given a time reference, called PTS ("Presentation Time Stamp" in English).
  • PTS Presentation Time Stamp
  • This temporal reference indicates the moment when the associated entity, here the image must be restored.
  • the basis of this time reference is the system reference clock, a 90 kHz clock. It is these temporal references which make it possible to synchronize between them the different elementary flows constituting the program.
  • the succession of these presentation time references in the program flow is generally not continuous from the beginning of the program to the end. Indeed, a program can result from the assembly of several sequences that have been separately encoded and whose temporal presentation references have not been calculated in the same time frame.
  • a common technique is to use differently encoded versions for different modes. For example, the server will have a version of the double-speed encoded program that it will use if it receives a fast-forward command.
  • the different versions of the program will have time references of presentation corresponding to different time repositories.
  • the temporal presentation references present in the flow therefore generally form a succession of sequences each of these sequences corresponding to a specific time reference.
  • the invention proposes a local method to the client for sending commands to a VOD server, for example according to RTSP, these commands comprising a reference to the relative current position.
  • This relative current position is maintained by the receiver on the basis of the PTS received in the MPEG stream, without resorting to a request to the server or based on the existence in the descriptor stream for dealing with sequence breaks. in the PTS included in the stream.
  • the invention also relates to the client adapted to implement the method.
  • the invention relates to a method of sending a command to a digital data stream server by a receiver, the digital stream being broadcast by the server to the receiver via a link connecting the server and the receiver, the digital data stream comprising at least one program intended to be reproduced at a given speed and time references associated with data of the stream, these temporal references being relative to the moment of restitution of the associated data in a temporal frame, these temporal references being sequentially flow, repository changes resulting in breaks in sequences, which may appear in the stream, comprising at least the following steps: the reception of said digital data stream;
  • this position is determined locally by the receiver, the only information coming from the flow involved in the determination of this position being the time references associated with flow data.
  • it also comprises a step of regularly updating the current value of the current relative time position.
  • the updating step comprises a sub-step of determining a value Delta corresponding to the difference between a new time reference received and the last time reference stored.
  • the updating step further comprises a sub-step for comparing the Delta value and a threshold depending on the rate of return of the flux, the presence of a break in sequence being determined by a Delta value greater than the threshold.
  • the update step further comprises adding, in the case of a lack of sequence break, the value of Delta to the current value of the time position maintained. .
  • the updating step further comprises the addition, in the case of a lack of sequence break, of the value of Delta multiplied by the speed of restitution to the value. the current time position.
  • the invention also relates to a digital data stream receiver, the digital stream being broadcast by the server to the receiver via a link connecting the server and the receiver, the digital data stream comprising at least one program intended to be restored to a given speed and temporal references associated with data of the stream, these temporal references being relative to the moment of restitution of the associated data in a temporal repository, these temporal references being sequenced in sequence in the stream, changes in the repository leading to breaks in sequences, which can appear in the stream, comprising at least the following means:
  • means for receiving said digital data stream means for sending a command containing the current relative temporal position in the program contained in the stream, characterized in that it furthermore comprises means for determining this position locally by the receiver, the only information coming from the flow involved in the determination of this position being the time references associated with flow data.
  • this furthermore comprises means for regularly updating the current value of the current relative time position.
  • the updating means comprise means for determining a value Delta corresponding to the difference between a new time reference received and the last time reference stored.
  • the updating means furthermore comprise means for comparing the value Delta and a threshold depending on the rate of restitution of the flow, the presence of a break in sequence being determined by a value of
  • the updating means furthermore comprise means for adding, in the case of a lack of sequence break, the value of Delta to the current value of the temporal position. maintained.
  • the updating means furthermore comprise means of addition, in the case of a lack of sequence break, of the value of Delta multiplied by the speed of restitution to the current value of the time position maintained.
  • Figure 1 shows the known architecture of a VOD service ("Video On Demand” in English).
  • FIG. 2 represents the hardware architecture of the exemplary embodiment of the IP decoder.
  • FIG. 3 represents the software architecture of the exemplary embodiment of the IP decoder.
  • Figure 4 shows an example of a RTSP dialog between a client and a server.
  • FIG. 5 represents a diagram of the images received during a normal rhythm reproduction with the associated PTS values.
  • Figure 6 shows a diagram of the received images and associated PTS during fast forwarding.
  • FIG. 7 represents a diagram of the received images and associated PTS during a transition from a reproduction at a normal rate to a fast forward.
  • Figure 8 shows a diagram of the received images and associated PTS out of range during a normal rhythm playback.
  • FIG. 9 represents a diagram of the images received and the associated PTSs during the transition from a normal-rate reproduction to a fast-forward with interval change.
  • Figure 10 shows a flowchart of the decoder time tracking method.
  • This exemplary embodiment of the invention is placed in the context of a video on demand (VOD) service system.
  • VOD video on demand
  • the general architecture of such a system is described in Figure 1.
  • the system comprises one or more servers, referenced 1.1. These servers store the programs to be broadcast and can send them as data streams.
  • the users of the system typically individuals subscribing to the services will have at their home a service display screen, referenced 1.5, a decoder 1.4, typically a MPEG decoder for decoding the digital data stream received in analog signals to the screen.
  • the decoder is an IP decoder adapted to the reception of the programs via an IP network, referenced 1.2.
  • the modem connects the user's network to the IP distribution network 1.2 which may be the Internet or the private IP distribution network of the video-on-demand service provider.
  • the decoder will be the RTSP client which controls the broadcast of the program by the server via the RTSP protocol in response to requests from the user.
  • the MPEG standard defines how to encode and multiplex the different elementary streams composing a multimedia program.
  • This program typically an audio video program, will consist of different elementary streams.
  • One will generally find a video stream and one or more audio streams.
  • Each elementary stream will comprise entities, called presentation units in the standard ("Presentation Unit” in English).
  • Each of its entities will be associated with a presentation time reference called PTS ("Presentation Time Stamp” in English) giving in the time repository of the encoder, ie according to its system clock, the moment at which this entity or unit presentation must be returned by the decoder. It is the presence of these presentation time references which make it possible, among other things, to synchronize the different elementary streams during the rendering by the decoder of the program.
  • the entity or unit of presentation will typically be the image, while it will be a sample in the case of audio.
  • FIG. 2 describes the hardware architecture of the MPEG decoder of the exemplary embodiment of the invention.
  • This decoder referenced 2.1, is connected to the modem, referenced 2.2, via an Ethernet interface, referenced 2.7. It delivers the analog signals from the decoding of the programs to the TV referenced 2.5.
  • the decoder operates under the direction of a central processor, referenced 2.9. This processor executes programs stored in a flash memory referenced 2.10 using RAM, referenced 2.11 as working memory.
  • the MPEG stream is received via the modem 2.2 and the Ethernet interface 2.7, it is then sent to the audio and video decoder 2.6, this decoder will separate the different elementary streams and to perform a decoding if they are encoded as well as to decompress them.
  • a graphic processor referenced 2.8 is responsible for the generation of graphics superimposed on the video images, it is typically user interface graphics or program guide data or other, the digital to analog conversion module 2.4 goes produce analog signals including programs as well as graphics. These signals will be sent to the program playback device, typically a television referenced 2.3.
  • FIG. 3 represents a diagram of the software architecture implemented on such a decoder according to the exemplary embodiment of the invention.
  • An RTOS real-time operating system (RTOS) ensures the basic operation of the device.
  • RTOS real-time operating system
  • a conditional access module referenced 3.4 will be responsible for ensuring that the user has the rights to view the programs.
  • an IP communication stack referenced 3.3, allows the dialogue with the network including the video-on-demand server.
  • VOD module referenced 3.8
  • VOD server The management of access to the video-on-demand service will be dedicated to a VOD module, referenced 3.8, lying on top of IP and will manage the dialogue with the VOD server, it is within this module that we find the means of implementation of the invention according to the embodiment described.
  • FIG. 4 represents an example of a dialogue between the client and the VOD server using the RTSP protocol according to the exemplary embodiment of the invention.
  • RTSP is a server client protocol for managing the commands of a real-time broadcast server. This protocol only manages the commands, it does not take into account the sending of data that is done according to other protocols.
  • RTP Real time Transport Protocol
  • the server is free to use any protocol of its choice in sending data.
  • UDP User Datagram Protocol
  • RTP User Datagram Protocol
  • RTSP offers the possibility to the client to open a session on the server via the "SETUP" command.
  • This session defines the requested program, destination, transport mode and various other parameters. It then makes it possible to ask the server to send the data for a program range, specifying the speed of playback, command "PLAY”. It is also possible to ask the server to pause the sending of data, command "PAUSE”. The end of the session comes on a "TEARDOWN" command.
  • the complete description of this protocol is referenced in RFC 2326.
  • the client VOD and therefore the decoder, initializes a session with a message M1 containing the command "SETUP".
  • This command specifies that the client wants the program whose address is rtsp: //192.9.210.233: 5004 / asset / vscontsrv% 3vodstream_scr-free-f using version 1.0 of the RTSP protocol in unicast via the UDP protocol to the address 192.9.210.23 on port 20000.
  • the server will respond with the M2 acceptance message.
  • this argument specifies that the program sent contains time references of presentation starting with the value 75621 and ending with the value 2146421. This information can be used by the client to later be located in the program. Indeed, a presentation time reference received should make it possible to locate the associated program entity with respect to these terminals that are called
  • NPT Normal Play Time
  • the left part of the fraction gives the time in second or hour, minute and second, while the right part measures fractions of seconds.
  • the message M3 therefore requests the broadcast of the entire program from its beginning "0.00" to the end "end”.
  • the message M4 is an acceptance of the message M3.
  • the client requests a break via the message M5. This pause is accepted via the message M6.
  • the message M7 is a message that requires a fast forward to 8 times the normal speed from the current point of the program.
  • the message M8 is an acceptance of the message M7.
  • the communication example above shows the importance of the temporal location in the broadcast stream for the decoder. Indeed, for example when the decoder requests a fast forwarding at the speed 8 as in the M7 message, it must give the starting point of the requested range. This starting point must correspond exactly to the current point of the broadcast of the program so that the user does not perceive a jump during the change of mode.
  • the decoder there are different ways for the decoder to know the current time position in the stream. It has been seen in the example that the server, when it acknowledges the "SETUP" command, gives the limits of the presentation time references used in the broadcast stream. These terminals are called PTS_Start and PTS_End. Excluding the broadcast MPEG stream contains presentation time references associated with the program images as illustrated in FIG. 5. In this figure each arrow represents an image received during the broadcast of a program with the associated presentation time reference value. Since the broadcast starts at time TO, the first image received will be associated with PTS_1 having the value value_1. The second image received will be associated with PTS_2 having the value value_2 and so on. Logically, the value value_1 corresponds to PTS_Start.
  • Figure 6 illustrates a fast forward in double speed of normal.
  • the first image is thus associated with a PTS of value value_1
  • the second corresponds to the third image of the program played at normal speed and is associated with a PTS of value value_3 corresponding to the moment of presentation of this third image if the flow was played at a normal speed.
  • a positioning based on the difference of the last PTS received with the PTS_Start still gives us the current relative time compared to the beginning of the program.
  • FIG. 7 illustrates the case where a passage in double speed mode occurs during transmission at time t1.
  • t0 and t1 during normal speed broadcasting or between t1 and t2 during double speed broadcasting, the same technique still gives a current relative time with respect to the beginning of the reliable program.
  • servers can rely on different versions of the program to implement particular rendering modes such as fast forward or rewind.
  • the server will have a version of the program for normal broadcasting and versions encoded at different speeds to meet requests for restitution at slow speed or accelerated.
  • a different version containing one of two images will be used for double speed broadcasting.
  • each version will generally have presentation time references calculated in a different time frame. This situation is illustrated in FIG. 9.
  • a request for fast double speed restitution occurs at time t1, the values of PTS value_x4 and value_x6 are in a time differential different from the values value_1, value_2 and value_3 of the stream broadcast at normal speed between t0 and t1.
  • NPT descriptor As described in chapter 8 of the DSM-CC standard (ISO / IEC 13818-6). These descriptors are inserted into the stream at the time of the sequence break and indicate the correspondence between the presentation timing references of the sequence and a logical repository for the stream. But not all servers use this possibility.
  • Another way to solve these problems is to not use the time references received but to ask the server current relative time value whenever needed.
  • the client before issuing a command to use a range argument such as the "PLAY" command, the client requests, using the "GET_PARAMETER” command, the relative current time position of the stream.
  • This method is generally functional but introduces a delay corresponding to the sending of the command and the return of the result as well as the corresponding use of the bandwidth.
  • FIG. 10 This method will consist in maintaining a current value relative to the beginning of the program and updating this value as a function of the time reference values received. This method is described in FIG. 10.
  • a first step E1 carried out at the beginning of the broadcast of the program, the first received PTS is stored in a variable Prime_PTS.
  • a variable Current_current is initialized to 0. This variable will contain at any time the current relative temporal position in the program.
  • the variable Demier_PTS corresponding to the value of the last PTS received, is also initialized to the value of the first PTS.
  • step E2 is performed. This step consists of calculating the difference between this new PTS received and the previous stored in Demier_PTS. This information is stored in a Delta variable.
  • the Delta value is compared to a threshold.
  • the temporal presentation references being associated with stream entities, typically video images, it is possible to determine the expected difference between two successive values of PTS received. This difference is typically the image frequency expressed according to a clock of 90 kHz.
  • Threshold for example equal to twice the frame rate, or the frame rate multiplied by the maximum speed of the server plus a safety factor.
  • step E4 is carried out, consisting of accumulating the Delta value in the current time.
  • the value of the last received PTS is updated with the value of the new PTS in step E5.
  • variable Current_time contains at any time an accumulation of the differences between the temporal references belonging to the same sequence. At the break of sequence no time is accumulated.
  • the decoder When the decoder has to send a command to the server requiring a range of which one of the terminals is the current time, it will use this value as the basis of the current time.
  • the calculation of a NPT value in seconds is direct and corresponds to Current_time divided by the image frequency.
  • the described method makes the assumption that the presentation temporal references inserted in the flux are the time references calculated for normal speed playback. Indeed, the difference between two PTS is considered as representing the time difference in the program between the two corresponding entities during a restitution in normal mode. It turns out that some servers, for the sake of compliance with the MPEG standard, will generate new presentation time references in modes of restitution at a modified speed compared to the normal speed.
  • two successive images corresponding to two images separated by 3 other images in the stream intended for the normal mode will be given PTS values separated from the image frequency in place of PTS values calculated in the flow destined for the normal mode and separated by 4 times the image frequency.
  • a variant of the described method consists in comparing, during a modified speed reproduction, the difference between two time reference values with the image frequency. If this difference is close to the frame rate instead of being produced by the restitution rate, the delta will be multiplied by the speed before being accumulated at the current time.
  • the exemplary embodiment of the invention is based on MPEG presentation time references as well as the use of the RTSP protocol using ranges defined in the NPT form, but the invention is generalized to other types of references. included in a digital data stream as well as to other server control protocols, regardless of the method of coding the temporal data used by this protocol.
  • the exemplary embodiment is based on the broadcast of the stream over an IP network, but the invention can be extended to other types of networks.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention propose un procédé local au client d'envoi de commandes vers un serveur de VOD, par exemple selon RTSP, ces commandes comprenant une référence à la position courante relative. Cette position courante relative est maintenue par le récepteur sur la base des PTS reçus dans le flux MPEG, sans faire appel à une requête vers le serveur ni en se basant sur l'existence dans le flux de descripteur permettant de faire face aux ruptures de séquences dans les PTS inclus dans le flux.

Description

Procédé d'envoi de commande à un serveur de flux de données numériques et appareil implémentant le procédé
La présente invention concerne le domaine du contrôle par un récepteur d'un serveur de contenu à la demande. Plus particulièrement dans le cas où le serveur diffuse » son contenu sous la forme d'un flux de données numérique via un réseau IP.
L'IETF (« Internet Engineering Task Force » en anglais) a défini, notamment dans la RFC (« Request For Comment » en anglais) 2326, un protocole de commande de serveurs de flux de données numériques. Ce protocole, appelé RTSP (« Real Time Streaming Protocol » en anglais), permet de commander un serveur, d'ouvrir une session, de demander le lancement d'un programme, son arrêt temporaire, sa reprise où son arrêt définitif.
Il est donc possible, à l'aide de RTSP, d'implémenter des modes de restitutions particuliers des programmes (« Trick Modes » en anglais). Ces modes permettent d'apporter les commandes auxquelles les utilisateurs sont habitués sur un magnétoscope, à la visualisation de programmes diffusés sur IP. On peut citer dans ces modes l'avance rapide et le retour arrière, ainsi que le positionnement à des endroits préalablement repérés dans le programme.
La plupart des commandes RTSP, notamment la commande
« Play » impliquée dans les modes de restitution particuliers, nécessitent un paramètre donnant la référence temporelle de la plage du programme que l'on souhaite repérée par un intervalle entre une référence de début et une référence de fin. Le client RTSP doit donc être en mesure de connaître précisément la localisation temporelle courante dans le fichier joué. Il existe plusieurs approches permettant au client de connaître à chaque instant la position temporelle courante relative dans le programme. Certains serveurs, par exemple les serveurs Oracle, envoient des descripteurs temporels mélangés au programme, mais ce mécanisme n'est pas adopté par la totalité des serveurs. Une autre façon de faire consiste pour le client à utiliser la commande RTSP « GET PARAMETER » pour obtenir du serveur la référence temporelle courante. Cette solution nécessite le temps de l'envoi de la requête et du retour de la réponse. C'est tout de même la méthode la plus couramment utilisée.
La norme MPEG, référencée « MPEG-2 System : ISO/IEC, 1994.
Generic Coding of Moving Pictures and Associated Audio : Systems, (MPEG-2 Systems Spécification), November, ISO/IEC 13818-1 » décrit la façon de multiplexer du contenu multimédia en vue de sa restitution et de son transport. Un programme est séparé en flux élémentaires, chaque flux élémentaire étant découpé en paquets de données.
De façon à permettre la restitution du contenu, chaque entité au niveau des flux élémentaires, par exemple une image pour un flux vidéo se voit attribuer une référence temporelle, appelée PTS ( « Présentation Time Stamp » en anglais). Cette référence temporelle, indique le moment où l'entité associée, ici l'image doit être restituée. La base de cette référence temporelle étant l'horloge de référence du système, une horloge à 90 kHz. Ce sont ces références temporelles qui permettent de synchroniser entre eux les différents flux élémentaires constituant le programme.
La succession de ces références temporelles de présentation dans le flux du programme n'est généralement pas continue du début du programme à la fin. En effet, un programme peut résulter de l'assemblage de plusieurs séquences ayant été encodées séparément et dont les références temporelles de présentation n'ont donc pas été calculées dans le même référentiel de temps. De plus, lors de l'utilisation des modes de restitution particuliers, une technique courante consiste à utiliser des versions encodées différemment pour différents modes. Par exemple, le serveur disposera d'une version du programme encodée en vitesse double dont il se servira s'il reçoit une commande d'avance rapide. Ici encore les différentes versions du programmes posséderont des références temporelles de présentation correspondant à différents référentiels de temps. Les références temporelles de présentation présentes dans le flux forment donc généralement une succession de séquences chacune de ces séquences correspondant à un référentiel de temps propre. II s'agit donc de trouver une méthode fiable de repérage temporel relatif au sein du programme diffusé applicable par le client RTSP. Cette méthode ne reposant pas sur l'utilisation des descripteurs qui ne sont pas toujours présents dans le flux diffusé, ne nécessitant pas de requête vers le serveurs et permettant de faire face aux changements de référentiel de temps des séquences de références temporelles de présentation.
L'invention propose un procédé local au client d'envoi de commandes vers un serveur de VOD, par exemple selon RTSP, ces commandes comprenant une référence à la position courante relative. Cette position courante relative est maintenue par le récepteur sur la base des PTS reçus dans le flux MPEG, sans faire appel à une requête vers le serveur ni en se basant sur l'existence dans le flux de descripteur permettant de faire face aux ruptures de séquences dans les PTS inclus dans le flux. L'invention concerne également le client adapté pour mettre en oeuvre le procédé.
L'invention concerne un procédé d'envoi de commande à un serveur de flux de données numériques par un récepteur, le flux numérique étant diffusé par le serveur à destination du récepteur via un lien reliant le serveur et le récepteur, le flux de données numérique comprenant au moins un programme destiné à être restitué à une vitesse donnée et des références temporelles associées à des données du flux, ces références temporelles étant relatives au moment de restitution des données associées dans un référentiel temporel, ces références temporelles se suivant en séquence dans le flux, des changements de référentiel entraînant des ruptures de séquences, pouvant apparaître dans le flux, comportant au moins les étapes suivantes : - la réception dudit flux de données numériques ;
- l'envoi d'une commande contenant la position temporelle relative courante dans le programme contenu dans le flux, caractérisé en ce que cette position est déterminée localement par le récepteur, les seules informations issues du flux intervenant dans la détermination de cette position étant les références temporelles associées à des données du flux. Selon un mode particulier de réalisation de l'invention celle-ci comprend en outre une étape de mise à jour régulière de la valeur courante de la position temporelle relative courante.
Selon un mode particulier de réalisation de l'invention l'étape de mise à jour comprend une sous étape de détermination d'une valeur Delta correspondant à la différence entre une nouvelle référence temporelle reçue et la dernière référence temporelle mémorisée.
Selon un mode particulier de réalisation de l'invention l'étape de mise à jour comprend en outre une sous étape de comparaison de la valeur Delta et d'un seuil dépendant de la vitesse de restitution du flux, la présence d'une rupture de séquence étant déterminée par une valeur de Delta supérieure au seuil.
Selon un mode particulier de réalisation de l'invention l'étape de mise à jour comprend en outre l'addition, dans le cas d'une absence de rupture de séquence, de la valeur de Delta à la valeur courante de la position temporelle maintenue.
Selon un mode particulier de réalisation de l'invention l'étape de mise à jour comprend en outre l'addition, dans le cas d'une absence de rupture de séquence, de la valeur de Delta multipliée par la vitesse de restitution à la valeur courante de la position temporelle maintenue.
L'invention concerne également un récepteur de flux de données numériques, le flux numérique étant diffusé par le serveur à destination du récepteur via un lien reliant le serveur et le récepteur, le flux de données numérique comprenant au moins un programme destiné à être restitué à une vitesse donnée et des références temporelles associées à des données du flux, ces références temporelles étant relatives au moment de restitution des données associées dans un référentiel temporel, ces références temporelles se suivant en séquence dans le flux, des changements de référentiel entraînant des ruptures de séquences, pouvant apparaître dans le flux, comportant au moins les moyens suivante :
- un moyen de réception dudit flux de données numériques ; - un moyen d'envoi d'une commande contenant la position temporelle relative courante dans le programme contenu dans le flux, caractérisé en ce qu'il comporte en outre un moyen de détermination de cette position localement par le récepteur, les seules informations issues du flux intervenant dans la détermination de cette position étant les références temporelles associées à des données du flux.
Selon un mode particulier de réalisation de l'invention celle-ci comprend en outre des moyens de mise à jour régulière de la valeur courante de la position temporelle relative courante.
Selon un mode particulier de réalisation de l'invention les moyens de mise à jour comprennent des moyens de détermination d'une valeur Delta correspondant à la différence entre une nouvelle référence temporelle reçue et la dernière référence temporelle mémorisée.
Selon un mode particulier de réalisation de l'invention les moyens de mise à jour comprennent en outre des moyens de comparaison de la valeur Delta et d'un seuil dépendant de la vitesse de restitution du flux, la présence d'une rupture de séquence étant déterminée par une valeur de
Delta supérieure au seuil.
Selon un mode particulier de réalisation de l'invention les moyens de mise à jour comprennent en outre des moyens d'addition, dans le cas d'une absence de rupture de séquence, de la valeur de Delta à la valeur courante de la position temporelle maintenue.
Selon un mode particulier de réalisation de l'invention les moyens de mise à jour comprennent en outre des moyens d'addition, dans le cas d'une absence de rupture de séquence, de la valeur de Delta multipliée par la vitesse de restitution à la valeur courante de la position temporelle maintenue. L'invention sera mieux comprise, et d'autres particularités et avantages apparaîtront à la lecture de la description qui va suivre, la description faisant référence aux dessins annexés parmi lesquels :
La figure 1 représente l'architecture connue d'un service de VOD (« Video On Demand » en anglais).
La figure 2 représente l'architecture matérielle de l'exemple de réalisation du décodeur IP.
La figure 3 représente l'architecture logicielle de l'exemple de réalisation du décodeur IP. La figure 4 représente un exemple de dialogue RTSP entre un client et un serveur.
La figure 5 représente un diagramme des images reçues lors d'une restitution à rythme normal avec les valeurs de PTS associées.
La figure 6 représente un diagramme des images reçues et des PTS associés lors d'une avance rapide.
La figure 7 représente un diagramme des images reçues et des PTS associés lors d'un passage d'une restitution à un rythme normal à une avance rapide.
La figure 8 représente un diagramme des images reçues et des PTS associés hors intervalle lors d'une restitution à rythme normal.
La figure 9 représente un diagramme des images reçues et des PTS associés lors du passage d'une restitution à rythme normal à une avance rapide avec changement d'intervalle.
La figure 10 représente un organigramme de la méthode de repérage temporel du décodeur.
Un exemple de réalisation de l'invention va maintenant être décrit.
Cet exemple de réalisation de l'invention se place dans le contexte d'un système de service de vidéo à la demande (VOD pour « Video On Demand » en anglais). L'architecture générale d'un tel système est décrit à la figure 1. Le système comprend un ou plusieurs serveurs, référencés 1.1. Ces serveurs stockent les programmes à diffuser et peuvent les envoyer sous la forme de flux de données. Les utilisateurs du système, typiquement des particuliers abonnés au services vont disposer à leur domicile d'un écran de visualisation du service, référencé 1.5, d'un décodeur 1.4, typiquement un décodeur MPEG permettant le décodage du flux de données numérique reçu en signaux analogiques à destination de l'écran. Dans le contexte ici décrit, le décodeur est un décodeur IP adapté à la réception des programmes via un réseau IP, référencé 1.2. Le modem, référencé 1.3 permet de connecter le réseau de l'utilisateur au réseau de distribution IP 1.2 qui peut être Internet ou le réseau de distribution IP privé du fournisseur de service de vidéo à la demande. Dans un tel système, le décodeur sera le client RTSP qui commande la diffusion du programme par le serveur via le protocole RTSP en réponse aux demandes de l'utilisateur.
La norme MPEG définit la façon d'encoder et de multiplexer les différents flux élémentaires composant un programme multimédia. Ce programme, typiquement un programme audio vidéo, va se composer de différents flux élémentaires. On trouvera généralement un flux vidéo et un ou plusieurs flux audio. Chaque flux élémentaire va comprendre des entités, appelées unités de présentation dans la norme (« Présentation Unit » en anglais). Chacune de ses entités se verra associé une référence temporelle de présentation appelée PTS (« Présentation Time Stamp » en anglais) donnant dans le référentiel temporel de l'encodeur, c'est à dire selon son horloge système, le moment auquel cette entité ou unité de présentation devra être restituée par le décodeur. C'est la présence de ces références temporelles de présentation qui permettent, entre autre, de synchroniser les différents flux élémentaires lors de la restitution par le décodeur du programme. Dans le cas de la vidéo, l'entité ou unité de présentation sera typiquement l'image, tandis qu'il s'agira d'un échantillon dans le cas de l'audio.
La figure 2 décrit l'architecture matérielle du décodeur MPEG de l'exemple de réalisation de l'invention. Ce décodeur, référencé 2.1 , est connecté au modem, référencé 2.2, via une interface Ethernet, référencée 2.7. Il délivre les signaux analogiques issus du décodage des programmes à la TV référencée 2.5. Le décodeur fonctionne sous la direction d'un processeur central, référencé 2.9. Ce processeur exécute des programmes stockés dans une mémoire Flash référencée 2.10 en utilisant la mémoire vive, référencée 2.11 comme mémoire de travail. Le flux MPEG est reçu via le modem 2.2 et l'interface Ethernet 2.7, il est ensuite envoyé au décodeur audio et vidéo 2.6, ce décodeur va séparer les différents flux élémentaires et en effectuer un décodage s'ils sont encodés ainsi que les décompresser. Les flux audio et vidéo élémentaires décompressés sont ensuite envoyés à un convertisseur numérique vers analogique, référencé 2.4. Un processeur graphique référencé 2.8 est chargé de la génération de graphiques venant se superposer sur les images vidéo, il s'agit typiquement de graphiques d'interface utilisateur ou de données de guide de programme ou autre, le module de conversion numérique vers analogique 2.4 va produire les signaux analogiques comprenant les programmes ainsi que les graphiques. Ces signaux seront envoyés vers l'appareil de restitution du programme, typiquement un téléviseur référencé 2.3.
La figure 3 représente un schéma de l'architecture logicielle implémentée sur un tel décodeur selon l'exemple de réalisation de l'invention. On y trouve une couche de pilotes référencé 3.6 servant à piloter le matériel référencé 3.7. Un système d'exploitation temps réel RTOS (pour « Real Time Operating System » en anglais) assure le fonctionnement de base de l'appareil. Généralement, un module d'accès conditionnel référencé 3.4 sera chargé d'assurer que l'utilisateur possède les droits permettant de visualiser les programmes. Pour gérer les communications et particulièrement la réception des programmes, une pile de communication IP, référencée 3.3, permet le dialogue avec le réseau dont le serveur de vidéo à la demande. La gestion de l'accès au service de vidéo à la demande sera dédiée à un module VOD, référencé 3.8, couché au dessus d'IP et qui va gérer le dialogue avec le serveur de VOD, c'est au sein de ce module que l'on trouve les moyens de mise en oeuvre de l'invention selon l'exemple de réalisation décrit. Au plus haut niveau, l'on trouve un ensemble d'applications référencé 3.2 permettant d'offrir à l'utilisateur un ensemble de services parmi lesquels, une interface de choix de programme et souvent un guide de programmes.
La figure 4 représente un exemple de dialogue entre le client et le serveur de VOD utilisant le protocole RTSP selon l'exemple de réalisation de l'invention. RTSP est un protocole client serveur permettant la gestion des commandes d'un serveur de diffusion temps réels de programmes. Ce protocole ne gère que les commandes, il ne prend pas en compte l'envoi des données qui se fait selon d'autres protocoles. Généralement RTSP est couplé avec l'envoi de données selon le protocole RTP (« Real time Transport Protocol » en anglais) décrit dans la RFC 1889. Mais le serveur est libre d'utiliser tout protocole de son choix dans l'envoi des données. On peut, par exemple, envoyer les données directement sur UDP (« User Datagram Protocol » en anglais, RFC 768), protocole sur lequel est basé RTP.
RTSP, offre la possibilité au client d'ouvrir une session sur le serveur via la commande « SETUP ». Cette session définit le programme demandé, la destination, le mode de transport ainsi que divers autres paramètres. Il permet ensuite de demander au serveur l'envoi des données pour une plage de programme, en précisant la vitesse de restitution, commande « PLAY ». Il est également possible de demander au serveur d'effectuer une pause dans l'envoi des données, commande « PAUSE ». La fin de la session intervient sur une commande « TEARDOWN ». La description complète de ce protocole se trouve référencée dans la RFC 2326.
Dans l'exemple de la figure 4, la client VOD, donc le décodeur, initialise une session par un message M1 contenant la commande « SETUP ». Cette commande précise que le client désire le programme dont l'adresse est rtsp://192.9.210.233:5004/asset/vscontsrv%3vodstream_scr- free-f en utilisant la version 1.0 du protocole RTSP en unicast via le protocole UDP vers l'adresse 192.9.210.23 sur le port 20000.
Le serveur va répondre par le message d'acceptation M2. On voit ici que le serveur envoie un argument « a=range:pts=75621 -2146421 », cet argument précise que le programme envoyé contient des références temporelles de présentation démarrant à la valeur 75621 et finissant à la valeur 2146421. Cette information peut être utilisée par le client pour ultérieurement se situer temporellement dans le programme. En effet, une référence temporelle de présentation reçue devrait permettre de situer l'entité de programme associée par rapport à ces bornes que l'on nomme
« PTS_start » et « PTS_end ». Nous verrons que malheureusement, tous les serveurs n'envoient pas cet argument et que même quand on en dispose, les références temporelles trouvées dans le programme diffusé ne sont pas toujours calculées dans le même référentiel que cet intervalle retourné en acceptation du « SETUP ». Le client est ensuite en mesure de demander au serveur de commencer l'envoi du programme par l'envoi du message M3 contenant une commande « PLAY ». La commande « PLAY » doit contenir une indication de la plage de programme que l'on souhaite recevoir. Cette plage peut être la totalité du programme, c'est ici le cas, ce qui est indiqué par l'argument « Range: npt=O.OO-end ». Il existe plusieurs manières d'indiquer une plage de programme, plusieurs manière d'indiquer le temps, l'exemple utilise la notation NPT (« Normal Play Time » en anglais) qui indique la position temporelle dans le flux relativement au début du programme sous la forme d'une fraction décimale. La partie gauche de la fraction donne le temps en seconde ou en heure, minute et seconde, tandis que la partie droite mesure des fractions de secondes. Le message M3 demande donc la diffusion du programme entier de son début « 0.00 » à la fin « end ».
Le message M4, est une acceptation du message M3.
Un peu plus tard, en cours de diffusion, le client demande une pause via le message M5. Cette pause est acceptée via le message M6.
Le message M7, quant à lui, est un message qui demande une avance rapide à 8 fois la vitesse normale à partir du point courant du programme. L'argument de plage utilisé est donc « Range: npt=42.72-end » et la vitesse de jeu demandée est passée via l'argument « Scale: 8.0 ». Le message M8 est une acceptation du message M7.
L'exemple de communication ci-dessus nous montre l'importance de la localisation temporelle dans le flux diffusé pour le décodeur. En effet, par exemple lorsque le décodeur demande un passage en avance rapide à la vitesse 8 comme dans le message M7, il doit donner le point de départ de la plage demandée. Ce point de départ doit correspondre exactement au point courant de la diffusion du programme pour que l'utilisateur ne perçoive pas de saut lors du changement de mode.
Il existe différents moyens pour le décodeur de connaître la position temporelle courante dans le flux. On a vu dans l'exemple que le serveur, lorsqu'il acquitte la commande « SETUP » donne les bornes des références temporelles de présentation utilisées dans le flux diffusé. Ces bornes sont appelées PTS_Start et PTS_End. Hors le flux MPEG diffusé contient des références temporelles de présentation associées aux images du programme comme illustré figure 5. Sur cette figure chaque flèche représente une image reçue lors de la diffusion d'un programme avec la valeur de référence temporelle de présentation associée. La diffusion démarrant au temps TO, la première image reçue sera associée au PTS_1 ayant la valeur value_1. La seconde image reçue sera associée au PTS_2 ayant la valeur value_2 et ainsi de suite. En toute logique la valeur value_1 correspond à PTS_Start. Dans ce schéma, il est possible de se situer dans le temps par rapport au début du programme en fonction de la dernière référence temporelle de présentation reçue, il suffit de soustraire à cette dernière valeur de PTS, la valeur stockée de PTS_Start pour connaître le temps relatif courant par rapport au début du programme. Ce temps sera connu à la précision de l'horloge de 90 kHz utilisée pour générer les PTS.
La figure 6 illustre une avance rapide en vitesse double de la normale. On voit ici que l'on reçoit une image sur 2 avec les références temporelles associées. La première image est donc associée à un PTS de valeur value_1 , tandis que la seconde correspond à la troisième image du programme joué à vitesse normale et est associée à un PTS de valeur value_3 correspondant au moment de présentation de cette troisième image si le flux était joué à une vitesse normale. On voit, donc que ici encore un positionnement basé sur la différence du dernier PTS reçu avec le PTS_Start nous donne encore le temps relatif courant par rapport au début du programme.
La figure 7 illustre le cas où un passage en mode vitesse double se produit en cours de diffusion à l'instant t1. Ici encore, que l'on se place entre tO et t1 , pendant la diffusion à vitesse normale ou entre t1 et t2 pendant la diffusion en vitesse double, la même technique donne encore un temps relatif courant par rapport au début du programme fiable.
Malheureusement, on constate d'une part que tous les serveurs ne donnent pas l'information de plage des PTS lors de l'acquittement d'une commande « SETUP ». De plus, même dans le cas où le serveur donne bien cette plage, il s'avère que les références temporelles de présentation contenues dans le flux reçu sont parfois calculées dans un référentiel temporel différent du référentiel utilisé pour le calcul des valeurs de PTS_Start et PTS_End communiquées par le serveur. Il arrive également que le programme diffusé soit l'assemblage de plusieurs séquences ayant été encodées séparément. Dans ce cas, généralement, chaque séquence possède des références temporelles de présentation calculées dans son propre référentiel temporel. Il s'ensuit des changements de référentiel au cours de la diffusion. Cette situation est décrite dans la figure 8, ici les valeurs appelées value_1 , value_2 et value_3 correspondent à une première séquence. Un changement de séquence intervient à l'instant t1. Les valeur appelée value_x4 et value_x5 correspondent à une seconde séquence. Chaque séquence ayant été encodée dans son propre référentiel, une rupture de séquence intervient entre les deux.
De même, les serveurs peuvent s'appuyer sur des versions différentes du programme pour implémenter les modes de restitution particuliers comme l'avance rapide ou le retour arrière. Dans ce cas le serveur va disposer d'une version du programme pour la diffusion normale et de versions encodées à différentes vitesses pour répondre aux demandes de restitution à vitesse lente où accélérée. Par exemple une version différente contenant une image sur deux sera utilisée pour la diffusion à vitesse double. Ici encore, chaque version possédera généralement des références temporelles de présentation calculées dans un référentiel temporel différent. Cette situation est illustrée figure 9. Sur cette figure, une demande de restitution rapide en vitesse double intervient à l'instant t1 , les valeurs de PTS value_x4 et value_x6 sont dans un différentiel temporel différent des valeurs value_1 , value_2 et value_3 du flux diffusé à vitesse normale entre tO et t1.
Une des solutions à ces problèmes de ruptures de séquence est l'insertion de « NPT descriptor » comme décrit au chapitre 8 du standard DSM-CC (ISO/IEC 13818-6). Ces descripteurs sont insérés dans le flux au moment de la rupture de séquence et indique la correspondance entre les références temporelles de présentation de la séquence et un référentiel logique pour le flux. Mais tous les serveurs n'utilisent pas cette possibilité.
Une autre façon de résoudre ces problèmes consiste à ne pas utiliser les références temporelles reçues mais à demander au serveur la valeur du temps relatif courant à chaque fois que l'on en a besoin. Un mécanisme existe dans RTSP pour demander des paramètres au serveur sous la forme d'une commande « GET PARAMETER ». Dans ce cas, avant d'émettre une commande devant utiliser un argument de plage comme la commande « PLAY » le client demande, à l'aide de la commande « GET_PARAMETER » la position courante temporelle relative du flux. Cette méthode est généralement fonctionnelle mais introduit un délai correspondant à l'envoi de la commande et au retour du résultat ainsi que l'utilisation correspondante de la bande passante.
Nous allons maintenant décrire un exemple de procédé fiable de calcul local de la position temporelle relative courante du flux, ne nécessitant pas l'insertion de descripteurs par le serveur ni l'envoi d'une requête au serveur. Ce procédé, permet également de faire face à des ruptures de séquences dans les références temporelles de présentation. Ce procédé est illustré figure 10. Il va consister à maintenir une valeur courante relative au début du programme et à mettre cette valeur à jour en fonction des valeurs de références temporelles reçues. Cette méthode est décrite figure 10. Lors d'une première étape E1 , effectuée au début de la diffusion du programme, on mémorise le premier PTS reçu, dans une variable Premier_PTS. On initialise une variable Temps_courant à 0. Cette variable contiendra à tout moment la position temporelle courante relative dans le programme. On initialise également la variable Demier_PTS, correspondant à la valeur du dernier PTS reçu, à la valeur du premier PTS.
Ensuite, lorsque l'on reçoit une nouvelle valeur de PTS dans le flux, on effectue l'étape E2. Cette étape consiste à calculer la différence entre ce nouveau PTS reçu et le précédent mémorisé dans Demier_PTS. Cette information est mémorisée dans une variable Delta.
Dans le but de détecter les ruptures de séquences, la valeur de Delta est comparée à un seuil. En effet, les références temporelles de présentation étant associées à des entités du flux, typiquement aux images vidéo, on est à même de déterminer la différence attendue entre deux valeurs successives de PTS reçus. Cette différence est typiquement la fréquence image exprimée selon une horloge de 90 kHz. Il faut, bien sûr, tenir compte de la vitesse de restitution courante. On peut donc déterminer un seuil Seuil, par exemple égal à deux fois la fréquence image, ou la fréquence image multiplié par la vitesse maximum du serveur plus un coefficient de sécurité. Lorsque la valeur Delta est supérieure à ce seuil, on estime être en présence d'une rupture de séquence. Dans le cas contraire, on estime qu'il n'y a pas de rupture de séquence. En l'absence de rupture de séquence, on effectue l'étape E4, consistant à accumuler la valeur Delta dans le temps courant. Dans tous les cas, on effectue une mise à jour de la valeur du dernier PTS reçu avec la valeur du nouveau PTS à l'étape E5. On boucle ensuite à nouveau sur l'étape E2 à la réception d'une nouvelle référence temporelle de présentation dans le flux.
De cette manière, la variable Temps_courant contient à tout moment une accumulation des différences entre les références temporelles appartenant à une même séquence. A la rupture de séquence aucun temps n'est accumulé.
Lorsque le décodeur doit envoyer une commande au serveur nécessitant une plage dont l'une des bornes est le temps courant il utilisera cette valeur comme base du temps courant. Le calcul d'une valeur NPT en seconde est direct et correspond à Temps_courant divisé par la fréquence image.
Dans les modes de restitution particuliers où le flux n'est pas joué à vitesse normale, c'est-à-dire les modes de ralenti ou de vitesse accéléré, le procédé décrit fait l'hypothèse que les références temporelles de présentation insérées dans le flux sont les références temporelles calculées pour une restitution à vitesse normale. En effet, la différence entre deux PTS est considérée comme représentant la différence temporelle dans le programme entre les deux entités correspondantes lors d'une restitution en mode normal. Il s'avère que certains serveurs, par soucis de respect de la norme MPEG, vont générer de nouvelles références temporelles de présentation dans les modes de restitution à vitesse modifiée par rapport à la vitesse normale. Par exemple, en vitesse accélérée d'un facteur 4, deux images successives correspondant à deux images séparées par 3 autres images dans le flux destiné au mode normal, vont se voir attribuer des valeurs de PTS séparées de la fréquence image en lieu et place des valeurs de PTS calculées dans le flux destiné au mode normal et séparées de 4 fois la fréquence image. Une variante du procédé décrit consiste à comparer, lors d'une restitution à vitesse modifiée, la différence entre deux valeurs de référence temporelle avec la fréquence image. Si cette différence est voisine de la fréquence image au lieu d'en être le produit par la vitesse de restitution, le delta sera multiplié par la vitesse avant d'être accumulé au temps courant.
L'exemple de réalisation de l'invention est basé sur les références temporelles de présentation de MPEG ainsi que sur l'utilisation du protocole RTSP utilisant des plages définies sous la forme NPT, mais l'invention se généralise à d'autres types de références temporelles incluse dans un flux de données numérique ainsi qu'à d'autres protocoles de commandes de serveurs et ceci quelle que soit la méthode de codage des données temporelles utilisées par ce protocole. L'exemple de réalisation est basée sur la diffusion du flux sur un réseau IP, mais l'invention peut s'étendre à d'autre types de réseaux.

Claims

REVENDICATIONS
1. Procédé d'envoi de commande à un serveur de flux de données numériques par un récepteur, le flux numérique étant diffusé par le serveur à destination du récepteur via un lien reliant le serveur et le récepteur, le flux de données numérique comprenant au moins un programme destiné à être restitué à une vitesse donnée et des références temporelles associées à des données du flux, ces références temporelles étant relatives au moment de restitution des données associées dans un référentiel temporel, ces références temporelles se suivant en séquence dans le flux, des changements de référentiel entraînant des ruptures de séquences, pouvant apparaître dans le flux, comportant au moins les étapes suivantes :
- la réception dudit flux de données numériques ; - l'envoi d'une commande contenant la position temporelle relative courante dans le programme contenu dans le flux, caractérisé en ce que cette position est déterminée localement par le récepteur, les seules informations issues du flux intervenant dans la détermination de cette position étant les références temporelles associées à des données du flux.
2. Procédé selon la revendication 1 comprenant en outre une étape de mise à jour régulière de la valeur courante de la position temporelle relative courante.
3. Procédé selon la revendication 2 où l'étape de mise à jour comprend une sous étape de détermination d'une valeur Delta correspondant à la différence entre une nouvelle référence temporelle reçue et la dernière référence temporelle mémorisée.
4. Procédé selon la revendication 3 où l'étape de mise à jour comprend en outre une sous étape de comparaison de la valeur Delta et d'un seuil dépendant de la vitesse de restitution du flux, la présence d'une rupture de séquence étant déterminée par une valeur de Delta supérieure au seuil.
5. Procédé selon la revendication 4 où l'étape de mise à jour comprend en outre l'addition, dans le cas d'une absence de rupture de séquence, de la valeur de Delta à la valeur courante de la position temporelle maintenue.
6. Procédé selon la revendication 4 où l'étape de mise à jour comprend en outre l'addition, dans le cas d'une absence de rupture de séquence, de la valeur de Delta multipliée par la vitesse de restitution à la valeur courante de la position temporelle maintenue.
7. Récepteur de flux de données numériques, le flux numérique étant diffusé par le serveur à destination du récepteur via un lien reliant le serveur et le récepteur, le flux de données numérique comprenant au moins un programme destiné à être restitué à une vitesse donnée et des références temporelles associées à des données du flux, ces références temporelles étant relatives au moment de restitution des données associées dans un référentiel temporel, ces références temporelles se suivant en séquence dans le flux, des changements de référentiel entraînant des ruptures de séquences, pouvant apparaître dans le flux, comportant au moins les moyens suivante : - un moyen de réception dudit flux de données numériques ; - un moyen d'envoi d'une commande contenant la position temporelle relative courante dans le programme contenu dans le flux, caractérisé en ce qu'il comporte en outre un moyen de détermination de cette position localement par le récepteur, les seules informations issues du flux intervenant dans la détermination de cette position étant les références temporelles associées à des données du flux.
8. Récepteur selon la revendication 7 comprenant en outre des moyens de mise à jour régulière de la valeur courante de la position temporelle relative courante.
9. Récepteur selon la revendication 8 où les moyens de mise à jour comprennent des moyens de détermination d'une valeur Delta correspondant à la différence entre une nouvelle référence temporelle reçue et la dernière référence temporelle mémorisée.
10. Récepteur selon la revendication 9 où les moyens de mise à jour comprennent en outre des moyens de comparaison de la valeur Delta et d'un seuil dépendant de la vitesse de restitution du flux, la présence d'une rupture de séquence étant déterminée par une valeur de Delta supérieure au seuil.
11. Récepteur selon la revendication 10 où les moyens de mise à jour comprennent en outre des moyens d'addition, dans le cas d'une absence de rupture de séquence, de la valeur de Delta à la valeur courante de la position temporelle maintenue.
12. Récepteur selon la revendication 10 où les moyens de mise à jour comprennent en outre des moyens d'addition, dans le cas d'une absence de rupture de séquence, de la valeur de Delta multipliée par la vitesse de restitution à la valeur courante de la position temporelle maintenue.
PCT/EP2006/060956 2005-03-25 2006-03-22 Procede d'envoi de commande a un serveur de flux de donnees numeriques et appareil implementant le procede WO2006100268A2 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
BRPI0608622-5A BRPI0608622A2 (pt) 2005-03-25 2006-03-22 mÉtodo para transmitir um comando para um servidor de fluxo de dados digitais e aparelho usado para implementar o dito mÉtodo
EP06725239.5A EP1862009B1 (fr) 2005-03-25 2006-03-22 Procede d'envoi de commande a un serveur de flux de donnees numeriques et appareil implementant le procede
CN2006800097458A CN101151901B (zh) 2005-03-25 2006-03-22 向数字数据流服务器发送命令的方法和用于实施该方法的装置
US11/886,819 US8677442B2 (en) 2005-03-25 2006-03-22 Method of sending a command to a digital data flow server and apparatus used to implement said method
JP2008502408A JP4719789B2 (ja) 2005-03-25 2006-03-22 デジタルデータフローサーバーへコマンドを送出する方法、及び当該方法を使用する装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0503011A FR2883692A1 (fr) 2005-03-25 2005-03-25 Procede d'envoi de commande a un serveur de flux de donnees numeriques et appareil implementant le procede
FR0503011 2005-03-25

Publications (2)

Publication Number Publication Date
WO2006100268A2 true WO2006100268A2 (fr) 2006-09-28
WO2006100268A3 WO2006100268A3 (fr) 2007-07-12

Family

ID=35482262

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/060956 WO2006100268A2 (fr) 2005-03-25 2006-03-22 Procede d'envoi de commande a un serveur de flux de donnees numeriques et appareil implementant le procede

Country Status (7)

Country Link
US (1) US8677442B2 (fr)
EP (1) EP1862009B1 (fr)
JP (1) JP4719789B2 (fr)
CN (1) CN101151901B (fr)
BR (1) BRPI0608622A2 (fr)
FR (1) FR2883692A1 (fr)
WO (1) WO2006100268A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009033454A (ja) * 2007-07-26 2009-02-12 Sony Corp コンテンツ再生装置、コンテンツ再生方法、およびプログラム
CN101287107B (zh) * 2008-05-29 2010-10-13 腾讯科技（深圳）有限公司 媒体文件的点播方法、系统和设备
US20110320629A1 (en) * 2008-12-29 2011-12-29 Zte Corporation Stream media server, client terminal and method and system for downloading stream media

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8265168B1 (en) * 2008-02-01 2012-09-11 Zenverge, Inc. Providing trick mode for video stream transmitted over network
US8018934B2 (en) * 2009-03-20 2011-09-13 Cisco Technology, Inc. Switched unicast in an internet protocol television environment
CN102648636B (zh) 2009-10-21 2016-08-17 爱立信(中国)通信有限公司 用于媒体位置控制的方法、设备和系统
US8357887B2 (en) * 2010-03-30 2013-01-22 Rich Ventures Llc Microwavable apparatus capable of keeping food moist
US7950845B1 (en) * 2010-06-03 2011-05-31 Omar Syed Time keeping system for turn-based games
KR101712102B1 (ko) * 2010-07-29 2017-03-14 삼성전자 주식회사 Ｒｔｓｐ 세션에 기초해 스트리밍 데이터를 송수신하는 방법 및 장치
WO2015052908A1 (fr) * 2013-10-11 2015-04-16 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ Procédé de transmission, procédé de réception, dispositif de transmission et dispositif de réception
US11064003B2 (en) * 2016-03-07 2021-07-13 Lg Electronics Inc. Method and apparatus for receiving streaming via transport protocol in wireless communication system
CN111836071B (zh) * 2020-07-16 2021-01-05 全时云商务服务股份有限公司 一种基于云会议的多媒体处理方法、装置及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003010970A2 (fr) * 2001-07-23 2003-02-06 Nds Limited Systeme permettant un acces selectif a un contenu
EP1439700A1 (fr) * 2003-01-16 2004-07-21 Deutsche Thomson-Brandt Gmbh Méthode d'affectation d'une référence temporelle absolue à un point d'entrée d'un flux de données

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6334219B1 (en) * 1994-09-26 2001-12-25 Adc Telecommunications Inc. Channel selection for a hybrid fiber coax network
EP0735776B1 (fr) * 1995-03-29 2004-01-28 Hitachi, Ltd. Décodeur pour des données vidéo et audio comprimées et multiplexées
US6215505B1 (en) * 1997-06-20 2001-04-10 Nippon Telegraph And Telephone Corporation Scheme for interactive video manipulation and display of moving object on background image
KR100247978B1 (ko) * 1997-08-08 2000-03-15 윤종용 픽쳐 디코딩 동기화 회로 및 그 방법
US6802074B1 (en) * 1999-05-31 2004-10-05 Matsushita Electric Industrial Co., Ltd. Recording apparatus, transmitting apparatus, and computer-readable recording medium
TW508945B (en) * 1999-10-15 2002-11-01 Matsushita Electric Ind Co Ltd Multichannel display data generating apparatus, medium, and informational set
US6681397B1 (en) * 2000-01-21 2004-01-20 Diva Systems Corp. Visual improvement of video stream transitions
JP2002209234A (ja) * 2001-01-11 2002-07-26 Fujitsu Ltd 通信システム
US20030066094A1 (en) * 2001-09-29 2003-04-03 Koninklijke Philips Electronics N.V. Robust method for recovering a program time base in MPEG-2 transport streams and achieving audio/video sychronization
CN1436001A (zh) * 2002-01-28 2003-08-13 北京华诺信息技术有限公司 解码系统中实现视频与音频同步的方法
US7610606B2 (en) * 2002-05-03 2009-10-27 Time Warner Cable, Inc. Technique for effectively providing various entertainment services through a communications network
US7530084B2 (en) * 2002-05-28 2009-05-05 Sony Corporation Method and apparatus for synchronizing dynamic graphics
AU2003275200A1 (en) * 2002-09-19 2004-04-08 Thomson Licensing S.A. Hybrid video on demand using mpeg 2 transport
JP2004120440A (ja) * 2002-09-26 2004-04-15 Toshiba Corp サーバー装置及びクライアント装置
US7953194B2 (en) * 2002-09-27 2011-05-31 Broadcom Corporation Handling video transition errors in video on demand streams
KR100482287B1 (ko) * 2002-10-26 2005-04-14 한국전자통신연구원 디지털 데이터 방송을 위한 동기화 스트림 데이터 삽입장치 및 그 방법
JP3943516B2 (ja) * 2003-03-27 2007-07-11 松下電器産業株式会社 画像再生装置
JP4315827B2 (ja) * 2004-01-29 2009-08-19 株式会社日立国際電気 画像表示方法及び画像表示装置並びに画像表示プログラム
US7657583B2 (en) * 2004-12-29 2010-02-02 International Business Machines Corporation Calculating recovery time of an application system
US7735111B2 (en) * 2005-04-29 2010-06-08 The Directv Group, Inc. Merging of multiple encoded audio-video streams into one program with source clock frequency locked and encoder clock synchronized
JP4282722B2 (ja) * 2007-01-31 2009-06-24 株式会社東芝 ストリーム記録装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003010970A2 (fr) * 2001-07-23 2003-02-06 Nds Limited Systeme permettant un acces selectif a un contenu
EP1439700A1 (fr) * 2003-01-16 2004-07-21 Deutsche Thomson-Brandt Gmbh Méthode d'affectation d'une référence temporelle absolue à un point d'entrée d'un flux de données

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"ISO/IEC IS 13818-6:1998, Extensions for DSM-CC" ISO/IEC, 1 septembre 1998 (1998-09-01), pages 137-139, XP002366278 *
"ISO/IEC IS 13818-6:1998, Extensions for DSM-CC" ISO/IEC, 1 septembre 1998 (1998-09-01), pages 280-281, XP002366279 *
"ISO/IEC JCT1/SC29/WG11/N5270: Corrected text of ITU-T Rec H.222.0Ÿ ISO/IEC 13818-1:2000/FDAM 1: carriage of metadata" ISO/IESC, janvier 2003 (2003-01), pages 1-23, XP002361915 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009033454A (ja) * 2007-07-26 2009-02-12 Sony Corp コンテンツ再生装置、コンテンツ再生方法、およびプログラム
CN101287107B (zh) * 2008-05-29 2010-10-13 腾讯科技（深圳）有限公司 媒体文件的点播方法、系统和设备
US20110320629A1 (en) * 2008-12-29 2011-12-29 Zte Corporation Stream media server, client terminal and method and system for downloading stream media

Also Published As

Publication number Publication date
CN101151901B (zh) 2011-01-12
JP2008535298A (ja) 2008-08-28
BRPI0608622A2 (pt) 2010-01-19
JP4719789B2 (ja) 2011-07-06
EP1862009A2 (fr) 2007-12-05
CN101151901A (zh) 2008-03-26
WO2006100268A3 (fr) 2007-07-12
FR2883692A1 (fr) 2006-09-29
US8677442B2 (en) 2014-03-18
EP1862009B1 (fr) 2017-11-22
US20090217328A1 (en) 2009-08-27

Similar Documents

Publication Publication Date Title
EP1862009B1 (fr) Procede d'envoi de commande a un serveur de flux de donnees numeriques et appareil implementant le procede
EP2057632B1 (fr) Procede de gestion d'un programme multimedia, serveur, terminaux, signal et programmes informatiques correspondants
EP3381196B1 (fr) Procédé de synchronisation d'un flux audio alternatif
FR2975555A1 (fr) Methode d'adaptation dynamique du debit de reception et recepteur associe
EP1483915B1 (fr) Procede de transmission de flux de donnees dependants
EP3652953B1 (fr) Procédé de signalisation d'une substitution à un terminal, procédé de substitution par un terminal, produits programme d'ordinateur, système et terminal correspondants
FR2827447A1 (fr) Procede de transmission de flux de donnees, flux de donnees, serveur, terminal, procede de reception et utilisation correspondants
FR3005386A1 (fr) Procede et dispositif de fourniture d’une partie deja diffusee d’un flux multimedia, terminal utilisateur, programme d’ordinateur et medium de stockage correspondants
WO2020259911A1 (fr) Procédé de gestion du téléchargement progressif adaptatif (has) d'un contenu numérique diffusé en temps réel, gestionnaire, terminal lecteur de flux multimédia et programme d'ordinateur correspondants
FR3054765B1 (fr) Procede pour la lecture sur un equipement d'un contenu multimedia avec un retard cible par rapport au direct inferieur a un retard maximal donne
WO2023208688A1 (fr) Gestion de la restitution d'un contenu multimédia
EP3926929B1 (fr) Procédé de gestion de la lecture d'un contenu numérique au sein d'un terminal lecteur de contenus multimédias connecté à un dispositif de restitution
FR2984669A1 (fr) Procede, dispositif et systeme de fourniture d'un flux video numerique a un equipement terminal
EP4184922A1 (fr) Procédé de gestion de l' accès à un contenu multimédia
EP4346216A1 (fr) Gestion de la lecture d'un contenu multimédia
FR3114719A1 (fr) Procédé de gestion de la lecture d’un contenu numérique au sein d’un terminal lecteur de contenus multimédias connecté à un dispositif de restitution
WO2020183080A1 (fr) Procédé de gestion du téléchargement d'images associées à des sauts d'images susceptibles d'être realisés lors d'une lecture accelerée d'un contenu multimedia diffusé en continu
FR3131160A1 (fr) Procédé de restitution d’un contenu multimédia, programme d’ordinateur et terminal lecteur de flux multimédia correspondants.
EP4109905A1 (fr) Gestion du téléchargement progressif adaptatif d'un contenu numérique en mode économiseur d'écran
WO2021105585A1 (fr) Procédé de gestion d'une liste de contenus accessibles au zapping, les contenus numériques étant téléchargeables en mode de téléchargement progressif adaptatif (has), dispositif de gestion, lecteur de flux multimédia et programme d'ordinateur correspondants
EP3973714A1 (fr) Restitution d'un contenu en arrière-plan ou sous forme d'incrustation dans le cadre d'un téléchargement progressif adaptatif de type has
EP4373099A1 (fr) Procédé de gestion de l'accès à une contenu a lecture d'un contenu multimédia
FR3135857A1 (fr) Gestion de la restitution d’un contenu multimédia sur plusieurs écrans.
EP3970386A1 (fr) Procédé de gestion de la réception de contenus numériques par un dispositif d'accès
WO2008043738A1 (fr) Procédé de retardement temporel de flux de contenus numériques, dispositif, et produit programme d'ordinateur correspondants

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 7016/DELNP/2007

Country of ref document: IN

REEP Request for entry into the european phase

Ref document number: 2006725239

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2006725239

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2008502408

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 200680009745.8

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Ref document number: DE

NENP Non-entry into the national phase

Ref country code: RU

WWW Wipo information: withdrawn in national office

Ref document number: RU

WWP Wipo information: published in national office

Ref document number: 2006725239

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11886819

Country of ref document: US

ENP Entry into the national phase

Ref document number: PI0608622

Country of ref document: BR

Kind code of ref document: A2