MX2011002521A

MX2011002521A - Seleccion de fuente de video dinamico.

Info

Publication number: MX2011002521A
Application number: MX2011002521A
Authority: MX
Inventors: Geraint Jenkin; Marcus C Liassides
Original assignee: Echostar Advanced Technologies L L C
Priority date: 2008-09-10
Filing date: 2009-09-10
Publication date: 2011-05-23
Also published as: US11831952B2; GB2463329A; US8332905B2; US20130007826A1; US20100064335A1; GB0822236D0; US20240048806A1; US20200236432A1; CA2736330A1; CA2736330C; US20130347045A1; US10616646B2; US8683543B2; WO2010029298A1; GB2463329B; US20140208345A1; US20100064324A1; EP2324633A1; US8935732B2; US8418207B2

Abstract

Un componente de Selección de Fuente de Video Dinámico (DVSS) que puede implementarse en una STB física o virtual que es capaz de presentar un servicio de alta calidad y un paradigma de navegación consistente al televidente, mientras detecta, selecciona y presenta la mejor calidad de programación posible de acuerdo con la posición actual del dispositivo del televidente dentro de la red.

Description

SELECCIÓN DE FUENTE DE VIDEO DINÁMICO DESCRIPCIÓN DE LA INVENCIÓN Modalidades de la presente invención se relacionan con tecnología de Televisión de Protocolo de Internet (IPTV) y, específicamente, a emular una caja de convertidor-descodificador (STB) física para proporcionar un servicio de IPTV a un usuario de manera que el usuario pueda visualizar contenido de programación en un dispositivo tal como un dispositivo de cómputo, manteniendo la presentación y funcionalidad asociadas con los paradigmas tradicionales de programación .

En un paradigma de televisión tradicional, el contenido de programación se envía como señal análoga o digital a un equipo de televisión del televidente mediante cable, satélite o por aire. Las señales entonces se reciben, procesan y despliegan para que el televidente las vea en la pantalla del equipo de televisión.

Sin embargo, con la propagación exotérica de los dispositivos electrónicos portátiles, tales como computadoras tipo laptop, los televidentes ya no desean que se les restrinja ver televisión mediante un equipo de televisión convencional el cual, se confina más o menos, para utilizarse en una ubicación física. Dado el deseo o necesidad de la capacidad de transporte, y la presencia universal de las tecnologías de Internet dentro de equipo de cómputo moderno, la capacidad de recibir servicios de IPTV mediante equipo de cómputo se vuelve cada vez más importante a partir de la perspectiva del consumidor (es decir, el televidente) y a partir de la perspectiva de los proveedores de servicios que buscan comercializar las oportunidades.

De esta manera, el monopolio de paradigma tradicional de televisión se está dañando y desafiando por el desarrollo de las tecnologías de Televisión por Internet (TV por Internet) y la Televisión de Protocolo de Internet (IPTV) .

La TV por Internet permite a un usuario elegir programas de una lista y típicamente se le proporciona sobre una red de IP en forma de video continuo mediante un sitio web. El contenido se integra en una página web, y el texto que lo acompaña típicamente rodea el video continuo el cual se presenta al televidente dentro de una ventana separada. En algunas formas, este estilo de presentación es similar a una página de periódico donde el texto circundante fluye alrededor y no sobre la imagen, no obstante que la imagen estática se remplace por un componente de video.

En contraste, un sistema de IPTV típicamente permite la entrega de un servicio de televisión digital a un televidente sobre una infraestructura de red cerrada. La entrega se realiza utilizando el Protocolo de Internet y típicamente incluye una conexión de banda ancha. El sistema de IPTV recibe y despliega la corriente de video, la cual se ha codificado como una serie de paquetes de protocolo de Internet (datos) . La IPTV puede tener la forma de TV en vivo, aunque también como video almacenado, algunas veces conocido como "video a la carta" (VOD) .

Tradicionalmente, el televidente debe utilizar un dispositivo conocido como caja de convertidor-descodificador (STB) junto con su equipo de televisión para recibir y ver IPTV. La caja de convertidor-descodificador actúa como una interfaz entre la televisión y la red, que descodifica los medios de transmisión continua de video entrante, que los convierte en señales de televisión estándar y proporciona comunicaciones de dos vías sobre la red de IP. También realiza procesamiento funcional, tal como configurar la conexión y la calidad de servicio (QoS) con el nodo de servicio, la funcionalidad de cambio de canal y el control de presentación del usuario. Esta funcionalidad se logra mediante el uso de software conocido como 'middleware' .

'Middleware' es un componente principal dentro de la arquitectura de soluciones de IPTV. La capa de software de aplicación que actúa como una interfaz entre la interfaz de usuario y el hardware/sistema operativo (OS) de la STB. Los vendedores de middleware adoptan las estrategias basadas en sustracción para aislarse a sí mismos del hardware subyacente.

Sin embargo, los proveedores de servicios pueden encontrar desafiante hacer del modelo comercial de IPTV comercialmente viable debido al costo (con frecuencia relativamente elevado) de las STB. Esto se compone por la naturaleza lineal de la línea de costo/funcionalidad de las STB, entre más características o funciones necesite tener la STB, mayor será el costo del dispositivo. Esto ha indicado a los proveedores de servicios de IPTV a que investiguen las posibilidades de entregar sus servicios a dispositivos de usuario final de mercado masivo (tal como computadoras personales) donde el costo del hardware ya se ha transmitido por el usuario final/televidente. De este modo, si los componentes de cómputo estándar pueden utilizarse para reflejar e imitar sus contrapartes televisuales (por ejemplo, monitor, CPU, disco utilizado para remplazar TV, STB, VCR respectivamente) , entonces la funcionalidad puede mantenerse mientras se elimina el costo e inconveniencia de una STB requerida .

La Figura 1 ilustra cómo, en una arquitectura 100 de IPTV tradicional que incluye una STB 120 física, el contenido de IPTV se suministra al equipo 120 de televisión del televidente de manera que el estilo de presentación del contenido de IPTV es el mismo que aquel experimentado por el televidente cuando utiliza un sistema de entrega sin IPTV (por ejemplo, difusiones de TV por aire) . Como muestra la Figura 1, las señales se transmiten desde el proveedor de servicios sobre una red, y se reenvían por un enrutador a la STB del televidente. La STB la cual se conecta al equipo de televisión del televidente, procesa las señales de manera que el contenido pueda desplegarse en la pantalla de televisión en un estilo y formato idénticos a aquel experimentado en los paradigmas de difusión de televisión más 'tradicionales'.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La invención puede entenderse mejor al referirse a la siguiente descripción y los dibujos anexos que se utilizan para ilustrar modalidades de la invención. En los dibujos: La Figura 1 muestra la arquitectura de un sistema de IPTV tradicional típico, el cual utiliza una STB física; la Figura 2 muestra un dispositivo de cómputo que ejecuta un middleware de un tercero que se ejecuta junto con un sistema de emulación de STB de acuerdo con una modalidad, aunque el middleware se haya diseñado para su uso con una STB tradicional ; la Figura 3 muestra cómo la arquitectura de IPTV tradicional y sistema de TV por web duplican las funciones centrales de cada uno, y también muestra los diferentes estilos de presentación cuando se despliega contenido para visualizarse en diferentes dispositivos finales; la Figura 4 muestra cómo un sistema de emulación de STB de acuerdo con una modalidad elimina o reduce la duplicación de funciones centrales, mientras proporciona contenido a una STB más televisión o un dispositivo de cómputo que se utiliza junto con un sistema de emulación de STB de acuerdo con una modalidad, y también mantiene el estilo de presentación del contenido para el televidente; la Figura 5 muestra la reducción en esfuerzo y gastos requeridos a nombre del proveedor de servicios, cuando se utiliza un sistema de emulación de STB de acuerdo con una modalidad; la Figura 6 muestra cómo la presentación televisual de servicio se conserva sin importar el dispositivo utilizado para presentar el contenido de acuerdo con una modalidad; la Figura 7 muestra los componentes principales de un sistema de emulación de STB para presentar contenido de IPTV a un usuario en un dispositivo electrónico de acuerdo con una modalidad; la Figura 8 muestra una modalidad de un sistema de emulación de STB que se dispone y configura para su uso con middleware de categoría II basado en interfaces de programación de aplicación (API) ; la Figura 9 muestra una modalidad de un sistema de emulación de STB que se dispone y configura para su uso con middleware de categoría I (integrado por explorador) ; la Figura 10 muestra los componentes centrales de un sistema de emulación de STB dispuesto para entregar contenido de IPTV a un dispositivo para presentación a un televidente de acuerdo con una modalidad; la Figura 11 muestra un esquema detallado de un componente de selección de fuente de video dinámico (DVSS) para realizar la selección de fuente dinámica de acuerdo con una modalidad; la Figura 12 muestra algunos componentes de un sistema de entrega de contenido de acuerdo con una modalidad, e ilustra su capacidad para tratar las capas de video y UI de manera independiente hasta el punto de presentación en el dispositivo final; la Figura 13 ilustra un diagrama simplificado de cómo un televidente puede tener una experiencia de visualización consistente en múltiples ambientes de red de acuerdo con una modalidad; la Figura 14 es una representación esquemática del mapeo de las API utilizadas en una modalidad de la presente invención; la Figura 15 es un diagrama de secuencias que ilustra un proceso de conmutación de medios que representa parte de las modalidades de la presente invención; la Figura 16 es un diagrama de secuencias que ilustra el proceso posterior de conmutación de corriente de medios de acuerdo con una modalidad; la Figura 17 es un diagrama de secuencias que ilustra la sincronización de datos de audio y video en una modalidad; la Figura 18 es un diagrama de secuencias que ilustra el mecanismo de comunicación de las API con las otras aplicaciones que forman modalidades de la presente invención; la Figura 19 es una representación esquemática de las relaciones entre el sistema operativo, las API de terceros y modalidades de la presente invención; la Figura 20 es un diagrama de flujo que ilustra la operación del subsistema de presentación de sustracción de acuerdo con una modalidad; la Figura 21 es una representación esquemática de extracciones de enlace utilizadas para ilustrar una modalidad; la Figura 22 es un diagrama de flujo que ilustra los flujos de datos sin procesar en una modalidad; la Figura 23 es una representación esquemática de los subsistemas utilizados en una modalidad y la interacción de los mismos; la Figura 24 es una representación esquemática de la implementación de pila de Protocolo de Transmisión Continua en Tiempo Real (RTSP) para VOD utilizado en una modalidad.

La siguiente descripción describe modalidades de una caja de convertidor-descodificador virtual (vSTB) para ejecutar un componente de middleware, diseñado para su ejecución por la STB física, que incluye emular las capacidades de hardware de la STB física para procesar el contenido de IPTV recibido sobre una conexión de red. El componente de middleware es una estructura contenedora en la cual pueden operar las aplicaciones. El componente de middleware puede ser la capa de software de aplicación que actúa con la interfaz entre la interfaz de usuario y el hardware y sistema operativo de la STB, o en el caso de vSTB, el hardware y sistema operativo del dispositivo de cliente (ninguna STB física) . Por ejemplo, el componente de middleware puede ser una capa del sistema operativo diseñada para electrónica de cliente, tal como para cajas de convertidor-descodificador físicas, que se conectan al sistema de un proveedor de servicios, tal como la Plataforma de Aplicación OpenCable utilizada para sistemas de televisión por cable. El componente de middleware típicamente es específico para el vendedor particular de los servicios de televisión .

La siguiente descripción también describe modalidades de un componente de DVSS que puede implementarse en una STB física o virtual que es capaz de presentar un servicio de alta calidad y paradigma de navegación consistente al televidente, mientras (transparente para el usuario) detecta, selecciona y presenta la programación de mejor calidad posible de acuerdo con la posición actual del dispositivo del televidente dentro de la red (sin importar el soporte de multidifusión) . El componente de DVSS puede utilizarse para proporcionar al usuario una experiencia única de calidad óptima, independientemente de la red en la cual opere el dispositivo de cliente. En una modalidad, el componente de DVSS determina y adquiere la programación de calidad óptima posible de acuerdo con la posición actual del dispositivo de usuario dentro de la red, por ejemplo, el componente de DVSS puede emitir una solicitud a una primera fuente utilizando un primer protocolo y, al determinar que falla la solicitud, reemitir la solicitud a una segunda fuente utilizando un segundo protocolo. El componente de DVSS puede recibir el contenido de medios solicitado utilizando un protocolo particular utilizado por la red de suministro particular utilizada por la fuente seleccionada. Por ejemplo, el contenido de medios puede recibirse en uno de los protocolos diferentes, por ejemplo, RTSP, Protocolo de Administración de Grupos de Internet (IGMP) , Difusión de Video Digital (DVB) , u otros, tal como de igual a igual (P2P) , corrientes continuas (por ejemplo, corrientes continuas de HTTP) descritos en lo siguiente.

En la siguiente descripción, se establecen numerosos detalles. Será aparente, sin embargo, para alguien con experiencia en la técnica, que la presente invención puede practicarse sin estos detalles específicos. En algunos casos, estructuras y dispositivos bien conocidos se muestran en forma de diagrama de bloque, en lugar de en detalle, para evitar oscurecer la presente invención.

Algunas porciones de las descripciones detalladas que siguen se presentan en términos de algoritmos y representaciones simbólicas de operaciones sobre bits de datos dentro de una memoria de computadora. Estas descripciones y representaciones algorítmicas son el medio utilizado por aquellos con experiencia en la técnica de procesamiento de datos para transmitir de manera más efectiva la sustancia de su trabajo a otros con experiencia en la técnica. Un algoritmo aquí, y de manera general, se forma para ser una secuencia auto-consistente de etapas que conllevan a un resultado deseado. Las etapas son aquellas que requieren manipulaciones físicas de cantidades físicas. Normalmente, aunque no de manera necesaria, estas cantidades tienen la forma de señales eléctricas o magnéticas capaces de almacenarse, transferirse, combinarse, compararse, y de otra manera manipularse. Algunas veces ha sido conveniente, principalmente, por razones de uso común referirse a estas señales, bits, valores, elementos, símbolos, caracteres, términos, números, o similares. Muchas de las unidades funcionales descritas en esta especificación se han etiquetado como módulos, motores, o administradores, para enfatizar de manera más particular su implementación e independencia. Por ejemplo, un módulo puede implementarse como un circuito de hardware que incluye circuitos integrados comunes o disposiciones de compuerta, semiconductores disponibles en el mercado tales como chips lógicos, transistores, u otros componentes discretos. Un módulo, motor o administrador también puede implementarse en dispositivos de hardware programable, tales como disposiciones de puerta programable de campo, lógica de disposición programable, dispositivos lógicos programables , o similares. Estos módulos, motores y administradores también pueden implementarse en software para su ejecución por varios tipos de dispositivos de cómputo. Un módulo identificado de código ejecutable, por ejemplo, puede incluir uno o más bloques físicos o lógicos de instrucciones que, por ejemplo, pueden organizarse como objeto, procedimiento o función. No obstante, los ejecutables de un módulo identificado no necesitan ubicarse físicamente juntos, pero pueden incluir instrucciones diferentes almacenadas en diferentes ubicaciones las cuales, cuando se unen lógicamente, incluyen el módulo y logran el propósito establecido para el módulo. De hecho, un módulo de código ejecutable puede ser una sola instrucción, o muchas instrucciones, e incluso puede distribuirse sobre varios diferentes segmentos de código, entre diferentes programas y a través de los diversos dispositivos de memoria. Similarmente, datos operacionales pueden identificarse e ilustrarse en la presente dentro de módulos, y pueden representarse en cualquier forma adecuada y organizarse dentro de cualquier tipo adecuado de estructura de datos. Los datos operacionales pueden recolectarse como conjunto de datos sencillos, o pueden distribuirse sobre diferentes lugares incluyendo sobre diferentes dispositivos de almacenamiento.

Sin embargo, debe tenerse en cuenta, que todos éstos y términos similares se asociarán con las cantidades físicas adecuadas y sólo etiquetas convenientes aplicadas a estas cantidades. A menos que se establezca específicamente lo contrario, como es aparente a partir de la siguiente descripción, se aprecia que a través de la descripción, discusiones que utilizan términos tales como "que envían", "que reciben", "que conectan", "que reenvían", "que capturan", o similares, se refieren a la acciones y procesos de un dispositivo de cómputo, o dispositivo de cómputo electrónico similar, que manipula y transforma datos representados como cantidades físicas (electrónica) dentro de los registros y memorias del dispositivo de cómputo en otros datos representados similarmente como cantidades físicas dentro de las memorias y registros del dispositivo de cómputo u otros dispositivos de almacenamiento, transmisión o presentación de información.

Las modalidades descritas aquí, pueden eliminar la necesidad de una STB tradicional (es decir, física) y/o un equipo de televisión, y proporciona, en una modalidad, un ambiente de emulación basada en software, de manera que las señales pueden recibirse, procesarse y visualizarse en un dispositivo alternativo, tal como un dispositivo de cómputo portátil (por ejemplo, una computadora tipo laptop) sin pérdida o adaptación de servicio, estilo de presentación o funcionalidad. Las modalidades también pueden utilizarse junto con una STB física y/o un equipo de televisión.

Este mantenimiento de experiencia de visualización se ilustra en la Figura 2, la cual muestra una computadora 200 tipo laptop que ejecuta un middleware de un tercero que se ejecuta junto con un sistema de emulación de STB de acuerdo con una modalidad, a pesar de que el middleware se haya diseñado para su uso con una STB tradicional . La Figura 2 también ilustra cómo un sistema de emulación de STB se ha diseñado para suministrar una experiencia televisual rica en multimedia similar a lo asociado tradicionalmente con una STB física y equipo de televisión. La imagen muestra el resultado final de cómo el middleware de un tercero ha elegido presentar la ínterfaz 201 de usuario y las capas 202 de video con respecto una de la otra, en lugar rodear los gráficos y/o texto alrededor del video, como se hace en la televisión web convencional.

De este modo, los componentes funcionales de la caja de convertidor-descodificador virtual (también denominada como sistema de emulación de STB) como se describe en las modalidades en la presente, permiten que el middleware defina las coordenadas exactas de cada elemento visual en los tres planos (X, Y, y Z) . El plano Z también incluye la capacidad de aplicar técnicas de flexión alfa para variar la opacidad de la de la capa de Interfaz de Usuario (UI) con respecto a la capa de video.

Para recibir servicios de IPTV y visualizarse en otro dispositivo electrónico alternativo, tal como una computadora personal o tipo laptop, el dispositivo electrónico mismo realiza el procesamiento funcional descrito en la presente con respecto a las STB utilizadas con televisiones, pero lo realiza al ejecutar un componente de middleware, diseñado para su ejecución por una STB física, que incluye capacidades de hardware de emulación de la STB física para procesar el contenido de IPTV como si el dispositivo electrónico fuera una STB física.

Las modalidades descritas aquí, describen un sistema que proporciona el suministro continuo de servicios de IPTV a un dispositivo alternativo tal como un dispositivo de cómputo, tal como una computadora 200 tipo laptop ilustrada en la Figura 2. Idealmente, tal sistema puede disponerse y configurarse para que pueda integrarse con tecnologías existentes de IPTV. Este trabajo de integración implica principalmente tres áreas: 1) Entrega de video: algunas modalidades se basan en tecnologías de difusión estándar, y no en aquellas que han surgido con respecto a los servicios basados en web (TV por Internet) . Esto es debido a la diferencia en las experiencias de visualización descritas en la presente; principalmente en la segregación de texto e imágenes móviles. 2) Acceso Condicional (CA) : proveedores de servicio requieren un medio para controlar y manejar el acceso a los servicios. Cada proveedor puede tener un mecanismo diferente para controlar y manejar el acceso a los servicios . Los suscriptores pueden optar por los niveles variados de servicio, y de este modo el acceso al contenido debe controlarse por un sistema de acceso condicional (CA) . Esto se implementa típicamente mediante el uso de 'tarjetas inteligentes' de hardware virtual o tradicional utilizadas junto con las STB. De manera ideal, tal sistema se maneja a partir de una instalación sencilla del cabezal de cable de CA del cliente y permite que los derechos se administren de manera continua sobre el dispositivo de presentación heterogéneo. 3) Middleware: el middleware juega una función principal en cualquier sistema de IPTV, y determina la capa de presentación de la mayoría de los servicios . La opción de middleware se determina por el proveedor de servicios seleccionado del televidente y típicamente de una arquitectura de cliente/servidor, el cliente que reside en la STB. Típicamente, el middleware incluye un componente de administración de aplicaciones, un ambiente de ejecución, y la capacidad de acceder a bibliotecas (Interfaces de Programación de Aplicaciones, conocidas como API) para controlar el hardware/OS subyacente.

En términos generales, el middleware conocido de terceros puede categorizarse en dos tipos: i) Middleware de categoría I: middleware que se integra en el Modelo de Objeto de Documento (DOM) de un explorador integrado de una STB. Estos productos utilizan extensiones proporcionadas por vendedores para ese ambiente, en forma de bibliotecas de lenguaje de secuencias de comandos (por ejemplo, bibliotecas de ECMAScript) , para controlar los elementos de administración de medios del servicio y utilizar estándares basados en tecnologías de presentación para presentar sus interfaces de usuario, tales como Lenguaje de Marcación de Hipertexto (HTML) , y Gráficos Vectoriales Escalables (SVG) ; o ii) Middleware de categoría II: middleware que se escribe directamente en la parte superior de las API de bajo nivel (típicamente implementadas en lenguaje tales C o C++) proporcionados por los vendedores de STB para controlar los elementos de administración de medios de servicio y típicamente utilizan tecnologías de presentación de propiedad para presentar sus interfaces de usuario.

Ambos procedimientos sufren del problema que el vendedor de STB proporcionó a las API (tanto ECMAScript y C/C++) no se estandarizan, y por lo tanto, cada vendedor de middleware debe realizar un ejercicio de 'portabilidad' cada vez que una nueva STB se agrega a su portafolio de dispositivos de usuario final soportados.

Otra área problemática que enfrenta los sistemas de IPTV basados en computadora (por ejemplo, pueden ser sistemas de IPTV basados en computadora que no utilizan una STB física) es que la mayoría de los sistemas de IPTV conocidos se diseñan para suministrar contenido de MPEG-2/4 encapsulado de IP en 2 a 4 Mbps a usuarios en redes habilitadas por multidifusión . A la fecha, la falta general de soporte de multidifusión dentro de grandes porciones de las redes disponibles restringe el número de clientes objetivo potenciales. Existen varios factores comerciales y técnicos en existencia, que siguen siendo barreras para una entrega efectiva de estos servicios.

Los usuarios finales de servicios de televisión típicamente se encuentran tranquilos con el mecanismo de suministro subyacente empleado para entregar la imagen a su dispositivo (por ejemplo, Televisión Terrestre Digital (DTTV o DTT) , IPTV, etc.). Sin embargo, se preocupan sobre la calidad del contenido que se desean ver y la facilidad de uso dentro de la cual tienen acceso a ese contenido de calidad óptima.

Por lo tanto, en algunas modalidades descritas con respecto al componente de DVSS, el sistema es capaz de presentar un servicio de alta calidad y paradigma de navegación consistente al televidente, mientras (transparente para el usuario) detecta, selecciona y presenta la programación de mejor calidad posible basándose en la posición actual del dispositivo del televidente dentro de la red (sin importar el soporte de multidifusión) .

Soluciones conocidas intentan solucionar algunas de estas dificultades, aunque típicamente implican gastos considerables a partir del proveedor de servicios, en términos de desarrollo y sobrecargas operacionales , para crear de manera efectiva un mecanismo de distribución paralelo (codificación, encriptación, entrega, integración de middleware, integración de dispositivos, etc.), y típicamente proporcionan una experiencia de visualización diferente (en términos de estilo de presentación y formato, interfaces de navegación, etc.) a partir de lo que el televidente puede esperar de un servicio basado en televisión tradicional.

Además, muchas soluciones propuestas se enfocan en cómo entregar el contenido de IPTV al usuario final, en lugar de cómo procesar y/o presentar ese contenido una vez que se ha recibido en el cliente final, o cómo mejorar/remplazar la tecnología empleada en el cliente final.

Por ejemplo, EP1895777 Al describe un método para proporcionar un servicio de IPTV a un suscriptor, y un elemento de red para ejecutar el método. Esto se logra al introducir un nivel adicional (un nivel de 'entrelazado') en la arquitectura de IPTV de 3 niveles tradicional. Este nivel de entrelazado incluye enrutadores de servicio de IPTV y una red de comunicación, que de este modo permite la provisión de un servicio de IPTV entre diferentes redes que pueden pertenecer a operadores diferentes y/o que se instalan en diferentes países. De este modo, el método y elemento descritos agregan funcionalidad de itinerancia al servicio de IPTV existente.

Sin embargo, el método y elemento descritos en EP1895777 Al no permiten que un suscriptor reciba y despliegue el contenido de IPTV en un dispositivo alternativo, tal como un dispositivo de cómputo que opera un sistema de emulación de STB. De hecho, el método descrito proporciona una arquitectura alternativa para el suministro del contenido de programación al suscriptor y no soluciona los problemas discutidos en lo anterior con respecto a la tecnología empleada en el cliente final.

Similarmente, la WO 2008/045384 A2 describe una arquitectura de transporte de IPTV con encriptación de doble capa y descifrado por volumen. La arquitectura de transporte descrita se diseña para operar de acuerdo con una combinación de televisión tradicional /STB del cliente, y no proporciona un medio para presentar el contenido de programación como un dispositivo alternativo que opera en un sistema de emulación de STB.

Se conocen una serie de sistemas con respecto a la simulación de STB, para el propósito de someter a prueba aspectos restringidos, aislados de entrega de servicio de IPTV. Por ejemplo, la solución descrita en EP 1914940 Al proporciona un aparato de prueba para evaluar la calidad de un servicio de IPTV, y para ubicar y reparar averías. El aparato de prueba accede a la red de IPTV (desde una oficina central) como una simulación de la STB del usuario, recibe y analiza información de canal y contenidos de medio descargados desde la red de IPTV, y después genera los resultados de prueba. Esto hace obvia la necesidad de que un operador ingrese a las instalaciones del usuario y realice la rutina de prueba utilizando aparatos de prueba manual. De este modo, la simulación de STB realizada por la solución descrita se limita de manera que sólo simula la forma en la cual la STB se presenta a sí misma a la red y recibe información de la red. No presenta un sistema de emulación de STB completamente operable que pudiera utilizarse para remplazar la STB y televisión del usuario y presentar el contenido recibido al televidente. De este modo, no proporciona un medio para realizar todas las funciones requeridas y esperadas de una STB física.

Similarmente, la US 2002 / 0026637 Al describe un programa de cómputo que permite a una computadora personal emular las funciones de varias STB para que un video combinado y corriente de contenido mejorada puedan desplegarse y accederse aleatoriamente para asegurar que un esquema deseado se logre con respecto al contenido desplegado. El programa se diseña para facilitar una comprobación rápida y fácil de la calidad de la presentación de contenido, con la modificación en la corriente de contenido combinada que se permite durante las comprobaciones, si se requiere. De este modo, sólo un aspecto de una funcionalidad de STB tradicional se soluciona por la solución descrita, la cual no proporciona un sistema alternativo, completo para su uso en presentar el contenido de IPTV a un usuario final. La solución descrita proporciona un medio para previsualizar video y contenido interactivo por un productor en lugar de presentar un servicio completo a un usuario.

Ni la US 2003 / 0026637 Al ni la EP 1914940 Al solucionan el problema de integrar diferentes formas de productos existentes de middleware por un sistema de emulación de STB. Tampoco incluyen componente de simulación para soportar o emular otras funciones tradicionalmente requeridas tal como acceso condicional y otras funciones de administración de red.

La Figura 3 muestra cómo la arquitectura de IPTV tradicional y los sistemas de TV web duplican las funciones centrales entre sí, y también muestran los diferentes estilos de presentación cuando se despliega contenido para visualizar en los dispositivos finales diferentes (es decir, una televisión más STB física que despliega contenido de IPTV contra un dispositivo de cómputo que despliega contenido de TV web) . En particular, la arquitectura 300 incluye un receptor/descodificador 302 integrado (IRD) que recibe señales de una o más fuentes 304 de difusión, codificadores 306 de duplicado que codifican el contenido de IPTV y el contenido de TV web por separado, encriptadores 308 de duplicado que encriptan el contenido de IPTV y el contenido de TV web por separado, y administradores 310 de encriptacion de duplicado que manejan el acceso a la encriptacion por separado para el contenido 311 de IPTV y el contenido 312 de TV web. Similarmente, la arquitectura 300 puede incluir fuentes 312 a la carta duplicadas para contenido de VOD para el contenido de IPTV y el contenido de TV web. La STB 320 física se comunica con el sistema de cabezal de cable de IPTV en la arquitectura 300 sobre la red por medio del enrutador 330 para presentar contenido de IPTV en una televisión 321. El dispositivo 340 de cómputo (por ejemplo, PC) se comunica con los componentes de duplicación de la arquitectura 300 para presentar el contenido de TV web en una pantalla 341 del dispositivo 340 de cómputo.

Como se muestra en la Figura 3 , los operadores se obligan típicamente a considerar una duplicación casi completa de su infraestructura de televisión cuando deciden tener como objetivo dispositivos tales como las PC con servicios. Generalmente, esto es debido a que los protocolos y tecnologías asociadas con la entrega de TV web, así como los paradigmas de navegación, difieren de aquellos de las implementaciones de IPTV. En gran medida, éste es el resultado de limitaciones tecnológicas de esa selección. Cuando se consideran servicios de TV web, los operadores normalmente se ven obligados a traducir o transcodificar su contenido existente en un formato más 'amigable' con la PC, tal como por ejemplo, formatos de Windows Media y Flash. Entonces, esto requiere el empleo de estrategias alternativas de acceso condicional y administración de derechos digitales (DRM) , y finalmente debe rediseñar toda su capa de UI/presentación para superar la naturaleza sin TV de su dispositivo objetivo. Generalmente, esto conlleva a implementaciones donde el texto fluye alrededor de (no sobre) el video. Las Figuras 1 , 3 y 4 enfatizan el punto al ilustrar el resultado de cada una de las arquitecturas sobre los servicios que pueden suministrarse al usuario final.

La Figura 4 muestra cómo un sistema de emulación de STB de acuerdo con una modalidad, elimina o reduce la duplicación de las funciones centrales mientras proporciona contenido a una televisión mas STB o dispositivo de cómputo que se utiliza junto con un sistema de emulación de STB de acuerdo con una modalidad, y también mantiene el estilo de presentación del contenido para el televidente. En particular, la arquitectura 400 incluye un receptor/descodificador integrado (IRD) 402 que recibe señales de una o más fuentes 304 de difusión, un codificador 406 que codifica el contenido de IPTV, un encriptador 408 que encripta el contenido de IPTV, y un administrador 410 de encriptación que maneja el acceso a la encriptación para el contenido 411 de IPTV. Similarmente, la arquitectura 400 puede incluir fuentes 412 a la carta duplicadas para contenido de VOD para contenido de IPTV. La STB 320 física se comunica con el sistema de cabezal de cable de IPTV en la arquitectura 400 sobre la red por medio del enrutador 330 para presentar el contenido de IPTV en la televisión 321 . El dispositivo 440 de cómputo (por ejemplo, PC) , el cual incluye el cliente 442 de vSTB (también denominado como el sistema de emulación de STB) como se describe en la presente, se comunica con un sistema de cabezal de cable de IPTV en la arquitectura 400 para presentar el contenido de IPTV en un pantalla 441 del dispositivo 440 de cómputo. Como se muestra en la Figura 4 , el sistema de emulación de STB puede eliminar o reducir la duplicación de las funciones centrales mientras proporciona contenido de IPTV a la televisión 321 utilizando la STB 320 física o el dispositivo 340 de cómputo que se utiliza junto con el sistema de emulación de STB de acuerdo con una modalidad. La Figura 4 también muestra cómo el estilo de presentación de contenido de IPTV para el televidente se mantiene, a diferencia del contenido de TV web en la pantalla 341 del dispositivo 340 de cómputo.

La Figura 5 muestra la reducción del esfuerzo y gastos requeridos a nombre del proveedor de servicios cuando se utiliza un sistema de emulación de STB de acuerdo con una modalidad. La Figura 5 muestra una comparación lado por lado de la arquitectura de IPTV como se describe en lo anterior. Como se muestra en la Figura 5 , utilizar el dispositivo 440 de cómputo, el cual incluye el cliente 442 de vSTB, el dispositivo 440 de cómputo que aparece en la red, así como a otros componentes, como si fuera una STB física, mientras el dispositivo 340 de cómputo requiere de aplicación de justo cada aspecto de la arquitectura 100 inicial para soportar un nuevo tipo de dispositivo (por ejemplo, una computadora personal) . La arquitectura 400 reduce gasto y esfuerzo de un proveedor de servicios para proporcionar servicio de IPTV a las STB 320 físicas, puesto que el costo de los dispositivos de cómputo que implementa el cliente 442 de vSTB ya se ha tomado por los suscriptores , como se describe en la presente.

La Figura 6 muestra como la presentación televisual del servicio que utiliza la arquitectura 400 se conserva sin importar si el contenido de IPTV se proporciona a la STB 320 física o al dispositivo 440 de cómputo, lo que se utilice para presentar el contenido de IPTV de acuerdo con una modalidad. En particular, un proveedor 600 puede utilizar un sistema 601 de cabezal de cable de IPTV sencillo para suministrar el contenido de IPTV a suscriptores a pesar de que el contenido de IPTV se presente en la televisión 320 utilizando la STB 321 física o en la pantalla 441 del dispositivo 440 de cómputo. En cualquier caso, la presentación de contenido de IPTV de la experiencia de usuario final es la misma o similar.

Las modalidades descritas en la presente pueden proporcionar un medio para recibir servicios de IPTV en un dispositivo de usuario, y presentar el contenido de IPTV en el dispositivo, de manera que el televidente disfrute de continuidad de servicio de programación sin importar su ubicación física o la plataforma de hardware/software subyacente del dispositivo. En una modalidad, el dispositivo del usuario actúa como alternativa a una televisión tradicional y combinación de STB. En una modalidad típica, el dispositivo es una computadora personal o tipo laptop, aunque otros dispositivos electrónicos pueden utilizarse. Las modalidades descritas aquí pueden proporcionar un sistema y método para la simulación de una STB física, y para permitir que componentes de cómputo estándar reflejen e imiten sus contrapartes televisuales (por ejemplo, monitor, CPU, disco-> TV, STB, y VCR) . Las modalidades descritas aquí pueden integrarse fácilmente con tecnologías de IPTV conocidas, por ejemplo, la STB virtual puede presentarse a sí misma en el sistema de cabezal de cable de IPTV como si fuera una STB física y puede ejecutar el componente de middleware que se ha diseñado para su ejecución en la STB física. Las modalidades descritas aquí pueden mantener de manera sustancial la misma experiencia de visualizacion que aquella experimentada por el usuario cuando recibe y visualiza servicios televisuales mediante tecnologías tradicionales (es decir, televisión más STB física) o alternativas. En otras palabras, el contenido, paradigma de navegación, presentación y calidad de servicio pueden ser sustancialmente las mismas que aquellas disfrutadas por usuarios de sistemas de IPTV tradicionales (es decir, una STB física que se utiliza junto con un equipo de televisión) . Por ejemplo, cuando se visualiza el contenido televisual, los estilos de navegación y presentación se mantienen, y el formato del contenido es el mismo o sustancialmente el mismo que aquel experimentado por un televidente que utiliza una STB física y equipo de televisión.

Las modalidades descritas aquí proporcionan medio para emulación de una STB tradicional (física) de manera que un ambiente de STB virtual se crea dentro del dispositivo de cómputo del televidente. Además del ambiente de STB virtual, se proporciona un conjunto de las API centrales que actúan como conductos en el middleware en un tercero que se ejecuta dentro del ambiente virtual (es decir, STB emulada) . Las solicitudes de servicio de las API realizadas por aplicaciones externas exponen la funcionalidad del middleware a esas aplicaciones. De este modo, el sistema de emulación de STB opera junto con el conjunto de las API centrales para permitir el mantenimiento de conectividad entre el middleware de categoría I y II estándar y el proveedor del servicio de IPTV. En una modalidad, para facilitar la administración a partir de la perspectiva del operador de red, se necesita un acceso directo al middleware integrado por el proveedor de servicios. Si el middleware pertenece a la categoría I, esto se logra por conectividad de DOM. Sin embargo, si el middleware pertenece a la categoría II entonces la conectividad se logra mediante las API del middleware que se conectan al conjunto de las API centrales. De este modo, el ambiente emulado como se describe en la presente es agnóstico a la conectividad de middleware de un tercero.

En una modalidad, se logra la emulación por un sistema basado en software que crea un ambiente de STB virtual para otro software (conocido) para interactuar, de manera que el sistema de emulación que se ejecuta en el dispositivo de cómputo, se representa a si mismo en la red (y proveedor de servicios) , como si fuera una STB física conectada a una televisión. Las modalidades descritas aquí pueden ser un recurso eficiente (especialmente con respecto al uso y memoria de CPU) .

En una modalidad, el middleware de un tercero, adecuado para el proveedor de servicios seleccionado por el televidente, se integra en el sistema de emulación. El sistema de emulación actúa como un envolvente alrededor del middleware de un tercero. En una modalidad, un sistema de emulación de STB se instala en el dispositivo del usuario final (es decir televidente) , y el sistema de emulación que encapsula el middleware de un tercero el cual es adecuado y compatible con el sistema de entrega proporcionado desplegado por el proveedor de servicios de IPTV seleccionado por el usuario. En una modalidad, el sistema de emulación de STB proporciona un ambiente de emulación de STB basado en API dentro del cual, el middleware de un tercero conocido (ambas categorías I y II) es capaz de ejecutarse. La ejecución y rendimiento del middleware se preserva en su forma tradicional, y el middleware de un tercero interactúa con el ambiente de STB virtual como si fuera con una STB tradicional que opera dentro de un sistema de IPTV tradicional. En esta modalidad, ninguna modificación de middleware de vendedor se requiere. Estas modalidades permiten al televidente visualizar contenido televisual en un dispositivo electrónico tal como una computadora personal o tipo laptop, u otro dispositivo electrónico al proporcionar un ambiente de STB virtual dentro del dispositivo, el ambiente virtual tiene capacidad de interconectarse e interactuar con el middleware de terceros conocidos para que todos los aspectos de la funcionalidad, rendimiento y formatos de presentación sean sustancialmente idénticos a aquellos disfrutados por usuarios de una configuración de IPTV tradicional (es decir, STB más V) .

Debe observarse que una modalidad típica del sistema de emulación descrita en la presente proporciona por lo menos dos conjuntos de distintas API: 1) el conjunto de las API que se integra en el DOM del explorador de propiedad, que proporciona emulación genuina de API de STB. Estas se escriben en un lenguaje de secuencia de comandos, tal como, por ejemplo, ECMAScript, para permitir su integración con el explorador integrado que forma un subcomponente del componente de emulación de STB; y 2) el conjunto de las API que se proporciona para permitir la integración de middleware de un vendedor tercero. Esto se escribe en un lenguaje, tal como por ejemplo, C o C++, y proporciona una interfaz extensible entre el middleware de categoría II de un tercero y las características de STB subyacentes. El conjunto de las API son los enlaces fundamentales en el middleware encapsulado o anidado en el ambiente emulado. El conjunto de las API virtualiza las funciones centrales y el hardware de la STB tradicional (física) como se enlista en lo anterior.

La Figura 7 muestra los componentes primarios del sistema 700 de emulación de STB para presentar contenido de IPTV a un usuario en un dispositivo electrónico de acuerdo con una modalidad de la presente invención. En esta modalidad, las interfaces de programación de aplicación (las API) 712-726 proporcionan las interfaces entre el OS 701 y el ambiente 702 emulado de vSTB en el cual se ejecuta el componente de middleware. El sistema 700 de emulación incluye un componente de middleware (no mostrado en la Figura 7) el cual se ejecuta en el ambiente 702 de ejecución de aplicación de VSTB, y múltiples componentes de emulación de STB (también denominados como componentes de administración) 704-710, los cuales se disponen y configuran para emular las capacidades de una STB física. La Figura 7 muestra cómo múltiples interfaces 712-726 se proporcionan para permitir comunicación entre el OS 701 y el componente de middleware (categoría I o II) que se integra en el ambiente 702 emulado. Las interfaces actúan como conductos para comunicación entre el OS 701 y los componentes 704-710 del ambiente 702 de STB emulado. Como tales, las interfaces 712-726 proporcionan los enlaces fundamentales entre el componente de middleware de un tercero e integrado en el ambiente 702 emulado.

Los componentes de emulación de la modalidad representada incluyen un administrador 704 de presentación, un administrador 706 de codificación, un administrador 708 de acceso condicional (CA) , y un componente 710 de DVSS. Alternativamente, otras interfaces pueden incluirse para extender el conjunto de capacidades o, alternativamente algunas interfaces descritas en lo siguiente pueden no requerirse en modalidades alternativas.

El administrador 704 de presentación se comunica con el sistema operativo 701 central tal como con los controladores 730 de audio y video para controlar la presentación de contenido de IPTV y una interfaz de usuario (UI) en la pantalla 441 del dispositivo 440 de cómputo. El administrador 704 de presentación renueva la pantalla 441. La interfaz 712 de gráficos proporciona el componente de middleware con el ambiente 702 de STB emulado con un mecanismo para informar al subsistema de gráficos subyacente (por ejemplo, controladores 730 de audio y video y administrador 704 de presentación) de que algo ha cambiado y que el sistema de gráficos subyacente ahora debe actualizarse. La interfaz 714 de MUX puede utilizarse para permitir que el componente de middleware controle la UI y las capacidades del estado de video (por ejemplo, que incluyen superposición de imágenes (chroma keying) y mezcla de imágenes (alpha blending) ) .

El administrador 706 de códec administra la codificación-descodificación de contenido de IPTV (por ejemplo, corriente o señal de datos digital) , por ejemplo, utilizando el Códec I 701 y el Códec II 703. En esta modalidad, el sistema puede tener uno o más codees diferentes que pueden soportar varios tipos de formatos tal como, MPEG-1, PEG-2, MPEG-4, MV, Flash, VC1, Flash, o similares como se representa por los Codees I y II 701 y 702. Estos codees 701 y 702 pueden operar de manera simultánea, de manera concurrente, o de manera individual. En una modalidad, los codees son codees de software. En otra modalidad, el administrador 706 de códec se puede administrar codificación y/o descodificación utilizando codees de hardware y los codees I y II 701 y 702 representan las interfaces a los codees de hardware.

El administrador 708 de acceso condicional es un mecanismo que controla y maneja la capacidad del usuario para acceder al contenido de IPTV (es decir, contenido de programación) o servicios proporcionados por un proveedor de red. En la modalidad representada, el administrador 708 de acceso condicional interactúa dentro de uno o más módulos de CA o mecanismos proporcionados por uno o más vendedores diferentes, como se representa por CA I-IV 705-711. Por ejemplo, diferentes tipos de vendedores pueden utilizar diferentes mecanismos de CA, y CA I-IV 705-711 representan que el sistema puede soportar varios tipos de módulos de CA o mecanismo. En algunas modalidades, los suscriptores podrán optar por niveles variados de servicio, y de este modo el acceso al contenido se controla mediante el administrador 708 de acceso condicional. A diferencia de la STB física que utiliza una 'tarjeta inteligente' de hardware tradicional, las modalidades descritas en la presente pueden utilizar una 'tarjeta inteligente' virtual. De manera ideal, tal sistema se maneja a partir de una instalación sencilla del sistema de cabezal de cable de CA del cliente y permite que los derechos se administren de manera continua sobre dispositivos de presentación heterogéneos. El administrador 708 de CA se comunica con el sistema 701 operativo central, tal como con la red y los controladores 732 de eventos, para comunicar las claves 713 hasta/desde el sistema de cabezal de cable de CA para controlar el acceso al contenido de IPTV. El administrador 708 de CA es un mecanismo fácil de suministrar y administrar el contenido de IPTV a partir de la perspectiva de un proveedor de red. Alternativamente, otros mecanismos de CA pueden utilizarse de manera que un proveedor de servicios es capaz de controlar y administrar la capacidad del usuario para tener acceso al contenido de programación.

La interfaz 716 de CA puede utilizarse para permitir que el componente de middleware inicie el registro de los subsistemas de acceso condicional de un tercero y para interactuar con las características proporcionadas por los proveedores. La interfaz 718 de medios puede utilizarse para permitir que el componente de middleware controle la solicitud, la decodificación y presentación de las corrientes de datos (por ejemplo, contenido IPTV) . Tales corrientes de datos podrían contener información de audio, video o datos. En una modalidad, la interfaz 718 de los medios sustrae del componente de middleware de los protocolos de transporte subyacente y los codees requeridos para presentar el contenido y lo simplifica en un número de comandos simples de "reproducir" .

El componente 710 de DVSS determina y adquiere la programación de calidad óptima posible basándose en la posición actual del dispositivo de usuario dentro de la red, por ejemplo, al recibir el contenido de IPTV en uno de los diferentes protocolos, por ejemplo, RTSP, IGMP, Difusión de Video Digital (DVB) , u otros, tal como de igual a igual (P2P) , corrientes continuas por ejemplo, corrientes continuas (corrientes continuas de HTTP) descritas en lo siguiente. De manera fundamental, el componente 710 de DVSS soluciona la necesidad antes mencionada para liberar al televidente de la carga de decidir que mecanismo subyacente se requiere para recibir el contenido televisual deseado. El televidente, típicamente, no se preocupa con la selección entre el RTSP 715, IG P 717, DVB-S/C/T 719 u otros 721 (por ejemplo, P2P, corrientes continuas HTTP) . De este modo, la interfaz 718 de medios da servicio a solicitudes del componente 710 de DVSS del ambiente 702 de vSTB, de manera que el televidente es capaz de seleccionar simplemente el contenido que desea ver, los aspectos técnicos del mecanismo del suministro óptimo que se maneja 'detrás de cámaras' sin que el usuario seleccione manualmente el mecanismo de suministro. El componente 710 de DVSS tiene la capacidad de tomar decisiones de acuerdo con el ambiente de red sobre cómo originar y suministrar mejor el contenido solicitado. En una modalidad, esta sustracción se continúa con respecto a los formatos del recipiente y los tipos de medios, que son capaces de descodificar de manera continua múltiples formatos tales como MPEG-1, MPEG-2, MPEG-4, WMV, Flash, etc. Alternativamente, otros componentes pueden utilizarse para proporcionar un sistema de IPTV para recibir y presentar servicios de IPTV en el dispositivo de un usuario de manera que DVSS dinámico se logra, donde el sistema es capaz de determinar y adquirir la programación de calidad óptima posible de acuerdo con la posición actual del dispositivo de usuario dentro de la red. Esta selección de fuente puede lograrse de manera dinámica, sin necesidad de entrada explícita del usuario. Alternativamente, la selección de fuente puede lograrse con poca o mínima entrada del usuario, tal como la preferencia del usuario.

La ínterfaz 720 de eventos es la interfaz principal que existe entre la red y los controladores 732 de eventos del OS 701 para teclado, ratón y dispositivos de control remoto para pasar sus entradas/acciones sobre componente de middleware dentro del ambiente 702 de STB emulada. La interfaz 720 de eventos puede comunicarse con la red y los controladores 732 de eventos utilizando una interfaz 723 de manejo de claves de Control Remoto (RC) y la interfaz 725 de teclado/ratón (Kb/M) . Alternativamente, la interfaz 720 de eventos puede interconectarse con otros dispositivos de entrada .

La interfaz 722 de red puede utilizarse para soportar el suministro de red sustraída requerido por la interfaz 718 de medios. La interfaz 722 de red proporciona módulos para soportar los mecanismos de suministro de video estándar: IGMP se proporciona para manejar contenido de difusión basado en IP de multidifusión, un proxy de RTSP inteligente se proporciona para comunicar el dialecto de RTSP adecuado con los servidores basados en RFC2326. Las interfaces 727 de HTTP y los HTTP también se proporcionan para comunicaciones basadas en UE 2.0.

La interfaz 724 de ajustes de sistema puede utilizarse para permitir que el operador configure el ambiente 702 virtual de acuerdo con sus necesidades y sin tener que hacer cambios en el componente de emulación de STB mismo (por ejemplo, 704-710) . En una modalidad, el sistema 700 de emulación de STB puede configurarse, o diseñarse, a los requerimientos del televidente (o proveedor de servicios) mediante el uso de archivos de configuración, los cuales almacena ajustes que permiten y facilitan la administración y control de comportamiento del sistema 700 de emulación STB.

La interfaz 726 de almacenamiento persistente puede utilizarse para proporcionar un mecanismo para que el componente de middleware que se ejecuta dentro del ambiente 702 emulado almacene contenido y los metadatos de contenido en el sistema local para permitir que tales características como videograbadora personal (PVR) y modos 'fuera de línea' se implementen. Adicionalmente, esto puede facilitar la operación de algunos productos de middleware que requieren esta característica para guardar en memoria caché los metadatos de la guía de programación electrónica (EPG) suministrada en el carrusel. La interfaz 724 de ajustes de sistema y la interfaz 726 de almacenamiento persistente se comunican con las unidades 734 de disco y de memoria del OS 701.

En una modalidad, el sistema 700 de emulación de STB se implementa en un dispositivo de cómputo que se configura y dispone para que el OS 701 sea capaz de ejecutarse del dispositivo de cómputo, y se conecte a una red de manera que los datos puedan recibirse desde fuentes externas sobre la red y/o enviarse a las fuentes externas sobre la red. En otra modalidad, el dispositivo de cómputo se configura y dispone para incluir uno o más componentes de hardware tal como aquellos incluidos en un sistema de cómputo personal típico/tipo laptop. Tales componentes de hardware pueden incluir, pero son se limitan a: i) un monitor ('pantalla') para visualizar información visual y contenido de programación; ii) altavoces para presentar sonidos y contenido de audio; iii) una unidad de disco duro para grabar contenido de programación y/u otros datos.

En una modalidad, el sistema 700 de emulación de STB proporciona un ambiente 702 de aplicación de STB virtual, el cual no sólo emula las capacidades de hardware subyacentes de una STB física (por ejemplo, escalado de video, posición de video, superposición de imágenes (chroma keying) , mezcla de imágenes (alpha blending) , esquema de UI, manejo de claves de Control Remoto, etc.), sino también proporciona el mismo el ambiente de software en términos de las API disponibles y bibliotecas de manera que el middleware de un tercero es capaz de ejecutarse en este ambiente sin modificación, aunque el middleware se diseñó originalmente para su uso con una STB física (y equipo de televisión) en lugar de con dispositivo de cómputo que opera el sistema 700 de emulación de STB.

En otra modalidad, el sistema 700 de emulación de STB proporciona un sistema de IPTV para recibir y presentar servicios de IPTV en un dispositivo de usuario de manera que la DVSS se logra, en donde el sistema es capaz de determinar y adquirir la programación de calidad óptima posible basándose en la posición actual del dispositivo de un usuario dentro de la red. Esta selección de fuente puede lograrse de manera dinámica, sin la necesidad de entrada explícita del usuario, o alternativamente, con la entrada de un usuario.

Las modalidades descritas en la presente también pueden proporcionar un medio para recibir y presentar servicio de IPTV de manera que el middleware de categoría I o categoría II de un tercero (descrito en lo siguiente) diseñado para su ejecución para una STB física, puede ejecutarse en una forma usual y proporcionar la misma funcionalidad en el dispositivo de cómputo del televidente sin ninguna alteración o modificación, aunque se diseñó originalmente para su uso con una STB física en lugar de un dispositivo de cómputo. La funcionalidad mantenida incluirá típicamente la capacidad de realizar presentación de capas de presentación, en mezcla de video y control de multimedia, y la proporción de las UI .

La Figura 8 muestra una modalidad de un sistema 800 de emulación de STB que se dispone y configura para su uso con la middleware 802 de categoría II basado en API . El sistema 800 de emulación de STB es similar al sistema 700 de emulación de STB como se observa por etiquetas de referencia similares excepto que el componente de middleware específicamente es el middleware 802 de categoría II. Como se describe en lo anterior, el middleware 802 de categoría II puede escribirse directamente en la parte superior de las API de bajo nivel (típicamente implementadas en lenguajes tales como C o C++) proporcionadas por los vendedores de STB para controlar los elementos de administración de medios (por ejemplo, componentes 704-710 ) del servicio y típicamente utilizará las tecnologías de presentación basadas en propiedad para presentar sus interfaces de usuario (las UI) . La Figura 8 muestra como las API 712 -726 de interfaces centrales se conectan directamente a las API proporcionadas por el middleware 802 de categoría II. De este modo, el middleware 802 de categoría II es capaz de operar dentro del ambiente 712 emulado sin ninguna alteración o modificación, aunque se diseñó originalmente para su uso con una STB física en lugar de un dispositivo de cómputo que opera el sistema 800 de emulación de STB.

La Figura 9 muestra una modalidad de un sistema 900 de emulación de STB que se dispone y configura para su uso con el middleware de categoría I integrado en el explorador.

El sistema 900 de emulación de STB, es similar al sistema 700 de emulación de STB, como se observa por las etiquetas de referencia similares, excepto que el componente de middleware es específicamente el middleware 902 de categoría I. Como se describe en lo anterior, el middleware 902 de categoría I se integra dentro del DOM de un explorador 906 incorporado en la STB, tal como el explorador web de propiedad. El middleware 902 de categoría I puede escribirse en forma de bibliotecas de secuencias de comandos (por ejemplo, bibliotecas ECMAScript) , para controlar los elementos de administración de medios (por ejemplo, componentes 704-710) del servicio y utilizar tecnologías de presentación basados en estándares para presentar sus interfaces de usuario (las IU) , tales como HTML y SVG. La Figura 9 muestra cómo las interfaces centrales (las API) 712-726 (por ejemplo, interfaz de gráficos, interfaz de eventos, etc.) se conectan al explorador 906 integrado, o alternativamente se integran con el explorador 906 integrado. En una modalidad, el middleware 902 de categoría I se conecta al explorador 906 mediante un componente 904 de emulación de API de STB. En una modalidad, el componente 904 de emulación de API de STB incluye un conjunto de las API de emulación de STB (escrito en ECMAScript) que se inserta en el DOM del explorador 906. El conjunto de las API de emulación de STB emula y/o remplaza las API que tradicionalmente pueden proporcionarse por el vendedor de STB. Toman solicitudes de DOM y las traducen en solicitudes de API. De este modo, el middle are 902 de categoría I es capaz de operar dentro del ambiente 702 emulado sin ninguna alteración o modificación, aunque se diseñó originalmente para su uso con una STB física en lugar de un dispositivo de cómputo que opera el sistema 900 de emulación de STB.

La Figura 10 muestra los componentes centrales del sistema de emulación de STB dispuesto para suministrar el contenido de IPTV en un dispositivo para presentación a un televidente de acuerdo con una modalidad. El sistema 1000 de emulación de STB incluye los siguientes subcomponentes i) un componente 1010 de reproductor; ii) bibliotecas de API 1020 ; iii) un explorador web integrado 1030 ; iv) un componente de administración 1040 . En otra modalidad, el sistema 1000 de emulación de STB además incluye un componente 1050 de DVSS.

En una modalidad, el componente 1010 de reproductor incluye uno o más subcomponentes, tal como la capa 1001 de sustracción de hardware, un componente 1002 de códec de video, un componente 1003 de códec de subtítulo de DVB, un filtro 1004 de PID, y un componente 1005 de códec de audio. Estos componentes se utilizan para representar el video, gráficos y/o texto y para presentar el audio en la pantalla y los altavoces 1072 del equipo 1070 de cliente. Estos componentes también pueden utilizarse para recibir la entrada de los dispositivos 1071 de entrada de usuario, tal como el teclado, ratón, control remoto, y/o similares, para volver a informar los eventos de navegación al explorador 1030 web integrado .

En una modalidad, las bibliotecas 1020 de API se implementan en un lenguaje tal como Javascript, y pueden incluir una pantalla API 1021 de visualizacion, la cual proporciona conectividad con el componente 1010 de reproductor, una API 1022 de AV, la cual proporciona conectividad con un controlador 1051 de DVSS, el cual a su vez se integra con el componente 1050 de DVSS, y una API 1023 de eventos, la cual proporciona soporte para solicitudes hechas por el componente 1040 de administración.

En una modalidad, el explorador 1030 de web integrado realiza la funcionalidad de UI . Las API de JavaScript integradas permiten al explorador 1030 integrarse con varios otros subcomponentes del sistema 1000 de emulación de STB para controlar la interfaz de usuario. Por ejemplo, la API 1020 de visualizacion puede proporcionarse para manejar solicitudes hechas mediante el explorador 1006 y que requiere acción de un sub-componente del componente 1010 reproductor. Similarmente, la API 1022 de AV y la API 1023 de evento pueden proporcionarse para manejar comunicación entre el explorador 1006 con los otros componentes y los subcomponentes del sistema 1000 de emulación de STB.

En una modalidad, el componente 1040 de administración incluye subcomponentes tal como un programa 1041, un componente 1042 de mantenimiento del registro/estadística, un administrador 1043 de licencia para manejar la licencia del sistema 1000 de emulación de STB, un cliente 1044 de TR-135 que permite al dispositivo ser administrado, por ejemplo, por servidores de administración basados en estándares (por ejemplo, servidores de administración basados en TR-069), y un Oyente 1045 de Eventos, el cual interactúa con la API 1023 de eventos proporcionada dentro las bibliotecas 1020 de API de JavaScript. En una modalidad, el componente 1040 de administración permite que un operador de red administre el sistema 1000 de emulación de STB como si fuera un dispositivo de red, tal como un enrutador o una STB física. En una modalidad, el componente de administración se utiliza para desplegar diversos componentes del sistema a muchos televidentes residenciales.

En una modalidad, el componente 1050 de DVSS además incluye subcomponentes tales como (pero no restringidos a) un controlador 1052 de PVR, un cliente 1053 de IGMP, un cliente 1054 de RTSP, y un cliente 1055 de DVB-T. El componente 1050 de DVSS se integra con el controlador 1051 de DVSS el cual a su vez se soporta por la API 1022 de AV contenida dentro de las bibliotecas 1020 de API de Javascript. En una modalidad, el componente 1050 de DVSS también se integra con un componente 1060 de descifrado, el cual se integra con el componente 1010 de reproductor. En una modalidad, el componente 1060 de descifrado recibe señales de una fuente dinámicamente seleccionada, descifra las señales y las pasa al componente 1010 de reproductor para procesamiento adicional y visualización.

La Figura 9 y 10 muestran un explorador web (por ejemplo, 906 ó 1030 ) integrado en una modalidad típica de manera que (cuando utiliza middleware de categoría I) la funcionalidad de UI pueda realizarse por el explorador integrado (por ejemplo, explorador de propiedad) . En una modalidad, el explorador cumple con las interfaces de manera que el middleware de categoría I puede ejecutarse en el dispositivo de cómputo del televidente sin modificación. El componente de emulación de API de STB (por ejemplo, 904 ) se inserta en el DOM del explorador y representa de manera precisa la interfaz que corresponde con la STB física, la cual se emula. En una modalidad, este componente 904 de emulación de API puede insertarse dinámicamente y como tal el explorador es capaz de emular muchas STB de IPTV estándar tal como se ilustra en la Figura 14 . Las API mismas proporcionan un mapeo de lenguaje de Javascript directamente en las API subyacentes (por ejemplo, escritas en C) . El objeto de DOM también es capaz de registrar los eventos de recordatorio de manera que eventos que se presenten dentro del ambiente de hardware puedan volverse informar al Javascript.

En una modalidad, el sistema 1000 de emulación de STB puede configurarse o diseñarse, a los requerimientos del televidente (o proveedor de servicios) mediante el uso de los archivos 1007 de configuración. Los archivos 1007 de configuración pueden almacenar ajustes para permitir facilitar la administración y control del comportamiento del sistema 1000 de emulación de STB.

En la modalidad representada, el sistema 1000 de emulación de STB interactúa con componentes del equipo 1070 de cliente. En una modalidad, el equipo 1070 de cliente incluye dispositivos 1071 de entrada de usuario, tales como teclado, ratón, control remoto, y/o similares, pantalla y altavoces 1072, un sistema operativo 1073 (por ejemplo, OS basado en Windows, OS basado en Mac, OS basado en Linux, OS basado en Unix, etc.) El hardware del equipo 1070 de cliente, tal como los dispositivos 1071 de entrada del usuario y la pantalla y los altavoces 1072, se comunican con la capa 1001 de sustracción de hardware del componente 1010 de reproductor. El equipo 1070 del cliente además incluye una interfaz 1074 de red, tal como una tarjeta de interfaz de red, la cual se comunica con la infraestructura 1080 de cabezal de cable (por ejemplo, sistema de cabezal de cable de IPTV como se describió anteriormente) . La infraestructura 1080 de cabezal de cable puede incluir un servidor 1081 de autorización de DRM, un propagador 1082 de multidifusión, un servidor 1023 de RTSP, un servidor 1084 de middleware de IPTV, y un servidor 1085 de licencia, los cuales cada uno se comunica con el sistema 1000 de emulación de STB mediante la interfaz 1074 de red. El servidor 1081 de autorización de DRM puede ser responsable de la autenticación del dispositivo del cliente y de realizar intercambios de claves seguras con el dispositivo de cliente. El propagador 1082 de muítidifusión puede ser la fase de salida de un DVB al Puerto de Enlace de IP. El componente suministra datagramas de UDP a la red los cuales encapsulan los datos de video, por ejemplo, los datos de video MPEG. El servidor 1023 de RTSP puede ser un servidor en cumplimiento con RFC 2326 controlado por el dispositivo de cliente para lograr la funcionalidad de VoD. El servidor 1084 de middleware IPTV puede ser responsable de orquestar la experiencia de usuario, así como los servicios basados en transacción, tal como por ejemplo, pagos de VoD y Eventos de Pago por Evento (PPV) . El servidor 1085 de licencia puede ser responsable del control de versión del software de vSTB desplegado. Los operadores pueden sugerir actualizaciones al usuario, obligar a realizar actualizaciones para el usuario, y/o revocar el uso del producto todo junto. El equipo 1070 de cliente también puede soportar varios protocolos, tales como los HTTP 1075 , los cuales pueden utilizarse para comunicarse con el componente 1040 de administración, USB-DVB 1076, el cual puede utilizarse para comunicarse con el componente 1050 de DVSS (por ejemplo, cliente 1055 de DVB-T) , y Plug and Play universal (UPnP) 1077, el cual puede configurarse para comunicarse con el componente 1050 de DVSS (por ejemplo, controlador 1052 de PVR) y otros dispositivos 1090 de red, tal como almacén 1091 remoto. El equipo 1070 de cliente también puede incluir el almacén 1078 local.

Como se establece previamente, los televidentes del contenido de programación de IPTV generalmente no se preocupan por los mecanismos de suministros subyacentes utilizados para proporcionar su contenido de visualización. Sin embargo, si cuidan la calidad del contenido, y la facilidad con la cual pueden acceder a sus programas deseados. Como tal, modalidades del componente 1050 de DVSS pueden utilizarse para presentar al televidente una experiencia de visualización consistente (por ejemplo, paradigma de navegación consistente) mientras, entre bastidores, determina y adquiere la programación de mejor calidad posible de acuerdo con la posición actual del dispositivo de cliente dentro de la red. El componente 1050 de DVSS puede utilizarse para conmutar entre fuentes de las cuales puede recibir contenidos de medios, tal como al recibir contenidos de IPTV utilizando IGMP, o recibir el contenido de medios utilizando diferentes protocolos, por ejemplo, RTSP, Difusión de video digital (DVB) , u otros, tal como de igual a igual (P2P) , o corrientes continuas (por ejemplo, corrientes continuas de HTTP) . En otra modalidad, el sistema 1000 de emulación de STB puede no incluir el componente 1050 de DVSS y puede comunicarse sólo a través de la red cerrada utilizando IGMP, por ejemplo.

Al utilizar el componente 1050 de DVSS, el sistema 1000 de emulación de STB puede proporcionar una experiencia sencilla de calidad óptima en cualquier red, sin importar si la red en la cual el dispositivo de cliente se ubica, es una red de suministro habilitada para multidifusión en una modalidad, el uso del componente 1050 de DVSS elimina el requerimiento de utilizar una red cerrada para el suministro de la IPTV al dispositivo de cliente cuando el dispositivo de cliente no se ubica dentro de la red cerrada. En otra modalidad la disposición del componente 1050 de DVSS elimina la necesidad de una red cerrada, y permite al dispositivo de cliente recibir alimentaciones de difusión basadas en DVB 'regulares' (típicamente mediante un dispositivo de DVB-T basado en USB) y de este modo no es obligatorio que los paquetes de vídeo recibidos mediante la red se encapsulen en IP.

El componente 1050 de DVSS puede proporcionar una experiencia de visualización consistente, utilizando cualquier red disponible, mientras mantiene la calidad óptima de servicio. En una modalidad, el componente 1050 de DVSS puede determinar que el dispositivo de cliente puede recibir el contenido de medios a través de una red cerrada que soporta, por ejemplo, IGMP o a través de una red abierta que soporta HTTP, por ejemplo. El componente 1050 de DVSS puede determinar qué mecanismo de suministro utilizar para proporcionar al usuario la programación de mejor calidad disponible. Por ejemplo, el componente 1050 de DVSS puede detectar que se ubica dentro de una red de suministro basado en P2P o en una red de suministro basado en HTTP (por ejemplo, CDN) , y el componente 1050 de DVSS puede recuperar el contenido de medios sobre uno de estos dispositivos adicionales de redes, en lugar de a través de la red cerrada. Pueden existir otros escenarios en donde el componente 1050 de DVSS detecta múltiples redes para suministrar el contenido de medios, y el componente DVSS detecta cuál de estas fuentes puede proporcionar la más alta calidad al televidente sin importar el protocolo de suministro seleccionado (por ejemplo, IGMP, HTTP, o similares) . Debe observarse que estas modalidades permiten que el sistema 1000 de emulación de STB recupere posiblemente el mismo conjunto de canales sobre un mecanismo de suministro diferente cuando se ubica dentro de ciertos ámbitos de red.

Para DVSS, el componente 1050 de DVSS necesita saber cómo determinar en qué red se encuentra a sí mismo cómo emitir la solicitud adecuadamente formada para suministrar el contenido de medio solicitada al televidente. La funcionalidad del componente 1050 de DVSS puede descomponerse en un número de áreas técnicas principales: 1) Conocimiento de red dinámica; y 2) Direccionamiento y origen dinámicos. Para el conocimiento de red dinámica, el componente 1050 de DVSS necesita estar al tanto del ambiente en el cual se encuentra a sí mismo. En una modalidad, el componente 1050 de DVSS tiene la capacidad de detectar la capacidad de una red para suministrar tráfico de multidifusión y, si es así, en qué índice de bits. El cálculo de índice de bits también debe tomar en cuenta la posibilidad de dos dispositivos (o más) que intentan originar contenido sobre la misma línea de DSL. Existe un número de formas para determinar la capacidad de red, por ejemplo, al emitir simplemente una solicitud de IGMP que no es suficiente para determinar la falta de soporte de multidifusión. Habiendo determinado el ambiente de red, el direccionamiento y origen dinámico implican que los metadatos recolectados en el cabezal de cable no deben multiplicarse basándose en el número de mecanismos de suministro disponibles para nosotros. En una modalidad, el componente 1050 de DVSS selecciona las sintaxis de URI adecuada para solicitar el contenido de medios. Seleccionar la sintaxis de URI adecuada también puede realizarse en un número de formas, por ejemplo, en una modalidad, el componente 1050 de DVSS utiliza un esquema de direccionamiento consistente para solicitar al contenido de medios desde diferentes fuentes: Multidifusión = igmp: //192.168.357 : 5000 Sin multidifusión =move: //movenetworks . com/ 192/ 168/357/ oday. qvt En otra modalidad, un procedimiento más simple puede utilizar un identificador común para el contenido y después permitir que el cliente determine el mecanismo de suministro adecuado. Por ejemplo, un activo de canal típicamente se crea para que el Canal 1 al asociarlo con un URL en forma de IGMP: //xxx. xx. xxx. xxx: 5000. Esto es desafortunado, ya que implica enérgicamente que una red de multidifusión se encuentre disponible (por ejemplo, IGMP) . En otra modalidad, el dispositivo de cliente simplemente puede ignorar el URL y utilizar un nombre único de canal con una clave para comunicarse con los otros receptores tales como P2P, DTT, o HTTP. Alternativamente, otros mecanismos pueden utilizarse para solicitar el contenido de diversas fuentes.

En otra modalidad, el componente 1050 de DVSS proporciona la capacidad de emitir las solicitudes adecuadas independientes de la información basada en URI original; tal vez, esto podría, ser de los dispositivos de DVB-T basados en USB de multidifusión u otras tecnologías de transmisión continúa tales como corrientes continuas P2P o HTTP.

La Figura 11 muestra un esquema detallado de un componente de DVSS para realizar selección de fuente dinámica de acuerdo con una modalidad. En esta modalidad, la arquitectura de cabezal de cable incluye un receptor/descodificador integrado y codificador/encapsulador de IP 1102 similar a aquellos descritos en lo anterior que reciben contenido de medios de las fuentes 1104 de difusión. La arquitectura de cabezal de cable también incluye un encriptador 1105 de IP que encripta el contenido de medios en el contenido de IPTV para el suministro sobre la red 1110 de suministro habilitada para multidifusión. En esta modalidad, cuando el componente 1050 de DVSS solicita el contenido de IPTV sobre la red 1110 de suministro habilitada para multidifusión, el contenido de IPTV se suministra utilizando el protocolo de IGMP y se recibe por la STB 1100 mediante la pila 1151 de IGMP. En una modalidad, la STB 1100 es una STB física. En otra modalidad, la STB 1100 es la STB virtual como se describe en la presente. En esta modalidad la arquitectura de cabezal de cable incluye un bloque 1130 de ingesta de P2P o HTTP y de segmentación de archivos que recibe contenido de medios del receptor-descodificador integrado y el encapsulador codificador 1102 de IP, así como el contenido de IPTV del encriptador 1106 de IP para el suministro de contenido de medios sobre la red 1120 del suministro de P2P o HTTP. En esta modalidad, cuando el componente 1050 de DVSS solicita el contenido de medios sobre una red de suministro habilitada sin multidifusión, tal como la red 1120 de suministro de HTTP, el contenido de medios se suministra utilizando protocolo de P2P o HTTP y se recibe por la STB 1100 mediante el cliente 1152 de P2P o HTTP. Debe observarse que aunque se ilustra como el mismo bloque, la arquitectura de cabezal de cable puede incluir componentes separados para preparar y suministrar el contenido de medios mediante una red de suministro de HTTP y la red de suministro de P2P.

En la modalidad representada, la STB 1100 también se configura para recibir contenido de multimedia utilizando un sistema de suministro basado sin IPTV (por ejemplo, difusiones de TV por aire) , tal como desde una fuente 1106 de difusión. En esta modalidad, cuando el componente 1050 de DVSS recibe el contenido de medios sobre el sistema de suministro no basado en IPTV mediante el cliente de DTT. La STB 1100 recibe el contenido de medios por aire utilizando un dispositivo 1154 de DVB-T basado en USB, por ejemplo. Alternativamente, la STB 1100 recibe el contenido de medios por aire utilizando otros mecanismos que pueden apreciarse por alguien con experiencia ordinaria en la técnica que tiene el beneficio de esta descripción.

En una modalidad, cuando es utiliza la red 1120 de suministro de HTTP, la STB 1100 puede solicitar el contenido de medios utilizando el concepto de corrientes continuas. El término "corriente continua", como se utiliza en la presente, se refiere a una sola representación codificada de una porción del video. Cada corriente continua puede ser una porción individual del contenido de medios , y puede encapsularse como objeto de medios independiente, que permite a la corriente continua guardarse en memoria caché de manera individual y poderse reproducir de manera independiente por un reproductor de medios. En una modalidad, la porción individual se almacena en un archivo que puede solicitarse de manera individual y puede guardarse en memoria caché, por ejemplo, utilizando una red de suministro de contenido (CDN) . Cada uno de estos archivos individuales puede reproducirse de manera independiente o individual, significando que el archivo puede reproducirse sin necesidad de un archivo previo o subsiguiente en el contenido de medios. En una modalidad, una corriente continua es un archivo estático que puede atenderse por un servidor no especializado, en lugar de un servidor de medios especializado. En una modalidad, el contenido en una corriente continua puede tener una duración predeterminada de tiempo de reproducción. La duración predeterminada de tiempo puede encontrarse en el margen de entre aproximadamente 0.1 y 5.0 segundos, por ejemplo. El contenido en la corriente continua puede tener un índice de tiempo único con respecto al inicio del contenido guardado en la corriente. Alternativamente, las corrientes continuas pueden dividirse de acuerdo con un tamaño de archivo, en lugar de un índice de tiempo. El término "corriente", como se utiliza en la presente, puede referirse a una colección de corrientes continuas del video codificado por el mismo perfil de calidad de video, por ejemplo, porciones del video que se han codificado en el mismo índice de video. Por ejemplo, el contenido de medios de un programa de televisión puede codificarse de acuerdo con diez diferentes perfiles de calidad de video, una corriente continua para cada porción del contenido de medios por perfil. Las corrientes continuas pueden almacenarse como archivos separados en cualquier de uno o más de los servidores web, o las memorias caché del proxy u otros dispositivos dentro de una CDN. Los archivos separados (por ejemplo, corrientes continuas) pueden solicitarse desde el servidor web utilizando HTTP. Utilizando un protocolo estándar, tal como HTTP, elimina la necesidad de administradores de red para configurar cortafuegos para reconocer y pasar a través del tráfico de red para un nuevo protocolo especializado, tal como un Protocolo de Transmisión Continua en Tiempo Real (RTSP) . Adicionalmente, puesto que el reproductor de medios inicia la solicitud, un servidor web, por ejemplo, sólo se requiere para recuperar y dar servicio a la corriente continua solicitada, no a toda la corriente. El reproductor de medios también puede recuperar corrientes continuas de más de uno de los servidores web. Estos servidores web pueden tener inteligencia secundaria sin servidor especializado para recuperar las porciones solicitadas. En otra modalidad, las corrientes continuas se almacenan como archivos separados en un servidor de memoria caché de un operador de infraestructura de red (por ejemplo, un ISP) , u otros componentes de una CDN. Aunque algunas de las presentes modalidades describen el uso de corrientes continuas, las modalidades descritas aquí no se limitan al uso en sistemas de cómputo que utilizan corrientes continuas, sino también pueden implementarse en otros sistemas que utilizan otras técnicas para suministrar el contenido de medios en vivo sobre la Internet. Por ejemplo, en otra modalidad, el contenido de medios se almacena en un solo archivo que divide en porciones que pueden guardarse en memoria caché en la CDN utilizando solicitudes de margen de HTTP.

En la modalidad representada, la arquitectura de cabezal de cable también incluye un sistema 1140 de administración de contenido, una plataforma 1142 de IPTV, y un sistema 1144 de Contabilidad, Clasificación y Facturación (ARB) . El sistema 1140 de administración de contenido es un depósito central que proporciona el enlace entre la corriente física que llega para descodificación, su representación abstracta dentro del middleware de IPTV, y sus valores materiales como se define dentro del sistema de facturación. La plataforma de IPTV es un servidor de middleware centralizado responsable de la experiencia de visualización de usuarios finales. La plataforma 1142 de IPTV puede comunicarse con la STB 1100 para enviar claves de encriptación, metadatos, etc., utilizando el protocolo de HTTP. El sistema 1144 de ARB es un sistema responsable de entender qué contenido se compra por qué cliente en qué punto en el tiempo. Por lo tanto, es capaz de presentar a este usuario el precio de descuento adecuado por cualquier artículo (por ejemplo comprar uno, obtener uno gratuito) y manejar todas las transacciones financieras con respecto a la compra de ese artículo (facturación de tarjeta de crédito, adeudos directos e impresión de facturación física) .

La Figura 12 muestra algunos componentes de un sistema del suministro de contenido de acuerdo con una modalidad, e ilustra su capacidad de tratar el video y las capas de UI de manera independiente hasta el punto de reproducción en el dispositivo final. En esta modalidad, la plataforma 1200 de suministro de servicio incluye varios componentes que se describen en la presente con respecto a la Figura 11, así como un enrutador 1202 de IP que se interconecta con las redes de suministro. La red de suministro puede incluir en los Proveedores A y B de Servicio de Internet para la entrega a los dispositivos 1203-1206 de cliente en varios lugares. Por ejemplo, en un caso del ISP A, los dispositivos 1203-1205 de cliente operan en una configuración de P2P, y en otro caso, uno de los dispositivos 1205 de cliente opera para recibir el contenido de medios utilizando HTTP. En otro caso de ISP B, el dispositivo 1206 de cliente opera en una red habilitada para multidifusión y recibe el contenido de IPTV a través de una red cerrada mediante ISP B.

En la modalidad representada, el dispositivo 1207 de cliente representa cualquiera del dispositivo 1203-1206 de cliente, e incluye el sistema 1210 de emulación de STB. En otra modalidad, el componente 1050 de DVSS puede integrarse en una STB física.

El sistema 1210 de emulación de STB incluye una pila de red que recibe el tráfico de red, incluyendo las claves de encriptación, contenido de IPTV (por ejemplo, IGMP) recibido a través de la red de suministro habilitada para multidifusión, o el contenido de medios recibida a través de una red de suministro habilitada por monodifusión, tal como utilizando RTSP, HTTP, P2P, o similares. El descifrador recibe el video de la pila de red y descifra el contenido de medios y los envía al códec. La pila de red también recibe los gráficos y/o texto para la UI, por ejemplo, de la plataforma de IP, tal como gráficos y/o texto para la guía de programación electrónica, texto subtitulado, etc. La aplicación del explorador se interconecta con el controlador de gráficos y el controlador de video mediante las API de Javascript. El multiplexor maneja la UI y las capacidades de mezclado de video, como se describe en la presente, y se comunica con la capa de abstracción de hardware para representar el video en la pantalla, reproducir cualquier audio en los altavoces del dispositivo 1207 de cliente. La capa de abstracción de hardware también recibe eventos de navegación del ratón, teclado o control remoto. Estos eventos se comunican a la aplicación de explorador.

En la modalidad representada, en la plataforma 1200 de suministro de servicio se acopla a la administración 1220 de atención al cliente. La administración 1220 de atención al cliente puede ser una herramienta de administración de terceros, típicamente los operadores de red, que proporciona una vista de administración del subsistema de televisión completo. Esto permite a un tercero administrar servicio (con respecto a la disposición de cliente, suspensión, cese y todas las otras formas de consultas operacionales ) de sus propios centros de llamada.

La Figura 13 ilustra un diagrama simplificado de cómo un televidente puede tener una experiencia de visualización persistente en múltiples ambientes de red de acuerdo con una modalidad. En esta modalidad, el televidente, Señor A, está con una suscripción de un servicio de TV basado en la STB 1301 física en casa 1302. El ISP B 1303 del Señor A tiene capacidad de multidifusión y tan pronto como presiona ' 1' en su control remoto para sintonizar un canal (por ejemplo, BBC 1 ) la STB física interpreta esta solicitud y emite una solicitud de IGMP para el contenido de medios para ese canal, BBC 1 .

En otra modalidad, el Señor A compra una STB 1304 física adicional y una suscripción para su casa 1302 . Cuando el Señor A selecciona ' 1 ' en su nuevo control remoto para BBC 1 , esta vez la STB 1304 física emite la solicitud de IGMP para BBC 1 . Sin embargo, su ISP 1303 puede no soportar múltiples corrientes para una sola residencia. Si el ISP 1303 no soportar múltiples corrientes para la casa 1302 del Señor A (por ejemplo, si dos STB operan al mismo tiempo) , la solicitud de IGMP tendrá éxito. Si no tiene éxito la STB 1304 física, la cual incluye el componente 1050 de DVSS descrito en la presente, volverá a emitir una solicitud de medios que correspondan con BBC 1 de una red 1305 no habilitada para multidifusión, tal como una red abierta como la Internet. En una modalidad, la STB 1304 física solicita una corriente continua de HTTP desde una CDN o desde un servidor de contenido sobre la red 1305 abierta (por ejemplo, red de suministro habilitada por HTTP) . El resultado final es que el Señor A obtiene BBC 1 aunque ahora puede ser a través de mecanismo de suministro completamente diferentes y/o utilizando un protocolo de suministro diferente.

En otra modalidad, el Señor A compra una extensión de PC para su suscripción. El Señor A selecciona BBC 1 en la computadora tipo laptop 1306, y la vSTB (sistema 1000 de emulación de STB como se describe en lo anterior) y emite la solicitud de IGMP de BBC 1. El ISP 1303 del Señor A puede o no soportar múltiples corrientes. Si el ISP 1303 no soporta múltiples corrientes en la casa 1302 del Señor A (por ejemplo, si otra STB opera al mismo tiempo que la vSTB) , la solicitud de IGMP tendrá éxito. Si no es así, la vSTB volverá a emitir una solicitud de medios que correspondan con BBC 1 desde una red 1305 no habilitada para multidifusión, tal como una red abierta como la Internet. En una modalidad, la vSTB solicita una corriente continua de HTTP desde una CDN de la red 1305 abierta, o desde un servidor de contenido sobre la red 1305 abierta (por ejemplo, red de suministro habilitada por HTTP) . El resultado final es que el Señor A obtiene BBC 1 aunque ahora puede ser a través de un mecanismo de suministro completamente diferente y/o utilizando un protocolo de suministro diferente.

En otra modalidad, el Señor A Compra una capacidad de Itinerancia para su suscripción de PC y visita un hotel 1307 en un viaje de negocios. El Señor A seleccionada BBC 1 en la computadora tipo laptop 1306, y la vSTB en su computadora tipo laptop 1306 emite la solicitud de IGMP para BBC 1. Puesto que el Señor A se conecta a la red 1305 abierta, la cual no soporta corrientes de multidifusión, la vSTB emite una solicitud del medio que corresponde con BBC 1 desde la red 1305 no habilitada para muítidifusión. En una modalidad, la vSTB solicita una corriente continua de HTTP desde una CDN de la red 1305 abierta o desde un servidor de contenido sobre la red 1305 abierta (por ejemplo, la red de suministro habilitada para HTTP) . Similarmente, el Señor A puede visitar una casa 1308 de un pariente que tiene un ISP 1309 , el cual es una red cerrada que no soporta multidifusión . El Señor A selecciona BBC 1 en la computadora tipo laptop 1306 , y la vSTB en esta computadora tipo laptop 1306 emite la solicitud de IGMP para BBC 1 desde la red 1309 no habilitada para multidifusión (ISP A) . Puesto que el Señor A se conecta a la red 1309 cerrada, la cual no soporta corrientes de multidifusión, la vSTB emite una solicitud del medio que corresponde con BBC 1 de la red 1309 no habilitada para multidifusión. El resultado final es que el Señor A obtiene BBC 1 aunque ahora puede ser a través de un mecanismo de suministro completamente diferente y/o utilizando un protocolo de suministro diferente.

Con referencia a la Figura 14 , una característica que hace que la vSTB de las presentes modalidades sea inmediatamente valiosa para desarrolladores de terceros, su capacidad de proporcionar una API emulada para números de STB basadas en hardware existente, tal como la Amino Aminet 110 . La API del sistema de emulación de STB se envuelve en un número de "emulaciones de Javascript puras" que presentan la API de la STB física natural, mientras mapea las llamadas a través de las aplicaciones que ejecutan el sistema de emulación de STB, indicado como objetos de iglú (A) . En la Figura 14, los objetos ovalados (etiqueta A) representan las API de 'vainilla' de propiedad del sistema de emulación de STB; las elipses (etiqueta B) representan las API específicas de la caja del convertidor-descodificador emuladas (estas API concuerdan con la API de la caja de convertidor-descodificador específica, pero mapea las llamadas en las API de iglú del sistema de emulación de STB) ; las flechas (etiquetadas como C) representan el mapeo de las API específicas de la caja de convertidor-descodificador en las API de iglú del sistema de emulación de STB; y las flechas (etiquetadas como D) representan el middleware de IPTV que se comunica con las API específicas de la caja del convertidor-descodificador emulada. Debe observarse que el middleware puede autorizarse ya sea al describir directamente en la API de 'vainilla' de propiedad o en las API específicas de STB sustraída de acuerdo con varias modalidades.

Debido a las limitaciones impuestas por el Modelo de Objeto de Componentes de Plataforma Cruzada (XPCOM) con respecto a la sobrecarga de modelo, los parámetros por defecto del método y los problemas de incompatibilidad adicionales entre exploradores, una técnica para inyectar la API directamente en la página web conforme se carga se han implementado . Esto logra la misma meta de transparencia para el usuario de las API y mantiene la capacidad de utilizar buenos principios orientados a objeto así como ser un explorador agnóstico.

Una de las funciones principales de la vSTB en una modalidad es la conmutación entre corrientes de medios. Esta conmutación de corrientes puede ser en respuesta a una entrada de usuario, por ejemplo, que solicite un cambio de un canal de programas de TV a otro o la selección de una nueva corriente por la caja del convertidor-descodificador virtual de una selección de múltiples fuentes y mecanismos de suministro que transmiten continuamente el mismo contenido. En una modalidad, los tres componentes principales implicados en la conmutación de corriente de medios son la aplicación contenedora principal (etiquetada como CProgrammeSource) , el componente de QI encapsulado por el explorador integrado (etiquetado como CInukBrowser) , y un número de administradores de corrientes específicas de protocolo, en este caso el administrador específico de multidifusión (etiquetado como CIgmpController) .

El explorador integrado sustrae una implementacion de explorador subyacente, tal como por ejemplo, WebKit o Mozilla. El CInukBrowser es un objeto global iniciado en main() en igloo. cpp. CInukBrowser crea la ventana del explorador utilizando Mozlib y recibe los eventos de ratón y teclado de la Capa Simple de DirectMedia (SDL) y las pasa a la ventana del explorador. También recibe eventos del cliente Javascript y reenvía la respuesta mediante un oyente registrado.

La CProgrammeSource es un objeto global en igloo. cpp que actúa como contenedor para fuentes de video clasificadas que incluyen aquellas que vienen de una videograbadora personal (PVR) o multidifusiones . La CProgrammeSource permite la unión de un canal por URL y encapsula los modos en los que puede encontrarse un canal (por ejemplo, fuera del aire) , encriptado, de una PVR; una multidifusión, un video a la carta (VOD) , y DVSS . En este caso, el componente de DVSS invocado durante la llamada PlayChannel (url ) ha determinado que el dispositivo de cliente es un ambiente con capacidad de multidifusión y como tal elige utilizar el administrador de corriente de multidifusión subyacente, CIgmpController . La CProgrammeSource crea una plaza de corriente de transporte, una memoria intermedia de multidifusión y un colector de multidifusión. Crea una tabla que analiza el enlace sobre un canal y detiene ese enlace a la salida. La CProgrammeSource mantiene el índice de tramas que se establece a partir de CodeLibAv/CH264Codec y se lee por varios componentes aunque puede no utilizarse por sí mismos en CProgrammeSource. También contiene un offAirTimeout que detecta la pérdida de canal basada en las anomalías de suministro de paquetes. La CProgrammeSource también crea un CVideoController que se sub-clasifica dependiendo del tipo de fuente, por ejemplo, el archivo, IGMP, RTSP, HTTP, etc.

El CIgmpController implementa el CVideoController para corrientes de IGMP. Con la conexión, utiliza un colector de multidifusion de inyección para unir un grupo de multidifusion. Crea un enlace de recepción e inyecta la memoria intermedia de multidifusion y el colector conectado. El enlace recibe los datos del colector, los divide en paquetes de Procesador de Video Digital (DVP) y pone cada paquete en la memoria intermedia de multidifusion. En un comando de detección, el colector se desconecta del grupo de multidifusion.

El diagrama de secuencias mostrado en la Figura 15 ilustra la operación de los componentes anteriores en el proceso de conmutación de medios. Con referencia a la Figura 16, este diagrama de secuencias ilustra el proceso que se presenta una vez que ha ocurrido la conmutación de corriente de medios, que muestra lo que sucede en un paquete de video de h.264 cuando se recibe la corriente de transporte.

Con referencia a la Figura 17, este diagrama de secuencias ilustra el proceso de sincronizar los datos de audio y video recibidos utilizando un mecanismo de recordatorio de audio que permite que el índice de video se determine por la frecuencia de audio. Con la capacidad de conmutar entre fuentes de medios y sincronizar la reproducción de los componentes de audio y video de las corrientes ya programadas en el software de STB, entonces es necesario proporcionar una interfaz a través de la cual las aplicaciones de terceros puedan aprovechar estas características utilizando una interfaz de programación de aplicación (API) de la STB.

Cuando se produce una nueva caja de convertidor-descodificador virtual, un desarrollador utiliza la API de la STB para alimentar la corriente de datos entrante al middleware y recibe la señal de salida del middleware, la cual entonces se utiliza para producir la presentación de salida al usuario en el dispositivo de visualización. Las API se presentan en el desarrollador a través del modelo de objeto de documento (DOM) del explorador basado en Mozilla integrado. La comunicación se logra a través de una combinación de eventos y manipulación del DOM de HTML como sigue. Cuando se carga la aplicación basada en el explorador (el middleware) , el explorador crea un objeto denominado IglooController que inserta un elemento, denominado como <iglooEvent> en el cabezal del documento de HTML. El elemento de <iglooEvent> tiene dos campos de cadena, un campo de solicitud y un campo de respuesta. Cuando el middleware necesita emitir un comando a la caja del convertidor-descodificador virtual, ubica el elemento <iglooEvent> y establece el campo de solicitud. El controlador entonces genera un evento iglooEvent y lo despacha. LLMozlib es un oyente que recibe el evento. Con la recepción, el LLMozlib ubica el elemento <iglooEvent> y examina los contenidos del atributo de solicitud. LLMozlib entonces llama al onlglooEvent en todos los LLEmbeddedBrowserWindowObservers registrados a los cuales el CInukBrowser es parte del mismo. El explorador pasa la corriente de comandos al processCommand. Si el iglú necesita pasar una respuesta nuevamente, llama a sendiglooResponse en LLMozlib en el cual establece el atributo de respuesta del elemento <iglooEvent> . Mientras tanto, el IglooController ha esperado el bloqueo en algo para establecer el atributo de respuesta. Una vez que este atributo de respuesta se ha establecido, se lee el IglooController, establece los contenidos en "" y regresa a su comunicante. El diagrama de secuencias de la Figura 18 ilustra este proceso.

La arquitectura de la vSTB de una modalidad se designa específicamente para ser una plataforma independiente y para tomar ventaja de cualquier aceleración de hardware natural en donde ésta se encuentre disponible. Esto se logra utilizando la capa de abstracción que proporciona una interfaz común a las características específicas de plataformas de hardware. Esta interfaz es una abstracción de los detalles específicos de implementacion de cada plataforma de hardware en la que se ejecutan las aplicaciones de la presente invención. Esta capa de aplicación es importante por una serie de razones y tiene la ventaja significativa de que las aplicaciones pueden ejecutarse de una nueva plataforma al esperar simplemente una nueva capa de abstracción sin cambiar el código de aplicación. También proporciona una separación lógica entre el código específico de plataforma y el código de las aplicaciones de la presente invención que hacen del proceso de mantenimiento de este código más directo. La abstracción de plataforma inicial se implementa utilizando la biblioteca de base de Capas Simples de DirectMedia (SDL) y las interfaces adicionales que llaman las soluciones del sistema operativo directamente. Mientras SDL proporciona una plataforma básica independiente de la capacidad de interfaz para varias plataformas de hardware, no puede manejar efectivamente todas las aceleraciones específicas de hardware, por ejemplo, operaciones de transferencia de bloques de bits gráficos. Tales operaciones, particularmente donde las imágenes se estiran y redimensionan, son computacionalmente costosas y por lo tanto requieren aceleración. En una modalidad, el sistema de emulación de STB implementa de manera independiente la aceleración de hardware por medio de registros especializados MMX y como resultado un uso significativamente disminuido de la CPU.

La capa de abstracción consiste de un número de componentes que proporcionan interfaces a los subsistemas de enlace, sincronización, manejo de eventos, gráficos y audio. La Figura 19 ilustra cómo la capa de abstracción utilizada en la presente invención se relaciona con las API de terceros tales como SDL, DirectX y OpenGL y también al sistema operativo. Las interfaces de gráficos y audio se crean durante el tiempo de ejecución utilizando las clases de CGraphicsFactory y CAudioFactory . Alternativamente, éstas pueden implementarse utilizando complementos.

Los subsistemas de abstracción y presentación se ilustran en la Figura 20 y el resto de los componentes entonces se implementa en una forma agnóstica de plataforma que opera por encima de la capa de abstracción de hardware.

La aplicación se implementa en una forma multi-enlazada para propósitos de rendimiento y elasticidad. Los grupos de enlaces principales se dividen en enlaces globales responsables de la operación general de la aplicación y de los eventos de canal que son casos ubicados responsables de las corrientes . Los enlaces globales cuidan actividades tales como manejo de eventos, presentación de video y recordatorios de audio, mientras los enlaces por canal son responsables de las actividades basadas en corriente tales como conexiones de colector, análisis de corrientes y administración de códec. Estos grupos de enlace se ilustran en la Figura 21. Colocados por encima del modelo de administración de enlace se encuentran los flujos de datos específicos tales como aquellos de los datos sin procesar recibidos en la pantalla de AV e ilustrados en la Figura 22. Los subsistemas restantes de la presente invención se ilustran en la Figura 23.

En una modalidad, para soportar el almacenamiento seguro de datos etiquetados de aplicación en la vSTB, un almacén de cookie segura se ha implementado dentro del explorador. Esto puede lograrse al modificar el código de fuente original de Mozilla y agregar una llamada a una biblioteca de encriptación genérica específica para la presente solicitud utilizada para el archivo de propiedades seguras . Este procedimiento puede ser transparente para el usuario y las páginas web que utilizan las cookies y una característica de depuración, el archivo resultante cookies.txt puede leerse con el editor de perfil de propiedades de PFE. Las biblioteca de encriptación genérica proporciona características de encriptación y descifrado utilizando el "Algoritmo de Encriptación Diminuto" (TEA) .

En una modalidad, la vSTB tiene una implementación de pila básica RSC2326 RTSP aumentada por la capacidad para detectar de manera dinámica y alterar su comportamiento de acuerdo con los diversos dialectos de RTSP implementado por los protectores de servidor como se ilustra en la Figura 24.

Una ventaja importante de la presente invención puede ser la capacidad de mezclar la interfaz de usuario gráfica en la parte superior y una corriente de video móvil en una forma que es familiar para el usuario. En otras palabras, el resultado de middle are en la vSTB produce el mismo menú en pantalla que yace sobre o a lo largo del video continuo como su STB física basada en hardware equivalente. Alternativamente, las modalidades descritas aquí pueden proporcionar otras ventajas como se describe en la presente.

Un problema que surge se relaciona con la información de formato de color. El codee h.264 regresa al video en el formato YUV mientras un explorador regresa un mapa de bit de RGB que requiere un formato para modificarse en el otro. Debido a que SDL no maneja bien las funciones de YUV complejas, la CPU debe utilizarse para realizar la mezcla de imágenes (alpha blending) de YUV y la fusión de las capas. Este video de YUV debe convertirse entonces en RGB en el hardware justo antes de desplegarse en pantalla ya que sólo monitores pueden desplegar RGB. Una ventaja inmediata de convertir las tramas de video de YUV en RGB es que las tramas pueden utilizar la superposición de imágenes (chroma key) cuando un píxel de trama previo tiene el mismo color que el siguiente píxel de trama. Este procedimiento también permite descentralizar el video y la capacidad de realizar manipulaciones avanzadas de margen.

Los algoritmos de YUV a RGB implementados son extremadamente rápidos y también manejan anomalías de color cerca de los extremos de los valores de color de RGB. Una función de retención rápida se ha desarrollado para mejorar el rendimiento así como para mejorar las capacidades de mezcla de imágenes (alpha blending) . Cada píxel se somete a prueba para compararse con el valor de superposición de imágenes (chroma key) . Los píxeles que concuerdan con la máscara de color permiten que el píxel de video se muestre sin alteración. Los píxeles que no concuerden con la superposición de imágenes (chroma key) son la mezcla de imágenes (alpha blending) (128 bits) en la parte superior de la capa de video.

Debe observarse que las modalidades antes mencionadas ilustran en lugar de limitar la invención, y que aquellos con experiencia en la técnica, serán capaces de diseñar muchas modalidades alternativas sin apartarse del alcance de la invención como se define por las reivindicaciones anexas. En las reivindicaciones, cualesquier signos de referencia colocados en paréntesis no deben interpretarse como limitantes de las reivindicaciones . La referencia en singular de un elemento no excluye la referencia en plural de tales elementos y viceversa. Algunas modalidades pueden implementarse por medio de hardware que incluye varios elementos distintos, y por medio de un dispositivo de cómputo programado de manera adecuada. En una reivindicación del dispositivo que enumera varios medios, varios de estos medios pueden representarse por uno y el mismo elemento de hardware. El sólo hecho de que ciertas medidas se narren en reivindicaciones dependientes mutuamente diferentes no indica que una combinación de estas medidas no pueda utilizarse para tomar ventaja.

Claims

REIVINDICACIONES

1. Un método implementado por computadora de selección de fuente de video dinámico (DVSS) , caracterizado porque comprende: utilizar un componente de DVSS que opera en un dispositivo electrónico, determinar que el dispositivo electrónico se ubica dentro de un ambiente de red, en el cual existe una pluralidad de fuentes disponibles para suministrar contenido de medios al dispositivo electrónico, en donde el dispositivo electrónico se configura para recibir y presentar contenidos de medios en una pantalla; utilizar el componente de DVSS, seleccionar una de la pluralidad de fuentes para suministrar el contenido de medios sobre una red de suministro de la fuente seleccionada al dispositivo electrónico basado en el cual la pluralidad de fuentes puede suministrar la copia de más alta calidad del contenido de medios que se encuentra disponible para el dispositivo electrónico; recibir en el dispositivo electrónico el contenido de medios sobre la red de suministro desde la fuente seleccionada; y presentar el contenido de medios en la pantalla.

2. El método de conformidad con la reivindicación 1, caracterizado porque presentar comprende presentar el contenido de medios utilizando un paradigma de navegación consistente a un usuario, sin importar la fuente seleccionada .

3. El método de conformidad con la reivindicación 1, caracterizado porque presentar comprende presentar el contenido de medios como por lo menos uno de video, un video y texto, un video y gráficos, una interfaz de usuario gráfica, y un video y la interfaz de usuario gráfica.

4. El método de conformidad con la reivindicación 1, caracterizado porque el contenido de medios en cada una de la pluralidad de fuentes es el mismo contenido de medios.

5. El método de conformidad con la reivindicación 1, caracterizado además porque comprende solicitar el contenido de medios de la fuente seleccionada.

6. El método de conformidad con la reivindicación 5, caracterizado porque la solicitud comprende: emitir una solicitud del contenido de medios de la pluralidad de fuentes que utiliza una red de suministro habilitada para multidifusión; y al determinar que falla la solicitud, volver a emitir la solicitud del contenido de medios de otra de la pluralidad de fuentes que es una red de suministro no habilitada para multidifusión.

7. El método de conformidad con la reivindicación 6, caracterizado porque la solicitud es una solicitud de Protocolo de Administración de Grupos de Internet (IGMP) , y en donde la solicitud reemitida es una solicitud de Protocolo de Transporte de Hipertexto (HTTP) .

8. El método de conformidad con la reivindicación 5, caracterizado porque la solicitud comprende: emitir una solicitud del contenido de medios desde una de la pluralidad de fuentes en una infraestructura de red cerrada ; al determinar que la solicitud falla, reemitir la solicitud del contenido de medios desde otra de la pluralidad de fuentes en una infraestructura de red abierta.

9. El método de conformidad con la reivindicación 1, caracterizado porque por lo menos una de la pluralidad de fuentes es una fuente de Difusión de Video Digital que controla el contenido de medios por aire, y en donde la recepción comprende recibir el contenido de medios por aire sin solicitar el contenido de medios.

10. El método de conformidad con la reivindicación 1, caracterizado porque por lo menos una de la pluralidad de fuentes utiliza una red de suministro habilitada para multidifusión que suministra el contenido de medios como contenido de Televisión de Protocolo de Internet (IPTV) , y por lo menos una de la pluralidad de fuentes utiliza una red de suministro no habilitada para multidifusión.

11. El método de conformidad con la reivindicación 10, caracterizado porque la red de suministro no habilitada para multidifusión es una red de suministro de Protocolo de Transferencia de Hipertexto (HTTP) , y la red de suministro de HTTP suministra el contenido de medios como una o más corrientes continuas de HTTP.

12. El método de conformidad con la reivindicación 10, caracterizado porque la red de suministro no habilitada para multidifusión es una red de suministro de Igual a Igual (P2P) .

13. El método de conformidad con la reivindicación 1, caracterizado porque el dispositivo electrónico es una caja del convertidor-descodificador (STB) física.

14. El método de conformidad con la reivindicación 1, caracterizado porque el dispositivo electrónico es un dispositivo de cómputo que opera un sistema de emulación de STB.

15. Un sistema, caracterizado porque comprende: un dispositivo electrónico que opera en un ambiente de red en el cual existe una pluralidad de fuentes disponibles para suministrar el contenido de medios al dispositivo electrónico, en donde el dispositivo electrónico se configura para recibir y presentar el contenido de medios en una pantalla; en donde el dispositivo electrónico comprende un dispositivo de cómputo que opera un componente de Selección de Fuente de Video Dinámico (DVSS) , en donde el componente de DVSS se configura para seleccionar una de la pluralidad de fuentes para suministrar el contenido de medios sobre una red de suministro desde la fuente seleccionada al dispositivo electrónico basándose en cuál de la pluralidad de fuentes puede suministrar la copia de más alta calidad del contenido de medios que se encuentra disponible para el dispositivo electrónico; y en donde el dispositivo electrónico se configura para recibir el contenido de medios sobre la red de suministro desde la fuente seleccionada y presentar el contenido de medios en la pantalla.

16. El sistema de conformidad con la reivindicación 15, caracterizado porque el dispositivo electrónico es una caja del convertidor-descodificador física.

17. El sistema de conformidad con la reivindicación 15, caracterizado porque el dispositivo electrónico es un dispositivo de cómputo que opera un sistema de emulación de STB.

18. El sistema de conformidad con la reivindicación 15, caracterizado porque el componente de DVSS se configura para solicitar el contenido de medios al, emitir una solicitud de Protocolo de Administración de Grupos de Internet (IGMP) para el contenido de medios de una de la pluralidad de fuentes que utiliza una red de suministro habilitada para multidifusion; y al determinar que la solicitud de IGMP falla, reemitir la solicitud como solicitud de Protocolo de Transferencia de Hipertexto (HTTP) para el contenido de medios desde otra de la pluralidad de fuentes que es una red de suministro de HTTP.

19. Un medio de almacenamiento legible por máquina que almacena instrucción en el mismo, cuando se ejecuta por un dispositivo de cómputo que provoca que el dispositivo de cómputo realice un método, caracterizado porque comprende: determinar que el dispositivo de cómputo se ubica dentro de un ambiente de red en el cual existe una pluralidad de fuentes disponibles para suministrar el contenido de medios al dispositivo de cómputo, en donde el dispositivo de cómputo se configura para recibir y presentar el contenido de medios en una pantalla; seleccionar una de la pluralidad de fuentes para suministrar el contenido de medios sobre una red de suministro desde la fuente seleccionada hasta el dispositivo electrónico basándose en cuál de la pluralidad de fuentes puede suministrar la copia de más alta calidad del contenido de medios que se encuentra disponible para el dispositivo electrónico ; recibir el contenido de medios sobre la red de suministro desde la fuente seleccionada; y presentar el contenido de medios en la pantalla.

20. El medio de almacenamiento legible por máquina de conformidad con la reivindicación 19, caracterizado además porque comprende solicitar el contenido de medios de la fuente seleccionada, en donde la solicitud comprende: emitir una solicitud del contenido de medios desde una de la pluralidad de fuentes que utiliza una red de suministro habilitada para multidifusion; y al determinar que la solicitud falla, reemitir la solicitud del contenido de medios desde otra de la pluralidad de fuentes que es una red de suministro no habilitada para multidifusion.