1414 comentários

• Bengt Karlsson(usuário não autenticado)

  12 de Março de 2008, 17:59

   

  Posso dividir com você a minha opinião, será que ajuda? :)

  A questão de interatividade vai além do canal de retorno, mas como você perguntou especificamente do canal de retorno, acho que é essa a parte que lhe interessa.

  Existem diversos meios possíveis para o canal de retorno. A princípio, acredito que os STBs vão oferecer o uso da linha telefônica como canal de retorno, como aconteceu pelo mundo com os boxes dos outros padrões. Outra forma que não deve demorar a chegar no mercado é o uso da rede ethernet, que também já vem sendo usado fora do Brasil. Mas isso é só o começo, tem bastante gente estudando e desenvolvendo outras formas de canais de retorno, pode chegar no mercado um box com suporte a rede sem fio, por exemplo.

  []'s Bengt.

  
  

  • Carlos da Silva(usuário não autenticado)

    12 de Março de 2008, 18:37

     

    Bengt Karlsson, era essa dúvida mesmo que eu estava querendo sanar. Partindo dessa idéia, você concorda comigo que a interatividade será limitada, pois não poderei fazer consultas como se faz hoje na internet, sendo que o retorno dessa consulta seria via ADSL e a TV seria apenas um dispositivo de saída (monitor).

     

    
    

    • Bengt Karlsson(usuário não autenticado)

      12 de Março de 2008, 18:55

       

      Não entendi muito bem a sua dúvida. A sua TV é um dispositivo de saída, ela recebe o sinal do set-top box e mostra a imagem. Mas é o seu STB que tem o canal de retorno e vai enviar e receber a informação. Você está utilizando uma aplicação, ela pode enviar uma mensagem através do canal de retorno e receber uma resposta.

      Pelo que eu acho que entendi, a interatividade não vai ser limitada da forma que você falou.

      []'s Bengt.

       

      
      

      • Alvaro da Veiga(usuário não autenticado)

        12 de Março de 2008, 19:27

         

        Não se esqueçam do celular como canal de retorno, principalmente devido a grande penetração que ele tem na população. Além disso, ele vai receber tb diretamente o sinal da TV. []s  Alvaro

        
        

        • Bengt Karlsson(usuário não autenticado)

          12 de Março de 2008, 20:30

           

          Concordo que teremos celulares com TV Digital e que poderão, em algum momento, receber aplicações e trocar informações através de alguma tecnologia, mas não vamos confundir as coisas. O celular não é um canal de retorno, ele é um dispositivo de recepção com um canal de comunicação. A idéia que a gente tá debatendo é a do set-top box, o celular seria um outro receptor.

          Cuidado com um outro detalhe que você esqueceu. Grande parte da população tem acesso a aparelhos de celular, mas não é essa mesma grande parte da população que tem acesso a aparelhos de uns 1.500 reais com suporte a áudio e vídeo digital. Mas aparelhos, serviços, planos de negócios e etc ficam pra outra conversa.

          []'s Bengt. 

          
          

          • Fernando Kakimoto(usuário não autenticado)

            13 de Março de 2008, 13:48

             

            Olá Bengt.

            Parabéns pelas suas explicações. Elas foram bastante esclarecedoras.

            Espero que não demore muito para a interatividade na TV Digital se tornar uma realidade em nosso país, já que no momento temos apenas o set-box sem o Ginga sendo comercializados. Assim, áreas de TI poderão usufruir de mais um recurso para o desenvolvimento de softwares e finalmente o mercado de TV terá a dinamicidade esperada desde a implantação do Sistema Brasileiro de Tv Digital.

            []'s Fernando.

            
            
          • Marcelo Moreno(usuário não autenticado)

            2 de Maio de 2008, 4:39

             

            Ola, Bengt e demais

               Só para apimentar a discussão, penso que o celular pode ser sim, um canal de retorno, independentemente se recebe o sinal de TV ou não. E poderia ser de duas formas:

                Canal de retorno 1: SMS manual. A aplicação interativa mostra na tela da TV: Mande SMS para 9999 e inicie o processo de compra deste produto (que você achou por navegação pela aplicação). Seria tal qual já é feito com a TV analógica, em votações de BBB, leilões reversos, por exemplo. E não se esqueçam dos recursos de pagamento/crédito que algumas operadoras oferecem (Oi Paggo etc)

                Canal de retorno 2: GPRS/EDGE/UTMS ou SMS automaticamente. Set-top boxes com bluetooth (ou USB) podem se conectar aos telefones e usar suas redes automaticamente, seja como modem para sua rede de dados, seja no envio de SMS.  E não pensem que bluetooth é tecnologia de celular caro, pois isso já passou.

               Mole de implementar!!!

            []s
            Moreno

            
            

            • LUCIENE SILVA(usuário não autenticado)

              16 de Maio de 2008, 8:17

               

              Bom dia ,

              Bem... sou nova no forum e estou precisando de ajuda. O meu projeto final é sobre TV Digital e o topico do projeto è o Ginga. Sera que alguem poderia me ajudar?

               

              Obrigada

               

              Luciene

              
              

              • Carlos de Salles Soares Neto(usuário não autenticado)

                16 de Maio de 2008, 11:57

                 

                Aqui na comunidade tem um link "documentos". Há muito material lá, inclusive um tutorial sobre o NCL. Há também as normas ABNT para o Ginga que descrevem em detalhes o Middleware.

                Poderia dar como foco o desenvolvimento de aplicações em NCL. Nesse caso, o tutorial a ajuda em tudo que precisas.

                Abraços,

                Carlos

                
                
            • Claudio Monteiro(usuário não autenticado)

              7 de Maio de 2008, 10:08

               

              Marcelo, gostei de sua observação.... mas aproveito para perguntar a você e aos demais colegas que discutem o assunto: O que dizem as normas sobre o canal de retorno em STB full-seg? A norma que li (ABNT-16604), que trata de receptores diz apenas que poderá vir, de forma opcional a pilha IP e algum tipo de conexão STFC.

              Bom, nós aqui estamos trabalhando com um STB virtual, baseado linux e com Ginga. Tudo está funcionando bem (aplicações NCL executando com chamadas a LUA). No entanto, para implemantarmos o canal de retorno, criamos uma camada de shell que verifica qual o tipo de conexão existente e ativa no STB. Se a conexão for ethernet, ela é então usada, se não, o STB pergunta  ao usuário qual o tipo de conexão. Se discada, pede número do provedor, usuário e senha para então discar e estabelecer uma conexão PPP. Funciona bem!

              No entanto, minha dúvida é: para que aplicação NCL/LUA consiga efetuar a conexão, precisamos usar uma API (LUASocket) que aparentemente não está prevista na norma. Em termos de mercado brasileiro, será que podemos contar com esse tipo de solução? (STB com uma camada que identifique e disponibilize os níveis 1, 2 e 3 do canal de retorno e a aplicação com uma API de sockets)???

              Valeu gente.
               

               

              
              

              • Carlos de Salles Soares Neto(usuário não autenticado)

                7 de Maio de 2008, 10:30

                 

                Oi Claudio,

                Acompanhe meu raciocínio.

                Suponha que sua implementação NCL/Lua faz uso da API Lua-TCP que consta na norma (provavelmente implementada por baixo com LuaSockets).

                Quando é feita uma chamada à API com o STB desconectado, o Ginga Commom Core é disparado para estabelecer o processo de conexão normalmente (da forma que você descreveu - talvez validando usuário/senha etc). Depois da conexão, a chamada prossegue. O usuário já espera por isso ... quando você abre seu navegador desconectado em seu PC é exatamente o que ocorre.

                Quando a chamada à API é feita com o STB conectado, o resultado é direto.

                Em suma, não precisa haver na API Lua-TCP uma primitiva de estabelecimento de conexão, o que deve ficar por fora. Isso só complicaria as implementações, já que assim TODA implementação teria que começar testando se a conexão está ativa e - pior ainda - teria que repetir esse teste a CADA chamada da API Lua-TCP.

                Faz sentido?

                Carlos

                
                

                • Claudio Monteiro(usuário não autenticado)

                  7 de Maio de 2008, 14:49

                   

                  Carlos, valeu pela resposta... realmente faz sentido mesmo! É exatamente assim que estou pensando e é assim que nossa aplicação está funcionando... a aplicação simplesmente abre um socket em nível de aplicação e o STB "se vira" para encaminhar isso da melhor forma. Mas fica a questão: Onde encontro a norma que fala que posso contar com a API Lua-TCP constante no STB? Como você disse, essa API (Lua-TCP) está na norma... se é assim, posso ficar tranquilo que estou desenvolvendo e testando minhas aplicações em um ambiente bastante parecido com o que teremos no mercado. Não é isso?

                  Valeu

                  Claudio.

                   

                  
                  

                  • Carlos de Salles Soares Neto(usuário não autenticado)

                    7 de Maio de 2008, 15:25

                     

                    A classe de eventos tcp do Lua começa a ser explicada a partir da página 155 da norma (que você encontra aqui: www.​abnt​.org​.br/​imag​ens/​Norm​aliz​acao​_TV_​Digi​tal/​ABNT​NBR1​5606​-2_2​007V​c_20​08.p​df&n​bsp;​).

                    Não quero criar confusão. Não há uma bilbioteca Lua-TCP ou API Lua-TCP. Chamei de Lua-TCP na postagem anterior por clareza. A norma deixa tudo muito mais claro.

                    Abraços,
                    Carlos

                    
                    

                    • Claudio Monteiro(usuário não autenticado)

                      8 de Maio de 2008, 12:37

                       

                      Carlos... obrigado mais uma vez. Agora entendi bem!