BRPI0608622A2 - mÉtodo para transmitir um comando para um servidor de fluxo de dados digitais e aparelho usado para implementar o dito mÉtodo - Google Patents
mÉtodo para transmitir um comando para um servidor de fluxo de dados digitais e aparelho usado para implementar o dito mÉtodo Download PDFInfo
- Publication number
- BRPI0608622A2 BRPI0608622A2 BRPI0608622-5A BRPI0608622A BRPI0608622A2 BR PI0608622 A2 BRPI0608622 A2 BR PI0608622A2 BR PI0608622 A BRPI0608622 A BR PI0608622A BR PI0608622 A2 BRPI0608622 A2 BR PI0608622A2
- Authority
- BR
- Brazil
- Prior art keywords
- time
- receiver
- server
- value
- continuous
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 30
- 238000011084 recovery Methods 0.000 claims description 16
- 230000002123 temporal effect Effects 0.000 claims description 9
- 230000005540 biological transmission Effects 0.000 claims description 6
- 238000001094 photothermal spectroscopy Methods 0.000 description 30
- 238000010586 diagram Methods 0.000 description 7
- 238000009792 diffusion process Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 230000004044 response Effects 0.000 description 2
- 238000009825 accumulation Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000015654 memory Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000003936 working memory Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
- H04N7/17309—Transmission or handling of upstream communications
- H04N7/17318—Direct or substantially direct transmission and handling of requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/21—Server components or server architectures
- H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
- H04N21/2225—Local VOD servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
- H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
- H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/65—Transmission of management data between client and server
- H04N21/658—Transmission by the client directed to the server
- H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Human Computer Interaction (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
MÉTODO PARA TRANSMITIR UM COMANDO PARA UM SERVIDOR DE FLUXO DE DADOS DIGITAIS E APARELHO USADO PARA IMPLEMENTAR O DITO MÉTODO. É descrito um método para transmitir comandos para um servidor VOD, por exemplo, usando RTSP, que é local para o cliente, os ditos comandos compreendendo uma referência à posição relativa atual. A posição relativa atual é mantida pelo receptor na base do PTS recebido no fluxo continuo MPEG, sem transmitir uma solicitação para o servidor ou basear na existência de um descritor no fluxo continuo que possa ser usado para lidar com saltos no PTS incluido no fluxo continuo.
Description
"MÉTODO PARA TRANSMITIR UM COMANDO PARA UMSERVIDOR DE FLUXO DE DADOS DIGITAIS E APARELHO USADO PARAIMPLEMENTAR O DITO MÉTODO"
A presente invenção diz respeito ao campo do con-trole por um receptor de um servidor de conteúdo sob deman-da- Mais particularmente, no caso em que o servidor "difun-de" seu conteúdo na forma de um fluxo de dados digitais a-través de uma rede IP.
A IETF (Internet Engineering Task Force) definiu,particularmente na RFC (Request For Comment) 2326, um proto-colo de controle de servidores de fluxo de dados digitais.Este protocolo, denominado RTSP (Protocolo de Fluxo Continuoem Tempo Real), é usado para controlar um servidor, abriruma ' sessão, solicitar a inicialização de .um programa, suaparada e inicio temporários ou parada definitiva.
Portanto, usando o RTSP, é possivel implementarmodos de recuperação especial dos programas ("Modos Tru-que" ). Estes modos são usados para fornecer os comandos aosquais os usuários estão acostumados em um gravador de video,para visualizar difusão de programas na IP. Pode-se citarnestes modos avanço rápido e rebobinamento, bem como o posi-cionamento em pontos previamente identificados no programa.
A maioria dos comandos RTSP, notavelmente o coman-do "Play" envolvido nos modos de recuperação específicos,exige um parâmetro dando a marca de tempo da faixa do pro-grama que precisa ser identificada por um intervalo entreuma referência de inicio e uma referência de final. Portan-to, o cliente RTSP deve ser capaz de conhecer precisamente alocalização temporal atual no arquivo reproduzido. Existemdiversas abordagens que permitem que o cliente conheça, emcada momento, a posição temporal atual relativa no programa.Alguns servidores, por exemplo, os servidores Oracle, trans-mitem descritores de tempo misturados com o programa, masnem todos os servidores usam este mecanismo. Uma outra ma-neira de fazer isto envolve o uso, pelo cliente, do comandoRTSP "GET_PARAMETER" para obter a marca de tempo atual doservidor. Esta solução exige o tempo para transmitir a soli-citação e do retorno da resposta. No entanto, este é o méto-do mais comumente usado.
O padrão MPEG, referenciado "MPEG-2 System:ISO/IEC, 1994, Generic Coding of Moving Pictures and Associ-ated Audio: Systems, (MPEG-2 Systems Specification), Novem-ber, ISO/IEC 13818-1", descreve a maneira de multiplexarconteúdo multimídia com. o objetivo da sua recuperação etransporte. Um programa é separado em fluxos contínuos ele-mentares , os fluxos contínuos elementares sendo cortados empacotes de dados.
Em uma maneira como esta para habilitar a recuperação do conteúdo, cada entidade no nivel dos fluxos contí-nuos elementares, por exemplo, uma figura para um fluxo con-tinuo de video, é designada com uma marca de tempo denomina-da PTS (Marca de Tempo de Apresentação). Esta marca de tempomostra o momento no qual a entidade associada, aqui a figu-ra, deve ser restaurada. A base desta marca de tempo é o re-lógio de referência do sistema, um relógio de 90 kHz. Estassão as marcas de tempo que são usadas para sincronizar mutu-amente os vários fluxos contínuos elementares que constituemo programa.
A sucessão destas marcas de tempo de apresentaçãono fluxo continuo do programa é, no geral, não continua doinicio do programa até o final. De fato, um programa podeser o resultado da montagem de diversas seqüências que foramcodificadas separadamente e das quais as marcas de tempo deapresentação não foram calculadas no mesmo sistema de refe-rência de tempo. Além do mais, durante o uso dos modos derecuperação especial, uma técnica atual consiste em usarversões codificadas diferentemente por diferentes modos. Porexemplo, o servidor terá uma versão do programa codificadoem velocidade dupla, a qual ele usará se ele receber um co-mando de avanço rápido. Novamente, aqui as diferentes ver-sões dos programas terão marcas de tempo de apresentaçãocorrespondentes a diferentes sistemas de referência de tem-po. Assim, as marcas de tempo de apresentação presentes nofluxo continuo, no geral, formam uma sucessão de seqüências,cada uma destas seqüências 'correspondendo a um sistema dereferência de tempo especifico.
Portanto, ela envolve encontrar um método confiá-vel de identificação de tempo relativo na difusão do progra-ma pelo cliente RTSP. Este método não se baseia no uso dosdescritores que não estão sempre presentes nos fluxos difun-didos, não exige nenhuma solicitação aos servidores e permi-te que as mudanças no sistema de referência de tempo das se-qüências de marca de tempo de apresentação sejam tratadas.
A invenção propõe um método local para o comandotransmitir cliente para um servidor VOD, por exemplo, de a-cordo com o RSP, estes comandos compreendem uma referência àposição atual relativa. Esta posição atual relativa é manti-da pelo receptor na base do PTS recebido nos fluxos MPEG,sem chamar uma solicitação ao servidor nem baseado na exis-tência no fluxo continuo de um descritor capaz de lidar com.as quebras nas seqüências nos PTSs incluídos no fluxo conti-nuo. A invenção também diz respeito ao cliente adequado paraimplementar o método.
A invenção diz respeito a um método para transmi-tir ordens a um servidor de fluxo continuo de dados digitaispor um receptor, o fluxo continuo digital sendo difundidopelo servidor para o receptor através de uma ligação conec-tando o servidor e o receptor, o fluxo de dados digitaiscompreendendo pelo menos um programa proj etado para ser re-cuperado em uma dada velocidade e marcas de tempo associadascom os dados do fluxo, estas marcas de tempo sendo relativasno momento da recuperação dos dados associados em um sistemade referência de tempo, estes sistemas de referência de tem-po seguindo um ao outro seqüencialmente no fluxo, mudançasno sistema de referência de tempo ocasionando quebras na se-qüência, que podem aparecer no fluxo continuo, compreendendopelo menos os seguintes estágios:
- a recepção do dito fluxo continuo de dados digi-tais;
- transmitir um comando contendo a posição tempo-ral relativa atual no programa contido no fluxo continuo, emque esta posição é determinada localmente pelo receptor, aúnica informação do fluxo continuo intervindo na determina-ção desta posição sendo as marcas de tempo associadas com osdados do fluxo continuo.
De acordo com uma modalidade particular da inven-ção, este também compreende uma etapa de atualização regulardo valor atual da posição de tempo relativa atual.
De acordo com uma modalidade particular da inven-ção, a etapa de atualização compreende uma subetapa para de-terminar um valor Delta correspondente à diferença entre umanova marca de tempo recebida e a última marca de tempo arma-zenada .
De acordo com uma modalidade particular da inven-ção, a etapa de atualização também compreende uma subetapapara comparar o valor Delta e um limite dependendo da velo-cidade de recuperação do fluxo continuo, a presença de umaquebra de seqüência sendo' determinada por um valor Deltamaior que o limite.
De acordo com uma modalidade particular da inven-ção, a etapa de atualização também compreende a adição, nocaso de nenhuma quebra de seqüência, do valor Delta até ovalor atual da posição de tempo mantida.
De acordo com uma modalidade particular da inven-ção, a etapa de atualização também compreende a adição, nocaso de nenhuma quebra de seqüência, do valor Delta multi-plicado pela velocidade de recuperação no valor atual da po-sição de tempo mantida.
A invenção diz respeito a um receptor de fluxocontinuo de dados digitais, o fluxo continuo digital sendodifundido pelo servidor para o receptor através de uma liga-ção conectando o servidor e o receptor, o fluxo de dados di-gitais compreendendo pelo menos um programa proj etado paraser recuperado em uma dada velocidade e marcas de tempo as-sociadas com os dados do fluxo, estas marcas de tempo sendorelativas no momento da recuperação dos dados associados emum sistema de referência de tempo, estas marcas de tempo se-guindo uma à outra seqüencialmente no fluxo, mudanças nosistema de referência de tempo ocasionando quebras de se-qüência , que podem aparecer no fluxo continuo, compreendendopelo menos os seguintes estágios:
- o dispositivo de recepção do dito fluxo continuode dados digitais;
um dispositivo para transmitir um comando con-tendo a posição temporal relativa atual no programa contidono fluxo continuo, em que ele também contém um dispositivopara determinar esta posição localmente pelo receptor, a ú-nica informação do fluxo continuo intervindo na determinaçãodesta posição sendo as marcas de tempo associadas com os da-dos do fluxo continuo.
De acordo com uma modalidade particular da inven-ção, este também compreende dispositivo de atualização regu-lar do valor atual da posição de tempo relativa atual.
De acordo com uma modalidade particular da inven-ção, o dispositivo de atualização compreende dispositivo pa-ra determinar um valor Delta correspondente à diferença en-tre uma nova marca de tempo recebida e a última marca detempo armazenada.De acordo com uma modalidade particular da inven-ção, o dispositivo de atualização também compreende disposi-tivo para comparar o valor Delta e um limite dependendo davelocidade de recuperação do fluxo continuo, a presença deuma quebra de seqüência sendo determinada por um valor Deltamaior que o limite.
De acordo com uma modalidade particular da inven-ção, o dispositivo de atualização também compreende disposi-tivo para adicionar,, no caso de nenhuma quebra de seqüência,o valor Delta ao valor atual da posição de tempo mantida.
De acordo com uma modalidade particular da inven-ção, o dispositivo de atualização também compreende disposi-tivo para adicionar, no caso de nenhuma quebra de seqüência,o valor Delta multiplicado pela velocidade de recuperação novalor atual da posição de tempo mantida.
A invenção será mais bem entendida, e outros re-cursos e vantagens específicos irão emergir da leitura daseguinte descrição, a descrição fazendo referência aos dese-nhos anexos em que:
a Figura 1 mostra a arquitetura conhecida de umserviço VOD (Video Sob Demanda).
A Figura 2 mostra a arquitetura de hardware da mo-dalidade do decodificador IP.
A Figura 3 mostra a arquitetura do suporte lógicoda modalidade do decodificador IP.
A Figura 4 mostra um exemplo do diálogo RTSP entreum cliente e um servidor.
A Figura 5 mostra um diagrama das imagens recebi-das durante uma recuperação em velocidade normal com os va-lores PTS associados.
A Figura 6 mostra um diagrama das imagens recebi-das e o PTS associado para avanço rápido.
A Figura 7 mostra um diagrama das imagens recebi-das e os PTSs associados durante a passagem de uma recupera-ção em velocidade normal para avanço rápido.
A Figura 8 mostra um diagrama das imagens recebi-das e o PTS associado a não intervalo para uma recuperaçãoem velocidade normal,
A Figura 9 mostra um diagrama das imagens recebi-das e os PTSs associados durante a passagem de uma recupera-ção em velocidade normal para avanço rápido com uma mudançano intervalo.
A Figura 10 mostra um fluxograma do método de i-dentificação temporal do decodificador.
Uma modalidade da invenção será agora descrita.
Esta modalidade da invenção se enquadra no contex-to do sistema de serviço de video sob demanda (VOD) . A ar-quitetura geral de um sistema como este é descrita na figura1. 0 sistema compreende um ou mais servidores, referenciados1.1. Estes servidores armazenam os programas a difundir e.podem transmiti-los na forma de fluxos contínuos de dados.Os usuários do sistema, tipicamente assinantes individuaisdos serviços, terão em suas casas uma tela de exibição deserviço, referenciada 1.5, um decodificador 1.4, tipicamen-te, um MPEG habilitando a decodificação do fluxo continuo dedados digitais recebidos em sinais analógicos transmitidospara a tela. No contexto aqui descrito, o decodificador é umdecodificador IP adequado para receber programas através deuma rede IP, referenciada 1.2. 0 modem, referenciado 1.3, éusado para conectar a rede do usuário na rede de distribui-ção IP 1.2 que pode ser a Internet ou a rede de distribuiçãoIP privada do provedor de serviço de video sob demanda. Emum sistema como este, o decodificador será o cliente RTSPque controla a difusão do programa pelo servidor através doprotocolo RTSP em resposta às solicitações do usuário. O padrão MPEG define a maneira de codificar e mul-
tiplexar os diferentes fluxos contínuos elementares compondoum programa multimídia. Este programa, tipicamente, um pro-grama audiovisual, é composto por diferentes fluxos contí-nuos elementares. No geral, encontra-se um fluxo continuo de video e um ou mais fluxos contínuos de áudio. Cada fluxocontinuo elementar inclui entidades, denominadas unidades deapresentação, no padrão. A cada uma destas entidades é de-signada uma marca de tempo de apresentação conhecida comoPTS dando o sistema de referência de tempo do codificador, que está de acordo com seu sistema do relógio, o momento noqual esta entidade ou unidade de apresentação deve ser recu-perada pelo decodificador. É a presença destas marcas detempo de apresentação que habilita, entre outras coisas, osdiferentes fluxos contínuos elementares a ser sincronizadosquando o decodificador recupera o programa. Tipicamente, nocaso do video, a entidade ou unidade de apresentação será umaimagem, ao passo que ela será uma amostra no caso do áudio.
A Figura 2 descreve a arquitetura de hardware dodecodificador MPEG da modalidade da invenção. Este decodifi-cador, referenciado 2.1, é conectado no modem, referenciado2.2, através de uma interface Ethernet, referenciada 2.7.Ele fornece à TV, referenciada 2.5, os sinais analógicosprovenientes da decodificação dos programas. O decodificadoropera sob o controle de um processador central, referenciado2.9. Este processador executa os programas armazenados emuma memória flash, referenciada 2.10, usando a RAM, referen-ciada 2.11, como a memória de trabalho. O fluxo continuoMPEG é recebido através do modem 2.2 e da interface Ethernet2.7, então ele é transmitido para o decodificador de áudio evideo 2.6, este decodificador . separa os diferentes fluxoscontínuos elementares e decodifica-os . se eles estiverem co-dificados, bem com descomprime-os. Então, os fluxos contínuosde áudio e video elementares descomprimidos são transmitidospara um conversor digital para analógico, referenciado 2.4.Um processador gráfico, referenciado 2.8, é responsável porgerar gráficos que são sobrepostos nas imagens de video, es-tes são, tipicamente, gráficos de interface de usuário oudados de guia do programa ou outros. 0 módulo de conversãodigital para analógico 2.4 produz os sinais analógicos con-tendo os programas e os gráficos. Estes sinais serão trans-mitidos para o dispositivo de recuperação de programa, tipi-camente, um conjunto de televisão, referenciado 2.3.
A Figura 3 mostra um diagrama da arquitetura dosuporte lógico implementado em um decodificador como este deacordo com a modalidade da invenção. Ela contém uma camadade acionadores, referenciada 3.6, sendo usada para controlaro hardware, referenciado 3.7. Um Sistema Operacional em Tem-po Real (RTOS) prove a operação básica do dispositivo. Nogeral, um módulo de acesso condicional, referenciado 3.4,será responsável por garantir que o usuário tenha o direitode habilitar os programas a ser visualizados. Para gerenciara comunicação e, particularmente, a recepção dos programas,uma pilha de comunicação IP, referenciada 3.3, dialoga com arede incluindo o servidor de video sob demanda. 0 gerencia-mento do acesso ao serviço de video sob 'demanda é dedicado aum módulo VOD, referenciado 3.8, disposto sobre IP e que irágerenciar o diálogo com o servidor VOD. É neste módulo queestá localizado o dispositivo de implementação da invençãode acordo com a modalidade descrita. No nivel mais alto, en-contra-se um conjunto de aplicações referenciado 3.2, permi-tindo que seja oferecido ao usuário um conjunto de serviços,entre os quais, uma interface de escolha de programa e, fre-qüentemente, um guia de programa.
A Figura 4 representa um exemplo de um diálogo en-tre o cliente e o servidor VOD usando o protocolo RTSP deacordo com a modalidade da invenção. RTSP é um protocoloservidor / cliente que habilita o gerenciamento dos comandosde um servidor de difusão em tempo real dos programas. Esteprotocolo somente gerencia os comandos, ele não leva em con-sideração a transmissão dos dados, que é feito por outrosprotocolos. RTSP é, no geral, acoplado com a transmissão dedados de acordo com o RAP (Protocolo de Transporte em TempoReal) descrito na RFC 1889. Mas o servidor é livre para usarqualquer protocolo que ele escolher para transmitir os da-dos. Pode-se, por exemplo, transmitir os dados diretamenteem UP (Protocolo de Datagrama de Usuário, RFC 768), um pro-tocolo no qual o RAP é baseado.
0 RTSP dá ao cliente a possibilidade de abrir umasessão no servidor através do comando "SETUP". Esta sessãodefine o programa solicitado, o destino, o modo de transpor-te bem como vários outros parâmetros. Então, ele permite queo servidor seja solicitado a transmitir dados para uma faixade programa especificando a velocidade de recuperação atra-vés do comando "PLAY". Também é possivel solicitar que oservidor pause a transmissão de dados através do comando"PAUSE". 0 fim da sessão ocorre com um comando "TEARDOWN". Adescrição completa deste protocolo é referenciada em RFC2326.
No exemplo da figura 4, o cliente VOD, portanto odecodificador, inicializa uma sessão através de uma mensagemMl contendo o comando "SETUP". Este comando especifica que ocliente deseja o programa cujo endereço értsp://192.9.210.233:5004/asset/vscontsrv%3vodstream_scr-free-f usando a versão 1.0 do protocolo RTSP no melhor modoatravés do protocolo UP para o endereço 192.9.210.23 na por-ta 20000.
O servidor responderá pela mensagem de aceitaçãoM2. Vê-se aqui que o servidor transmite um argumento"a=range:pts=7 5621-2146421", este argumento especifica que oprograma transmitido contém marcas de tempo de apresentaçãoiniciando no valor 75621 e terminando no valor 2146421. Estainformação pode ser usada pelo cliente para ser subseqüente-mente localizada temporariamente no programa. De fato, umamarca de tempo de apresentação recebida deve habilitar a en-tidade de programa associada a ser localizada em relação aestes limites que são denominados "PTS_start" e "PTS_end".Vê-se que, .infelizmente, nem todos os servidores transmitemeste argumento e que mesmo quando ele está disponível, asmarcas de tempo na difusão do programa não são sempre calcu-ladas no mesmo sistema de referência que este intervalo re-tornado em aceitação ao "SETUP".
Então, o cliente é capaz de solicitar que o servidor comece a transmitir o programa transmitindo a mensagemM3 contendo um comando "PLAY". 0 "PLAY" deve conter uma in-dicação da faixa do programa que se deseja receber. Estafaixa pode ser a integra do programa, este é o caso aqui,que é indicada pelo argumento "Range: npt=0.00-end". Há di-versas maneiras de indicar uma faixa de programa, diversasmaneiras de indicar o tempo, o exemplo usa notação NPT (Tem-po de Reprodução Normal), que indica a posição de tempo nofluxo continuo relativamente ao inicio do programa na formade uma fração decimal. A parte esquerda da fração dá o tempoem segundos ou horas, minutos e segundos, ao passo que aparte direita mede frações de segundos. Portanto, a mensagemM3 solicita a difusão da integra do programa do seu começo"0.00" até o final "end".
A mensagem M4 é uma aceitação da mensagem M3.
Um pouco depois, durante a difusão, o consumidorsolicita uma pausa através de uma mensagem M5. Esta pausa éaceita através da mensagem M6.Quanto à mensagem M7, ela é uma mensagem que soli-cita um avanço rápido em 8 vezes a velocidade normal a par-tir do ponto atual do programa - Portanto, o argumento dafaixa usada é "Range: npt=42.72-end" e a velocidade da re-produção é passada através do argumento "Scale: 8.0". A men-sagem M8 é uma aceitação da mensagem M7.
0 exemplo de comunicação exposto mostra a impor-tância da.localização temporal na difusão do fluxo continuopara o decodificador. De fato, por exemplo, quando o decodi-ficador solicita uma mudança para avanço rápido na velocida-de 8 como na mensagem M7, ele deve dar o ponto de inicio dafaixa solicitada. Este ponto de inicio deve corresponder e-xatamente ao ponto atual da difusão do programa para que ousuário não.perceba nenhum salto durante o modo de mudança.
Há diferentes meios para o decodificador conhecera posição de tempo atual no fluxo continuo. O exemplo ilus-tra que o servidor, quando reconhece o comando "SETUP", dáos limites das marcas de tempo de apresentação usadas na di-fusão do fluxo continuo. Estes limites são denominadosPTS_Start e PTS_End. Entretanto, o fluxo continuo MPEG di-fundido contém marcas de tempo de apresentação associadascom as imagens do programa da forma ilustrada na figura 5.Nesta figura, cada seta representa uma imagem recebida du-rante a difusão de um programa com o valor de marca de tempode apresentação associado. A difusão iniciando no momentoTO, a primeira imagem recebida será associada com o PTS_1tendo o valor value_l. A segunda imagem recebida será asso-ciada com o PTS_2 tendo o valor value_2 e assim por diante.Logicamente, o valor value_l corresponde ao PTS_Start. Nestediagrama, é possível localizar a si próprio no tempo em re-lação ao inicio do programa de acordo com a última marca detempo de apresentação recebida, ela é suficiente para sub- trair deste último valor PTS o valor armazenado do PTS_Startpara conhecer o tempo relativo atual em relação ao inicio doprograma. Este tempo será conhecido na precisão do relógiode 90 kHz usado para gerar o PTS.
A Figura 6 ilustra um avanço rápido no dobro da velocidade em relação à velocidade normal. Vê-se aqui queuma imagem em 2 é recebida com as marcas de tempo associa-das. Portanto, a primeira imagem é associada com um PTS devalor value_l, enquanto que a segunda corresponde à terceiraimagem do programa reproduzido em velocidade normal e é as- sociada com um PTS de valor value_3 correspondente ao momen-to da apresentação desta terceira imagem se o fluxo continuofoi reproduzido em velocidade normal. Portanto, vê-se nova-mente que aqui um posicionamento com base na diferença doúltimo PTS recebido com o PTS_Start ainda dá o tempo relati- vo atual em relação ao inicio do programa.
A Figura 7 ilustra o caso em que.a passagem para odobro da velocidade ocorre durante a difusão no momento tl.Novamente, aqui, se um estiver entre tO e tl durante a difu-são em velocidade normal ou entre tl e t2 durante a difusão no dobro da velocidade, a mesma técnica ainda dá um temporelativo atual confiável em relação ao inicio do programa.
Infelizmente, pode-se ver por um lado que nem to-dos os servidores dão a informação de faixa PTS quando umcomando "SETUP" é reconhecido. Além do mais, mesmo no casoem que o servidor dá esta faixa, ele constata que as marcasde tempo de apresentação contidas no fluxo recebido algumasvezes são calculadas em um sistema de referência de tempodiferente do sistema de referência usado para calcular osvalores PTS_Start e PTS_End comunicados pelo servidor. Tam-bém acontece que a difusão do programa é uma montagem de di-versas seqüências que foram separadamente codificadas. Nestecaso, no geral, cada seqüência tem marcas de tempo de apre-sentação calculadas em seu próprio sistema de referência detempo. As mudanças no sistema de referência seguem durante adifusão. Esta situação é descrita na figura 8, aqui os valo-res denominados value_l, value_2 e value_3 correspondem auma primeira seqüência. Uma mudança da seqüência ocorre nomomento tl. Os valores denominados value_x4 e value_x5 cor-respondem a uma segunda seqüência. Cada seqüência foi codi-ficada em seu próprio sistema de referência, uma quebra deseqüência ocorre entre as duas.
Igualmente, os servidores podem explorar diferen-tes versões do programa para implementar os modos de recupe-ração particular tais como avanço rápido ou rebobinamento.Neste caso, o servidor tem uma versão do programa para difu-são normal e versões codificadas em diferentes velocidadespara responder às solicitações de recuperação em velocidadelenta ou acelerada. Por exemplo, uma versão diferente con-tendo uma de duas imagens será usada para difusão em veloci-dade dupla. Aqui, novamente, cada versão terá, no geral,marcas de tempo de apresentação calculadas em um sistema dereferência de tempo diferente. Esta situação é ilustrada nafigura 9. Nesta figura, ocorre uma solicitação de recupera-ção em velocidade dupla no momento tl, os valores do PTS va-lue_x4 e value_x6 estão em um diferente diferencial de tempodos valores value_l, value_2 e value_3 da difusão do fluxocontinuo em velocidade normal entre tO e tl.
Uma das soluções para estes problemas com as que-bras de seqüência é a inserção do "descritor NPT" da formadescrita no capitulo 8 do padrão DSM-CC . (ISO/IEC 13818-6) .Estes descritores são inseridos no fluxo continuo no momentodas quebras de seqüência e indicam a correspondência entreas marcas de tempo de apresentação da seqüência e um sistemade referência lógica para o fluxo continuo. Mas nem todos osservidores usam esta possibilidade.
Uma outra maneira de resolver estes problemas con-siste em não usar as marcas de tempo recebidas, mas em soli-citar ao servidor o valor do tempo relativo atual a cada vezque ele é exigido. Existe um mecanismo no RTSP para solici-tar parâmetros do servidor na forma de um comando"GET_PARAMETER". Neste caso, antes de transmitir um comandotendo o uso" de um argumento de faixa, tal como o comando"PLAY", o cliente solicita, usando o comando"GET_PARAMETER", a posição atual de tempo relativo do fluxocontinuo. No geral, este método é funcional, mas introduz umtempo correspondente à transmissão do comando e ao retornodo resultado bem como ao correspondente uso da largura debanda.
Agora será descrito um exemplo de um método confi-ável para o cálculo local da posição de tempo relativa atualdo fluxo continuo sem exigir a inserção de descritores peloservidor nem a transmissão de uma solicitação para o servi-dor . Este método também permite lidar com as quebras de se-qüência nas marcas de tempo de apresentação. Este método éilustrado na figura 10. Ele consiste em manter um valor atu-al relativo no inicio do programa e atualizar este valor deacordo com os valores das marcas de tempo recebidas. Estemétodo é descrito na figura 10. Durante uma primeira etapaEl, realizada no inicio da difusão do programa, o primeiroPTS recebido é memorizado em uma variável First_PTS. Uma va-riável Current_time é a j ustada em 0. Esta variável irá con-ter em todos os momentos a posição de tempo relativa atualno programa. A variável Last_PTS também é ajustada, corres-pondendo ao valor do último PTS recebido, no valor do pri-meiro PTS.
Depois, quando um novo valor PTS for recebido nofluxo continuo, a etapa E2 é realizada. Esta etapa consisteem calcular a diferença entre este novo PTS recebido e o an-terior memorizado em Last_PTS. Esta informação é armazenadaem uma variável Delta.
Com o objetivo de detectar as quebras de seqüên-cia, o valor Delta é comparado com um limite. De fato, es-tando as marcas de tempo de apresentação associadas com en-tidades do fluxo continuo, tipicamente imagens de vídeo, épossível determinar a diferença esperada entre dois PTS su-cessivos recebidos. Tipicamente, esta diferença é a freqüên-cia da imagem expressa de acordo com um relógio de 90 kHz.Naturalmente, a velocidade de recuperação atual deve serconsiderada. Portanto, é possível determinar um valor Limi-te, por exemplo, igual a duas vezes a freqüência da imagem,ou a freqüência da imagem multiplicada pela velocidade máxi-ma do servidor mais um coeficiente de segurança. Quando ovalor Delta.for maior que este limite, considera-se que háuma quebra de seqüência. Caso contrário, considera-se quenão há quebra de seqüência. Na ausência de qualquer quebrade seqüência, a etapa E4 é realizada, consistindo em acumu-lar o valor Delta no tempo atual. Em todos os casos, o valordo último PTS recebido é atualizado com o valor do novo PTSna etapa E5. Depois, retorna-se à etapa E2 na recepção deuma nova marca de tempo de apresentação no fluxo continuo.
Desta maneira, a variável Current_time contém, emqualquer momento, uma acumulação das diferenças entre asmarcas de tempo que pertencem à mesma seqüência. Nenhum tem-po é acumulado na quebra de seqüência.
Quando o decodifiçador tiver que transmitir um co-mando para o servidor solicitando uma faixa da qual um doslimites é o tempo atual, ele usará este valor como a base dotempo atual. 0 cálculo de um valor NPT em segundos é diretoe corresponde à Current_time dividida pela freqüência da i-magem.
Nos modos de recuperação particular em que o fluxonão é reproduzido em velocidade normal, a saber, os modos decâmera lenta ou velocidade acelerada, o método descrito faza hipótese que as marcas de tempo de apresentação inseridasno fluxo continuo são as marcas de tempo calculadas para umarecuperação em velocidade normal- De fato, a diferença entredois PTS é considerada representando a diferença de tempo noprograma entre as duas entidades correspondentes durante umarecuperação em modo normal. Constata-se que algum servidor,a fim de se conformar com o padrão MPEG, irá gerar novasmarcas de tempo de apresentação nos modos de recuperação emvelocidade modificada em relação à velocidade normal. Porexemplo, em velocidade acelerada de'um fator de 4, duas ima-gens sucessivas separadas por outras 3 imagens no fluxo con-tinuo propostas para modo normal serão designadas com valo-res PTS separados da freqüência da imagem no lugar dos valo-res PTS calculados no fluxo continuo proposto para modo nor-mal e separados por 4 vezes a freqüência da imagem. Uma va-riante do método descrito consiste em comparar, durante umarecuperação em velocidade modificada, a diferença entre doisvalores de marca de tempo com a freqüência da imagem. Se es-ta diferença estiver próxima à freqüência da imagem em vezde ser o produto pela velocidade de recuperação, o delta se-rá multiplicado pela velocidade antes de ser acumulado notempo atual.
A modalidade da invenção é baseada nas marcas detempo de apresentação MPEG bem como no uso do protocolo RTSPusando faixas definidas na forma NPT, mas a invenção podeser generalizada para outros tipos de marcas de tempo inclu-ídas em um fluxo de dados digitais bem como para outros pro-tocolos de comando de servidor e independente do método decodificação de dados de tempo usado por este protocolo. Oexemplo de modalidade é baseado na difusão do fluxo continuoem uma rede IP, mas a invenção pode ser estendida a outrostipos de redes.
Claims (12)
1. Método para transmitir pedidos a um servidor defluxo continuo de dados digitais por um receptor,CARACTERIZADO pelo fato de que o fluxo continuo digital édifundido pelo servidor para o receptor através de uma liga-ção conectando o servidor e o receptor, o fluxo de dados di-gitais compreendendo pelo menos um programa projetado paraser recuperado em uma dada velocidade e marcas de tempo as-sociadas com os dados do fluxo, estas marcas de tempo sendorelativas ao momento da recuperação dos dados associados emum sistema de referência de tempo, estas marcas de tempo se-guindo uma à outra seqüencialmente no fluxo, mudanças nosistema de referência de tempo ocasionando quebras de se-qüência capazes de aparecer no fluxo continuo, compreendendopelo menos os seguintes estágios:- recepção do dito fluxo continuo de dados digi-tais,transmissão de um comando contendo a posiçãotemporal relativa atual no programa contido no fluxo conti-nuo, em que esta posição é determinada localmente pelo re-ceptor, a única informação do fluxo continuo que interferena determinação desta posição sendo as marcas de tempo asso-ciadas com os dados do fluxo continuo.
2. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que também compreende uma etapade atualização regular do valor atual da posição de temporelativa atual.
3. Método, de acordo com a reivindicação 2,CARACTERIZADO pelo fato de que a etapa de atualização com-preende uma subetapa para determinar um valor Delta corres-pondente à diferença entre uma nova marca de tempo recebidae a última marca de tempo armazenada.
4. Método, de acordo com a reivindicação 3,CARACTERIZADO pelo fato de que a etapa de atualização tambémcompreende uma subetapa para comparar o valor Delta e um li-mite dependendo da velocidade de recuperação do fluxo conti-nuo, a presença de uma quebra de seqüência sendo determinadapor um valor Delta maior que o limite.
5. Método, de acordo com a reivindicação 4,CARACTERIZADO pelo fato de que a etapa de atualização tambémcompreende a adição, no caso de nenhuma quebra de seqüência,do valor Delta no valor atual da posição de tempo mantida.
6. Método, de acordo com a reivindicação 4,CARACTERIZADO pelo fato de que a etapa de atualização tambémcompreende a adição, no caso de nenhuma quebra de seqüência,do valor Delta multiplicado pela velocidade de recuperaçãono valor atual da posição de tempo mantida.
7. Receptor de fluxo continuo de dados digitais,CARACTERIZADO pelo fato de que o fluxo continuo digital édifundido pelo servidor para o receptor através de uma liga-ção conectando o servidor e o receptor, o fluxo de dados di-gitais compreendendo pelo menos um programa projetado paraser recuperado em uma dada velocidade e marcas de tempo as-sociadas com os dados do fluxo, estas marcas de tempo sendorelativas no momento da recuperação dos dados associados emum sistema de referência de tempo, estas marcas de tempo se-guindo uma à outra seqüencialmente no fluxo, mudanças nosistema de referência de tempo ocasionando quebras de se-qüência capazes de aparecer no fluxo continuo, compreendendopelo menos os seguintes estágios:- dispositivo de recepção do dito fluxo continuode dados digitais,- dispositivo para transmitir um comando contendoa posição temporal relativa atual no programa contido nofluxo continuo, em que ele também contém dispositivo para determinar esta posição localmente pelo receptor, a únicainformação do fluxo continuo intervindo na determinação des-ta posição sendo as marcas de tempo associadas com os dadosdo fluxo continuo.
8. Receptor, de acordo com a reivindicação 7,CARACTERIZADO pelo fato de que também compreende um disposi-tivo de atualização regular do valor atual da posição detempo relativa atual.
9. Receptor, de acordo com a reivindicação 8,CARACTERIZADO pelo fato de que o dispositivo de atualizaçãocompreende dispositivo para determinar um valor Delta cor-respondente à diferença entre uma nova marca de tempo rece-bida e a última marca de tempo armazenada.
10. Receptor, de acordo com a reivindicação 9,CARACTERIZADO pelo fato de que o dispositivo de atualização também compreende um dispositivo para comparar o valor Deltae um limite dependendo da velocidade de recuperação do fluxocontinuo, a presença de uma quebra de seqüência sendo deter-minada por um valor Delta maior que o limite.
11. Receptor, de acordo com a reivindicação 10,CARACTERIZADO pelo fato de que o dispositivo de atualizaçãotambém compreende dispositivo para adicionar, no caso de ne-nhuma quebra de seqüência, o valor Delta no valor atual da posição de tempo mantida.
12. Receptor, de acordo com a reivindicação 10,CARACTERIZADO pelo fato de que o dispositivo de atualizaçãotambém compreende dispositivo para adicionar, no caso de ne-nhuma quebra de seqüência, o valor. Delta multiplicado pela velocidade de recuperação no valor atual da posição de tempomantida.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0503011A FR2883692A1 (fr) | 2005-03-25 | 2005-03-25 | Procede d'envoi de commande a un serveur de flux de donnees numeriques et appareil implementant le procede |
| PCT/EP2006/060956 WO2006100268A2 (fr) | 2005-03-25 | 2006-03-22 | Procede d'envoi de commande a un serveur de flux de donnees numeriques et appareil implementant le procede |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0608622A2 true BRPI0608622A2 (pt) | 2010-01-19 |
Family
ID=35482262
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0608622-5A BRPI0608622A2 (pt) | 2005-03-25 | 2006-03-22 | mÉtodo para transmitir um comando para um servidor de fluxo de dados digitais e aparelho usado para implementar o dito mÉtodo |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US8677442B2 (pt) |
| EP (1) | EP1862009B1 (pt) |
| JP (1) | JP4719789B2 (pt) |
| CN (1) | CN101151901B (pt) |
| BR (1) | BRPI0608622A2 (pt) |
| FR (1) | FR2883692A1 (pt) |
| WO (1) | WO2006100268A2 (pt) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5211569B2 (ja) * | 2007-07-26 | 2013-06-12 | ソニー株式会社 | コンテンツ再生装置、コンテンツ再生方法、およびプログラム |
| US8265168B1 (en) * | 2008-02-01 | 2012-09-11 | Zenverge, Inc. | Providing trick mode for video stream transmitted over network |
| CN101287107B (zh) * | 2008-05-29 | 2010-10-13 | 腾讯科技（深圳）有限公司 | 媒体文件的点播方法、系统和设备 |
| CN101459693A (zh) * | 2008-12-29 | 2009-06-17 | 中兴通讯股份有限公司 | 一种流媒体下载方法及系统 |
| US8018934B2 (en) * | 2009-03-20 | 2011-09-13 | Cisco Technology, Inc. | Switched unicast in an internet protocol television environment |
| CN102648636B (zh) | 2009-10-21 | 2016-08-17 | 爱立信(中国)通信有限公司 | 用于媒体位置控制的方法、设备和系统 |
| US8357887B2 (en) * | 2010-03-30 | 2013-01-22 | Rich Ventures Llc | Microwavable apparatus capable of keeping food moist |
| US7950845B1 (en) * | 2010-06-03 | 2011-05-31 | Omar Syed | Time keeping system for turn-based games |
| KR101712102B1 (ko) * | 2010-07-29 | 2017-03-14 | 삼성전자 주식회사 | Ｒｔｓｐ 세션에 기초해 스트리밍 데이터를 송수신하는 방법 및 장치 |
| WO2015052908A1 (ja) * | 2013-10-11 | 2015-04-16 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ | 送信方法、受信方法、送信装置および受信装置 |
| WO2017155271A1 (ko) | 2016-03-07 | 2017-09-14 | 엘지전자 주식회사 | 무선 통신 시스템에서 트랜스포트를 통해 스트리밍을 제공받는 방법 및 장치 |
| CN111836071B (zh) * | 2020-07-16 | 2021-01-05 | 全时云商务服务股份有限公司 | 一种基于云会议的多媒体处理方法、装置及存储介质 |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6334219B1 (en) * | 1994-09-26 | 2001-12-25 | Adc Telecommunications Inc. | Channel selection for a hybrid fiber coax network |
| US5898695A (en) * | 1995-03-29 | 1999-04-27 | Hitachi, Ltd. | Decoder for compressed and multiplexed video and audio data |
| US6215505B1 (en) * | 1997-06-20 | 2001-04-10 | Nippon Telegraph And Telephone Corporation | Scheme for interactive video manipulation and display of moving object on background image |
| KR100247978B1 (ko) * | 1997-08-08 | 2000-03-15 | 윤종용 | 픽쳐 디코딩 동기화 회로 및 그 방법 |
| US6802074B1 (en) * | 1999-05-31 | 2004-10-05 | Matsushita Electric Industrial Co., Ltd. | Recording apparatus, transmitting apparatus, and computer-readable recording medium |
| DE60034409T2 (de) * | 1999-10-15 | 2007-08-16 | Matsushita Electric Industrial Co., Ltd., Kadoma | Vorrichtung zur Datenanzeige von mehreren Datenkanälen und Datenträger und Rechnerprogramm dafür |
| US6681397B1 (en) * | 2000-01-21 | 2004-01-20 | Diva Systems Corp. | Visual improvement of video stream transitions |
| JP2002209234A (ja) * | 2001-01-11 | 2002-07-26 | Fujitsu Ltd | 通信システム |
| GB0117926D0 (en) * | 2001-07-23 | 2001-09-12 | Nds Ltd | Method for random access to encrypted content |
| US20030066094A1 (en) * | 2001-09-29 | 2003-04-03 | Koninklijke Philips Electronics N.V. | Robust method for recovering a program time base in MPEG-2 transport streams and achieving audio/video sychronization |
| CN1436001A (zh) * | 2002-01-28 | 2003-08-13 | 北京华诺信息技术有限公司 | 解码系统中实现视频与音频同步的方法 |
| US7610606B2 (en) * | 2002-05-03 | 2009-10-27 | Time Warner Cable, Inc. | Technique for effectively providing various entertainment services through a communications network |
| US7530084B2 (en) * | 2002-05-28 | 2009-05-05 | Sony Corporation | Method and apparatus for synchronizing dynamic graphics |
| AU2003275200A1 (en) * | 2002-09-19 | 2004-04-08 | Thomson Licensing S.A. | Hybrid video on demand using mpeg 2 transport |
| JP2004120440A (ja) * | 2002-09-26 | 2004-04-15 | Toshiba Corp | サーバー装置及びクライアント装置 |
| US7953194B2 (en) * | 2002-09-27 | 2011-05-31 | Broadcom Corporation | Handling video transition errors in video on demand streams |
| KR100482287B1 (ko) * | 2002-10-26 | 2005-04-14 | 한국전자통신연구원 | 디지털 데이터 방송을 위한 동기화 스트림 데이터 삽입장치 및 그 방법 |
| EP1439700A1 (en) * | 2003-01-16 | 2004-07-21 | Deutsche Thomson-Brandt Gmbh | Method of assigning an absolute time value to an entry point of a data stream sequence |
| JP3943516B2 (ja) * | 2003-03-27 | 2007-07-11 | 松下電器産業株式会社 | 画像再生装置 |
| JP4315827B2 (ja) * | 2004-01-29 | 2009-08-19 | 株式会社日立国際電気 | 画像表示方法及び画像表示装置並びに画像表示プログラム |
| US7657583B2 (en) * | 2004-12-29 | 2010-02-02 | International Business Machines Corporation | Calculating recovery time of an application system |
| US7735111B2 (en) * | 2005-04-29 | 2010-06-08 | The Directv Group, Inc. | Merging of multiple encoded audio-video streams into one program with source clock frequency locked and encoder clock synchronized |
| JP4282722B2 (ja) * | 2007-01-31 | 2009-06-24 | 株式会社東芝 | ストリーム記録装置 |
-
2005
- 2005-03-25 FR FR0503011A patent/FR2883692A1/fr active Pending
-
2006
- 2006-03-22 CN CN2006800097458A patent/CN101151901B/zh not_active Expired - Fee Related
- 2006-03-22 EP EP06725239.5A patent/EP1862009B1/fr not_active Ceased
- 2006-03-22 BR BRPI0608622-5A patent/BRPI0608622A2/pt not_active IP Right Cessation
- 2006-03-22 JP JP2008502408A patent/JP4719789B2/ja not_active Expired - Fee Related
- 2006-03-22 US US11/886,819 patent/US8677442B2/en not_active Expired - Fee Related
- 2006-03-22 WO PCT/EP2006/060956 patent/WO2006100268A2/fr not_active Ceased
Also Published As
| Publication number | Publication date |
|---|---|
| US8677442B2 (en) | 2014-03-18 |
| JP4719789B2 (ja) | 2011-07-06 |
| WO2006100268A3 (fr) | 2007-07-12 |
| EP1862009B1 (fr) | 2017-11-22 |
| EP1862009A2 (fr) | 2007-12-05 |
| CN101151901A (zh) | 2008-03-26 |
| WO2006100268A2 (fr) | 2006-09-28 |
| US20090217328A1 (en) | 2009-08-27 |
| CN101151901B (zh) | 2011-01-12 |
| JP2008535298A (ja) | 2008-08-28 |
| FR2883692A1 (fr) | 2006-09-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10820065B2 (en) | Service signaling recovery for multimedia content using embedded watermarks | |
| KR101759959B1 (ko) | 미디어 컴포넌트 송수신 방법 및 그를 이용한 송수신 장치 | |
| KR101786050B1 (ko) | 데이터 전송 방법 및 장치 | |
| US6034746A (en) | System and method for inserting data into a digital audio/video data stream | |
| KR101748198B1 (ko) | 다수의 오버 더 탑 스트리밍 클라이언트들의 동기화 | |
| US7830908B2 (en) | Systems and methods of reducing delay in decoding | |
| US9281011B2 (en) | System and methods for encoding live multimedia content with synchronized audio data | |
| BR112014026741B1 (pt) | Método para estruturar os dados de conteúdo a serem servidos utilizando um servidor de mídia, servidor de mídia e memória legível por computador | |
| CN112672163B (zh) | 用于分段流动性的代码转换器调节 | |
| KR20140031929A (ko) | 미디어 컨텐트 송수신 방법 및 그를 이용한 송수신 장치 | |
| BRPI0608622A2 (pt) | mÉtodo para transmitir um comando para um servidor de fluxo de dados digitais e aparelho usado para implementar o dito mÉtodo | |
| US20200267423A1 (en) | Method for initiating a transmission of a streaming content delivered to a client device and access point for implementing this method | |
| US20100262492A1 (en) | Method and arrangement relating to a media structure | |
| US10277924B1 (en) | Stitching content streams together | |
| JP2005123907A (ja) | データ再構成装置 | |
| CN101489122B (zh) | 实现传输流时间映射的方法、装置及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B08F | Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette] | ||
| B08K | Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette] |