Décodeur de flux DVB

La présente invention se rapporte à la télévision numérique DVB (pour « Digital Video BroadCasting »), que ce soit la télévision numérique terrestre définie par la norme DVB-T (pour « Terrestrial ») ou bien la télévision numérique mobile définie par la norme DVB-H ( pour « Handheld »). Par exemple, la norme DVB-H dans sa version V1.2.1 de Novembre 2005 est présentée dans le document ETSI-TR- 102377 disponible en ligne, sur le site INTERNET de l'ETSI. Les symboles et abréviations utilisées dans le présent texte, si ils ne sont pas explicites, sont définis dans cette norme. Dans le présent document, l'invention sera plus précisément présentée dans le contexte de la télévision numérique mobile DVB-H, mais l'invention peut être mise en œuvre dans un autre contexte, par exemple celui de la télévision numérique terrestre DVB-T.

Un service de télévision mobile a pour but de permettre la visualisation du contenu d'un canal vidéo sur un appareil autonome, portable comportant un écran, appelé ci-après lecteur. Le lecteur peut être un téléphone portable, un assistant personnel, une télévision, etc. Le service de télévision mobile a pour vocation de permettre la diffusion d'un contenu vidéo au cours du déplacement de l'utilisateur. Il s'agit de diffuser un signal vidéo avec un débit suffisant pour garantir une image de qualité satisfaisante sur un écran dont la dimension n'excède pas 7 pouces de diagonale selon l'une des contraintes actuelles de la norme DVB.

Eventuellement, le lecteur est muni d'une carte à puce d'identification, équivalent d'une carte au format SIM actuellement utilisée largement dans les téléphones GSM, de manière à pouvoir gérer l'accès au contenu vidéo par un lecteur et/ou un utilisateur identifié. La carte à puce permet au distributeur du contenu vidéo de contrôler les droits d'accès et d'autoriser éventuellement le décryptage du flux vidéo.

Le principe général de la DVB-H par rapport à la DVB-T est d'émettre des paquets de données périodiquement pendant un temps de transmission extrêmement court, alors que la DVB-T émet des données de manière essentiellement uniforme et continue. De la sorte, un lecteur portable, synchronisé avec l'émetteur et connaissant la période d'émission des paquets DVB-H, ne fonctionne que pendant un temps très court correspondant à la réception d'un paquet de données. Entre la réception de deux paquets successifs, le lecteur est éteint. Sa consommation électrique est ainsi réduite répondant ainsi au critère d'autonomie du lecteur. Rappelons que la norme DVB est un protocole de communication et se rapporte donc à la couche physique de la transmission de données. La couche de données, quant à elle, peut comprendre par exemple des données vidéo au format MPEG2 ou bien des datagrammes IP encapsulant à leur tour des informations vidéo pouvant être codées sous le format MPEG4. De plus, le lecteur doit pouvoir être déplacé d'une

cellule du réseau d'émission à une autre et la couche de données du protocole DVB-H comporte des données de correction d'erreurs de transmission pour obtenir une image vidéo de qualité, même dans des zones de faible couverture.

Au cours des études destinées à déterminer les modes possibles d'utilisation de la vidéo sur un terminal mobile, il a été constaté qu'un tel service serait essentiellement utilisé à domicile, c'est-à-dire non seulement sans déplacement d'une cellule du réseau à une autre, mais surtout en étant dans une enceinte plus ou moins hermétique aux ondes électromagnétiques de la couche physique du protocole DVB-H. En conséquence, pour que le signal effectivement reçu par le lecteur soit suffisamment puissant pour une communication correcte, il est actuellement envisagé d'augmenter la puissance des antennes émettrices du réseau, de manière à ce que la puissance du signal reçu soit suffisante malgré les pertes importantes lors de la traversée des murs des maisons d'habitation.

Ce besoin d'une puissance supplémentaire, qui existe également dans le cas de la télévision numérique terrestre DVB-T, pour assurer la pénétration des ondes dans les habitations, représente un coût additionnel de l'infrastructure d'émission qui n'est pas marginal. On estime que cela représente un coût additionnel de deux à quatre fois le coût d'une installation d'émission de puissance nominale, et ceci essentiellement à cause du nombre d'antennes à déployer pour atteindre effectivement la puissance requise sur tout le territoire couvert.

Il y a donc un besoin pour minimiser les coûts de déploiement d'une telle infrastructure permettant la diffusion de la télévision numérique DVB sur des lecteurs qu'ils soient portables (« Portable Media Device » - PMD) ou fixes, comme un poste de télévision. La présente invention concerne donc plus particulièrement un décodeur de flux audio/vidéo au format DVB ainsi que des procédés adaptés qui permet la gestion locale, notamment au sein d'une habitation individuelle, voire collective, ou au sein d'une commune de flux audio/vidéo entrants de diverses origines dont DVB vers des terminaux, notamment portables, d'utilisateurs. Les procédés et le décodeur sont mis en œuvre dans/sous forme d'un dispositif recevant des données audio/vidéo par liaison radio de type DVB ainsi que, de préférence, des données audio/vidéo ou d'autres types (images, textes, instructions, programmes informatiques...) en provenance de la toile (INTERNET) par liaison radio ou filaire. Ces données sont traitées dans le dispositif où elles sont décodées puis ré-encodées avec compression de données pour transmission radio locale (Wl-Fl ou BLUETOOTH de préférence) entre le dispositif et un terminal (ou plusieurs) d'un utilisateur (ou plusieurs terminaux d'un utilisateur ou de plusieurs utilisateurs) où les données ré-encodées reçues sont décompressées pour y être restituées visuellement et/ou sous forme de sons selon le cas. Le dispositif s'apparente donc à un transcodeur (appelé également dispositif transcodeur ou dispositif de

transcodage) qui gère la redistribution des flux audio/vidéo en local. En outre de la compression, le ré-encodage peut comporter un cryptage notamment dans le cas de données devant être protégées (par droits d'auteur par exemple) et que seul un terminal autorisé pourra décrypter. De préférence, la compression pour diffusion sur liaison radio locale se fait selon un procédé MPEG-4 AVC.

Du fait que la liaison radio (Wl-Fl, WI-MAX, BLUETOOTH) locale/finale entre le dispositif transcodeur et le/les terminaux présente un débit limité par rapport aux flux initiaux en amont du dispositif (notamment DVB), une sélection de flux (choix d'un canal vidéo/audio parmi ceux possibles arrivant sur le dispositif, notamment parmi les canaux DVB) ainsi qu'une gestion de la bande passante sur la liaison radio locale/finale des canaux de données vidéo/audio est mise en œuvre dans le dispositif transcodeur, notamment sous la forme d'une adaptation en temps réel ou quasi réel de la compression à la qualité de la liaison radio locale/finale entre le dispositif et le terminal. En outre, avant le ou au début d'une restitution sur un terminal (à la mise en marche du terminal ou lors d'un passage en mode de réception et affichage vidéo/audio sur le terminal) ou lorsque l'utilisateur change la résolution (nombre de données et/ou qualité) d'affichage sur son terminal (si cela lui est possible), la compression est adaptée à ladite résolution courante du terminal concerné. A noter que, dans une variante, en cas de dégradation de la qualité de la liaison, le dispositif peut imposer de sa propre initiative une réduction de la résolution à un terminal donné.

Outre ses capacités de diffusion vers le ou les terminaux du ou des utilisateurs, de données vidéo/audio (ou autres) DVB et/ou en provenance de la toile, le dispositif (et les procédés de l'invention) permet une remontée d'information en provenance de l'utilisateur vers la toile (notamment vers une plateforme de service dédiée ou tout autre site ad hoc) par l'intermédiaire du dispositif de transcodage. Cette provenance peut être directe, notamment par l'intermédiaire d'une télécommande actionnée par l'utilisateur et communiquant avec le dispositif transcodeur (la télécommande peut être un appareil dédié - télécommande classique ou perfectionnée- ou un téléphone -par l'intermédiaire de BLUETOOTH par exemple- ou un ordinateur personnel portable ou tout autre outil pouvant communiquer avec le dispositif transcodeur). Cette provenance peut être indirecte, notamment par prise d'informations sur ce que l'utilisateur est en train de voir et/ou d'écouter, d'informations sur sa position absolue ou relative (en pratique de son terminal, voire de sa télécommande ou autre), de capteurs propres au terminal... En effet, le contenu vidéo/audio DVB et/ou de la toile, est généralement associé à des informations sous le format -Electronic Programme Guide-, EPG (ou autre format pour celles en provenance de la toile : nom de fichier par exemple) concernant leur identité (source, titre par exemple) et ces informations peuvent être renvoyées sur la toile par le dispositif de transcodage. Il est ainsi possible de suivre les

choix actuels et passés d'un utilisateur et de lui proposer pour l'avenir des contenus divers audio/vidéo adaptés à ceux-ci.

L'invention consiste en un décodeur de flux audio/vidéo au format DVB, qui comporte : - des moyens de réception d'un flux de données primaire selon le protocole de communication DVB ayant des données de contenu correspondant à une pluralité de canaux ; des moyens d'extraction, de séparation et de traitement des données de contenu dudit flux primaire pour produire une pluralité d'ensembles de données, chaque ensemble de données correspondant à un canal dudit flux primaire; et, des moyens de réémission d'un ensemble parmi lesdits ensembles de données en tant que données de contenu d'un flux de données secondaire dans un protocole de radio communication secondaire locale vers un terminal d'un utilisateur pour restitution du flux, le protocole de communication secondaire constituant une contrainte sur le débit du flux de données secondaire par rapport à celui du flux primaire, ledit décodeur comportant des moyens de compression de l'ensemble de données réémis, lesdits moyens de compression étant adaptatifs en fonction d'au moins un critère de qualité de transmission de la radio communication secondaire locale.

Selon différents modes de réalisation présentant chacun ses avantages respectifs :

• au moins un critère de qualité de transmission de la radio communication secondaire locale sont choisis parmi : - temps de latence entre une demande de restitution et la restitution sur le terminal,

- débit de transmission sur la radio communication secondaire locale,

- taux de réémission radio du fait d'erreur de transmission sur la radio communication secondaire locale,

• lesdits moyens de compression sont adaptatifs en fonction d'au moins un critère de résolution de la restitution du flux du terminal utilisateur.

• le protocole de communication du flux secondaire est fondé sur un protocole de communication sans fil, de préférence WIFI ou BLUETOOTH.

• le protocole de communication du flux secondaire est fondé sur un protocole de communication filaire, de préférence du type Courants Porteurs en Ligne.

• il comporte des moyens de navigation intra-flux DVB permettant la sélection de l'ensemble de données effectivement réémis par lesdits moyens d'émission, parmi ladite pluralité d'ensembles de données.

• lesdits moyens de navigation comportent une partie déportée du boîtier du décodeur, de préférence sur une télécommande ou sur un lecteur apte à fonctionner avec ledit décodeur.

« les données de contenu dudit flux primaire étant cryptées, il comporte des moyens de décryptage des données du flux primaire, de sorte que le contenu dudit flux secondaire réémis est décrypté.

• lesdits moyens d'émission permettent la réémission d'un flux secondaire sécurisé.

• le protocole de communication secondaire constitue une contrainte sur le débit du flux de données secondaire par rapport à celui du flux primaire, ledit décodeur comportant alors des moyens de compression de l'ensemble de données réémis.

L'invention concerne également un procédé de décodage d'un flux de données DVB, comportant les étapes consistant à: capter un flux primaire de données au format DVB; - extraire, séparer et traiter les données de contenu dudit flux primaire de manière à produire une pluralité de flux individuels de données décodées correspondant chacun à l'un des canaux dudit flux primaire ; retransmettre un desdits flux individuels correspondant à un canal vidéo au moyen d'un protocole secondaire de communication locale.

Selon différents modes de réalisation présentant chacun ses avantages respectifs :

• ledit protocole secondaire est fondé sur une liaison de communication secondaire sans fil du type WIFI ou BLUETOOTH.

• les flux individuels étant cryptés, le procédé consiste en outre à décrypter lesdites données.

• ladite étape de décryptage est réalisée avant ladite étape de retransmission, et en ce que le procédé comporte une étape initiale d'établissement d'une liaison de communication secondaire sécurisée pour la retransmission dudit flux secondaire décrypté.

• il comporte une étape consistant à compresser lesdits flux individuels de données avant ladite étape de retransmission secondaire.

Avantageusement, l'invention porte donc sur un dispositif et un procédé permettant le découplage de la fonction de décodage du flux de données DVB et de la fonction d'affichage. Pour cela la totalité ou une partie des données vidéo décodées est réémise au moyen d'une liaison secondaire vers le lecteur affichant ce contenu vidéo. Parmi les avantages de la présente invention on peut mentionner que pour le

DVB-T, notamment à cause de problèmes d'intégration d'antennes en bande UHF et des pertes de pénétration dans les maisons ou appartements, la zone de réception pour un fonctionnement acceptable à l'intérieur des bâtiments est limitée. Dans le cas de la Télévision Numérique Terrestre, TNT française, l'organisme de régulation a privilégié un nombre maximum de chaînes par Multiplex en spécifiant une modulation sophistiquée (64 QAM 2/3) offrant le maximum de débit (-24 Mbit/s par MUX), en contrepartie d'une sensibilité de réception très faible. La couverture TNT annoncée concerne une réception fixe avec une antenne sur le toit à une hauteur de 10m. Dans le cas d'une utilisation de récepteurs TNT portables à l'intérieur de bâtiments, le rayon de couverture est limité à environ 15 % (avec une seule antenne) ou au mieux à 20% (avec deux antennes en mode diversité) du rayon de couverture annoncé La retransmission, conforme à l'invention, en Wl-Fl ou BLUETOOTH du signal audio/vidéo reçu en TNT au niveau d'une fenêtre permettrait d'éliminer les pertes occasionnées par les murs et cloisons et d'atteindre ainsi un rayon de couverture à l'intérieur des bâtiments plus important et plus proche du rayon de couverture fixe annoncé. On doit noter que ce problème est identique pour les transmissions DVB-H.

Les autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lumière de la description détaillée qui va suivre de modes de réalisation actuellement préférés. Cette description faite en référence aux figures annexées illustre l'invention mais n'a pas pour but de réduire ou de limiter celle-ci.

- La Figure 1 représente sous la forme d'un schéma blocs, l'architecture générale mise en œuvre selon l'invention,

- La Figure 2 représente sous la forme d'un schéma blocs, l'architecture générale de la mise en œuvre de l'invention dans le cas d'un dispositif transcodeur DVB-T WI-FI,

- La Figure 3 représente sous la forme d'un schéma blocs, l'architecture mise en œuvre de l'invention dans le cas d'un dispositif transcodeur DVB-H BLUETOOTH,

- La Figure 4 représente sous la forme d'un schéma blocs, l'architecture générale de la mise en œuvre de l'invention dans le cas d'un dispositif transcodeur DVB-T Wl-Fl pour diffusion vers un ordinateur (PC),

- La Figure 5 représente sous la forme d'un schéma blocs, une architecture équivalente à celle de la Figure 4 mais dans le cas où des flux/chaînes cryptées doivent également être diffusées vers un/des terminaux utilisateurs,

- La Figure 6 montre un diagramme par bloc de l'architecture détaillée d'un exemple de réalisation d'un dispositif transcodeur selon l'invention,

- La Figure 7 montre un diagramme de séquence de la phase de découverte des chaînes,

- La Figure 8 montre un diagramme de séquence d'une demande de connexion initiale,

- La Figure 9 montre un diagramme de séquence d'une demande de fin de connexion, - La Figure 10 montre un diagramme de séquence d'une demande de changement de chaîne, et

- la Figure 1 1 montre un diagramme de séquence du dialogue client-serveur. Ces figures sont pour la plupart des organigrammes constitués de schémas bloc dont la fonction est précisée à l'intérieur du cadre correspondant. L'exemple de mise en œuvre représenté Figure 1 , permet la réception dans un décodeur 1 d'un flux amont radio DVB par une antenne 3 et un canal audio/vidéo est redistribué par une connexion sans fil radio locale du type WIFI ou BLUETOOTH vers un lecteur 20. Le décodeur 1 distribue un flux de données secondaire dans une zone de couverture « éclairée » par le signal radio local d'environ 300 mètres autour du décodeur dans le cas du Wl-Fl. Le décodeur est de préférence raccordé au secteur par un câble d'alimentation 2. Une télécommande 30 permet de piloter à distance le décodeur 1. Les autres éléments mis en œuvre seront décrits plus en détail par la suite.

En pratique, le dispositif transcodeur peut se présenter sous forme d'un boîtier dédié ou être intégré à un appareil de diffusion audio/vidéo comme par exemple un décodeur TNT, un démodulateur satellite, un téléviseur ou un vidéo projecteur. Dans une variante, il se présente sous forme d'une carte informatique à insérer dans un ordinateur ou un boîtier (« dongle ») à raccorder à une entrée d'un ordinateur personnel.

Dans un mode de réalisation particulier, le dispositif transcodeur se présente sous la forme d'un récepteur DVB-T Wl-Fl qui se met le long d'une fenêtre d'une maison pour réception DVB et redistribue des flux audio/vidéo par liaison WIFI dans la maison sur tous types de terminaux à écran. L'enjeu technique est la capacité a filtrer au sein d'un signal broadcast multiplexe à 24 Mbit/s, réception DVB par exemple, un flux de programme unique de 2 Mbit/s, le Wl-Fl, et en adaptant automatiquement le débit de ce flux à l'écran de visualisation du terminal choisi à l'aide d'un réencodage robuste et efficace.

Un schéma fonctionnel d'un tel récepteur est donné sur la Figure 2. SVC signifie «Scalable Video Coding » pour codage vidéo variable et zapping symbolise la possibilité de télécommande en retour entre le terminal (ou une télécommande) et le récepteur.

Le/les cryptage et/ou décryptage représentés dans le dispositif de transcodage sont optionnels, notamment le décryptage peut être omis dans le cas d'une diffusion d'une ou/de chaînes en clair. P pour les chaînes cryptées, le décryptage s'effectue dans le terminal utilisateur, notamment la transmission finale (liaison Wl-Fl locale en l'espèce sur la Figure 2) peut s'effectue avec ou sans cryptage propre.

Dans un autre mode de réalisation, le dispositif transcodeur se présente sous la forme d'un récepteur DVB-H BLUETOOTH autonome, disposant d'un mécanisme d'authentification, par exemple une carte sim, qui reçoit des flux à 7,37 Mbit/s, les décompose en canaux de 384 Kbit/s et renvoie un canal vers un terminal BLUETOOTH à capacité d'affichage pour restitution audio et/ou vidéo. Ce terminal peut être un téléphone portable bluetooth équipé d'un logiciel de restitution ("player") adapté. Ce logiciel de restitution peut incorporer une télécommande logicielle intégré. Un schéma fonctionnel d'un tel récepteur est donné sur la Figure 3. Le/les cryptage et/ou décryptage représentés dans le dispositif de transcodage sont optionnels, notamment le décryptage peut être omis dans le cas de diffusion d'une/de chaînes en clair (ou pour une/des chaînes cryptées, le décryptage s'effectuant dans le terminal utilisateur), notamment la transmission finale (liaison BLUETOOTH locale en l'espèce sur cette Figure 3 peut s'effectuer avec ou sans cryptage propre.

Dans un autre mode de réalisation particulier représenté sur la Figure 4, le dispositif transcodeur se présente sous la forme d'un récepteur DVB-T Wl-Fl pour la diffusion de chaines TNT en clair SD retransmise par diffusion Wl-Fl sur un ordinateur personnel (PC). Ce dispositif de transcodage comporte un récepteur (tuner) démodulateur DVB-T et est compatible avec notamment les formats de données suivants : DVB-T ; MPEG-2 SD(vidéo) ; MPEG-1 Layer 2 stéréo, AC3, MPEG-2 AAC, MPEG-4 HE AAC, Enhanced AC3, AC3 (audio) ; Ceefax et DVB-Sub (sous-titres) ; ElTp/factual&other, EITs (données programme).

Le dispositif transcodeur est capable d'effectuer un balayage complet de la bande UHF pour rechercher les chaînes, de les ordonnancer selon les tables de signalisation, et de mémoriser ces informations techniques. Le Tuner/démodulateur peut recevoir des commandes pour se caler sur une fréquence et une chaîne particulière.

Dans le cas d'un tuner/démodulateur DVB-H, la compatibilité est notamment possible les formats de données suivants : DVB-H ; H264 QVGA (vidéo) ; HE-AAC V2 (audio), DVB-IPDC (Guide Electronique des Services).

La Figure 5, extension fonctionnelle du dispositif transcodeur de la Figure 4, présente un dispositif permettant la diffusion de chaînes cryptées. Il comporte une fonctionnalité de décryptage de flux DVB puis de cryptage pour le flux de la liaison radio locale, le terminal comportant un moyen de décryptage adapté.

Le nombre de tuners/démodulateurs en entrée peut être quelconque (1 , 2, 3, 4 ou plus). Le dispositif transcodeur est capable de transmettre par Wl-Fl un nombre de flux TV qui est égal au nombre de tuners/décodeurs. Les fonctionnalités de transcodage audio/vidéo du dispositif transcodeur doivent donc être modulaires pour s'adapter à un nombre quelconque de tuners/démodulateurs. Cette fonctionnalité est mise en œuvre sous forme d'une puce de transcodage, et doit permettre de gérer un au moins flux TV en entrée et de le transcoder. Dans le cas où la puce ne peut gérer qu'un seul flux (une seule chaîne) on mettra en œuvre autant de puce que de tuners/démodulateurs. Dans une modalité particulière, un dispositif de transcodage de ce type peut comporter 3 tuners/démodulateurs et 3 puces de transcodage, en plus d'un disque dur intégré. Il est alors possible de visualiser sur une télévision (TV) par exemple ou sur un écran déporté (téléphone portable, TV de poche) le flux (la chaîne) du premier tuner, de consulter sur une autre TV ou un autre écran déporté le flux du deuxième tuner et d'enregistrer sur le disque dur du dispositif de transcodage le flux (la chaîne) du troisième tuner dédié. Le transcodage dans le dispositif de transcodage s'effectue selon un procédé de compression variable en fonction de la qualité de la liaison finale, Wl-Fl en l'espèce. Ainsi, la puce permet de transcoder n'importe quel flux vidéo provenant du Tuner/démodulateur vers un format MPEG-4 AVC dans cet exemple. De même pour le signal, la puce est capable de transcoder n'importe quel flux audio entrant, vers un flux audio mp3 ou AAC à un débit réduit. De même pour les sous-titres (ou autres données accessoires à l'audio ou vidéo), la puce est capable de transcoder n'importe quel flux de sous-titre vers un flux de sous-titre compatible avec le terminal utilisateur recevant le signal radio local Wl-Fl en l'espèce (streaming text 3GPP par exemple).

Le terminal utilisateur est ici un PC avec un logiciel de restitution (« Player ») dédié installé. Le PC peut permettre de consulter la liste des chaînes disponibles et assurer la

télécommande (notamment « zapping » sur une chaîne désirée) via un navigateur web ou un lecteur vidéo (type VLC).

Le PC peut restituer les flux vidéo/audio/sous-titre, sélectionner la piste audio et sous-titre à restituer. Si le PC n'est pas adapté pour restituer une piste audio (AC3 par exemple), il doit être configuré pour sélectionner un flux audio MPEG-2 de même langue.

On comprend que le dispositif de transcodage dispose à priori (saisie ou programmation préalable) ou reconnaît (reconnaissance automatique) les capacités de décodage de chaque terminal utilisateur afin que le dispositif puisse fournir un flux vidéo/audio compatible, et de qualité maximale (notamment en terme de capacité d'affichage), selon les capacités de chaque terminal utilisateur. Le dispositif de transcodage détermine en temps réel les capacités du canal de transmission et envoi un flux vidéo/audio de qualité maximale selon le débit effectivement disponible, et compatible avec les capacités de chaque terminal utilisateur. En particulier, si l'utilisateur se déplace avec son terminal dans le bâtiment, le dispositif transcodeur doit adapter la qualité du flux TV sur la liaison radio locale au débit disponible à tout moment. Par exemple, les critères de qualité minimaux, selon chaque terminal utilisateur, sont : 12 trames par seconde minimum sur téléphone mobile, en définition QVGA minimum et 25 trames par seconde en rendu sur PC (avec éventuellement interpolation temporelle si elle est non perceptible), en définition VGA minimum. Pour un terminal de type TV fixe, le nombre minimal de trames par seconde peut être plus élevé.

Dans une modalité de fonctionnement particulière, le dispositif de transcodage, pour conserver la qualité d'image maximale, peut ne pas effectuer de compression de flux lorsque cela n'est pas indispensable (transmission par Ethernet par exemple, transmission par Wi-Fi vers un deuxième décodeur TV, etc.), cela seulement si le terminal s'annonce comme étant fixe pour éviter des interruptions de service lors de l'activation de la compression.

La mise en œuvre d'une liaison locale radio de type Wl-Fl ou BLUETOOTH permet une application type « Plug and Play » pour les terminaux des utilisateurs. Dans ce cas, l'utilisateur n'a à effectuer aucun réglage, hormis l'installation d'une application sur son terminal.

D'une manière générale, le terminal utilisateur peut être tout appareil capable de traiter/gérer (par exemple magnétoscope ou enregistreur numérique) et/ou de restituer (par exemple TV) au moins un flux audio/vidéo comme, à titre d'exemple, un PC, être un Mac, un PMP, un assistant personnel (PDA), un téléphone Wl-Fl. L'accès peut se faire sur la majorité des téléphones Wl-Fl du marché (Symbian, iPhone, Windows Mobile, Android).

On comprend que certaines des fonctionnalités à mettre en oeuvre dans l'invention peuvent être réalisées sous forme purement logicielle (programme informatique) ou purement matérielle (logique câblée) ou, encore mixte. On comprend également qu'un compromis entre ces forme est effectué à la fois notamment en terme de côut, souplesse (possibilité d'évolution et/ou adaptation, notamment par téléchargement de logiciel) et de capacité (temps de réponse, qualité de la diffusion locale, nombre de terminaux pouvant être connectés).

Grâce aux fonctionnalités mises en oeuvre dans le dispositif de transcodage, les utilisateurs peuvent bénéficier de certaines facilités dont au moins: pour la première:

• Un abonné regarde la TV sur son terminal principal, dans le salon.

• Un autre abonné du foyer regarde la TV sur un terminal secondaire, dans une chambre.

• le dispositif transcodeur adapte le flux TV Live aux capacités de la liaison radio locale et du terminal. pour la deuxième :

• Un abonné regarde la TV sur son terminal principal, dans le salon.

• Un autre abonné du foyer regarde la TV sur un terminal secondaire.

• Ce deuxième abonné se déplace dans la maison ou le jardin avec son terminal secondaire

• le dispositif transcodeur adapte le flux TV Live au débit immédiat disponible de la liaison radio locale, en temps réel. pour la troisième :

• Un abonné regarde la TV sur son terminal principal, dans le salon. - Un autre abonné du foyer regarde la TV sur un terminal secondaire.

• Ce deuxième abonné sélectionne sur le terminal secondaire un autre flux TV à jouer.

• le dispositif transcodeur permet la sélection de flux, de manière transparente pour l'abonné. pour la quatrième :

• Un abonné regarde la TV sur un terminal secondaire.

• Un autre abonné du foyer regarde la TV sur un autre terminal secondaire, indépendamment du premier terminal secondaire. (Selon le nombre de tuner intégré, il peut être possible d'utiliser plus de terminaux secondaires.) - le dispositif transcodeur permet la sélection de flux, de manière transparente pour l'abonné. - pour la cinquième :

• Un abonné regarde la TV sur son terminal principal, dans le salon.

• Un autre abonné du foyer, mais en déplacement dans un autre pays, se connecte au terminal principal à l'aide d'un terminal secondaire, et peut accéder aux flux TV, comme s'il était dans le foyer.

• le dispositif transcodeur permet le « place shifting ». La figure 6 montre un diagramme par bloc de l'architecture détaillée d'un dispositif transcodeur selon l'invention.

L'architecture du client sera détaillée par la suite. Dans ce diagramme et dans la suite, le terme 'module' désigne un composant logiciel, matériel ou mixte qui réalise un ensemble de fonctions élémentaires cohérentes. Les regroupements de fonctions effectués pour définir les modules sont indicatifs et destinés à faciliter les explications. Ces modules peuvent être dupliqués, tripliqués ou plus en fonction des besoins, ce sont les suivants :

I ) Un module Tuner/Démodulateur -Digital Video Broadcasting-DVB 31 -1 , 31 -2 a pour objet de scanner la bande de fréquences, de trouver les fréquences qui transmettent des données, de transmettre les données au démultiplexeur pour l'analyse des tables du -System Information- SI (la table -Programm Association Table-PAT, la table -Programm Map Table-PMT, la table -Network Information Table- NIT, la table -Bouquet Information Table- BAT, la table -Service Description Table- SDT ...) puis de se caller sur une fréquence donnée et transmettre le flux -Transport Stream-TS au démultiplexeur pour lecture. Ce module permet de demander l'arrêt de la transmission du flux TS au démultiplexeur.

2) Un module de démultiplexage 32-1 , 32-2 permet d'analyser un flux TS et de stocker et/ou de mettre à jour le plan de service. Entre autre, la liste des chaînes, leur ordre, l'association d'une chaîneou d'une fréquence à un numéro de programme, ...)

Ce module effectue également l'extraction des flux (Audio/Vidéo/sous-titre) correspondant à une chaîne, et la transmission des flux (au format TS ou -Packetized Elementary Stream- PES) aux modules de transcodage Audio, Vidéo ou sous-titre et remonte le nom de la chaîne, le choix de la langue audio, le choix des sous-titres.

II effectue également l'extraction des sections -Event Information Table-EIT, TDT/TOT du TS et transmission au module de génération des données EPG

3) Le module d'encapsulation RTP 33 permet d'encapsuler selon le protocole rtp, les données issues des transcodeurs.

Il est également possible de configurer l'encapsulation en identifiant en entrée, le flux à paramétrer et les paramètres à utiliser (taille des paquets, mode d'encapsulation, configuration du décodeur).

Ce module permet la génération d'un fichier SDP (Session Description Protocol) pour chaque session rtp ouverte. Ce fichier est transmis aux terminaux utilisateurs grâce au module de gestion des requêtes clients

4) Le module de Transcodage Vidéo 34 permet le transcodage des données issues du démultiplexage et la transmission au module d'encapsulation rtp. Ce module est en liaison avec le module de paramétrage 45 qui peut modifier les paramètres de transcodage en temps réel.

5) Le module de Transcodage Audio 35 permet le transcodage des données issues du démultiplexage et la transmission au module d'encapsulation rtp. Ce module est en liaison avec le module de paramétrage qui peut modifier les paramètres de transcodage en temps réel.

6) Le module de Transcodage de sous-titre 36 permet la sélection des sous- titres ayant la bonne langue (celle choisie par l'utilisateur) et assure la transmission au module d'encapsulation rtp.

7) Le module de décodage de données -Electronic Programm Guide- EPG 37-1 , 37-2 a pour fonction de décoder les données -Event Information Table-EIT,-Time

Offset Table-TOT et Time Division Table-TDT.

8) Le module de monitoring réseau et de paramétrage 38 a pour but de modifier les paramètres des modules de transcodages audio et vidéo en fonction: 1 - du type d'équipement utilisateur

2- du paramétrages de l'utilisateur

3- de la qualité du lien sans-fil

Les paramètres pouvant ainsi être modifiés sont d'une part au niveau du transcodeur vidéo le niveau du signal sur bruit vidéo, le nombre d'images par seconde et la résolution des images (taille de l'écran au niveau des terminaux de réception), d'autre part au niveau du transcodeur audio le taux d'encodage.

Plus précisément les éléments en fonction desquels ces paramètres sont modifiés, sont en ce qui concerne :

1 - Le type de terminal utilisateur (au niveau de la réception, o la résolution de l'écran

o les formats audios supportés (par exemple si le format AAC+ n'est pas supporté, alors le transcodeur audio effectuera du transcodage au format mp3 par exemple). o les paramètres signal sur bruit et nombre d'images par seconde afin de rendre le débit nominal du flux compatible avec le type de connexion sans fil disponible sur tel ou tel terminal utilisateur (si un équipement possède une connexion WIFI 802.1 1 n alors il acceptera des débits nominaux supérieurs à un équipement qui possède une connexion WIFI 802.1 1 b).

Pour cela, le module de paramétrage accède à une base de données qui caractérise les différents terminaux se connectant au service (cette base est mise à jour régulièrement pour supporter les nouveaux terminaux sans-fils). La description du terminal utilisateur est automatiquement récupérée à la 1 ère connexion au niveau du module de gestion des requêtes clients.

2- La possibilité offerte à l'utilisateur de paramétrer par exemple la qualité minimum en termes de signal sur bruit, le nombre d'images par seconde et résolution minimale.

Ce type de paramétrage commande la qualité minimum en dessous de laquelle le service sera interrompu pour l'utilisateur.

Un profil utilisateur enregisté dans une base de données 46 agit sur le module de transcodage des sous-titres paramétrant la langue sélectionnée afin de filtrer les sous-titres dans la langue adaptée au choix de l'utilisateur.

3- le module de monitoring réseau qui analyse les temps d'aller-retour sur le réseau et le débit utilisé par le flux sur chaque lien sans-fil.

Cette mesure de débit réel prend en compte les retransmissions associées à un canal sans-fil bruité. L'indicateur pertinent est le débit réel divisé par le débit nominal. C'est une valeur supérieure à 1. Lorsque le canal est parfait et n'est pas bruité (ce qui correspond à une distance émetteur / récepteur de quelques mètres), l'indicateur de qualité du lien est égal à 1. Lorsque on augmente cette distance jusqu'à la limite de portée du canal sans-fil, l'indicateur peut augmenter de plusieurs multiples.

II existe une table prenant en entrée les indicateurs de qualité de chaque lien ainsi que le débit total et en fournit en sortie des paramètres de transcodage audio et vidéo.

Par exemple si <X1 > est l'indicateur du flux 1 et <X2> celui du flux 2 et ( X1 + X2) / débit max disponible est le ratio entre le débit réel utilisé par les 2 flux 1 et 2 par

rapport au total disponible, alors en fonction de seuils sur ces 3 valeurs, on associe les paramètres de transcodages.

Le 3ème paramètre est important car il permet de gérer la coexistence entre plusieurs flux en parallèle et éviter qu'un flux vers un terminal en limite de zone, n'occupe la totalité des ressources au détriment d'un autre terminal proche.

9) Le module de gestion des requêtes client 39 est un serveur http qui réceptionne les requêtes utilisateur et transfert au module de pilotage. Il permet également la récupération du type d'équipement utilisateur et donne au module de paramétrage les informations nécessaires permettant

10) Le module de pilotage 40 initialise dans l'ordre, les modules suivant :

1. • Le module d'encapsulation RTP, Gestion des requêtes client

2. • Le module de transcodage (A/V/ST/EPG) 3. • Le module de paramétrage, Module de démultiplexage

4. • le module de monitoring réseau,

5. • Le module Démodulateur

Ce module de pilotage assure la détermination des chaînes/flux DVB disponibles (appel au démodulateur pour scanner la bande qui appellera le démultiplexeur pour analyser les flux) et également les flux disponibles depuis la plateforme de service en effectuant des requêtes vers la plateforme de service (format : Web Service. Requêtes http et réponses XML)

II permet de traiter une demande de connexion initiale (en provenance de l'utilisateur via le module de gestion des requêtes clients: détermination des paramètres nécessaires au démodulateur et demande de changement de fréquence détermination des paramètres et demande de changement de PID au démultiplexeur demande de mise à jour des paramètres d'encodage et d'encapsulation à partir des informations reçues dans la requête HTTP (profil utilisateur) et des paramètres réseau

Récupération de la description SDP (Session Description Protocol) • Pour les flux vidéo issues de serveurs de diffusion sur Internet, le module de pilotage récupère de la plateforme de service les urls de streaming de ces flux et envoie ces urls aux modules de décodage (si l'affichage se fait sur le terminal Principal) ou de transcodage (si l'affichage se fait sur les terminaux utilisateurs secondaires)

Ce module permet aussi de traiter les demandes de changement de chaîne : détermination des paramètres nécessaires au démodulateur et demande de changement de fréquence détermination des paramètres et demande de changement de PID au démultiplexeur changement d'url de streaming dans le cas d'un flux diffusé par un serveur sur Internet

Ce module traite aussi de la mise en pause et de la fin d'un flux

1 1 ) Le module de génération de I' -Electronic Program Guide- 41 EPG agrégé récupère les données en provenance des flux DVB-T et DVB-H (en passant à travers des modules de décodage des EPG DBV-T et DVB-H)

Le format EPG est différent entre le flux DVB-T et DVB-H même si le même type d'information est fourni.

Ci-dessous est décrit l'ensemble des données EPG DVB-T tel que décrit dans la norme DVB :

PlD Abbr Nom Description

0x001 1 SDT Serv ⁱ ce Descr ⁱ pt ⁱ on _Déc ht les services du système

0 0012 EIT Event Information Décrit les événements des services, par exemple, nom de Table l'événement, heure de départ, durée etc.

0x0014 TDT _j ^ ^Definitl0n Fournit l'information sur la date et l'heure au format UTC

0x0014 TOT Time offset Table ieXseauSre ^ ^ '* ^ * ^* ^ ^* ^ ™™ ^

Ce module d'agrégation d'EPG peut être exécuté sur le boitier PINGO mais aussi au niveau de la Plateforme de Service.

Dans le 1 er cas, le module d'agrégation d'EPG remonte à la plateforme de service les données élémentaires provenant des flux DVB démultiplexés. La remontée de ces données se fait sous forme de requête http

La plateforme de service renvoie au boitier Pingo des données enrichies sur le programme en cours. Ces données sont dans un format XML

Dans le 2ème cas, l'architecture décrite sur le schéma est répliqué au niveau serveur, c'est-à-dire que le serveurs de la plateforme récupèrent les EPG DVB à partir de tuners, démodulateurs et démultiplexeurs DVB situés côté plateforme. L'échange de données entre le client (boitier Pingo) et le serveur (Plateforme de

Service) selon un protocole type flux RSS avec date de rafraîchissement adaptée et calculée côté plateforme de service

L'intérêt de ce deuxième mode de réalisation est de limiter le besoin en ressource processeur et mémoire du boitier.

Ces flux XML de métadonnées enrichies sont décodés et incorporés à l'EPG agrégé (enrichi)

L'EPG est affiché sur les terminaux utilisateurs secondaires (en passant par le module d'encapsulation rtp et le module de communication sans-fil) ou pour le terminal principal (relié au boitier Pingo par l'interface Ecran TV (type péritel)

On décrira maintenant le flux de métadonnées enrichi :

Les métadonnées sont spécifiques à chaque type de flux et de programme en cours.

Une liste non exhaustive de type de programmes possibles est la suivante :

typel : Emission talk avec invités (que ce soit des émissions sur IP TV, flux DVB ou vidéos type You Tube)

titre : nom du programme (exemple : « T'empêches tout le monde de dormir ») heure de début et de fin animateur(s) nom de l'animateur 1

Photo de l'animateur

liste des émissions avec le même animateur et liens vers podcasts vidéos vidéos YouTube avec comme mot clé l'animateur nom de l'animateur 2

• lnvité(s)

Nom de l'invité 1 actualité de l'invité 1 (une ou deux phrases) Bio de l'invité Photo de l'invité • Détails de son actualité (si c'est un livre, ça serait la page web du livre)

Videos You Tube de l'invité et/ou de son actualité Nom de l'invité 2

Vidéos You Tube relatives aux mots clés de l'émission • Flux connexes (dont l'émission en cours est proche de l'émission en cours d'écoute)

Liens publicitaires en liaison avec les sujets de l'émission (liens vers des livres par exemple)

Type 2 : film et série (diffusé par DVB, IP TV ou Vidéo à la Demande)

Nom du film

Heure de début et de fin • Producteur/metteur en scène

Noms des producteurs, metteurs en scène

Photos o Liste des films produits par ces producteurs ou mis en scène par ces metteurs en scène • Acteurs

Noms

Photos

Bios

Actualités • Filmographie

Type 3 : Clips musicaux (diffusé par DVB, IP TV ou Vidéos type You Tube)

Nom du titre, album Jacquette de l'album Compositeurs, chanteurs Noms • Photos

Bios

Actualités Discographie Paroles de la chanson

Type 4 : Journal Télévisé (ou de manière générale, tout type de programme sans invités et avec des chroniques et un ou des animateurs)

Nom du journal • Heure de début et fin

Présentateur(s) nom du présentateur photo actualité du présentateur • Liste des chroniques

Nom de la chronique

Sujet de la chronique

Vidéos You Tube connexes (récupérés à partir des mots clés du sujet et nom de la chronique) • Emission/flux connexes (par exemple l'émission qui parle du même sujet sur une autre chaine)

Type 5 : vidéos (site de partage de vidéos sur Internet comme You Tube ou DailyMotion)

Nom de la vidéo Notation

Nombre de vidéos visionnées Liste de vidéos connexes • Liste d'émissions qui ont des sujets connexes

On décrira maintenant le mécanisme de synchronisation type RSS avec date de rafraîchissement adaptée :

Dans le fichier XML de métadonnée envoyé au boitier PINGO, le durée de la séquence en cours pour que le boitier Pingo puisse télécharger le nouveau flux lorsqu'il est nécessaire de le faire et pas à fréquence régulière (ce qui induirait une charge trop importante sur la plateforme)

Constitution des métadonnées agrégées et enrichies côté plateforme de service

La plateforme de service se connecte à des sites de contenus partenaires pour récupérer les informations telles que les acteurs qui jouent dans un film et pourra récupérer auprès d'un autre site sous un autre format, les biographies de ces acteurs et ainsi de suite.

La plateforme de service a un rôle d'agrégation de contenus hétérogènes

12) Le module de I'- Electronic Service Guide - ESG contextuel 42.

L'ESG est dit contextuel lorsque les services disponibles sont dépendants de ce qui est diffusé en ce moment sur la chaine sélectionnée.

Il s'agit d'une communication entre le boitier Pingo et la plateforme de Service

Quatre types de services contextuels sont notamment possibles:

1. • Achat des albums, films, livres recommandés (dans les métadonnées enrichies et intégrées dans l'EPG agrégé) 2. • Possibilité d'accéder à ces contenus sur d'autres terminaux utilisateurs comme un téléphone ou un ordinateur connecté à la plateforme de service

3. • Pour certaines émissions, l'utilisateur peut voter

4. • Certains jeux types « question à choix multiples » peuvent être proposés à l'utilisateur

13) Le module de statistiques 43

Capte tous les enchaînements visualisés sur les terminaux utilisateurs cette information est remontée à la plateforme de service.

La plateforme de service croise ensuite les informations de grille de programme enrichie et historique de l'utilisateur pour d'écrire de manière précise les types d'émissions visualisés, les noms des animateurs/présentateurs favoris, les musiques préférées et les thèmes préférés.

Ce module permet ensuite de pouvoir générer des bouquets de flux (DVB-T, DVB-H, IP TV, Vidéo à la demande ou Vidéo sur site de partager de vidéos) en fonction des goûts utilisateurs et de l'historique

14) Le module de transmission sans-fil peut utiliser l'une des normes suivantes: 802.1 1 b/g/a/n, Ultra Wide Band, Bluetooth 1.2, 2.0, 2.1 ou toute autre norme de communication permettant de faire transiter des paquets IP, en particulier le WIMAX.

Dans ce dernier cas, la mise en œuvre de l'invention permet de limiter les besoins de couvertures du DVB-T et DVB-H dans les zones peu denses en diffusant le flux TV re-encodés dans les derniers kilomètres via le réseau WIMAX.

Les normes Ethernet filaire et courant porteur sont également envisageables pour certaines applications La mise en œuvre des fonctions décrites plus haut est avantageusement faite sous forme logicielle, dansle cas où des/les fonctionnalités sont mises en œuvre en logique câblée, certaines informations peuvent être inutiles (par exemple les liens sont inhérents au câblage entre des blocs matériels ou circuits dédiés).

En complément, on peut préciser que la découverte des chaînes est conduite par le module de pilotage qui appelle le module de démodulation qui appelle à son tour N fois (pour chaque nouveau TS) le module de démultiplexage. On peut utiliser un fonctionnement inverse : le module de pilotage demande au démultiplexeur de demander au module de démodulation.

Dans la mise en œuvre logicielle de l'invention, des « thread » (segmentation de processus) peuvent être utilisés. Au minimum on peut mettre en œuvre des « thread » suivants : un pour le serveur HTTP et le module de pilotage, un pour le monitoring réseau, un pour la démodulation, un pour l'ensemble démultiplexage, transcodage, encapsulation et transmission. Dans ce dernier « thread », les fonctions de transcodage et encapsulation seraient appelées consécutivement quand des données sont démultiplexées. On peut également mettre en œuvre des « threads » séparés pour traiter les chaînes audio/vidéo/sous-titre/EPG. Dans ce cas, il faut transformer les fonctions de transcodage avec une fonction démarrage du transcodage et ajouter une fonction d'arrêt du transcodage.

On va maintenant détailler les modalités des échanges de données qui ont lieu lors de la mise en œuvre de l'invention et plus particulièrement des diagrammes de séquences.

Sur la Figure 7, est représenté un diagramme de séquence de la phase de découverte des chaînes.

Sur la Figure 8 est représenté un diagramme de séquence d'une demande de connexion initiale.

Le traitement (transcodage, encapsulation, envoi) peut commencer dès que le démultiplexeur a été informé de la chaîne à traiter. On privilégie ici une solution où une négociation des ports de communication IP entre client et serveur n'est pas nécessaire (réduction du temps de latence) et pour cela on enverra les données RTP sur des adresses « IP multicast ». Afin que la session se termine et que les ressources soient libérées pour d'autres utilisateurs, il est nécessaire de prévoir un message de fin de connexion avec une requête HTTP POST. Sur la Figure 9, on a un diagramme de séquence d'une demande de fin de connexion. Sur la Figure 10, est représenté un diagramme de séquence d'une demande de changement de chaîne

II est important de souligner ici que le demande de changement de chaîne ne modifie pas le contenu du fichier SDP (configuration du décodeur, mode d'encapsulation, ...) donc il n'est pas nécessaire de renvoyer un SDP. On peut donc conserver la même session de « streaming » (moins de latence). Les requêtes de changement de chaîne peuvent donc être des POST HTTP.

Par ailleurs, en ce qui concerne les dialogues Client / Serveur et Architecture Client, on doit noter que l'on souhaite maximiser les possibilités de lecture du contenu sur les terminaux utilisateurs cibles dont les téléphones, et que les limitations actuelles des téléphones sont les suivantes :

- Ils disposent d'un navigateur sur la toile (« Web ») capable d'afficher du contenu graphique mais faisant appel à des programmes (« plugins ») externes pour jouer l'audio vidéo. Cette solution n'est pas la plus satisfaisante car l'intégration de l'EPG et de l'A/V dans ce cas serait trop limitée.

- Ils disposent d'un lecteur multimédia, capable de jouer de l'audio/vidéo et parfois des sous-titres, mais peu de lecteurs savent afficher une surcouche graphique et interactive.

La solution proposée par l'invention permet : - Aux lecteurs limités de pouvoir jouer au moins la partie Audio/Vidéo/Sous-titre. On pourrait envisager que la consultation de l'EPG et la sélection de la chaîne se fasse par une interface Web.

- Aux lecteurs avancés (GPAC) de jouer toutes les données sous forme intégrée. Cette solution s'appuie sur le dialogue client-serveur représenté sur la Figure 1 1 qui représente un diagramme de séquence du dialogue client-serveur. Cette solution nécessite le pré requis suivant au niveau du client :

- Support du protocole RTP : les contraintes de « paquetisation » que le lecteur devra supporter seront celles de la norme 3GPP PSS. Le lecteur devra notamment supporter les adresses « multicast ».

- Support du protocole SDP : les descriptions SDP utilisées seront conformes à la norme 3GPP PSS. Elles contiendront au moins un flux audio, un flux vidéo et un flux de sous-titre (au format « 3GPP Timed Text »). Elles contiendront un flux 3GPP DIMS qui pourra être ignoré ou traité afin d'afficher l'EPG en surcouche graphique. - Possibilité d'envoyer des requêtes HTTP GET avec en attachement le profil du terminal (taille écran, capacité de décodage ...) : ce traitement pourra être fait directement dans le lecteur si un format graphique et interactif type SVG est supporté. Sinon, le navigateur « Web » du téléphone pourra être utilisé. Ce profil du terminal peut être stocké dans la base de données 46. - Possibilité d'envoyer des requêtes HTTP POST avec en paramètres les valeurs de la chaîne et des pistes audio et sous-titres souhaités : ce traitement pourra être fait directement dans le lecteur si un format graphique et interactif type SVG est supporté. Sinon, le navigateur Web du téléphone pourra être utilisé. On va maintenant détailler des exemples de mise en œuvre de l'invention. Dans ce premier mode de réalisation du décodeur selon l'invention, la liaison secondaire est réalisée au moyen d'une connexion sans fil du type WIFI entre le décodeur 1 et le lecteur 20. Le décodeur 1 distribue un flux de données secondaire dans une zone de couverture « éclairée » par le signal WIFI, d'environ 300 mètres autour du décodeur. La mise en œuvre d'un tel format d'échange consommant une quantité relativement importante d'énergie électrique, le décodeur est de préférence raccordé au secteur par un câble d'alimentation 2.

Le décodeur 1 selon l'invention est de préférence positionné à proximité d'une fenêtre du bâtiment à l'intérieur duquel se trouve le lecteur sur lequel l'utilisateur souhaite visualiser un contenu vidéo. Le décodeur 1 peut même être placé à l'extérieur du bâtiment, sur la façade de celui-ci, par exemple.

L'avantage d'un tel décodeur en ce qu'il est possible de le positionner de manière à recevoir un signal DVB de bonne qualité. Pour que le signal DVB ne subisse que peu de perte de puissance, il est préférable de positionner le décodeur près d'une fenêtre ou à l'extérieur du bâtiment. En conséquence, si l'utilisation d'un tel décodeur relais domestique était généralisée, la puissance du réseau d'antennes de diffusion DVB qu'il faudrait mettre en place serait à revoir à la baisse. En effet le nombre des antennes du réseau serait en nombre plus faible qu'initialement estimé. Cela conduirait à diminuer les coûts de déploiement du réseau DVB qui deviendrait alors un projet dont la mise en œuvre serait plus facile, en particulier pour un réseau DVB-H.

Le décodeur 1 est avantageusement muni de plusieurs antennes 3 pour capter le signal DVB. En effet, il a été constaté que la qualité de réception était fortement améliorée lorsque le système comportait plusieurs antennes ayant des orientations relatives différentes, garantissant ainsi une très bonne réception quelle que soit la

position du décodeur par rapport au cône d'émission de l'antenne du réseau près de laquelle se situe le décodeur.

Le flux DVB-H reçu est décodé par une puce DVB-H 4 dédiée.

Après que le flux de données DVB-H a été décodé par la puce DVB-H 4, le flux de données décodé est transmis, le long de connexions internes 6, vers une unité de calcul CPU référencée par le chiffre 5 sur la figure 1.

Selon le protocole DVB, cinq canaux individuels indépendants sont multiplexes et transmis dans un même flux de données à une fréquence définie. Le premier canal

« + » représente le contenu vidéo de la chaîne n+1 , le deuxième canal « 0 » représente le contenu vidéo de la chaîne n, le troisième canal « -» représente le contenu vidéo de la chaîne n-1 , le contenu du quatrième canal « I » est un flux de données correspondant à des informations sur les données vidéos des trois premiers canaux, telles que des metadonnées, et le cinquième canal « Q » correspond à des données sur la qualité de transmission. Selon la norme DVB-H, le flux de données a un débit de 2 Mbps. Le flux de données correspondant à un canal vidéo individuel est donc de

384 kbps chacun.

Le traitement effectue par le CPU 5 consiste en la séparation, ou démultiplexage, des cinq canaux individuels composant le flux de données décodé primaire en autant de flux de données décodé individuels. Ces flux de données décodé individuels sont ensuite dirigés vers des moyens de stockage et de mémorisation. Plus précisément, des fichiers « + », « 0 » et « - », par exemple du type MPEG, sont simultanément et respectivement augmentés dynamiquement des données du flux DVB décodé et démultiplexé.

Eventuellement, le flux de données individuel, et donc le fichier correspondant, est enrichi de certaines des données contextuelles du quatrième canal « I » du flux DVB-H.

Un des fichiers « + », « 0 » et « - » est alors sélectionné pour être réémis vers le lecteur de l'utilisateur.

Dans un mode de réalisation préférentiel, le support physique du protocole secondaire est une liaison hertzienne locale, sans fil du type WIFI. La norme WIFI, par exemple 802.1 1 b, a un débit théorique de 1 1 Mbps, soit 6 Mbps en débit réel, sur une porteuse à 2,4 GHz, dans un périmètre de 300 mètres. Le décodeur 1 comporte donc des moyens d'émission WIFI 10 et une antenne 1 1 associée au.

Le décodeur 1 couvre une zone importante dans laquelle un utilisateur identifié peut avoir plusieurs dispositifs de visualisation du signal vidéo, ou bien plusieurs utilisateurs peuvent recevoir le même signal vidéo.

L'avantage de l'utilisation du format WIFI est qu'il a été défini pour encapsuler des datagrammes IP. Ainsi, en cas d'utilisation de datagrammes IP encapsulés dans le format DVB-H, ceux-ci sont simplement réencapsulés dans le format WIFI.

De son coté, le lecteur vidéo 20 portable comporte une antenne 21 et des moyens aptes à la réception et au décodage des signaux WIFI 22 captés. Le flux de données secondaire ainsi reçu est traité par le CPU 25 du lecteur 20 pour être affiché sur un écran 23 de ce lecteur. Dans le mode de réalisation actuellement préféré, le décodeur 1 communique directement avec le lecteur, sans passer par l'intermédiaire d'un routeur domestique. En effet, sur un lien de communication partagé entre plusieurs services, il a été constaté que la diffusion d'un flux vidéo est facilement perturbée par les autres données transitant sur ce lien. Par exemple, le téléchargement de fichiers depuis l'Internet en parallèle avec la diffusion d'un flux vidéo perturbe ce dernier. La vidéo est affichée de manière saccadée. En conséquence, on préférera disposer d'une liaison locale WIFI dédiée à la rediffusion du flux vidéo.

On pourrait imaginer qu'une évolution prochaine du protocole de communication WIFI introduise la notion de hiérarchie et de priorité entre paquets de données. De la sorte, l'on pourrait donner une priorité supérieure au flux vidéo par rapport à des activités Internet menées en parallèle, tel que le téléchargement de fichiers. Grâce à cette évolution du format WIFI, le décodeur DVB pourrait être intégré à un routeur domestique et la connexion WIFI pourrait être partagée entre plusieurs utilisateurs ou fonctionnalités. Alternativement, le décodeur pourrait communiquer avec le routeur domestique au moyen d'une liaison filaire ou sans fil, le routeur réémettant à son tour le flux vidéo en direction du lecteur vidéo par une liaison locale sans fil WIFI. Notion de navigation intraflux (d'un canal vidéo à l'autre)

Les différents canaux vidéo diffusés par la télévision numérique sont répertoriés dans une liste ordonnée. Chaque fréquence particulière de fonctionnement de la télévision numérique selon la norme DVB porte trois canaux multiplexes choisis successivement dans cette liste : un canal central « n » et deux canaux voisins respectivement directement au-dessus « n+1 » et directement au-dessous « n-1 » du canal central.

Les moyens de réception DVB-H comportent une fonctionnalité « tuner » permettant au récepteur DVB-H de passer d'une première fréquence f1 de réception à une seconde fréquence f2 voisine, par exemple directement au-dessus de la première fréquence. Alors que la première fréquence f 1 porte les canaux n-1 , n et n+1 , le canal n étant le canal central « 0 » pour cette fréquence f1 , la seconde fréquence f2 porte les canaux n, n+1 et n+2, le canal central « 0 » correspondant pour cette seconde fréquence f2 au canal n+1. Cette fonction « tuner » correspond donc à la capacité de passer d'un groupe de canaux à un autre groupe de canaux situés immédiatement au- dessus dans la liste ordonnée des canaux vidéo diffusés.

A côté de cette fonctionnalité de sélection en fréquence, le décodeur 1 selon l'invention dispose d'une fonctionnalité permettant à l'utilisateur de sélectionner un

canal vidéo parmi les trois canaux vidéo présents dans un flux de données DVB-H décodé à l'instant présent. Il s'agit d'une sorte de navigation à l'intérieur d'un flux de données DVB-H caractérisé par une fréquence constante de fonctionnement des moyens de réception du flux DVB-H. Ainsi, d'une manière qui sera décrite ci-après en détail, l'utilisateur, alors qu'il était en train de visualiser le programme vidéo associé au canal central « 0 », décide de visualiser le contenu du canal immédiatement au-dessus « + » ou au-dessous « - » du canal central, en actionnant la fonctionnalité de navigation « intraflux ». Ainsi, alors que le fichier « 0 » correspondant au canal « 0 » était retransmis vers les moyens de retransmission 7, 10 et 1 1 , c'est maintenant le fichier « + » qui est retransmis et visualisable sur l'écran du lecteur 20.

Cette fonctionnalité permet une très grande fluidité de l'utilisation du service de télévision numérique. En effet, la fonction « tuner » des moyens de réception DVB permettent également de naviguer parmi les canaux diffusés, mais à chaque modification de la fréquence de réception, il faut recréer les fichiers « 0 », « + » et « - » et attendre qu'il ait un volume suffisant pour permettre une diffusion secondaire sans rupture du flux. Cela représente donc un certain temps mort. De plus, dans les installations connues de télévision IP, il a été constaté que du fait même de l'utilisation du protocole IP, un temps de latence important existe lors d'un changement de chaîne. En effet, le temps de recréer une connexion IP transportant des informations vidéo relatives à la nouvelle chaîne et le temps de stocker dans une mémoire tampon suffisamment d'informations pour assurer ultérieurement un affichage fluide et continu du programme vidéo, est d'environ 10 à 15 s. Ce temps de latence est rédhibitoire pour que l'utilisateur final d'un système de visualisation portable soit satisfait par ce nouveau moyen de regarder un programme vidéo. Au contraire, la navigation intraflux selon l'invention constitue un découplage entre l'utilisation de la fonction « tuner » et la sélection du canal vidéo sélectionné.

Avantageusement, alors que le fichier correspondant à un canal individuel est émis vers lelecteur, la fonction tuner DVB est activée pour caller la réception primaire sur la fréquence immédiatement au-dessus de la fréquence reçue jusqu'à présent. Ainsi, le canal vidéo individuel sélectionné et actuellement visualisé, correspond maintenant au canal central « 0 » du flux de données DVB-H primaire. Lors de ce changement de fréquence, un nouveau fichier tampon MPEG correspondant au canal n+2 nouvellement décodé est crée ; les fichiers correspondants aux canaux communs n et n+1 continuent d'être décodés et sont mis à jour, éventuellement en en changeant le nom ; et le fichier correspondant au canal n-1 qui n'est plus décodé est supprimé.

Pour naviguer, l'utilisateur choisit un canal par l'intermédiaire d'une télécommande 30, soit réelle et dédiée au décodeur 1 , soit virtuelle et émulée par un logiciel exécuté sur le lecteur vidéo portable 20. Dans ce dernier cas, les données de

sélection du canal sont transmises du lecteur 20 vers le décodeur 10 en utilisant le flux montant de la liaison bidirectionnelle WIFI.

Dans le cas de l'utilisation d'une télécommande 30 réelle, la navigation se fait par l'utilisation des boutons de sélection + 31 et - 32. Leur actionnement génère l'envoi d'informations par exemple au moyen d'une liaison infrarouge entre des moyens d'émission 35 de la télécommande 30 vers des moyens de réception IR 15 dont est équipé le décodeur 10. La communication entre la télécommande 30 et le décodeur 1 peut se faire selon un protocole de communication propriétaire.

De préférence, la télécommande comporte un écran LCD 36 sur lequel les metadonnées correspondantes au canal vidéo actuellement affiché sur le lecteur. Cet écran LCD 36 comporte, dans sa partie supérieure, une série de cristaux liquides 37 alignés permettant d'indiquer la puissance du signal DVB capté par le décodeur 1. Cette fonctionnalité permet de placer le décodeur de sorte que la réception du signal DVB soit la meilleure possible. Dans l'alternative consistant à émuler des moyens de navigation intraflux sur le lecteur 20, un logiciel correspondant à une télécommande virtuelle peut être téléchargé lors de la première connexion s'établissant entre le décodeur 1 et le lecteur 20. Ce logiciel téléchargé est ensuite exécuté pour munir le lecteur 20 de cette fonctionnalité virtuelle. Cryptage des données vidéo

Les données vidéo multiplexées dans le flux DVB primaire peuvent être cryptées par l'opérateur de manière à ne permettre la visualisation du contenu qu'à des utilisateurs identifiés. Deux architectures sont alors possibles.

Selon une première architecture représentée sur la figure 1 , après décodage, un flux de données décodé crypté correspondant à un canal individuel est réémis vers le lecteur, et l'opération de décryptage à lieu au niveau du lecteur 20. Pour cela, le lecteur 20 comporte une carte à puce 26 d'identification du lecteur et de son utilisateur. L'utilisation de cette première architecture nécessite la transmission d'une clé de décryptage jusqu'au lecteur 20. Ceci peut être réalisé à intervalle régulier, par exemple tous les mois, par l'émission par l'opérateur d'un flux DVB dont le quatrième canal, dit d'information, véhicule ces données de clé. Un fichier tampon de transmission de la clé est alors émis du décodeur 1 vers le lecteur 20.

Une fois que le lecteur 20, identifié grâce à sa carte à puce, a reçu et mémorisé la clé correspondante, il est apte à décrypter le signal vidéo reçu pendant toute la durée de validité de ladite clé. Le CPU 25 du lecteur 20 lit la clé de décryptage mémorisée dans une mémoire morte dudit lecteur 20 afin de décrypter le flux vidéo secondaire reçu. Le CPU 25 est ensuite apte à transmettre les données décryptées vers l'écran 23. Carte à puce sur le décodeur

Selon une seconde architecture, le décodeur 1 est identifiable par sa propre carte à puce 8 (représenté en pointillés sur la figure 1 ). Après identification selon un procédé connu, une clé de décryptage peut être transmise à travers le quatrième canal d'information du flux DVB vers ce décodeur identifié. La clé une fois disponible permet au CPU 5 de décrypter les différents flux des canaux vidéo. Selon cette variante de réalisation, les moyens 7, 10 et 1 1 mettent à disposition un signal vidéo secondaire décrypté.

En conséquence, celui-ci peut être affiché par plusieurs lecteurs situés dans la zone de couverture de l'antenne WIFI 1 1. C'est la raison pour laquelle, de préférence, la liaison WIFI entre le décodeur 1 et un lecteur 20 est sécurisée. Dans ce schéma de contrôle du flux secondaire diffusé, le signal n'est pas de nouveau encodé, mais est simplement sécurisé. Ceci est par exemple réalisable en utilisant un protocole WIFI sécurisé, ou d'autres protocoles WPA ou WPA 2. II est également à noter la possibilité de munir le décodeur 1 d'un moyen de traitement intermédiaire 14 pour les flux individuels de données décodées. Il a été évoqué ci-dessus la possibilité d'enrichir le fichier correspondant à un canal vidéo individuel de métadonnées. De plus, lorsque le protocole de communication secondaire constitue une contrainte, il est également possible de compresser les flux individuels de manière à générer des fichiers individuels compressés dont le volume plus faible est compatible avec le débit de la liaison secondaire. Mode de réalisation 1 décodeur BLUETOOTH

En alternative à l'utilisation d'un protocole secondaire sur un support WIFI, un protocole secondaire fondé sur un support BLUETOOTH est également envisagé. Le format de communication BLUETOOTH définit par exemple par la norme IEEE

802.15.1 présente l'avantage de couvrir une zone réduite d'environ 100 mètres de rayon autour de l'émetteur. Ce moyen de réémission d'un flux vidéo secondaire par un décodeur de télévision numérique selon l'invention est particulièrement bien adapté à un véhicule. Et ceci d'autant plus que ce format est d'ores et déjà utilisé pour toute une série d'applications dans l'univers automobile.

L'avantage supplémentaire d'une connexion BLUETOOTH réside en ce que dès à présent, un grand nombre des téléphones portables et PDA vendus est équipé de moyens de communication BLUETOOTH.

De plus le décodeur peut alors être autonome. Il comporte dans ce cas une batterie de faible puissance rechargeable, par exemple au moyen d'une cellule solaire associée au décodeur lorsqu'il est placé sur la façade du bâtiment ou sur la lunette arrière d'une voiture.

L'utilisation d'une liaison BLUETOOTH nécessite l'association initiale du lecteur et du décodeur. Cette étape d'appariement peut se faire simplement en saisissant sur

le lecteur une clé caractérisant la liaison BLUETOOTH du décodeur, indiquée par exemple sur une étiquette placée sur le dessous de celui-ci.

L'invention peut être déclinée de nombreuses autres manières que celles spécifiquement décrites à titre d'exemple. Notamment les fonctionnalités peuvent être mises en œuvre par logiciel plutôt que câblées ou en mode mixte (câblé + logiciel), ces fonctionnalités peuvent être étendues ou limitées en fonction des usages : limitation des capacités du démodulateur par exemple, du type de signal DVB, du choix des flux : en clair ou non, cryptage sur la liaison radio locale ou non, choix du procédé de compression de données adaptatif, choix des paramètres définissant la qualité de la liaison locale (temps de latence, débit, taux de retransmission...)...