BRPI0904441A2 - método e aparelho para a recepção de conteúdo - Google Patents
método e aparelho para a recepção de conteúdo Download PDFInfo
- Publication number
- BRPI0904441A2 BRPI0904441A2 BRPI0904441-8A BRPI0904441A BRPI0904441A2 BR PI0904441 A2 BRPI0904441 A2 BR PI0904441A2 BR PI0904441 A BRPI0904441 A BR PI0904441A BR PI0904441 A2 BRPI0904441 A2 BR PI0904441A2
- Authority
- BR
- Brazil
- Prior art keywords
- content
- data
- received
- time position
- video
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/2389—Multiplex stream processing, e.g. multiplex stream encrypting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
- H04N21/4347—Demultiplexing of several video streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
- H04N21/4385—Multiplex stream processing, e.g. multiplex stream decrypting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management e.g. creating a master electronic programme guide from data received from the Internet and a Head-end or controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
MéTODO E APARELHO PARA A RECEPçãO DE CONTEúDO. é provido um método para um dispositivo cliente para o recebimento de um conteúdo, compreendendo as etapas de enviar uma solicitação para o conteúdo, e, em resposta à dita solicitação, receber os dados do dito conteúdo começando de uma dada posição de tempo do dito conteúdo, o dito conteúdo é carregado em um fluxo de dados a partir de um primeiro dispositivo; e receber os dados do dito conteúdo correspondentes a uma posição de tempo anterior à dita determinada posição de tempo do dito conteúdo por parte de pelo menos um segundo dispositivo. Sendo assim, a presente invenção reduz o retardo ao mudar para um conteúdo.
Description
"MÉTODO E APARELHO PARA A RECEPÇÃO DE CONTEÚDO"
CAMPO DA TÉCNICA
A presente invenção refere-se, de modo geral, às redes de comunicação, e, maisparticularmente, se refere à recepção de conteúdo.
FUNDAMENTOS
Com o desenvolvimento das tecnologias, os programas de mídia, tais como a difu-são / multidifusão de TV e a difusão / multidifusão de vídeo, são entregues a usuários finaismediante o uso de pacotes de dados, tais como os pacotes de Protocolo da Internet (IP), ascélulas de Modo de Transferência Assíncrono (ATM) e tipos de pacotes similares.
Diferentemente da maneira tradicional de os usuários finais reproduzirem um con-teúdo de mídia digital depois de todo um arquivo de mídia ou um clip de mídia ser baixado, oconteúdo de um arquivo de mídia ou de um clip de mídia é transmitido aos usuários finaismediante o uso de um modo de multidifusão / difusão ou de unidifusão, e o conteúdo demídia será decodificado e reproduzido depois de uma quantidade predefinida de fluxo dedados do conteúdo de mídia ser armazenada temporariamente por um receptor. Neste caso,um fluxo de dados vem a ser uma seqüência de sinais coerentes digitalmente codificadosusados para transmitir ou receber informações que se encontram em transmissão. Por e-xemplo, no padrão H.264, o sinal coerente digitalmente codificado é a unidade de acesso(os dados codificados de uma imagem). Um aspecto do fluxo de dados é que há uma Iimita-ção de tempo sobre a unidade de acesso, o que significa que as unidades de acesso dofluxo de dados são enviadas uma após a outra de acordo com o seu carimbo de hora, e aunidade de acesso posterior será enviada após a anterior.
Devido ao ambiente de transmissão, o fluxo de dados do conteúdo não poderá sertransmitido ao usuário final com uma taxa de bits estável. Isto resultará em uma reproduçãointermitente do conteúdo. Sendo assim, a fim de obter uma reprodução suave do conteúdo,um armazenador temporário de um tamanho predefinido é utilizado no sentido de compen-sar a entrega imprevisível do conteúdo por uma rede errática em função do armazenamentotemporário de alguns fluxos de dados do conteúdo antes de iniciar a sua reprodução. Nor-malmente, o tamanho do armazenador temporário varia como uma função da qualidade detransmissão da rede. De modo geral, quanto pior a qualidade de transmissão da rede, tantomaior precisará ser o tamanho do armazenador temporário. Além disso, o tamanho do ar-mazenador temporário é normalmente grande em uma rede sem fio e em outras redes cujasqualidades de transmissão variam ao longo do tempo. No entanto, à medida que o tamanhodo armazenador temporário se torna maior, mais tempo se faz necessário para armazenartemporariamente o fluxo de dados de um conteúdo ao comutar para um conteúdo de mídia.É desejável diminuir o retardo causado pelo armazenamento temporário dos dados de fluxoao comutar para um conteúdo.SUMÁRIO
De acordo com um aspecto da presente invenção, é provido um método para umdispositivo cliente receber um conteúdo compreendendo o envio de uma solicitação para odito conteúdo; e, em resposta à dita solicitação, o recebimento de dados do dito conteúdocomeçando em uma determinada posição de tempo do dito conteúdo, o dito conteúdo é car-regado em um fluxo de dados a partir de um primeiro dispositivo, e o recebimento dos dadosdo dito conteúdo correspondentes a uma posição de tempo anterior à dita determinada posi-ção de tempo do dito conteúdo a partir de pelo menos um segundo dispositivo.
De acordo com um aspecto da presente invenção, um dispositivo cliente é providopara o recebimento de um conteúdo. O mesmo compreende um módulo receptor e um mó-dulo processador. O módulo receptor é configurado para receber os dados carregados emum fluxo de dados a partir de um primeiro dispositivo e receber os dados de pelo menos umsegundo dispositivo; e o módulo processador é configurado para enviar uma mensagemcontendo uma posição de tempo para solicitar o dito conteúdo a partir do pelo menos umsegundo dispositivo, sendo que, em resposta à mensagem enviada, os dados que precedemà dita posição de tempo são recebidos a partir do dito pelo menos um segundo dispositivo.
De acordo com um aspecto da presente invenção, o retardo é reduzido ao mudarpara outro conteúdo.
Deve-sè entender que aspectos e vantagens adicionais da presente invenção tor-nar-se-ão aparentes a uma pessoa versada na técnica após a leitura da descrição detalhadaa seguir.
BREVE DESCRIÇÃO DOS DESENHOS
Os desenhos em anexo, incluídos de modo a prover um maior entendimento dapresente invenção e incorporados e constituindo uma parte do presente pedido, ilustramuma modalidade da presente invenção juntamente com a descrição que serve para explicaro princípio da presente invenção. Nos desenhos:
A Figura 1 é um fluxograma que ilustra o método para a mudança de canal de a-cordo com uma modalidade da presente invenção;
A Figura 2 é um diagrama esquemático que ilustra um sistema de acordo com amodalidade da presente invenção; e
A Figura 3 é um diagrama em blocos do dispositivo cliente para uma mudança decanal de acordo com a modalidade da presente invenção.
DESCRIÇÃO DETALHADA
A modalidade da presente invenção será descrita em detalhe a seguir em conjuntocom os desenhos. Na descrição a seguir, algumas descrições detalhadas de funções e con-figurações conhecidas poderão ser omitidas para fins de clareza e concisão.
De acordo com uma modalidade da presente invenção, uma rede típica compreen-de pelo menos um servidor de vídeo, pelo menos um servidor de cache e pelo menos umdispositivo cliente. O dispositivo cliente é configurado de modo a receber dados de vídeo. Oservidor de vídeo é configurado para prover dados de vídeo. Os dados de vídeo são trans-mitidos ou no servidor de vídeo ou em outro dispositivo comunicativamente conectado aoservidor de vídeo. O servidor de cache é configurado para armazenar em cache os dados devídeo do servidor de vídeo, e é também configurado para prover dados de vídeo armazena-dos em cache em resposta à solicitação dos dados armazenados em cache por parte dodispositivo cliente.
A Figura 1 é um fluxograma que ilustra o processo de mudança de canal em umambiente de multidifusão de acordo com uma modalidade da presente invenção.
- Na etapa 101, um dispositivo cliente envia uma solicitação indicativa da sintoniza-ção para um conteúdo de vídeo, tal com um canal de TV. Geralmente, a solicitação é envia-da pelo dispositivo cliente quando o dispositivo cliente é ligado ou comutado de um conteú-do de vídeo para outro.
- Na etapa 102, em resposta à solicitação para o conteúdo de vídeo por parte dodispositivo cliente, o dispositivo cliente recebe do servidor de vídeo os dados de vídeo deum conteúdo de vídeo solicitado em um fluxo de dados, e os dados de vídeo carregados nofluxo de dados (doravante referidos como "dados de vídeo futuros") são recebidos a partir daposição de reprodução corrente T de um conteúdo de vídeo solicitado. Em tais aplicações,como os serviços de multidifusão de vídeo, devido ao fato de que o conteúdo de vídeo étransmitido na forma de um fluxo de dados, o dispositivo cliente só poderá receber os dadosde vídeo subsequentes à posição T no eixo de tempo através de um fluxo de multidifusão.
- Na etapa 103, o dispositivo cliente recebe os dados de vídeo de um conteúdo devídeo solicitado antes da posição T no eixo de tempo (doravante referidos como "dados devídeo passados") a partir de pelo menos um servidor de cache. O pelo menos um servidorde cache, neste caso, será capaz de prover os dados de vídeo de um conteúdo de vídeosolicitado antes da posição T no eixo de tempo. O servidor de cache pode ser um servidordedicado que guarda o recebimento do fluxo de dados de conteúdo de vídeo solicitado earmazena os dados de vídeo contidos no fluxo de dados recebido, ou um servidor dedicadoque é instruído em um ponto de tempo para começar a receber o fluxo de dados de um con-teúdo de vídeo solicitado e armazena os dados de vídeo. O método a seguir pode ser usadopelo dispositivo cliente no sentido de receber os dados de vídeo passados: o dispositivo cli-ente instrui o servidor de cache para transmitir os dados de vídeo passados de uma maneiraem retrocesso a partir da posição Τ, o que significa que os dados de vídeo passados sãotransmitidos em um sentido a partir da posição T para a posição de início de um conteúdode vídeo solicitado. Uma vez que os dados de vídeo passados são transmitidos de uma ma-neira inversa, o dispositivo cliente ou o dispositivo de cache não precisará calcular ou infor-mar o servidor de cache quantos dados de vídeo passados precisam ser transmitidos. Comouma conseqüência, estes dados economizam o tempo para tal cálculo e evitam, portanto, atroca de sinal entre o dispositivo de cache e o dispositivo cliente. Neste caso, os dados devídeo passados armazenados em cache podem ser transmitidos em um bloco de dados tãorapidamente quanto os recursos de rede permitam.
- Na etapa 104, quando é determinado que os dados de vídeo armazenados tempo-rariamente no dispositivo cliente que são recebidos do servidor de vídeo e do pelo menosum servidor de cache atingem um valor limite predeterminado, o dispositivo cliente decodifi-ca e exibe o vídeo com base na combinação dos dados de vídeo do servidor de vídeo e dopelo menos um servidor de cache. Neste caso, o valor limite é definido em um valor quepermite que o dispositivo cliente decodifique e suavemente e exiba o conteúdo de vídeo.Uma vez que os dados de vídeo da posição T e os dados de vídeo antes da posição T sãorecebidos, os dados de vídeo podem ser combinados coerentemente na posição T medianteo uso do método a seguir: Tendo em vista que os dados de vídeo, tais como uma unidadede acesso, são geralmente encapsulados com o Protocolo de Transporte em Tempo Real(RTP) antes de serem transmitidos, os dados de vídeo podem ser combinados mediante aclassificação dos dados de vídeo recebidos do servidor de vídeo e do pelo menos um servi-dor de cache com base no campo "número de seqüência" do cabeçalho do protocolo RTP.
Uma vez que o armazenador temporário é preenchido com os dados de vídeo pas-sados de uma maneira inversa a partir do pelo menos um servidor de cache além dos dadosde vídeo do servidor de vídeo, menos tempo será utilizado para preencher o armazenadortemporário em um valor limite predeterminado de modo a acelerar a mudança de canal.Quando os dados de vídeo armazenados temporariamente atingem um valor limite prede-terminado, o dispositivo cliente decodifica os dados de vídeo combinados, e exibem o con-teúdo de vídeo que começa com os dados de vídeo tendo o menor "Número de Seqüência".Além disso, depois de os dados armazenados temporariamente atingirem um valor limitepredeterminado, o dispositivo cliente poderá instruir o servidor de cache para interromper atransmissão dos dados de vídeo passados ou descartar os dados de vídeo passados rece-bidos posteriormente.
Além disso, o valor limite pode ser um valor estático ou um valor dinâmico de acor-do com as exigências do conteúdo de vídeo e/ou com os aspectos do conteúdo de vídeocodificado, ou com as condições da rede. Quando o valor limite é dinamicamente determi-nado, o mesmo poderá ser determinado com base nas informações de controle do conteúdode vídeo, tais como as informações de Verificação Virtual de Armazenamento Temporário(VBV) das informações do padrão MPEG-4 Part2 ou as informações do Decodificador Hipo-tético de Referência (HRD) do padrão MPEG-4 AVS (Padrão de Vídeo Áudio)/H.264. Nor-malmente, as informações de controle compreendem o decodificador HRD ou a verificaçãoVBV, o carimbo de horas, etc. Além disso, as informações de controle podem ser usadaspara auxiliar o dispositivo cliente a medir a densidade horizontal de um determinado quadrode vídeo de maneira precisa. Por exemplo, durante a decodificação, as informações decpb_removal_delay e de removal_delay iniciais do decodificador HRD podem ser aplicadasna verificação do número de quadros de decodificação. As informações dedpb_output_delay do decodificador HRD podem ser combinadas com o número de quadrosobtido de modo a derivar qual quadro deve ser exibido.
De acordo com uma variante da presente modalidade, o dispositivo cliente pode re-ceber um conteúdo de vídeo solicitado de um outro dispositivo intermediário comunicativa-mente conectado entre o servidor de vídeo e o dispositivo cliente, tal como um roteador. Odispositivo intermediário é capaz de retransmitir um conteúdo de vídeo solicitado que é re-cebido do servidor de vídeo.
De acordo com uma variante da presente modalidade, quando os recursos de rede,tais como uma largura de banda de transmissão, são limitados, e existe uma competiçãopara tais recursos de rede entre a conexão que carrega os dados de vídeo futuros e a cone-xão que carrega os dados de vídeo passados, a conexão que carrega os dados de vídeofuturos receberá uma prioridade maior.
De acordo com a presente modalidade, o estabelecimento das conexões de trans-missão para um conteúdo de vídeo solicitado é inicializado pelo servidor de vídeo e peloservidor de cache separadamente na etapa 102 e na etapa 103. No entanto, de acordo comuma variante da presente invenção, é provido um dispositivo de controle central que detémtodas as informações de status sobre o servidor de vídeo e o servidor de cache, por exem-plo, com relação a que conteúdo se encontra correntemente disponível. Quando o clientedeseja mudar para um outro conteúdo de vídeo, é enviada uma solicitação para o dispositivode controle central, e o dispositivo de controle central instrui o servidor de vídeo com o con-teúdo de vídeo solicitado e o servidor de cache com os dados de vídeo passados armaze-nados em cache sobre um conteúdo de vídeo solicitado de modo a inicializar uma conexãode transmissão com o dispositivo cliente.
De acordo com uma variante da presente modalidade, a execução da etapa 102 eda etapa 103 pode ser intercambiável ou simultânea.
De acordo com uma variante da presente modalidade, a mesma pode também seraplicada em ambientes de difusão e de unidifusão. Com relação à etapa 102, no ambientede multidifusão da presente modalidade, o dispositivo cliente precisa se juntar a um grupode multidifusão existente para um conteúdo de vídeo solicitado ou ingressar em um novogrupo de multidifusão para um conteúdo de vídeo solicitado e, em seguida, se juntar aomesmo. No entanto, no ambiente de difusão, o dispositivo cliente simplesmente recebe umconteúdo de vídeo solicitado em um canal de difusão existente. No ambiente de unidifusão,deve ser estabelecida uma conexão de transmissão de unidifusão para a transmissão defluxos de dados de um conteúdo de vídeo solicitado entre o dispositivo cliente e o servidorde vídeo.
De acordo com uma variante da presente modalidade, o servidor de cache pode serum módulo localizado no servidor de vídeo, ou um dispositivo independente na rede, ou oarmazenador temporário de um outro dispositivo cliente que armazena temporariamente oconteúdo de vídeo recebido e ao mesmo tempo recebe um conteúdo de vídeo solicitado emum fluxo de dados.
A Figura 2 é um diagrama esquemático que ilustra um sistema para a mudança decanal de acordo com a presente modalidade. Conforme mostrado na Figura 2, o sistemacompreende um servidor de vídeo 201, um servidor de cache A 202, um servidor de cache B203 e diferentes tipos de dispositivos clientes com capacidade de decodificar os dados devídeo, tais como um STB (aparelho conversor) conectado à TV 208, um Iaptop 205 ou umcomputador de mesa PC 207 conectado a um AP (ponto de acesso) 206. Supondo que oservidor de vídeo tenha de 1 a 10 canais de vídeo, cada qual tendo um conteúdo de vídeo, eque o servidor de cache A seja usado para armazenar em cache os canais de 1 a 5, en-quanto o servidor de cache B seja usado para armazenar em cache os canais de 6 a 10. Ousuário do laptop 205 está visualizando o canal 1 quando de repente comuta para o canal 6.Neste caso, 6 laptop 205 receberá os dados de vídeo do canal 6 a partir do servidor de ví-deo 201, uma vez que a posição de reprodução em questão do fluxo de dados e dos dadosde vídeo passados a partir do servidor de cache B 203 é inversa à posição de reproduçãocorrente. Além disso, como um exemplo, pode ser possível que o usuário da TV 208 estejanaquele momento visualizando o canal 6 através do aparelho conversor STB 204 e o con-versor STB 204 tem um armazenador temporário utilizado para armazenar os dados de ví-deo recebidos por parte do servidor de vídeo. Neste caso, o Iaptop 205 poderá estabeleceruma conexão com o conversor STB 204 no sentido de obter os dados de vídeo armazena-dos temporariamente de uma maneira inversa. Como uma conseqüência, o retardo no pro-cedimento de mudança de canal se torna menor. Além disso, deve-se entender que um me-canismo de coordenação será introduzido quando os dados de vídeo passados são recebi-dos a partir de mais de um servidor armazenado em cache. Um mecanismo simples é aque-le no qual o dispositivo cliente recebe os dados de vídeo passados a partir de mais de umservidor de cache de uma maneira inversa e descarta os dados de vídeo idênticos que se-rão recebidos mais adiante.
A Figura 3 é um diagrama em blocos do dispositivo cliente de acordo com a presen-te modalidade da presente invenção. O dispositivo cliente 300 compreende um primeiro mó-dulo receptor 301, um segundo módulo receptor 302, um armazenador temporário 303, ummódulo decodificador 304, um módulo de vídeo 305 e um módulo processador 306. O pri-meiro módulo receptor 301 é usado para receber os dados de vídeo futuros de um canal devídeo solicitado através de um fluxo de dados. O segundo módulo receptor 302 é usado pa-ra receber os dados de vídeo passados de um canal de vídeo solicitado por parte de pelomenos um servidor de cache de uma maneira inversa. Neste caso, o módulo receptor 302será instruído pelo módulo processador 306 a descartar os dados de vídeo passados queforam recebidos depois de os dados armazenados temporariamente no armazenador tem-porário 303 atingirem um valor limite predeterminado. O armazenador temporário 303 é u-sado para armazenar temporariamente os dados de vídeo recebido pelo primeiro móduloreceptor 301 e pelo segundo módulo receptor 302. O módulo decodificador 304 é usadopara decodificar os dados de vídeo em um armazenador temporário 303 de modo a gerar osdados de vídeo decodificados que o módulo de vídeo 305 exibirá. O módulo processador306 é usado para enviar uma solicitação para sintonizar um canal ao mudar de um canalpara outro ou quando o dispositivo cliente é ligado, instruir o primeiro módulo receptor 301 areceber os dados de vídeo futuros de um canal solicitado, começando com uma posição detempo do conteúdo de um canal solicitado, e instruir, por exemplo, ao enviar uma mensa-gem contendo um índice indicativo da posição de tempo, o segundo módulo receptor 302 areceber de uma maneira inversa os dados de vídeo passados de um canal solicitado antesda posição de tempo, e instruir o módulo decodificador 304 a decodificar a combinação dosdados de vídeo recebidos pelo módulo receptor 301 e pelo segundo módulo receptor 302quando os dados de vídeo armazenados temporariamente no armazenador temporário 303são determinados a atingir um valor limite predeterminado. Além disso, o módulo processa-dor 306 pode ser configurado para instruir o servidor de cache a interromper o envio de da-dos de vídeo passados quando os dados de vídeo em um armazenador temporário atingemum valor limite predeterminado. Deve-se entender que o dispositivo cliente não precisa in-cluir todos os módulos acima mencionados acima. Por exemplo, o módulo de vídeo 305 éredundante para um conversor STB, e o módulo decodificador 304 é redundante quando umdispositivo de vídeo tem a capacidade de decodificar. Além disso, os módulos podem sercombinados ou divididos em uma dada implementação.
De acordo com uma variante da presente modalidade, o dispositivo cliente compre-ende ainda um módulo de provisão de dados. O módulo de provisão de dados é usado demodo a prover os dados de vídeo de um canal de vídeo corrente armazenado temporaria-mente no armazenador temporário 303 para um outro dispositivo cliente que comuta paraeste canal de vídeo.
De acordo com uma variante da presente modalidade, o método, o sistema e o dis-positivo mostrados acima de acordo com a presente modalidade podem ser aplicados emoutros sistemas de entrega de recurso em tempo real, nos quais o recurso é entregue emum fluxo, como, por exemplo, um fluxo de áudio.Foi aqui descrito um número de implementações. Contudo, deve-se entender quevárias modificações podem ser feitas. Por exemplo, elementos de diferentes implementa-ções podem ser combinados, suplementados, modificados, ou removidos no sentido de pro-duzir outras implementações. Além disso, uma pessoa com habilidade simples na técnicadeverá entender que outras estruturas e processos podem substituir as estruturas e proces-sos aqui apresentados, e estas implementações resultantes realizarão, pelo menos subs-tancialmente, as mesmas funções, pelo menos substancialmente da mesma maneira, demodo a atingir pelo menos substancialmente os mesmos resultados das implementaçõesaqui apresentadas.
Claims (11)
1. Método para um dispositivo cliente para receber um conteúdo, o método sendoCARACTERIZADO pelo fato de compreender as etapas de:- enviar uma solicitação para o dito conteúdo; e- em resposta à dita solicitação, receber dados do dito conteúdo que se iniciam emuma dada posição de tempo do dito conteúdo, o dito conteúdo é carregado em um fluxo dedados a partir de um primeiro dispositivo, e receber os dados do dito conteúdo correspon-dentes à posição de tempo antes da dita determinada posição de tempo do dito conteúdo apartir de pelo menos um segundo dispositivo.
2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de com-preender ainda a etapa de:- exibir o conteúdo com base nos dados recebidos por parte do dito primeiro dispo-sitivo e do dito pelo menos, um segundo dispositivo ao determinar a quantidade de dadosrecebidos do dito primeiro dispositivo e quando o dito pelo menos um segundo dispositivoatinge um valor limite predeterminado.
3. Método, de acordo com a reivindicação 1 ou 2, CARACTERIZADO pelo fato deque os dados recebidos do dito primeiro dispositivo e os dados recebidos do dito pelo me-nos um segundo dispositivo são combinados com base nas informações de seqüência as-sociadas a cada dado.
4. Método, de acordo com a reivindicação 1 ou 2, CARACTERIZADO pelo fato decompreender ainda a etapa de:- em resposta aos dados recebidos a partir do dito primeiro dispositivo e pelo ditopelo menos um segundo dispositivo que atingem um valor limite predeterminado, enviar umamensagem ao dito pelo menos um segundo dispositivo indicativo de uma interrupção datransmissão dos dados correspondentes a um tempo anterior à dita determinada posição detempo, ou descartar ainda os dados recebidos do dito pelo menos um segundo dispositivo.
5. Método, de acordo com qualquer uma das reivindicações 1 a 4,CARACTERIZADO pelo fato de que os dados do dito conteúdo do dito pelo menos um se-gundo dispositivo são recebidos de uma maneira inversa a partir da dita determinada posi-ção de tempo.
6. Método, de acordo com a reivindicação 1 ou 2, CARACTERIZADO pelo fato deque, antes de receber os dados do dito primeiro dispositivo e do dito pelo menos um segun-do dispositivo, o dito dispositivo cliente envia uma mensagem indicativa da sintonização dodito conteúdo para um dispositivo de controle, que é usado para instruir o dito primeiro dis-positivo a transmitir os dados do dito conteúdo a partir da dita determinada posição de tem-po em um fluxo de dados para o dito dispositivo cliente e para o dito menos um segundodispositivo de modo a transmitir os dados do dito conteúdo correspondentes a um tempoanterior à dita determinada posição de tempo para o dito dispositivo cliente.
7. Método, de acordo com qualquer uma das reivindicações 1 a 6,CARACTERIZADO pelo fato de que os dados que começam na dita determinada posiçãode tempo são transmitidos em um fluxo de dados em quaisquer dos seguintes modos deunidifusão, de multidifusão ou de difusão.
8. Dispositivo cliente para o recebimento de um conteúdo, CARACTERIZADO pelofato de compreender:- um módulo receptor (301, 302) configurado para receber os dados carregados emum fluxo de dados a partir de um primeiro dispositivo e receber os dados do pelo menos umsegundo dispositivo; e- um módulo processador (306) configurado para enviar uma mensagem contendouma posição de tempo no sentido de solicitar o dito conteúdo do pelo menos um segundodispositivo, sendo que, em resposta à mensagem enviada, os dados que antecedem a ditaposição de tempo são recebidos do dito pelo menos um segundo dispositivo.
9. Dispositivo cliente, de acordo com a reivindicação 8, CARACTERIZADO pelo fa-to de que o dito módulo processador (306) é ainda configurado para enviar uma mensagemde modo a solicitar o dito conteúdo por parte do dito primeiro dispositivo, sendo que os da-dos subsequentes à dita posição de tempo são recebidos do dito primeiro dispositivo.
10. Dispositivo cliente, de acordo com a reivindicação 8 ou 9, CARACTERIZADOpelo fato de compreender ainda:- um armazenador temporário (303) configurado para armazenar temporariamenteos dados do dito conteúdo recebido do dito primeiro dispositivo e do dito pelo menos umsegundo dispositivo, sendo que os dados do dito conteúdo recebido do dito primeiro disposi-tivo e do dito pelo menos um segundo dispositivo são combinados com base nas informa-ções de seqüência associadas a cada um dos dados.
11. Dispositivo cliente, de acordo com qualquer uma das reivindicações 8 a 10,CARACTERIZADO pelo fato de que os dados do dito conteúdo que antecedem a dita posi-ção são recebidos de uma maneira inversa a partir da dita posição de tempo.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP08305841A EP2192746A1 (en) | 2008-11-26 | 2008-11-26 | Method and apparatus for receiving content |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0904441A2 true BRPI0904441A2 (pt) | 2011-02-01 |
Family
ID=40459798
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0904441-8A BRPI0904441A2 (pt) | 2008-11-26 | 2009-11-24 | método e aparelho para a recepção de conteúdo |
Country Status (7)
| Country | Link |
|---|---|
| EP (2) | EP2192746A1 (pt) |
| JP (1) | JP5610743B2 (pt) |
| KR (1) | KR101625663B1 (pt) |
| BR (1) | BRPI0904441A2 (pt) |
| ES (1) | ES2386518T3 (pt) |
| PL (1) | PL2192740T3 (pt) |
| PT (1) | PT2192740E (pt) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140215071A1 (en) * | 2011-08-18 | 2014-07-31 | Lg Electronics Inc. | Method and device for receiving content |
| CN104009920B (zh) * | 2013-02-25 | 2017-05-31 | 华为技术有限公司 | 数据源移动的处理方法、转发报文的方法及其装置 |
| CN110213308A (zh) * | 2018-02-28 | 2019-09-06 | 杭州海康威视数字技术股份有限公司 | 一种解码视频数据的方法及装置 |
| CN111010603A (zh) * | 2019-12-18 | 2020-04-14 | 浙江大华技术股份有限公司 | 一种视频缓存转发处理方法及装置 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7174385B2 (en) * | 2004-09-03 | 2007-02-06 | Microsoft Corporation | System and method for receiver-driven streaming in a peer-to-peer network |
| JP2007080161A (ja) * | 2005-09-16 | 2007-03-29 | Nec Personal Products Co Ltd | データ配信システム、部分コンテンツ格納サーバ、応答高速化方法、及びプログラム |
| JP2007104085A (ja) * | 2005-09-30 | 2007-04-19 | Toshiba Corp | 通信回線を用いるデジタル放送方法およびその装置 |
| JP2007281868A (ja) * | 2006-04-06 | 2007-10-25 | Nippon Hoso Kyokai <Nhk> | 送信装置及び受信装置 |
| US9325786B2 (en) * | 2006-07-27 | 2016-04-26 | The Hong Kong University Of Science And Technology | Peer-to-peer interactive media-on-demand |
-
2008
- 2008-11-26 EP EP08305841A patent/EP2192746A1/en not_active Withdrawn
-
2009
- 2009-11-04 ES ES09174993T patent/ES2386518T3/es active Active
- 2009-11-04 PL PL09174993T patent/PL2192740T3/pl unknown
- 2009-11-04 PT PT09174993T patent/PT2192740E/pt unknown
- 2009-11-04 EP EP09174993A patent/EP2192740B1/en active Active
- 2009-11-06 JP JP2009255117A patent/JP5610743B2/ja not_active Expired - Fee Related
- 2009-11-11 KR KR1020090108624A patent/KR101625663B1/ko not_active Expired - Fee Related
- 2009-11-24 BR BRPI0904441-8A patent/BRPI0904441A2/pt not_active Application Discontinuation
Also Published As
| Publication number | Publication date |
|---|---|
| EP2192740A1 (en) | 2010-06-02 |
| CN101742244A (zh) | 2010-06-16 |
| JP5610743B2 (ja) | 2014-10-22 |
| ES2386518T3 (es) | 2012-08-22 |
| EP2192740B1 (en) | 2012-06-20 |
| PT2192740E (pt) | 2012-07-16 |
| PL2192740T3 (pl) | 2012-09-28 |
| KR101625663B1 (ko) | 2016-05-30 |
| JP2010130692A (ja) | 2010-06-10 |
| EP2192746A1 (en) | 2010-06-02 |
| KR20100059686A (ko) | 2010-06-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8713195B2 (en) | Method and system for streaming digital video content to a client in a digital video network | |
| US7668914B2 (en) | Milestone synchronization in broadcast multimedia streams | |
| US7904581B2 (en) | Fast channel change with conditional return to multicasting | |
| ES2811769T3 (es) | Suministro de contenido | |
| US8140699B2 (en) | Switching a client from unicasting to multicasting by simultaneously providing unicast and multicast streams to the client | |
| JP5363473B2 (ja) | 改善されたメディア・セッション管理の方法と装置 | |
| CN113612726B (zh) | 用于直播自适应比特率(abr)媒体的优化传递的方法 | |
| US8356324B2 (en) | Implementing network personal video recorder for digital video settop boxes | |
| US7778279B2 (en) | Method and apparatus for instant channel change | |
| CN112771877A (zh) | 用于流式传输媒体数据的服务描述 | |
| CN107431704A (zh) | 用于使用多播机制的直播自适应比特率(abr)媒体的优化传递的系统和方法 | |
| CN101651826A (zh) | 发送和接收媒体的方法、装置以及系统 | |
| WO2017096935A1 (zh) | 一种快速频道切换方法、服务器及iptv系统 | |
| EP3298747B1 (en) | Iptv in managed networks | |
| ES2386518T3 (es) | Método y aparato para recibir contenidos | |
| Haems et al. | Towards efficient transport for Real-Time immersive applications over hybrid networks | |
| ES2968442T3 (es) | Procedimiento y controlador para la distribución de contenido de audio y/o vídeo | |
| CN101742244B (zh) | 用于接收内容的方法和设备 | |
| US20120089743A1 (en) | Method and apparatus for improving quality of service in a multimedia streaming service | |
| Porter | Evaluating and improving the performance of video content distribution in lossy networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B03A | Publication of a patent application or of a certificate of addition of invention [chapter 3.1 patent gazette] | ||
| B06F | Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette] | ||
| B06T | Formal requirements before examination [chapter 6.20 patent gazette] | ||
| B25G | Requested change of headquarter approved |
Owner name: THOMSON LICENSING (FR) |
|
| B25G | Requested change of headquarter approved |
Owner name: THOMSON LICENSING (FR) |
|
| B25A | Requested transfer of rights approved |
Owner name: INTERDIGITAL CE PATENT HOLDINGS (FR) |
|
| B06A | Patent application procedure suspended [chapter 6.1 patent gazette] | ||
| B11B | Dismissal acc. art. 36, par 1 of ipl - no reply within 90 days to fullfil the necessary requirements |