FR2898236A1 - Procede de transmission de flux audiovisuels en anticipant les commandes de l'utilisateurs, recepteur et emetteur pour la mise en oeuvre du procede - Google Patents

Procede de transmission de flux audiovisuels en anticipant les commandes de l'utilisateurs, recepteur et emetteur pour la mise en oeuvre du procede Download PDF

Info

Publication number
FR2898236A1
FR2898236A1 FR0650759A FR0650759A FR2898236A1 FR 2898236 A1 FR2898236 A1 FR 2898236A1 FR 0650759 A FR0650759 A FR 0650759A FR 0650759 A FR0650759 A FR 0650759A FR 2898236 A1 FR2898236 A1 FR 2898236A1
Authority
FR
France
Prior art keywords
stream
transmitting
user
request
server
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
FR0650759A
Other languages
English (en)
Inventor
Remi Houdaille
Willem Lubbers
Eric Gautier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thomson Licensing SAS
Original Assignee
Thomson Licensing SAS
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 SAS filed Critical Thomson Licensing SAS
Priority to FR0650759A priority Critical patent/FR2898236A1/fr
Priority to US11/709,010 priority patent/US20070206622A1/en
Priority to EP07102916A priority patent/EP1830540B1/fr
Priority to DE602007001988T priority patent/DE602007001988D1/de
Priority to CN2007100842090A priority patent/CN101031080B/zh
Priority to JP2007051482A priority patent/JP5627834B2/ja
Priority to KR1020070020884A priority patent/KR101372131B1/ko
Publication of FR2898236A1 publication Critical patent/FR2898236A1/fr
Priority to JP2013164958A priority patent/JP5744984B2/ja
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4383Accessing a communication channel
    • H04N21/4384Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/12Arrangements for remote connection or disconnection of substations or of equipment thereof
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2668Creating a channel for a dedicated end-user group, e.g. insertion of targeted commercials based on end-user profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44213Monitoring of end-user related data
    • H04N21/44222Analytics of user selections, e.g. selection of programs or purchase activity
    • H04N21/44224Monitoring of user activity on external systems, e.g. Internet browsing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/637Control signals issued by the client directed to the server or network components
    • H04N21/6377Control signals issued by the client directed to the server or network components directed to server
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • H04N21/6581Reference data, e.g. a movie identifier for ordering a movie or a product identifier in a home shopping application

Abstract

La présente invention concerne un procédé de transmission de flux audiovisuels entre au moins un appareil contrôlé par un utilisateur et un serveur. Les flux audiovisuels spécifiés par des demandes de l'utilisateur sont visualisés au niveau de l'appareil. L'utilisateur introduit une première commande de changement de flux à destination du serveur afin d'établir une communication pour la transmission du flux déterminé. Le serveur établit alors le flux déterminé et au moins un second flux avec une bande passante réduite. Ce second flux correspond à un flux immédiatement accessible par une seconde commande de l'utilisateur.L'invention concerne également un récepteur et un émetteur pour la mise en oeuvre du procédé.

Description

L'invention concerne un procédé de transmission de flux audiovisuels entre
un appareil contrôlé par un utilisateur et un serveur, un récepteur multimédia muni d'une interface utilisateur pour la mise en oeuvre du procédé et un émetteur transmettant les flux audiovisuels.
Dans un système de télévision numérique, le nombre de canaux disponibles devient très important. Plusieurs centaines de canaux peuvent être mis à disposition de l'utilisateur. Les utilisateurs peuvent sélectionner un canal à l'aide d'un Guide Electronique de Programme (EPG en abrégé), ou io encore, passer d'un canal à un autre en appuyant sur les touches Programme+ ou Programme ù de la télécommande associée à leur récepteur, cette façon de naviguer s'appelle communément le zapping . Dans le premier cas, l'EPG peut être constitué d'une mosaïque d'images montrant la vidéo des programmes diffusés sur un certain nombre de 15 canaux, typiquement 16 canaux. Ces images étant petites, les données audiovisuelles pour afficher chacune d'elles n'ont pas besoin d'une grande précision, de ce fait les flux qui transmettent les vidéos peuvent être en basse résolution. Un flux basse résolution ou flux réduit, est un flux ayant une bande passante très inférieure à un flux normal. Dans le cas du zapping, 20 le récepteur comporte une liste ordonnée de canaux. Généralement, le réseau de diffusion attribue aux canaux un numéro, et l'ordre suivi par le programme de navigation lorsque l'utilisateur saute sur le canal suivant ou précédent. L'utilisateur peut aussi élaborer une liste favorite en sélectionnant certains canaux parmi ceux offerts par le réseau, l'utilisateur navigue ensuite 25 dans sa liste en zappant d'une chaîne à l'autre. L'appareil de l'utilisateur est également pourvu d'une unité de réception de flux de données D en provenance d'un réseau de communication. La communication s'effectue soit en multidiffusion ou multicast en Anglais (littéralement point à multipoints ), soit en 30 diffusion individuelle unicast en Anglais (littéralement point à point ). Dans ce dernier cas, l'appareil dispose d'un moyen de communication bidirectionnelle, de préférence à haut débit, par exemple une ligne IP DSL (acronyme de Digital Subscriber Line ) pour recevoir les paquets de données audiovisuelles. L'appareil adresse une requête à un serveur du réseau pour recevoir une chaîne déterminée, dans le cas d'un diffusion multicast, un routeur reçoit les différentes requêtes et les traite.
Lors du zapping, les images des programmes diffusés par l'appareil apparaissent successivement à l'écran. Dans tous les cas, les temps de commutation dépendent notamment de : - des temps de transmission des commandes entre le client et le routeur du réseau io - des temps de mise en place des flux, - de la taille des buffers de gestion des paquets IP, pour absorber les variations dans l'arrivée de ceux-ci, - de la taille des buffers de traitement vidéo, - de la re-synchronisation du décodage nécessitant l'attente de la 15 prochaine image intra codée. De ce fait, lors des changements de chaînes, l'image sur l'écran se fige, et quelquefois un écran noir apparaît. Une solution consisterait à transmettre touts les chaînes, l'appareil n'effectuant qu'une simple commutation sans émettre de requête au serveur. Mais sur un accès de type 20 ADSL, la bande passante disponible ne permet pas de faire transiter en permanence plusieurs flux audiovisuels en parallèle, et les ressources de décodage sur l'appareil de réception ne permettent pas non plus en général de multiplier les décodages en parallèle. Cette solution n'est donc pas satisfaisante. 25 La présente invention apporte une solution nouvelle à ce problème de réduction du temps de commutation des chaînes au cours d'un zapping.
L'invention a pour objet un procédé de transmission de flux audiovisuels à partir d'un serveur vers un appareil chargé de les visualiser, 30 comportant une étape de réception d'une requête provenant d'un appareil pour la transmission d'un flux déterminé et une étape de transmission vers l'appareil du flux déterminé en pleine résolution en réponse à la réception de la requête. Le procédé comporte une seconde étape de transmission du serveur vers l'appareil, concomitamment à la première étape de transmission, d'au moins un second flux avec une bande passante réduite, ce second flux étant accessible par une première commande introduite au niveau de l'appareil lorsque le flux déterminé est en cours de visualisation.
De cette façon, l'invention permet d'exploiter la disponibilité d'un flux basse résolution sur la chaîne vers laquelle l'utilisateur peut prochainement sélectionner à l'aide d'une commande. L'appareil recevant le flux basse io résolution peut ainsi anticiper une prochaine commande de changement de canal. Selon un perfectionnement, le procédé comporte une étape d'introduction d'une seconde commande de l'utilisateur déclenchant une première étape d'affichage du canal transmis avec une bande passante 15 réduite, suivi d'une seconde étape d'affichage du canal déterminé en pleine résolution. De cette façon, l'utilisateur voit immédiatement l'image extrait du flux basse résolution lorsqu'il demande un changement de canal. Ensuite, lorsque le flux pleine résolution est correctement reçu, l'affichage bascule sur le flux pleine résolution. 20 Selon un autre perfectionnement, la première étape d'affichage comporte une étape d'animation de l'image extraite du canal avec une bande passante réduite. De cette façon, la transition entre le flux basse résolution et le flux pleine résolution est moins surprenante pour l'utilisateur. Selon un perfectionnement, l'étape d'animation se termine par l'affichage du canal 25 avec une bande passante réduite en plein écran, ce qui réduit encore la perception de la transition. Selon un autre perfectionnement, l'appareil émet vers le serveur une requête de réception du canal déterminé dans un flux pleine résolution et d'un autre canal immédiatement accessible par une seconde commande de 30 l'utilisateur. De cette manière, la façon de passer d'un canal à un autre est définie par l'appareil, et le serveur peut en être informé pour anticiper les nouvelles commandes de changement de canaux. Selon un autre perfectionnement, l'appareil peut afficher une image mosaïque composée des images transmises par l'ensemble des canaux transmis par le serveur qu'il soit de pleine résolution ou avec une bande passante réduite. L'utilisateur peut ainsi avoir un choix multiple de commande de zapping, et à chaque fois il peut voir immédiatement une image du nouveau canal sélectionné. Selon un perfectionnement, le canal avec une bande passante réduite est extrait d'un canal transmettant une image mosaïque. De cette manière, l'invention utilise un flux mosaïque existant pour en extraire les flux io avec une bande passante réduite. Selon un perfectionnement, l'appareil peut établir une liste favorite de canaux, l'autre canal étant immédiatement accessible par la seconde commande de l'utilisateur en naviguant dans ladite liste favorite. Ainsi, chaque appareil est personnalisé et le serveur concourt à l'anticipation des commandes de changement de canaux. Selon un 15 perfectionnement, l'appareil affiche un canal en pleine résolution et un identificateur de l'autre canal avec une bande passante réduite.
L'invention a également pour objet un émetteur comportant un moyen d'émission de flux audiovisuels sur un réseau, et un moyen de 20 réception d'une requête provenant d'un appareil pour la transmission d'un flux déterminé déclenchant l'activation du moyen d'émission pour émettre vers l'appareil le flux déterminé en pleine résolution. L'émetteur comporte un moyen d'émission vers le même appareil d'au moins un second flux avec une bande passante réduite, ledit moyen d'émission étant aussi activé par le 25 moyen de réception de la requête, le second flux étant accessible par une commande introduite au niveau de l'appareil lorsque le flux déterminé est en cours de visualisation. L'invention a également pour objet un récepteur comportant un moyen de réception de flux audiovisuels transmis par un réseau, un moyen 30 d'affichage d'un flux reçu et un moyen d'émission d'une requête pour la transmission d'un flux en pleine résolution sélectionné par l'utilisateur. Le récepteur comporte en outre un moyen de réception d'au moins un second flux avec une bande passante réduite, un moyen d'introduction d'une commande de changement de flux déclenchant l'émission d'une requête pour la transmission du nouveau flux et l'affichage du contenu du second flux reçu avec une bande passante réduite, l'affichage du nouveau flux s'effectuant ensuite lorsque la réception en pleine résolution est établi.
La présente invention apparaîtra maintenant avec plus de détails dans le cadre de la description qui suit d'exemples de réalisation donnés à titre illustratif en se référant aux figures annexées parmi lesquelles: io la figure 1 est un diagramme bloc d'un récepteur audiovisuel pour la mise en oeuvre de l'invention, la figure 2 est un schéma montrant les différents éléments d'un serveur selon l'invention, les figures 3.a, 3.b, 3.c et 3.d illustrent les différentes étapes de 15 dialogues entre le récepteur audiovisuel et le serveur; les figures 4.a, 4.b, et 4.c représentent des apparences d'écran pour la mise en oeuvre de l'invention.
On décrira tout d'abord à l'aide de la figure 1, le fonctionnement d'un 20 récepteur audiovisuel 1 connecté à un dispositif d'affichage 2. Le récepteur comprend une unité centrale 3 reliée à une mémoire 4 de programme (ROM) et de travail (RAM), et une interface 5 pour une communication bidirectionnelle avec un réseau 6. Selon un mode particulier de réalisation, l'appareil est un ordinateur doté d'un écran graphique. Le réseau est 25 typiquement Internet mais la présente invention concerne n'importe quel réseau permettant de recevoir des flux audiovisuels, le débit doit être suffisant mais relativement limitée pour que la possibilité de transmettre tous les flux en pleine résolution ne soit pas possible. Selon un exemple préféré de réalisation, le réseau utilise la technologie ADSL. Le récepteur comprend 30 en outre un récepteur de signaux infrarouge 7 pour recevoir les signaux d'une télécommande 8 et une logique de décodage audio/vidéo 10 pour la génération des signaux audiovisuels envoyés à l'écran de télévision 2. La télécommande 8 est dotée des touches de direction et des touches: P+, P- et OK dont nous verrons l'emploi plus loin dans la description. Le récepteur comprend également un circuit 11 d'affichage de données sur l'écran, appelé souvent circuit OSD, de l'anglais "On Screen Display" (signifiant littéralement "affichage sur l'écran"). Le circuit OSD 11 est un générateur de texte et de graphisme qui permet d'afficher à l'écran des menus, des pictogrammes (par exemple, un numéro correspondant à la chaîne visualisée), ou qui permet de mélanger deux contenus audiovisuels. Le circuit OSD est contrôlé par l'Unité Centrale 3 et un programme appelé io Zapper qui est résident dans la mémoire 4. Le Zapper est typiquement constitué d'un module de programme inscrit en mémoire morte et de paramètres enregistrés en mémoire de travail. Le Zapper peut aussi être réalisé sous la forme d'un circuit spécialisé de type ASIC par exemple. Ce circuit peut être doté de fonctions sécuritaires permettant de réaliser un 15 paiement suite à la décision d'un utilisateur de visualiser une émission payante. Le récepteur reçoit des données d'identification d'émissions audiovisuelles de la voie de retour 6 ou du réseau de diffusion. Ces données comprennent des éléments visualisables, le titre par exemple ou une image 20 de la bande annonce. A l'aide d'un EPG et des touches de sa télécommande, l'utilisateur sélectionne une ou plusieurs émissions en vue de les recevoir.
L'émetteur transmettant les flux est selon un mode préféré de 25 réalisation un serveur DSLAM 20 qui est décrit à la figure 2 comprend une unité centrale 2.1, une mémoire de programme 2.2, une logique d'encodage 2.3 et une interface de communication réalisant une pluralité de liaison bidirectionnelle 2.4 à travers le réseau 6 avec les récepteurs décrits précédemment. Le serveur DSLAM 20 reçoit d'un diffuseur l'ensemble des 30 chaînes et canaux du bouquet de programmes. A la demande d'un utilisateur, le DSLAM émet vers son récepteur le programme désiré dans un flux pleine résolution, appelée également définition standard ou SD. La tête du réseau produit un flux basse résolution et la transmet à la logique d'encodage 2.3 du DSLAM. Ce flux réduit est utilisable notamment pour un guide de programme. La tendance actuelle est de fournir dans l'interaction utilisateur une visualisation en vignette du programme qui est présenté (dans le cas du bandeau de zapping, c'est en parallèle à l'affichage de la vidéo plein écran). La transmission d'un flux en taille réduite (typiquement 1/16ème d'image, aussi appelé QCIF) peut être absorbée en supplément d'un flux dans la bande passante. Le décodage temps réel d'un flux pleine résolution io en parallèle avec un flux réduit est acceptable.
Après avoir décrit les différents éléments de l'invention, nous allons maintenant expliquer comment ceux-ci coopèrent. Les différents dialogues entre l'utilisateur et le serveur sont illustrés 15 par les différentes étapes illustrées par les quatre figures 3.a, 3.b, 3.c et 3.d. A l'étape 3.1 illustrée par la figure 3.a, l'utilisateur a introduit un numéro de canal sur sa télécommande, la demande a été transmise au DSLAM 20. Puis, la communication s'est établie et le contenu audiovisuel de la chaîne sélectionnée est transmis. A l'étape 3.2 illustrée par la figure 3.b, le 20 récepteur 1 lance l'exécution du Zappeur en tache de fond. Le zappeur identifie le canal 1 en cours de réception et en déduit les programmes immédiatement accessibles si l'utilisateur appuie sur la touche P+ ou P-de sa télécommande 8. Typiquement, l'ordre de zapping est défini par le diffuseur de programmes par les numéros des flux, on peut s'attendre donc à 25 ce que la prochaine commande de zapping sélectionne le canal 2. De cette façon, le serveur en recevant la requête de changement de canal déduit quel est le canal à flux réduit qu'il faut émettre. Une variante consiste en ce que l'utilisateur définit une liste favorite et navigue au sein de cette liste. Le zappeur transmet au DSLAM 20 une requête d'établissement du flux pleine 30 résolution demandée et des flux réduits des programmes suivants et/ou précédents celui demandé. Le récepteur 1 reçoit alors le flux F1 pleine résolution du canal sélectionné par l'utilisateur et au moins le flux réduits F'2 (éventuellement F'3, F'4, ....). L'affichage s'effectue en temps réel, dès que la synchronisation des données est réalisée. A l'étape 3.3 illustrée par la figure 3.c, l'utilisateur appuie sur la touche P+ de sa télécommande 8. Le zappeur transmet une demande au DSLAM pour recevoir le canal F2 qui suit le canal F1 en cours de diffusion. Dans le même temps, le zappeur commute l'extraction des données à afficher du flux F1, vers le flux réduit F'2, les données sont envoyées vers la logique de décodage audio/vidéo 10 pour la reproduction vidéo sur le moyen d'affichage 2 et l'émission de signaux audio. De cette façon, la commande de io zapping entraîne immédiatement l'apparition du programme désiré. Dans la mesure où le zappeur utilise un flux réduit, la reproduction sera de qualité médiocre mais suffisante pour que l'utilisateur suive l'action. Si le flux réduit est conçu pour afficher une petite image ou imagette , pour son intégration dans une image mosaïque par exemple, le zappeur réalise un 15 agrandissement de l'imagette et l'affiche en plein écran. Dès que le flux F2 est arrivé à une image permettant de l'accrocher, l'affichage bascule du flux réduit au flux pleine résolution. A l'étape 3.4 illustrée par la figure 3.d, le DSLAM transmet le programme désiré par un flux pleine résolution F2. Le récepteur extrait les 20 données du flux pleine résolution et les envoie à la logique de décodage audio/vidéo 10 pour la reproduction vidéo sur le moyen d'affichage 2 et l'émission de signaux audio. A partir de ce moment, l'utilisateur reçoit le canal désiré avec une qualité optimale de reproduction. Le standard DVB_IP préconise d'utiliser les signaux RTP et RTSP pour gérer la synchronisation 25 entre plusieurs flux. Le récepteur 1 utilise ces signaux pour assurer la synchronisation lors des transitions entre un flux réduit F'i et le flux pleine résolution Fi correspondant, et réciproquement. Ensuite, le zappeur transmet au DSLAM une requête d'établissement des flux réduits des nouveaux programmes qui ont la plus grande probabilité d'être sélectionné par 30 l'utilisateur lors d'un zapping. On remarque que le récepteur demande des flux que l'utilisateur ne demande pas, dans le but de se mettre en position telle que si l'utilisateur change de chaîne le flux réduit correspondant soit déjà connecté. Différentes heuristiques d'anticipation connues peuvent ici être utilisables.
Selon un perfectionnement, juste après la sélection d'une nouvelle chaîne par une commande de zapping, les références des flux suivants et précédents qui sont identifiées par le zappeur apparaissent dans un bandeau en bas de l'écran. Ce bandeau disparaît au bout de quelques secondes. De cette façon, l'utilisateur sait que ces chaînes sont immédiatement visualisables par une commande de zapping. io L'invention dans ce qui précède est décrite dans le contexte du zapping, lorsque l'utilisateur navigue de chaînes en chaînes en introduisant une commande. L'invention n'est pas limitée à ce contexte, d'autres événements peuvent déclencher des requêtes qui anticipent le comportement de l'utilisateur. Par exemple, lorsque le programme 15 actuellement diffusé mentionne d'autres programmes diffusés sur d'autres chaînes au même moment. Le récepteur 1 demande au DSLAM de lui transmettre les flux réduits de canaux diffusant ces programmes au cas où l'utilisateur en sélectionnerait un. Un autre événement est la prise en main de la télécommande par l'utilisateur, des capteurs de préhension sur la 20 télécommande 8 informe le récepteur que l'utilisateur a pris la télécommande afin probablement d'introduire une nouvelle commande. Le récepteur 1 anticipe la commande de zapping en demandant au DSLAM de lui transmettre les flux des programmes suivants et précédents celui en cours. Selon un mode simple de réalisation, le zappeur ne demande qu'un 25 seul flux réduit. Ce flux est celui correspondant au canal sélectionné par l'utilisateur par la même dernière commande de zapping. Si pour accéder au programme actuel, l'utilisateur a appuyé sur P+, alors c'est le flux réduit du canal suivant qui est demandé au DSLAM. Si pour accéder au programme actuel, l'utilisateur a appuyé sur P-, alors c'est le flux réduit du canal 30 précédent qui est demandé au DSLAM. Dans un mode plus consommateur en bande passante, le zappeur demande au serveur deux flux réduits correspondant aux deux chaînes accessibles soit par la commande P+, soit par la commande P-. Selon un autre mode de réalisation, le serveur émet un flux transportant une image mosaïque construite par agrégation de flux réduits au niveau du serveur. Le récepteur extrait de l'image mosaïque l'image de la chaîne demandée par la commande de zapping, cette image est agrandie et apparaît en plein écran suite à la commande de zapping. L'avantage de ce mode de réalisation est que le serveur diffuse constamment les flux mosaïques, il n'y a donc pas de nécessité de faire une requête spécifique au io serveur. Selon une variante de réalisation, le serveur ne diffuse pas de flux mosaïque, de sorte que c'est le zappeur qui demande à recevoir huit flux réduits, quatre flux correspondants aux canaux accessibles en appuyant une fois, deux fois, trois fois et quatre fois sur la touche P+ et quatre flux correspondants aux canaux accessibles en appuyant une fois, deux fois, 15 trois fois et quatre fois sur la touche P- . En appuyant sur la touche M comme Mosaïque , le zappeur fait apparaître les vidéos transmises par les huit flux réduits et le flux reçu en pleine résolution, préférentiellement l'image vidéo du flux reçu en pleine résolution étant au centre de la mosaïque de neuf images. De cette façon, l'apparition de l'image mosaïque 20 s'effectue en un temps très court puisque les flux sont déjà disponibles. L'image mosaïque peut comporter un autre nombre d'image que 9, par exemple 16 ou 25. Dans le mode mosaïque, en appuyant sur P+ ou P- , l'utilisateur change le canal reçu en pleine résolution. L'appareil envoie une requête au serveur en demandant de recevoir un nouveau canal en 25 mode réduit. Dans un premier temps, la mosaïque affiche huit images, puis la neuvième correspondant au nouveau canal en flux réduit. Cette apparition tardive permet à l'utilisateur de mieux distinguer les évolutions d'une image mosaïque à une autre, et notamment l'image du nouveau canal. Un flux réduit est un flux permettant d'afficher une image de plus 30 faible définition qu'une image normale. Le flux réduit peut avoir une forme de GOP court qui privilégie un zapping plus rapide que la séquence pleine résolution (le surcoût des images I sur cette taille d'image est moindre qu'en pleine résolution). Les figures 4.a, 4.b, et 4.c montrent l'évolution des images affichées avant et après une commande de zapping. La figure 4.a montre l'image extraite d'un flux plein définition. L'utilisateur active une commande pour passer à la chaîne suivante. Le zappeur extrait l'image du flux réduit et l'apparence d'écran de la figure 4.b apparaît alors. L'image affichée est de qualité médiocre. Au bout d'un certain temps, le récepteur établit le flux pleine résolution et affiche l'image représentée à la figure 4.c, celle-ci est de io qualité optimale. Comme on le voit sur les figures 4, juste après la commande de zapping, l'image issue du flux réduit est dégradée par rapport à l'image en pleine résolution. Des perfectionnements permettent de masquer temporairement cette dégradation aux yeux de l'utilisateur. En effet, la 15 transition visuelle entre le flux réduit et le flux pleine résolution est relativement sensible, ce qui peut surprendre l'utilisateur. Une première façon de faire consiste à afficher l'image dégradée en lui donnant un effet de zoom pour amener progressivement l'imagette de départ sur la totalité de la surface d'écran. Une telle animation prend un délai qui peut être 20 le même que le temps qu'il faut pour accrocher le flux pleine résolution. Visuellement, sur une image dont la taille varie on remarquera moins les problèmes de résolution. L'image étant petite au départ, le fait qu'elle soit extraite d'un flux réduit est ainsi en grande partie masqué. Une autre façon de faire consiste à créer une animation, l'image extraite du flux réduit 25 apparaît comme un volet tantôt à gauche, tantôt à droite. Une autre façon de faire consiste à présenter l'image extraite du flux réduit sur deux faces d'un cube en rotation et qui va grandissant. A la fin de la rotation, la face occupe tout l'écran et c'est à ce moment que la commutation sur le flux en pleine résolution s'opère. Une autre façon consiste à créer un fondu enchaîné ou 30 tout autre animation dont le but est de détourner l'attention de l'utilisateur de la qualité des premières images. Dans tous les cas, l'animation dure le temps d'établissement et d'affichage du flux pleine résolution. Avantageusement, ce temps correspond au temps le plus long mesuré lors d'une précédente commutation. Une autre façon pour masquer la transition aux yeux des utilisateurs consiste à mettre en place un filtrage. Typiquement, le récepteur fait une moyenne pondérée entre l'image agrandie issue du flux réduit et l'image en pleine résolution. La pondération varie de (100%, 0%) à (0%, 100%) dans un délai qui comprend au moins celui permettant d'établir le flux pleine résolution. Avantageusement, le temps de l'étape de filtrage dépasse nettement celui pour établir le flux, ce qui permet d'utiliser à la fin les io données pleine résolution et arriver ainsi à 100% d'image en plein définition. 25

Claims (11)

Revendications
1. Procédé de transmission de flux audiovisuels à partir d'un serveur vers un appareil chargé de les visualiser, comportant une étape de réception d'une requête provenant d'un appareil (1) pour la transmission d'un flux déterminé et une étape de transmission vers l'appareil (1) du flux déterminé en pleine résolution en réponse à la réception de la requête ; caractérisé en ce qu'il comporte une seconde étape de transmission du serveur vers l'appareil, concomitamment à la première étape de io transmission, d'au moins un second flux avec une bande passante réduite, ce second flux étant accessible par une première commande introduite au niveau de l'appareil (1) lorsque le flux déterminé est en cours de visualisation. 15
2. Procédé de transmission de flux audiovisuels selon la revendication 1 ; caractérisé en ce qu'il comporte une étape d'introduction d'une seconde commande déclenchant une première étape d'affichage du flux transmis avec une bande passante réduite, suivi d'une seconde étape d'affichage du flux déterminé en pleine résolution. 20
3. Procédé de transmission de flux audiovisuels selon la revendication 2 ; caractérisé en ce que la première étape d'affichage comporte une étape d'animation de l'image extraite du flux avec une bande passante réduite.
4. Procédé de transmission de flux audiovisuels selon la revendication 3 ; caractérisé en ce que l'étape d'animation se termine par l'affichage du flux avec une bande passante réduite en plein écran. 30
5. Procédé de transmission de flux audiovisuels selon l'une quelconque des revendications 1 à 4 ; caractérisé en ce qu'il comporte une étape d'émission par l'appareil vers le serveur d'une requête de réception du flux déterminé dans un flux pleine résolution et d'un second flux immédiatement accessible par une seconde commande de l'utilisateur.
6. Procédé de transmission de flux audiovisuels selon l'une quelconque des revendications 1 à 4 ; caractérisé en ce qu'il comporte une étape d'émission par l'appareil vers le serveur d'une requête de réception du flux déterminé dans un flux pleine résolution et d'une pluralité de second flux accessibles par une succession de secondes commandes de l'utilisateur, et une étape d'établissement au sein de l'appareil d'une image mosaïque io composée de l'ensemble des flux transmis par le serveur.
7. Procédé de transmission de flux audiovisuels selon l'une quelconque des revendications 1 à 5 ; caractérisé en ce que le flux avec une bande passante réduite est extrait d'un flux transmettant une image 15 mosaïque.
8. Procédé de transmission de flux audiovisuels selon l'une quelconque des revendications précédentes ; caractérisé en ce qu'il comporte une étape d'établissement d'une liste favorite de flux, l'un des 20 second flux étant immédiatement accessible par la seconde commande de l'utilisateur en naviguant dans ladite liste favorite.
9. Procédé de transmission de flux audiovisuels selon l'une quelconque des revendications précédentes ; caractérisé en ce qu'il 25 comporte au niveau de l'appareil (1) une étape d'affichage du flux en plein définition et d'un identificateur de second flux avec une bande passante réduite.
10. Emetteur (20) comportant un moyen d'émission (2.4) de flux 30 audiovisuels sur un réseau (6), et un moyen de réception (2.4) d'une requête provenant d'un appareil (1) pour la transmission d'un flux déterminé déclenchant l'activation du moyen d'émission pour émettre vers l'appareil (1) le flux déterminé en pleine résolution ; caractérisé en ce qu'il comporte un moyen d'émission (2.4) vers le même appareil (1) d'au moins un second flux avec une bande passante réduite, ledit moyen d'émission (2.4) étant aussi activé par le moyen de réception (2.4) de la requête, le second flux étant accessible par une commande introduite au niveau de l'appareil (1) lorsque le flux déterminé est en cours de visualisation. io
11. Récepteur (1) comportant un moyen de réception (5) de flux audiovisuels transmis par un réseau (6), un moyen d'affichage (10 ; 2) d'un flux reçu et un moyen d'émission (3, 4, 5) d'une requête pour la transmission d'un flux en pleine résolution sélectionné par l'utilisateur ; caractérisé en ce qu'il comporte un moyen de réception (3, 4, 5) d'au 15 moins un second flux avec une bande passante réduite, un moyen d'introduction (4, 7, 8) d'une commande de changement de flux déclenchant l'émission d'une requête pour la transmission du nouveau flux et l'affichage du contenu du second flux reçu avec une bande passante réduite, l'affichage du nouveau flux s'effectuant ensuite lorsque la réception en pleine résolution 20 est établi.
FR0650759A 2006-03-03 2006-03-03 Procede de transmission de flux audiovisuels en anticipant les commandes de l'utilisateurs, recepteur et emetteur pour la mise en oeuvre du procede Pending FR2898236A1 (fr)

Priority Applications (8)

Application Number Priority Date Filing Date Title
FR0650759A FR2898236A1 (fr) 2006-03-03 2006-03-03 Procede de transmission de flux audiovisuels en anticipant les commandes de l'utilisateurs, recepteur et emetteur pour la mise en oeuvre du procede
US11/709,010 US20070206622A1 (en) 2006-03-03 2007-02-20 Method of transmitting audiovisual streams ahead of the user commands, and receiver and transmitter for implementing the method
EP07102916A EP1830540B1 (fr) 2006-03-03 2007-02-22 Procédé de transmission de flux audiovisuels en anticipant les commandes de l'utilisateur, récepteur et émetteur pour la mise en oeuvre du procédé
DE602007001988T DE602007001988D1 (de) 2006-03-03 2007-02-22 Verfahren zum Senden von audiovisuellen Strömen vor den Benutzerbefehlen und Empfänger und Sender zum Ausführen des Verfahrens
CN2007100842090A CN101031080B (zh) 2006-03-03 2007-02-27 在用户命令之前发送视听流的方法以及接收机和发射机
JP2007051482A JP5627834B2 (ja) 2006-03-03 2007-03-01 視聴覚ストリームを送信する方法及び受信器
KR1020070020884A KR101372131B1 (ko) 2006-03-03 2007-03-02 유저 커맨드의 오디오비주얼 스트림 어헤드 송신 방법 및그 방법을 구현하기 위한 수신기 및 송신기
JP2013164958A JP5744984B2 (ja) 2006-03-03 2013-08-08 視聴覚ストリームの送信方法、受信方法、送信器及び受信器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0650759A FR2898236A1 (fr) 2006-03-03 2006-03-03 Procede de transmission de flux audiovisuels en anticipant les commandes de l'utilisateurs, recepteur et emetteur pour la mise en oeuvre du procede

Publications (1)

Publication Number Publication Date
FR2898236A1 true FR2898236A1 (fr) 2007-09-07

Family

ID=37173698

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0650759A Pending FR2898236A1 (fr) 2006-03-03 2006-03-03 Procede de transmission de flux audiovisuels en anticipant les commandes de l'utilisateurs, recepteur et emetteur pour la mise en oeuvre du procede

Country Status (7)

Country Link
US (1) US20070206622A1 (fr)
EP (1) EP1830540B1 (fr)
JP (2) JP5627834B2 (fr)
KR (1) KR101372131B1 (fr)
CN (1) CN101031080B (fr)
DE (1) DE602007001988D1 (fr)
FR (1) FR2898236A1 (fr)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7705859B2 (en) * 2003-12-03 2010-04-27 Sony Corporation Transitioning between two high resolution video sources
US9154844B2 (en) 2006-10-30 2015-10-06 Alcatel Lucent Method and apparatus for reducing delays due to channel changes
JP5003690B2 (ja) * 2007-01-19 2012-08-15 日本電気株式会社 映像音声ストリーム配信システム、配信方法、および配信用プログラム
JP5061619B2 (ja) * 2007-01-24 2012-10-31 日本電気株式会社 リソース確保方法、中継装置、配信システム、およびプログラム
EP2165529A2 (fr) * 2007-06-11 2010-03-24 Nxp B.V. Récepteur vidéo
CN101682753B (zh) * 2007-06-13 2013-05-22 汤姆森许可贸易公司 减小频道切换时间的系统和方法
US9699242B2 (en) 2007-12-07 2017-07-04 Dan Atsmon Multimedia file upload
GB2469235B (en) * 2008-01-31 2013-04-03 Ericsson Telefon Ab L M Method and apparatus for obtaining media over a communications network
JP2010028232A (ja) * 2008-07-15 2010-02-04 Sony Corp 通信制御装置および通信制御方法
CN102113323A (zh) * 2008-07-28 2011-06-29 汤姆森特许公司 使用辅助频道视频流的快速频道改变的方法和装置
JP4912366B2 (ja) * 2008-08-01 2012-04-11 株式会社コナミデジタルエンタテインメント 動画再生装置、サーバ装置、動画再生方法、サービス方法、ならびに、プログラム
EP2224728A1 (fr) * 2009-02-27 2010-09-01 France Telecom Procédé pour zapper d'une chaîne d'origine à une chaîne cible sur un écran d'affichage à l'aide d'un dispositif de réception télévisuel, et dispositif de réception associé
JP2012525076A (ja) 2009-04-24 2012-10-18 デルタ・ヴィディオ・インコーポレイテッド デジタルビデオ配信システムにおける即時マルチチャネルビデオコンテンツブラウジングのためのシステム、方法、およびコンピュータ可読媒体
EP2296366A1 (fr) * 2009-09-03 2011-03-16 Thomson Licensing, Inc. Procédés pour la transmission et la réception de services vidéo
US20110191813A1 (en) * 2010-02-04 2011-08-04 Mike Rozhavsky Use of picture-in-picture stream for internet protocol television fast channel change
JP5500649B2 (ja) * 2010-09-29 2014-05-21 Kddi株式会社 映像配信サーバ
KR101753448B1 (ko) * 2010-09-30 2017-07-03 톰슨 라이센싱 모자이크 채널을 제공하기 위한 방법 및 디바이스
GB2493498A (en) 2011-07-18 2013-02-13 Nds Ltd Fast channel change using an aggregated video service
CN102421014A (zh) * 2011-11-22 2012-04-18 中兴通讯股份有限公司 实现自定义马赛克业务的方法、终端及系统
US8958569B2 (en) * 2011-12-17 2015-02-17 Microsoft Technology Licensing, Llc Selective spatial audio communication
US9247283B1 (en) * 2014-10-27 2016-01-26 Cisco Technology, Inc. Mosaic presentation screen production
EP3425920A1 (fr) * 2017-07-06 2019-01-09 Vestel Elektronik Sanayi ve Ticaret A.S. Récepteur multimédia permettant d'éviter l'interruption de l'affichage d'images lors d'un changement de chaîne

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001074063A1 (fr) * 2000-03-29 2001-10-04 Digeo Broadband, Inc. Interface avec un contenu televisuel et internet pouvant etre personnalisee par l'utilisateur
US20030196211A1 (en) * 2002-04-10 2003-10-16 Peter Chan Systems, methods and apparatuses for simulated rapid tuning of digital video channels
WO2005112465A1 (fr) * 2004-05-03 2005-11-24 Thomson Research Funding Corporation Procede et dispositif permettant un changement rapide de voie pour un systeme dsl
US20060020995A1 (en) * 2004-07-20 2006-01-26 Comcast Cable Communications, Llc Fast channel change in digital media systems

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07107441A (ja) * 1993-09-30 1995-04-21 Toshiba Corp 映像信号送受信装置
JP3855282B2 (ja) * 1995-02-06 2006-12-06 ソニー株式会社 受信装置および受信方法
US6118498A (en) * 1997-09-26 2000-09-12 Sarnoff Corporation Channel scanning and channel change latency reduction in an ATSC television receiver
JP4040766B2 (ja) * 1998-09-28 2008-01-30 株式会社東芝 ディジタル放送受信端末装置
US7237251B1 (en) * 1999-03-02 2007-06-26 Bigband Networks, Inc. Method and apparatus for using delay time during switching events to display previously stored information elements
JP2001285736A (ja) * 2000-03-31 2001-10-12 Canon Inc テレビジョン放送受信装置、テレビジョン放送受信システム、テレビジョン放送受信方法、及び記憶媒体
JP2002262190A (ja) * 2001-03-02 2002-09-13 Sony Corp 情報処理装置および方法、記録媒体、並びにプログラム
JP2003087668A (ja) * 2001-09-13 2003-03-20 Mitsubishi Electric Corp デジタル放送受信方法およびデジタル放送受信装置
JP3932019B2 (ja) * 2001-11-02 2007-06-20 日本電信電話株式会社 番組選択方法、番組選択装置及び番組選択プログラム
JP4443833B2 (ja) * 2002-02-27 2010-03-31 パナソニック株式会社 情報再生方法、送信装置および受信装置
US8745689B2 (en) * 2002-07-01 2014-06-03 J. Carl Cooper Channel surfing compressed television sign method and television receiver
US7523482B2 (en) * 2002-08-13 2009-04-21 Microsoft Corporation Seamless digital channel changing
JP3935412B2 (ja) * 2002-09-09 2007-06-20 キヤノン株式会社 受信装置及び受信装置の制御方法、ストリームデータ配信システム
JP4612791B2 (ja) 2002-10-22 2011-01-12 キヤノン株式会社 受信装置及び受信方法
JP4408677B2 (ja) * 2002-11-29 2010-02-03 キヤノン株式会社 受信装置及び受信方法
US7227583B2 (en) * 2002-12-11 2007-06-05 Lg Electronics Inc. Digital TV method for switching channel automatically
JP2004266704A (ja) * 2003-03-04 2004-09-24 Funai Electric Co Ltd 放送受信装置
JP2004320660A (ja) * 2003-04-18 2004-11-11 Matsushita Electric Ind Co Ltd ストリーム受信装置
US20050091693A1 (en) * 2003-10-22 2005-04-28 Rochelle Communications, Inc. Dual mode set-top box that optimizes the delivery and user selection of audio or video programming over data networks
JP2005130087A (ja) * 2003-10-22 2005-05-19 Canon Inc マルチメディア情報機器
KR100690725B1 (ko) * 2004-09-08 2007-03-09 엘지전자 주식회사 위성방송수신기의 채널 전환 장치
US7477653B2 (en) * 2004-12-10 2009-01-13 Microsoft Corporation Accelerated channel change in rate-limited environments
US20060200842A1 (en) * 2005-03-01 2006-09-07 Microsoft Corporation Picture-in-picture (PIP) alerts
JP4609236B2 (ja) * 2005-08-23 2011-01-12 日本電信電話株式会社 映像配信システム及び受信ルータ
JP4534997B2 (ja) * 2006-02-13 2010-09-01 ソニー株式会社 送受信システム、受信装置、受信方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001074063A1 (fr) * 2000-03-29 2001-10-04 Digeo Broadband, Inc. Interface avec un contenu televisuel et internet pouvant etre personnalisee par l'utilisateur
US20030196211A1 (en) * 2002-04-10 2003-10-16 Peter Chan Systems, methods and apparatuses for simulated rapid tuning of digital video channels
WO2005112465A1 (fr) * 2004-05-03 2005-11-24 Thomson Research Funding Corporation Procede et dispositif permettant un changement rapide de voie pour un systeme dsl
US20060020995A1 (en) * 2004-07-20 2006-01-26 Comcast Cable Communications, Llc Fast channel change in digital media systems

Also Published As

Publication number Publication date
JP5744984B2 (ja) 2015-07-08
EP1830540A1 (fr) 2007-09-05
CN101031080A (zh) 2007-09-05
JP2007243947A (ja) 2007-09-20
KR101372131B1 (ko) 2014-03-07
CN101031080B (zh) 2012-12-12
JP2013243771A (ja) 2013-12-05
JP5627834B2 (ja) 2014-11-19
KR20070090812A (ko) 2007-09-06
EP1830540B1 (fr) 2009-08-19
DE602007001988D1 (de) 2009-10-01
US20070206622A1 (en) 2007-09-06

Similar Documents

Publication Publication Date Title
FR2898236A1 (fr) Procede de transmission de flux audiovisuels en anticipant les commandes de l'utilisateurs, recepteur et emetteur pour la mise en oeuvre du procede
US8869200B2 (en) Selection list of thumbnails
CA2269874C (fr) Procede et appareil pour masquer les temps d'attente dans un systeme interactif de diffusion d'informations
US9837126B2 (en) Providing enhanced content
EP1946484B1 (fr) Reception de contenus audiovisuels a destination de plusieurs appareils
FR2902568A1 (fr) Procede d'affichage d'une image mosaique au sein d'un recepteur pour la selection de programmes audiovisuels, recepteurs et serveurs associes
US20090276820A1 (en) Dynamic synchronization of multiple media streams
EP2487898A1 (fr) Procédé d'affichage d'une mosaïque vidéo personnalisée et réceptacle audiovisuel correspondant
EP2670156A1 (fr) Système de diffusion audio/vidéo interactive, son procédé de fonctionnement et dispositif d'utilisateur pour un fonctionnement dans le système de diffusion audio/vidéo interactive
EP4224868A2 (fr) Procédés de synchronisation, de génération d'un flux, programmes d ordinateur, media de stockage, dispositifs de restitution, d exécution et de génération correspondants
FR2834416A1 (fr) Procede de diffusion de services audiovisuels, central de diffusion et support d'enregistrement, procede de visualisation d'emissions audiovisuelles et dispositif associes
WO2016008913A1 (fr) Procede de changement de chaine et passerelle pour des flux tv numeriques
WO2013102745A1 (fr) Controle de services a la demande communiques en mode de diffusion
FR2812160A1 (fr) Decodeur avec fonction de creation d'images mosaiques de services de television
EP1605702A1 (fr) Procédé de commutation de programmes vidéo numériques et émetteur pour sa mise en oeuvre