Posts recentes

  • Archive.org

    0 comentários

    por: Pedro Markun, na categoria Plataformas de compartilhamento dia 07/03/2010

    archive

    O Internet Archive é um projeto sem fins lucrativos, criado em 1996 pela Alexa Internet, cujo objetivo é construir uma biblioteca de conteúdos multimídia na internet. Atualmente, o Internet Archive reúne um acervo de mais de 250 mil itens, entre textos, vídeos, fotos e softwares,  alimentado por qualquer usuário.

    Também é responsável pelo WayBack Machine, principal ferramenta de arquivamento do histórico de páginas web, ou seja, o sistema grava, de tempos em tempos, versões de grande parte de todos os sites disponíveis na web. Atualmente possui 150 bilhões de arquivos.

    Embora não seja propriamente um site de compartilhamento de vídeo e tenha uma interface antiquada e pouco funcional,  o Internet Archive se destaca por permitir o armazenamento de conteúdos multimídia em qualquer tamanho ou formato.   Além disso, permite que o usuário visualize, compartilhe e faça o download de qualquer arquivo. Seu sistema também realiza conversões de arquivos em vários formatos, proprietários (como flv e wmv) e livres (como ogg theora).

    Tags: , , , , ,

  • Entrevista: VJ Pixel

    0 comentários

    por: Gabriela Agustini, na categoria Entrevistas dia 05/03/2010

    pixelPesquisador multimídia e VJ, Pixel passou a usar software livre em suas performances em 2003 quando se tornou o primeiro VJ brasileiro a trabalhar em plataforma inteiramente aberta. Participou da estruturação e coordenação da Ação Cultura Digital, projeto do Ministério da Cultura que busca interligar as produções textuais e audiovisuais e ações dos Pontos de Cultura do país.

    Foi coordenador adjunto de tecnologia da Coordenação Nacional do Projeto Casa Brasil, do Governo Federal, e Coordenador de Tecnologia Social do Programa Acessa SP.
    É criador da rede VJBR, que propõe a integração e compartilhamento de experiências entre VJs brasileiros e integra o coletivo de artistas Media Sana, realizador de intervenções musicais e visuais a partir de notícias coletadas na imprensa. Pixel é membro da rede MetaReciclagem, ligada à apropriação de novas tecnologias para a transformação social, e Estúdio Livre, focada na produção e circulação de bens culturais livres, de obras que podem ser distribuídas, remixadas e retransmitidas livremente de forma legal e sem qualquer tipo de restrição.

    Colabora ainda com a ONG internacional Tactical Technology Collective, que utiliza novas ferramentas para a defesa dos direitos humanos, com o desenvolvimento do LiVES, software livre de edição de vídeo, e pesquisa interfaces de interação entre homem e computador no Desvio, núcleo do Laboratório de Inclusão Digital e Educação Comunitária Weblab.

    Perfil no Twitter: @vjpixel

    Pixel é membro do coletivo que compõe a Casa da Cultura Digital, lugar em que foi gravada em janeiro de 2010 a entrevista feita por Rodrigo Savazoni presente nesta pesquisa. Veja o vídeo e íntegra, em texto, abaixo:

    >>> O que é o mais difícil em relação ao vídeo online hoje?

    Pixel: “O mais difícil hoje é difundir padrões livres como padrões de fato. As empresas com muita inserção de mercado querem impor seus próprios padrões. Isso acontece com a Apple, e o seu MP4, a Microsoft com o Windows Media Video, que são codecs bons, mas por serem proprietários restringem o direito das pessoas de reproduzir o conteúdo.

    Como são de uma empresa, ela pode definir que quem quiser usar um player com aquele padrão tem que pagar por ele, fazendo com que um software extremamente difundido deixe de ser utilizado. Existem milhares de razões para que uma empresa queira fazer isso. Pode ser uma questão financeira, uma estratégia de contra ataque à ações do mercado, ou até mesmo em função de algum problema técnico.”

    >> E qual o papel do governo nisso?

    Pixel: “Eu acho que o Estado deve difundir padrões abertos, livres. O governo existe para defender os interesses do povo, então não pode privar as pessoas do acesso a alguma informação. A partir do momento em que uma pessoa precisa pagar para ter o codec e acessar uma determinada informação, ela não tem, de fato, essa informação, naõ se pode acessar aquilo livremente sem ter que, para isso, gastar dinheiro.”

    Continue lendo…

    Tags: , , , ,

  • Flash, Google, VP8 e o futuro do vídeo na internet

    0 comentários

    por: Gabriela Agustini, na categoria Sem categoria dia 04/03/2010

    O post abaixo foi publicado originalmente no blog Diary Of An x264 Developer (Diário de um desenvolvedor de x264- em referência ao codec livre de vídeo). No espaço atualizado por Jason Garrett-Glaser, também desenvolvedor de ffmpeg, o autor mostra seu ponto de vista sobre o futuro do vídeo na internet, levando em consideração os avanços no suporte ao HTML5, as ações do Google, da Adobe, a possibilidade de adoção de vídeo livre pelas empresas e, é claro, o desenvolvimento do x264.

    Replicamos o conteúdo devido à argumentação e sustentação dos pontos de vista defendidos pelo autor. O que não significa estarmos de acordo com eles. A tradução foi incluída na pesquisa por mostrar uma visão em relação ao que pode acontecer com o mercado de vídeo online. Outras opiniões são possíveis. Deixamos aberto aqui o debate.

    Flash, Google, VP8 e o futuro do vídeo na internet
    Publicado originalmente em: http://x264dev.multimedia.cx/?p=292

    Há tempos se vê na internet um grande número de posts reclamando do Flash. A posição é válida: o Flash tem uma performance horrível em qualquer sistema diferente do Windows 86 e a Adobe parece não se importar com isso. Mas, em vez de repetir as críticas, vamos tentar aprofundar um pouco e entender o que acontece.

    A popularidade do Flash se deve ao seu poder e flexibilidade. Na época, era a única opção para vetores gráficos animados e conteúdo interativo (como, por exemplo, o VMRL- Linguagem para Modelagem de Realidade Virtual, um padrão de formato de arquivo para realidade virtual). Além disso, antes do Flash, as opções de vídeo eram Windows Media, Real e Quicktime: todos proprietários, sem codificadores ou decodificadores de software livre, e (exceto o Windows Media) era necessário ao usuário instalar um aplicativo externo e não apenas um plugin. Dado tudo isso, fica claro porque o Flash ganhou: ele suportava os formatos multimídia abertos como H.263 e MP3, usando um formato contêiner ultra-simples que qualquer um poderia escrever (FLV), e trabalhava de forma mais fácil e segura às outras alternativas que se tinha.

    Assim, a Adobe (na época, Macromedia) conseguiu 98% de sua base. E com isso, começaram a se tornar complacentes. Qualquer sugestão de um concorrente era imediatamente descartada: como alguém poderia, eventualmente, competir com a Adobe, dada a grande base instalada? Isso seria insano, ninguém seria capaz de fazê-lo. Eles cometeram o pecado original de desenvolvimento de software: acreditar que um concorrente ser melhor era perdoável. No x264, se encontrarmos um concorrente que faz algo melhor, nós imediatamente olhamos para tentar nos colocar de volta no topo. É por isso que x264 é o melhor encoder de vídeo do mundo. Mas na Adobe, esta atitude claramente caiu depois que virou um monopólio. E este é o verdadeiro perigo dos monopólios: eles impedem o desenvolvimento, porque o monpolista não tem incentivo para melhorar o seu produto.

    Em suma, eles viveram a maré alta, mas estavam errados em alguns pontos críticos:

    O primeiro erro foi supor que Linux e OS X não importavam. Linux é um sistema operacional usado por uma minúscula minoria de usuários finais, mas essas pessoas formam uma parcela enorme de desenvolvedores web e de software do mundo. Apenas olhando para o número de usuários, pode-se pensar que não vale a pena otimizar. Então, a Adobe colocou apenas um desenvolvedor para a plataforma Linux inteira. Em termos de OS X, o Mac se tornou muito popular nos últimos anos – especialmente entre esse mesmo grupo de desenvolvedores. E além disso, a Apple é uma empresa enorme. Flash funcionando terrivelmente em sua plataforma é um grande incentivo para a Apple ficar na posição. Assim, a Adobe criou como inimigo a Apple e os desenvolvedores.

    O segundo erro foi atacar o software livre. Praticamente todos os sites na internet usam soluções livres em seus servidores – e não apenas no LAMP (Linux Apache Mysql Php)– [‘padrão’ de aplicativos opensource usado para rodar paginas web]. Youtube, Facebook, Hulu e Vimeo todos usam ffmpeg e o x264. Codificador H.264 no Adobe Flash Media Encoder é tão horrível que é muito pior do que H.263 ffmpeg ou Theora, eles estão praticamente assumindo que os usuários irão utilizar x264 no lugar. Para software de servidor real, o software livre Red5 é extremamente popular para sistemas baseados em RTMP. E, além de tudo isso, a Adobe enviou um pedido para parar as atividades dos servidores de hospedagem RTMPdump, alegando (absurdamente) que eles violavam a DMCA ao permitir aos usuários salvarem streams de vídeo em seu disco rígido. RTMPdump não morreu, é claro, e era apenas um programa, mas esse ataque permaneceu na mente dos desenvolvedores de todo o mundo. Ficou claro para eles que a Adobe não era amigo do software livre.

    O terceiro erro é não ter apoiado uma implementação em software livre do Flash. A falta de um bom Flash em software livre não é culpa da Adobe; ficou ainda claro que os seguidores do Gnash são incompetentes e não despertou o interesse de muita gente. O desenvolvedor Cody Brocious escreveu seu próprio código renderizado de Flash em questão de dias para propor um aplicativo de conversão do Flash para o iPhone. Ele só parou porque a Adobe lançou sua própria versão poucos dias antes dele lançar a sua. A especificação do Flash é aberta, e não há registro de implementações de software livre de algum codec em Flash: não há nada impedindo uma boa implementação gratuita. Mas o erro da Adobe é o da falta de ação: eles não pressionam para isso porque não é importante para eles.

    Por comparação, olhe a Moonlight, a implementação em software livre do Silverlight. A Microsoft tem trabalhado ativamente com a comunidade de software livre para ajudar a produzir Moonlight. Pense em como isso soa absurdo; Microsoft – bane o do software livre e tem apoiado ativamente uma LGPL projeto de software livre, enquanto a Adobe não! O maior problema que isso cria é de um monopólio: as pessoas se sentem inseguras usando Flash porque há apenas uma aplicação, deixando-as à mercê da Adobe. Em qualquer situação, quando existem várias implementações populares de um formato de arquivo, é muito mais difícil de se cometer abusos. Evidentemente, isso é intencional por parte da Adobe: eles querem ter o poder de abuso, o que explica por que eles não suportam uma aplicação alternativa.

    Agora fica claro por que o Flash é tão detestado. É longe o mais inseguro de plugins do browser popular; Java tem muito mais vulnerabilidades de acordo com a Secunia. Não é certamente o menos confiável, nem é totalmente proprietári— como mencionado anteriormente, a especificação é pública. No entanto, por causa dos três erros acima a Adobe tem se tornado inimiga de desenvolvedores no mundo inteiro.

    Mas e agora? Flash é horrível, nós odiamos o Flash. Mas como se livrar dele pelo menos no que diz respeito ao vídeo na internet?

    Vamos começar com HTML5 . É evidente que, salvo um ato de Deus (ou o Google, mais cedo ou mais tarde), se o Flash for suvstituído num futuro próximo esta será a forma. No momento, ainda existem muitos problemas, a maioria dos quais devem ser resolvidos para que exista alguma chance:

    1. Características ausentes. Desenvolvedores que não trabalharam com o Flash, muitas vezes, subestimam suas capacidades e assumem que exibir um vídeo é tão simples como exibir imagens. Mas há muitas coisas que são úteis para o controle. O Flash permite dizer ao cliente quanto tempo terá que esperar antes de começar o stream (muito importante para a reprodução de qualquer vídeo ao vivo). Ele fornece sinalização de volta ao servidor de taxas de perda de pacotes, de modo a permitir o servidor acelerar a banda de acordo.

    Há dezenas de outras, essas são apenas alguns exemplos. Mas este é o principal problema mencionado no início deste artigo, o problema que atingiu a Adobe tão fortemente: “acreditar que ter um concorrente melhor é desculpável”. Muitos defensores do software livre promovem o HTML5 declarando que a falta desses recursos não é um grande problema e que podemos viver sem eles. Isso não é desculpável! Se você quiser desbancar a Adobe, você precisa fornecer um superconjunto de todos os recursos mais usados.

    2. Vídeo/ áudio /formato de contêiner. Theora é difícil de vender para a maioria das empresas, dada a sua compressão muito pior do x264 e H.264 e da falta de direitos de vídeo na web. É complicado tentar convencer o mercado de alguma coisa com benefícios nebuloso. Ser “patente-livre” pode soar agradável para os defensores do software livre como nós, mas a maioria das pessoas de negócios só se preocupam com a linha de frente, e se ser “patente-livre” não resolve seus problemas, eles provavelmente não vão se importar. (Nota: um comentarista observou que o H.264 tem licença livre apenas para o conteúdo livre e não para o conteúdo pago. Isso provavelmente não é um grande problema, uma vez que a porcentagem de royalties é muito pequena para conteúdos pagos, e se você está cobrando por conteúdo pode provavelmente ter recursos para pagar os honorários de pequeno porte. Mas, obviamente, é uma situação um pouco diferente.).

    Mas mesmo se você ignorar a questão da compressão, a maioria das empresas não gostam de guardar várias versões de cada vídeo – eles ainda precisam H.264 para suporte do iPhone. Fazendo uma observação, Dirac é uma opção potencial de patente livre e pode fornecer uma melhor compressão, mas é mais lento para decodificar quando comparado ao Theora. É definitivamente uma opção a considerar, e que muitas vezes é ignorada quando se fala em formatos de vídeo para HTML5.

    O Youtube, por exemplo, tem jogado fora petabytes de largura de banda na busca de versões menores de cada vídeo: o padrão “baixa qualidade H.264″, que agora usa o x264, é o básico no perfil. Oferecer uma alternativa maior poderia salvá-los 30-50% de banda para os usuários de desktop, que compõem a grande maioria dos usuários do YouTube. Mas seria necessário armazenar uma outra cópia do vídeo (já que é necessário para iPhones), o que é muito caro para eles. Para duplicar cada vídeo novamente seria necessário algum benefício – e, aparentemente, o Google acredita que uma melhor compressão de 30-50% não é suficiente, e parece haver algo estranho acontecendo com os 360p/480p que recentemente desenrolaram (que nem High Profile é).

    Claro que, apesar de receber 50 milhões dólares a cada ano do Google, a Mozilla nunca vai pagar as taxas de licença H.264, nem eles provavelmente vão apoiar os usuários a instalar os seus próprios codecs. Assim, estamos em um impasse. Se a Microsoft suportar o HTML5 no IE9, o que é perfeitamente possível, é quase certo que vão suportar o H.264 e não o Theora. Então, mesmo ignorando o caso de dispositivos móveis como o iPhone, nem H.264 nem Theora abrangerá todo o mercado. O que as empresas vão escolher? A maioria vai enxergar a divisão de mercado como razão para evitar o completamente e voltar para o Flash.

    3. Ubiquidade. Flash tem 98% da base de instalação do mercado, uma força poderosa. Até o Internet Explorer tornar-se um navegador da baixa popularidade -(improvável no curto prazo) ou suportar o HTML5, o Flash simplesmente não será substituído. Além disso, isso efetivamente força os sites a usar H.264: se quiserem apoiar o Flash e o HTML5, usar Theora irá forçá-los a armazenar duas cópias redundantes dos vídeos, que o Flash não suporta Theora.

    4. Qualidade de implementações. As implementações do HTML5 existentes variam de mau a pior, apesar dos anos que os desenvolvedores estão batendo no Flash. Muitas das implementações são mais lentas que os players de mídia nativos, usam escala pixelada (por exemplo, o Chrome), estão cheios de bugs ou tem todos esses problemas citados. Não são apenas as implementações que são ruin, muitas vezes a concepção já é inconsistente. E mesmo que algumas funcionem bem, não adianta se muitas outras não.

    Com todos esses problemas, HTML 5 parece estar em grave perigo apesar das promessa. E isso nos leva ao tema principal: o que aconteceu com o Google, On2, e VP8? Se, como a FSF defende freneticamente, o Google coloca o VP8, que problemas isso resolve equais problemas que se criam? E quais os benefícios que isso traz para o Google?

    VP8 resolve o problema de compressão: que ainda provavelmente não é tão boa como a do x264 (ver a adendo no final para obter mais detalhes sobre essa previsão), mas a diferença já é muito menor do que com Theora, o suficiente para que a compressão não seja mais uma questão. Mas também traz uma série de novos problemas:

    1. Anos atrás, a Microsoft relançou o WMV9 proprietário como o software VC-1, alegando ser livre. Alguns meses depois, dezenas de empresas se pronunciaram dizendo ter a patente do VC-1. Em um ano, o lincenciamento do VC-1 foi instituído e as patentes “livre” deixaram de existir. Qualquer suposição de que o VP8 está completamente livre de patentes é provavelmente um pouco prematura. Mesmo se isso não acontecer imediatamente, muitas empresas não vão querer incluir decodificadores VP8 em seu software até que eles estejam confiantes de que isso não é ilícito. Theora vem sendo feito há 6 anos e ainda há muitas empresas (principalmente Nokia e Apple), que ainda se recusam a incluí-lo! Claro que esta atitude pode parecer absurda, mas é preciso entender a estratégia de marketing. Uma pessoa não pode se livrar dos empresários com medo de patentes ignorando-os.

    2. VP8 é proprietário, e mesmo se abrir, ainda vai ter muitos dos problemas de um formato proprietário. Provavelmente existirão bugs que nunca serão revistos porque apenas uma implementação foi escrita (veja RealVideo para ter um exemplo disso). Haverá apenas uma aplicação por algum tempo; Theora vem sendo desenvolvido há 6 anos e até agora há apenas um codificador. A falta implementações competitivas gera complacência e estagna o progresso. E dada a qualidade do On2 lançado no passado, eu não tenho muita esperança para o código-fonte real do VP8, ele provavelmente terá que ser totalmente reescrito para obter uma alta qualidade compativel a uma implementação em software livre.

    3. Ele não resolve os problemas de compatibilidade de hardware: a maioria dos dispositivos móveis utiliza ASICs para decodificação de vídeo, os quais provavelmente não podem ser facilmente redirecionado para VP8. Esse pode ser um problema menor se eles focarem em implementações de software para isso, o que poderia gastar mais bateria e ser limitado por dispositivos móveis com processadores poderosos. Não seria razoável reproduzir VP8 em um chip ARM rápido (veja o adendo para saber mais sobre isso).

    A grande vantagem do VP8 é que resolve um problema insolúvel para Theora: Theora está para sempre prejudicada pela sua tecnologia obsoleta e conjunto fraco de recursos. Com RD e otimização de psy, como no x264, Theora pode provavelmente tornar-se competitivo com Xvid ou mesmo com WMV9, mas provavelmente não com x264. A única maneira de corrigir isso seria um “Theora 2”, mas garantir a patente livre do Theora e adicionar novos recursos seria muito difícil no atual ambiente de patentes de software. VP8, por outro lado, oferece um salto imediato para o que se espera de H.264, em relação a nível comparável de compressão.

    E agora a grande questão: por que o Google pretende abrir VP8 e, se o fizerem, como será? O Google provavelmente não quer pagar um centavo das taxas de licença para Youtube. H.264 é gratuito, pelo menos até 2016 para distribuição pela Internet, mas taxas de codificador se aplicam a quem tiver mais de 100.000 servidores de codificação. O custo das licença para Chrome são mínimos (alguns milhões de dólares por ano, no máximo). Mas, apesar disso, há realmente alguns bons motivos para a ação do Google:

    1. Controle. Google pode ver o controle de outras empresas sobre o H.264 como uma ameaça: embora H.264 é licenciado em termos RAND (razoáveis e não discriminatórios, que legalmente não podem ser anti-competitiva), há muitas razões para que o Google queira mais controle. Se eles empurram o VP8, eles podem competir com o Flash pelo HTML5 e também impedir o Flash de rodarem seus vídeos. Como é improvável (pelas razões mencionadas no início do artigo) que a Adobe embarque no VP8, isso cria uma janela de oportunidade para o Google roubar o controle da Adobe.

    2. Guerra-relâmpago. A coisa mais arriscada e também mais poderosa que o Google pode fazer é mudar o Youtube exclusivamente para VP8 e criar um novo plugin no browser para suportá-lo (o suporte ao HTML5 é permitido). Dada a popularidade do YouTube, isso provavelmente levará a instalação a 80% da base instalada em questão de um um ou dois meses, efetivamente uma guerra roubando fatias de mercado da Adobe. Este seria poderoso porque não teriam que esperar os navegadores existentes (especialmente o Internet Explorer) passar ao VP8.

    3. Trunfo. O Google pode estar preocupado com o futuro. Se o H.264 tiver êxito em eliminar toda a concorrência no mercado web, será bem possível que o MPEG-LA tente abusar da sua posição e comece a cobrar taxas para o uso da web. Talvez MPEG-AL precise de um bom susto para se certificar de que eles nunca consideraram tal coisa. Monocultura de software é perigoso.

    Esses parecem ser motivos suficientes, embora um pouco traiçoeiros (especialmente o 2), para o Google fazer esse ataque. Mas nós queremos realmente que o Google tenha tanto controle? Não tenho certeza, mas é uma opção melhor que a Adobe. E vai realmente acontecer? Muito possível, a outra única explicação plausível para uma aquisição de US$ 100 milhões seria a de adquirir patentes para usar em processos de patentes. Daria certo? Dependeria de como eles fizessem isso e o que outras empresas teriam como plano. Depende também do que estão mirando: será que estão tentando empurrar o suporte a hardware também?

    Onde o x264 se encaixa em tudo isso? O H.264 certamente não irá acabar, não por agora. Na maior parte do mundo, as patentes de software não são problema. Mas no final, nada disso importa para x264 : vamos continuar nossa missão de criar o melhor software de compressão de vídeo na Terra. Diferentemente da Adobe, não ficamos satisfeito quando somos os melhores, nós mantemos tentando ser ainda melhor. Nós adicionamos novos recursos, melhoramos a compressão, suportamos novas plataformas, melhoramos o desempenho, e há muito mais por vir. Nós não nos importamos que muitos codificadores H.264 estão tão ruins que podem ser batidos por Theora ou Xvid. Nós não nos importamos se VP8 sai; esse é só mais um codificador para bater. Nós estamos aqui para garantir que a melhor escolha é o software livre fazendo constantemente o software livre ser melhor.

    E, é claro, nós apoiamos a busca por licença livre, fomatos livres de software multimídia. Existem muitos casos em que ser livre de patentes é mais importante do que compressão, qualidade, desempenho ou até mesmo alguns recursos. Bink Video é um exemplo incrivelmente popular: o uso em dezenas de milhares de jogos, apesar da compressão 10 vezes pior aos formatos modernos de vídeo- se deve à sua licença-livre (embora o software seja proprietário). Se chegar o dia em que o Bink seja substituido por uma alternativa em software livre, nós saberemos que a busca por um software livre de vídeo sem patentes amplamente aceito terã chegado ao fim. Até lá, eu desejo sorte para todos aqueles que perseguem essa meta.

    Adendo: O conjunto de recursos do VP8 e a sua capacidade de compressão

    Muitas pessoas têm pensado o que é a realidade por trás do VP8, por trás do marketing usual que essas empresas divulgam. Como não há especificação do público e até mesmo o próprio codificador ainda não é liberado, tudo isso é um palpite baseado nas informações que tenho.

    O VP8 está sendo divulgado pela assessoria de imprensa como basicamente uma “melhoria do VP7”, com o objetivo de ser mais rápido para decodificar em software nos dispositivos móveis, especialmente aqueles sem SIMD (ARM11, por exemplo). Assim, é razoável começar a abordar VP8 comentando o VP7. O VP7 foi lançado em 2003, na mesma época que os codificadores H.264. Fez sucesso por estar muito melhor do que praticamente todos os codificadores H.264, na época. O motivo não era o VP7 ser melhor ao H.264, mas sim que o On2 tinha um código base bem mais maduro: foi desenvolvido por anos, enquanto a maioria dos codificadores H.264 ficaram prontos nos meses seguintes à finalização da especificação. Mas, o VP7 nunca pegou porque era completamente proprietário; ninguém mais quer ter um codec proprietário. Com o passar dos anos, a On2 nunca atualizou o VP7 e os melhores encoders H.264, como o x264, foram para frente. O VP7 foi em grande parte esquecido, exceto por uma alguns aplicativos como o Skype, que o licenciou.

    Agora, vamos analisar o VP7 tecnicamente. Embora eu não saiba muito sobre o processo interno, VP7 é notável em confiar pesadamente em filtros de pós-processamento. Ele não é o único, praticamente todos os codecs da On2 tem isso. Mesmo Theora tem um filtro opcional pós-processamento herdado da VP3. Os filtros de pós-processamento da On2 geralmente trabalham com três categorias: desbloqueio, nitidez, e pontilhado. Este último é útil para evitar o bloqueio em áreas escuras e planas, semelhantes aos efeitos do filtro gradfun do mplayer. O filtro de sharpening ajuda a compensar o efeito natural, a indefinição dos codificadores, que não são muito otimizados visualmente. O filtro de desbloqueio é notório para mexer nas enormes quantidades de texturas e detalhes (exemplo: VP7, x264). E isso também fornece uma vantagem significativa: ao mover muitas características do codec para o pós-processamento, o vídeo passa a ser escalável; um decodificador pode fazer “menos trabalho” enquanto continua reproduzindo o arquivo, embora em menor qualidade. Isso não funcionar se todas as etapas são obrigatórias

    Como o VP8 é divulgado como menos complexo que o VP7, é provável que ainda não contenha codificação aritmética, B-frames, ou outros recursos de computação intensiva. Sabemos a partir do material de marketing produzido que uma dos grandes chamarizes era permitir que o codificador escolha entre os modos de interpolação para ter decodificação rápida, se necessário. Claramente, VP8 é mais rápido – o que significa provavelmente não ter um monte de novos recursos de compressão relacionados. Se ele melhorou muito do VP7, será provavelmente devido a otimizações psicovisuais no codificador. Mas, segundo o último press release que mostrava uma comparação com x264, é claro que eles não fizeram isso. A imagem do VP8 é desfocada, sem detalhes, ao contrário ds imagem do x264, que realmente parecia melhor para muitos no Doom9, apesar dos testes obviamente encenados.

    No geral, acredito que o VP8 é melhor do que o MPEG-4 ASP (Xvid / DivX) e WMV9/VC-1. Ele provavelmente vai ser quase tão bom quanto o codificador do Mainconcept H.264 (um dos melhores não-x264 codificadores), mas assumindo que ainda acreditam que borrar a imagem inteira é uma boa ideia, provavelmente é inferior ao x264.

    Tags: , , , , ,

  • Ferramentas de Software

    0 comentários

    por: Gabriela Agustini, na categoria Ferramentas de software dia 02/03/2010

    Streaming

    Streaming é um método de fornecimento de arquivos de mídia pela Internet. Em vez do download de um arquivo na íntegra em uma unidade de disco rígido, ele permite transferir uma quantidade constante de informações de um servidor para um navegador, através de uma rede (como a Internet). O streaming, ou transmissão ao vivo de vídeo é realizada através do envio de um fluxo de vídeo e a mídia geralmente é, à medida que chega ao cliente, armazenada em um buffer local e, em seguida, reproduzida.

    Na maioria das vezes o streaming das informações da mídia não são arquivadas definitivamente pelo cliente que está recebendo o fluxo (a não ser que o usuário ativamente faça a gravação dos dados). No caso da conexão do cliente não suportar velocidade suficiente para a transmissão dos dados do streaming em tempo real, os dados excedentes são desconsiderados, de modo que podem haver “pulos” (falhas) na exibição da imagem ou som. Webrádios e WebTVs utilizam streaming para fazer suas transmissões.

    Tocadores

    Tocadores online são a maneira mais simples de assistir vídeos na Internet. Esses players, na maioria das vezes, tocam vídeos que estão armazenados em servidores, mas há também a possibilidade de utilizar esta tecnologia para assistir vídeos ao vivo. O tocador online é necessário para decodificar o sinal streaming vindo do Servidor de Mídia via Internet (ou Intranet no caso de transmissões corporativas fechadas).

    Metodologia para Ferramentas de Software

    Os dados sobre ferramentas de software foram obtidos primeiramente a partir de planilhas da wikipedia. Em seguida, fomos preenchendo os dados que faltavam através dos sites das empresas desenvolvedoras e outras fontes da internet. Num segundo momento as informações obtidas na wikipédia foram revisadas. Para terminar, essas informações foram interpretadas no sentido de elaborar recomendações determinando o mehor streaming e o melhor tocador.

    Tags: , ,

  • Distribuição

    0 comentários

    por: Gabriela Agustini, na categoria Distribuição dia 02/03/2010

    Nessa seção descrevemos métodos de distribuição de vídeo online, apresentando seus fluxos de informação a partir da interação do usuário.

    São listados 5 métodos:

    Download direto, que consiste na cópia do arquivo do servidor para o cliente.

    Download via BitTorrent: cópia do arquivo de uma rede descentralizada de clientes, ao mesmo tempo que se envia partes já baixadas desse arquivo para essa rede.

    Streaming, transmissão ao vídeo de um fluxo de vídeo.

    Vodcast, download automatizado de vídeos por meio da assinatura de canais.

    Tocador online, um player embutido nas páginas da Internet que torna possível assistir o vídeo diretamente no navegador.

    Comparação

    Cada uma das tecnologias de distribuição citadas acima têm suas vantagens e desvantagens, que são um reflexo de suas características próprias. A seguir é apresentada uma tabela comparativa com esses dados:

    [tabela]

    Observações:

    a) As informações apresentadas acima são o padrão, mas em muito casos podem haver exceções (por exemplo, o servidor ou cliente de streaming ficar responsável pelo armazenamento de dados).

    b) Armazenar no cliente significa ser possível a exibição dos arquivos diversas vezes após a conclusão do download.

    Notas:

    1) Apesar dos dados não ficarem necessariamente armazenados em um servidor em tecnologias P2P, é necessário baixar um arquivo .torrent em que se encontram informações necessárias para iniciar o download do arquivo.

    Metodologia para métodos de distribuição de vídeo online

    Foram selecionadas as tecnologias mais usadas para a distribuição de vídeos na internet, descritas com base em dois critérios: a interatividade do usuário, quais passos são necessários para o uso das tecnologias, e como cada uma delas funciona internamente, ou seja, como se dá efetivamente a distribuição de dados. Esses dois critérios estão intimamente relacionados, pois essas tecnologias não são completamente automatizadas e necessitam da interação com o usuário para funcionar.

    Uma tabela comparativa foi elaborada, baseada em quatro características importantes que permitem comparar de forma simples essas tecnologias e definir qual o modelo mais adequado para cada situação. As quatro características são: se o vídeo é armazenado no servidor ou não, se o cliente reenvia dados ou não, se é possível assistir o vídeo ao vivo e se o vídeo é armazenado no cliente ou não.

    Tags: , , , , ,

  • Comunidades

    0 comentários

    por: Gabriela Agustini, na categoria Comunidades dia 02/03/2010

    As comunidades de vídeo apresentadas aqui são bastante heterogêneas. A característica comum a elas é o fato de envolver pessoas interessadas na discussão, produção e troca de vídeos, feitos por fãs de cinema ou anime ou por VJs e outros artistas. A discussão sobre ferramentas livres de produção e distribuição de vídeos está mais concentrada nas comunidades do Estúdio Livre e do Open Video.

    Metodologia para Comunidades:

    Os tipos de comunidades de vídeo descritas foram selecionados por meio de uma pesquisas na internet com os termos “video community”. A partir daí foram verificadas as comunidades mais relevantes para serem colocadas na pesquisa.

    Duas comunidades merecem atenção especial: Estúdio Livre e Open Video. Elas representam lugares em que a produção de vídeo é pensada como um todo e a discussão sobre tecnologias livres está mais avançada. Para descrevê-las foram usadas informações de seus respectivos sites, da Wikipédia e outras páginas da internet. Outros dados foram obtidos nas entrevistas com o VJ pixel e Joshua Green, por exemplo.

    Ao olhar para as comunidades de fãs, notamos a importância expressiva das comunidade de Anime Music Videos (AMV) que por isso ganharam categoria própria. No que diz respeito às comunidades de VJs listamos as duas principais para o contexto do estudo que tem também relevância mundial. Show in a Box foi detalhada por ser responsável pelo desenvolvimento de uma plataforma de vídeo online.

    Tags:

  • Arquivos de vídeo

    0 comentários

    por: Gabriela Agustini, na categoria Arquivos de vídeo dia 02/03/2010

    Os arquivos de vídeo são compostos por codecs e contêineres:

    Codecs

    Um codec é um dispositivo ou programa de computador capaz de codificar e decodificar um fluxo ou sinal de dados. A palavra codec vem de compressor-decompressor. O seu objetivo é reunir dados para transmissão, armazenamento ou encriptação [processo de transformar informação usando um algoritmo impossibilitando a sua leitura a todos exceto àqueles que possuam um conhecimento especial, chamado de chave], para alcançar uma imagem ou som o mais fiel possível ao original, ao mesmo tempo que reduz ao máximo a banda necessária para transmissão ou espaço para armazenamento.

    A maioria dos codecs são implementados como bibliotecas utilizadas por um ou mais tocadores de mídia. Em hardware, um codec é um dispositivo que codifica sinal analógico de som ou imagem em digital e vice-versa. De maneira simples, podemos defini-lo como um software que adiciona suporte para um determinado formato de vídeo ou áudio em um sistema, tornando possível tocá-lo (decodificá-lo) ou, em alguns casos, trocando outro formato de áudio/vídeo pelo necessário (codificação).

    São divididos em dois tipos: os com e os sem perdas. Codecs sem perdas reúnem som ou imagem para comprimir o arquivo sem alterar os originais. Se o arquivo for descomprimido, o novo arquivo será idêntico ao original e normalmente de duas a três vezes menores. São muito utilizados em rádios e emissoras de televisão para manter a qualidade do som e da imagem.

    Codecs com perdas compilam som ou imagem, alcançando altas taxas de compressão, o que ocasiona em perda de qualidade. O desafio na utilização desse tipo de dispositivo é gerar um arquivo com a maior qualidade e o menor tamanho possível.

    Saiba mais sobre Codecs:
    Codecs de vídeo
    Codecs de áudio
    http://en.wikipedia.org/wiki/Codec (em inglês)
    http://pt.wikipedia.org/wiki/Codec (em português)

    Contêineres

    Um contêiner, ou arquivo recipiente, armazena os bytes gerados pelos codecs e outras informações relevantes para decodificá-los como: resolução, taxa de frames por segundo, nome do vídeo/áudio/artista, taxa de bits por segundo, o codec a ser utilizado. Contêineres mais simples podem conter diferentes tipos de dados comprimidos por codecs de áudio, enquanto arquivos recipientes mais complexos podem suportar múltiplas faixas de áudio, vídeo, legendas, informações sobre capítulos e outros metadados, além da informação necessária para sincronização entre várias transmissões.

    Na escolha de um contêiner, deve-se levar em conta cinco principais características: a popularidade (o quão suportável o formato é), tamanho, suporte para funcionalidades avançadas de codec e suporte para streaming.

    Saiba mais sobre Contêineres:
    http://culturadigital.br/videoonline/2010/01/22/conteineres/

    Metodologia da pesquisa para arquivos de vídeo

    Os dados sobre codecs e contêineres foram obtidos primeiramente a partir de planilhas da Wikipedia. Em seguida, foram preenchidos os dados que faltavam por meio de buscas realizadas nos sites das empresas desenvolvedoras e outras fontes da internet. Num segundo momento, as informações obtidas na wikipedia foram revisadas. E, para terminar, essas informações foram interpretadas no sentido de elaborar recomendações determinando os melhores codecs e contêineres nas categorias tecnologia livre e proprietária.

    Tags: , ,

  • Ferramentas de busca de vídeo

    0 comentários

    por: Gabriela Agustini, na categoria Ferramentas de busca dia 02/03/2010

    Buscadores de vídeo são serviços web que vasculham um ou mais serviços de distribuição procurando por vídeos usando palavra chaves ou – em alguns casos – tecnologias de analise semântica.

    A metodologia usada para analisar os buscadores de vídeo se baseou na seleção dos sites mais importantes da internet, seja pela sua popularidade, seja por trazer alguma característica diferencial em relação aos demais. A partir daí, foram pesquisadas informações em três diferentes fontes: os próprios sites das empresas, o Crunchbase — um banco de dados de companhias tecnológicas, pessoas e investidores, que pode ser editado pelos usuário- e a Wikipedia. Quando necessário, as informações foram complementadas com dados presentes em artigos especializados.

    Os sites analisados por esta pesquisa são: Blinkx, VideoSurf, Truveo, Fooooo, Pixsy, Clipta e Google Video Search. Para saber um pouco mais sobre cada um desses buscadores de vídeo online, clique em:

    Tags: , , , , , , ,

  • WebTV

    0 comentários

    por: Gabriela Agustini, na categoria WebTV dia 01/03/2010

    A metodologia usada para a análise dos sites de WebTV foi baseada na importância que as plataformas têm na rede e também em informações colhidas sobre cada uma delas. Para isso, a pesquisa levou em consideração três diferentes fontes: os sites das próprias companhias, a Wikipedia e o Crunchbase, um banco de dados de companhias tecnológicas, pessoas e investidores, que pode ser editado pelos usuários. Quando necessário, as informações foram complementadas com dados encontrados em artigos especializados.

    Os sites de WebTV pesquisados são: BBC iPlayer, Joost, Hulu.

    Ainda dentro de WebTV foi criada a categoria “outros”, que agrega sites que não podem ser considerados realmente WebTV, mas são relevantes para o escopo desta pesquisa. A saber, esses sites são The Auteurs, Boxee, TIVo, Netflix. A metodologia usada para analisar esses sites é semelhante à descrita acima.

    Para saber um pouco mais sobre cada site, clique abaixo:

    Tags: , , , , , ,

  • Plataformas de transmissão ao vivo

    0 comentários

    por: Gabriela Agustini, na categoria transmissão ao vivo dia 01/03/2010

    Plataformas de transmissão ao vivo são serviços web que permitem a transmissão, por meio de webcam ou cameras digitas, de um sinal de vídeo para usuários da internet. Essa transmissão geralmente é feita através de um site especifico, mas alguns possuem tecnologia de embed para que o vídeo possa ser disponibilizado em outros espaços.

    A metodologia utilizada na análise das plataformas de transmissão ao vivo foi baseada na seleção dos sites mais importantes da rede e nas informações pesquisadas sobre os serviços. Para isso, foram consultadas três fontes diferentes: os sites das próprias empresas, a Wikipedia e o Crunchbase — um banco de dados de companhias tecnológicas, pessoas e investidores, que pode ser editado pelos usuários. Quando necessário, as informações foram complementadas com dados tirados de artigos especializados.

    Nessa categoria, foram analisados: Kyte, Qik, Ustream, Justin.tv e Livestream. Clique abaixo para ver as informações levantadas sobre cada item:

    Tags: , , , ,