Frameworks Mobile HTML5

Com a proliferação dos dispositivos móveis, surgiram várias frameworks HTML5/CSS3 com intuito de suportar o desenvolvimento de aplicações destinadas às plataformas mó- veis, com interfaces tácteis. Estas frameworks oferecem um maior e mais consistente suporte do HTML5 e CSS3, além de mitigarem as diferências entre os vários sistemas operativos móveis. Providenciam um conjunto de métodos e ferramentas que auxiliam, por exemplo a integração dos eventos multi toque ou a definição de um layout orientado a dispositivos móveis. Foram analisadas e testadas algumas das frameworks disponíveis a fim de escolher a que melhor se adequa ao projecto. Assim, as frameworks que foram postas à prova são:

• Sencha Touch; • JQTouch; • JQuery Mobile.

O Sencha Touch [Lab11b] é uma framework bastante poderosa e rica em funcionali- dades quando comparada com as restantes. Suporta dispositivos baseados em Android e iOS, providenciando um conjunto alargado de eventos touch e animações. As aplicações webdesenvolvidas via Sencha Touch são independentes da resolução, o que constitui uma mais valia na utilização em multi-plataformas e dispositivos. Contudo, apesar de todas as funcionalidades que o Sencha Touch oferece, a programação é efectuada usando a library de JavaScript ExtJS. O ExtJS tem, tipicamente, uma grande curva de aprendizagem o que aliado ao facto de os tutoriais disponíveis não oferecerem grande ajuda, faz com que o Sencha Touch seja uma opção pouco viável.

O JQTouch é um plugin desenvolvido para a library popular JQuery [Lab11a]. Ofe- rece os eventos touch e gestures nativos da plataforma iOS, suportando iPhone e iPod Touch, sendo no entanto possível utilizar outros dispositivos móveis, sem garantia de total compatibilidade. O plugin disponibiliza vários temas customizáveis consoante os

requisitos da aplicação. Os poucos dispositivos suportados, incluindo a falta de um su- porte aos tablets, a falta de documentação, com poucos exemplos disponíveis no site e a manutenção e desenvolvimento lento, ditaram o afastamento do JQTouch.

O JQuery Mobile é uma framework baseada, tal como o nome indica, no JQuery e é desenvolvida pela mesma equipa que desenvolve o JQuery [JM11]. No site contém a API e várias demos, o que facilita o uso da framework. Apesar de estar ainda em fase Alpha 4, já apresenta um vasto leque de funcionalidades, onde se destacam os seguintes:

• Compatibilidade com iOS, Android, BlackBerry, Symbian, Windows Phone, entre outros;

• Optimizado para tablets e smartphones; • Vários temas disponíveis e customizáveis; • Facilidade de uso;

• Controlo de eventos baseados em touch;

O JQuery Mobile apresenta uma grande comunidade, além de ter um desenvolvimento sustentado e contínuo. A framework é actualmente suportada por empresas reconhecidas como Mozilla Corporation, Blackberry ou Adobe, o que é mais um ponto que evidencia a sua qualidade. Desta forma, a escolha recai sobre o JQuery Mobile, pois contém todos os elementos necessários para o projecto.

Especificação do Projecto

Os sistemas file-based vieram para ficar e prova disso é a constante evolução que se tem verificado ao longo dos últimos anos, e a estagnação que tem afectado os sistemas tape-based. As limitações dos sistemas baseados em tapes provocaram o advento dos sistemas integrados baseados no formato MXF. Os workflows dos file-based são bastante diferentes dos actuais workflows dos sistemas tape-based.

Figura 3.1: Workflow de um sistema baseado em tapes [DWBT06]

Os workflows que se baseiam em tapes, Figura 3.5, têm processos próprios devido às características intrínsicas das tapes. O material é capturado, e depois é levado para Pós-Produção. Na Pós-Produção, são editados de forma linear os conteúdos. Antes do aparecimento de software de edição, a edição dos conteúdos era feita através da directa manipulação da tape, usando um VTR, com outra tape a servir como destino. O editor necessitava de avançar ou retroceder a tape, por não ser fisicamente possível aceder a uma

frame directamente. Depois da Pós-Produção, o material editado segue para distribuição. No fim da difusão, as tapes são armazenadas em arquivo, com as outras tapes.

Como pode ser visto a produção de material televisivo com tapes oferece várias fra- gilidades. As tapes, desde que são gravadas "viajam"por todo o processo. A edição é linear, o que traz muitas complicações e pouca flexidade à Pós-Produção quando com- parado com os sistemas actuais de edição não-lineares. O sistema de arquivo de tapes, tende a ser de difícil organização além de ocupar bastante espaço físico. Como as tapes só podem ser utilizadas algumas vezes para gravação, é necessário novas tapes ao fim de algumas gravações de conteúdo audiovisual, o que acarreta custos elevados. Os proble- mas tinham que ser eliminados ou, na pior das hipóteses, minimizados pelo que foi um questão de tempo e tecnologia até começarem a surgir sistemas digitais que integrassem todas as fases associadas ao broadcasting.

Figura 3.2: Workflow de um sistema baseado em ficheiros [DWBT06]

O fluxo de trabalho dos sistemas centralizados em ficheiros, Figura 3.2, permitem ex- plorar novas possibilidades, como streaming via Web ou através de dispositivos móveis. Além da abertura da Televisão a novos devices e plataformas, os sistemas de ficheiros trazem optimizações aos workflows de produção de vídeo profissional e consequente- mente redução de custos. O workflow dos sistemas file-based, descrito na secção 2.1.1, diferencia-se em todas as fases do workflow dos, agora obsoletos, tape-based systems.

Na fase de captura são usados discos ópticos, como são exemplo os discos da Sony XDCam, ou SSDs como é o caso do modelo P2 da Panasonic. Estes devices permitem fácil acesso ao conteúdo, alto índice de reusabilidade, baixo custo, velocidades altas de datarate, e claro a possibilidade de fazer NLE através de um software de edição profissi- onal. O material depois de ter sido gravado, é lido por um VTR ou um leitor dos discos ópticos ou SSD para ser feito ingest através duma interface HD-SDI/SDI, USB, firewire ou pelo protocolo FTP. O resultado da operação de ingest são ficheiros passíveis de serem

editados.

A fase de Pós-Produção dedica-se à alteração e edição dos conteúdos anteriormente gravados. O surgimento de software de edição cada vez mais poderoso, permitiu que a Edição fosse ganhando maior protagonismo. A adição de efeitos especiais visuais através da tecnologia CGI, permitiu um grande avanço na alteração dos conteúdos previamente capturados.

A distribuição dos conteúdos é hoje feita em sinal HD, para plataformas Web e mobile. A Televisão é actualmente difundida para mais dispositivos, e teve que entrar na Internet sob pena de ser substituída e perder audências para outros meios de comunicação. A Tele- visão através de dispositivos móveis está a ganhar cada vez mais adeptos, sendo exemplo o aumento de mais de 500% de dispositivos móveis que visualizaram as Olimpíadas de Vancouver 2010, comparativamente às Olímpiadas de Beijing 2008 [Rev].

O arquivo engloba os processos de armazenamento e registo dos conteúdos. Depois do material ser difundido, este é guardado em storages servers.

A Televisão enfrenta grandes desafios, não sendo tão importante e única como o era nas décadas anteriores. Um canal de televisão enfrenta a concorrência de websites, de blogs, do Youtube, de outros canais de televisão, além dos tradicionais concorrentes como a Rádio. A optimização de processos, nos tempos que correm, torna-se assim mais impor- tante do que nunca para a Televisão. A produção de notícias televisivas é um caso onde esta optimização é ainda mais essencial, por ser, muitas das vezes, onde as televisões obtêm as maiores audiências.

As notícias são eventos relevantes para a sociedade, que são necessários difundir em virtude do objectivo principal dos meios de comunicação: transmitir informação. Como nem sempre é possível prever a ocorrência de um evento passível de ser notícia, as reda- ções têm de estar preparadas para todo o tipo de notícias. A informação que é difundida, passa por um longo processo até chegar às audiências. O workflow de produção das notí- cias pela Televisão, foco da tese proposta, é detalhado no próximo capítulo.

3.1

Produção de Notícias

Da realização das Teses de Mestrado de Francisco Brito [Bri11] e José Nuno Fer- reira [Fer11] propostas pela MOG, foram realizadas duas visitas aos estúdios da televisão estatal portuguesa RTP. O objectivo principal das visitas foi o de perceber e analisar o pro- cesso de produção de notícias de um canal de televisão. Embora seja descrito o processo de produção de notícias da RTP, pode-se considerar que este processo é muito semelhante ao de qualquer outro canal de televisão.

A RTP é o canal de televisão estatal de Portugal, e dedica-se à produção de variados conteúdos televisivos como telejornais, concursos ou transmissão de eventos desportivos.

A RTP tem a seu cargo dois gabinetes localizados no Porto e em Lisboa. De seguida, irá ser detalhado o processo de produção de notícias usado no canal de televisão referido.

3.1.1 Workflow actual

O workflow da RTP relativamente à produção de notícias consiste em cinco fases [Fer11]:

• Aquisição do tema da notícia; • Angariação de informação; • Edição;

• Publicação; • Broadcasting.

Na fase de aquisição do tema da notícia, o jornalista descobre um evento passível de ser noticiado ou é-lhe atribuído pelo redactor um tema para posterior divulgação. A equipa de produção de notícias tem acesso a um conjunto alargado de fontes de informa- ção como: agências de notícias, meios de comunicação impressos, tais como jornais ou revistas, Rádio, contribuições de telespectadores, websites, entre outros. Se a notícia for da iniciativa do jornalista, esta está dependente do aprovação do Director de Informação. A fase seguinte, é a fase onde o jornalista procede ao desenvolvimento da notícia . O jornalista, caso tenha essa possibilidade, desloca-se ao local onde ocorreu o evento para um melhor apuramento dos factos, por exemplo através de entrevistas ou de gravações vídeo. No entanto, o jornalista apoia-se sempre em outros meios de comunicação para uma definição mais precisa e correcta do conteúdo. As agências de notícias são um forte aliado nesta fase, pois possibilitam o acesso a um vasto leque de notícias em tempo real. Depois de feita a filtragem e selecção do conteúdo a ser produzido, o jornalista procede à fase de edição.

Depois de criado o tema e respectivo conteúdo, o jornalista foca-se na edição da notí- cia. A notícia é editada, cortada e arranjada de forma a ser apelativa aos telespectadores. São adicionadas legendas, um técnica muito importante das notícias televisivas, pois aju- dam a manter o interesse do público. Depois de estar formatada e devidamente preparada, a notícia é armazenada em rede para ser publicada em servidores playout.

A publicação é a fase onde se realiza a adição da metadata definida pela RTP. Depois da fase de pós-produção, é importante definir a metadata de forma concordante com os padrões seguidos pelo canal de televisão. No caso da RTP, a metadata introduzida contém informação relevante como: o texto de introdução que o apresentador do noticiário deverá ler, ou informação essencial para a equipa de produção.

A última fase do workflow é a aquela onde as notícias, depois de estarem finalizadas, são difundidas para serem visualizadas pela audiência. As notícias produzidas estão nos servidores playout, e são adicionadas à timeline do software ENPS para serem transmiti- das.

A RTP tem ao seu dispôr várias ferramentas que auxiliam o processo de produção de notícias. O ENPS é um sistema de produção de notícias desenvolvido pela AP [ENP11]. Integra editores de vídeo, armazenamento, e sistemas de outgest, permitindo aos jornalis- tas gerirem melhor as notícias a serem produzidas. O sistema é a base de todo o workflow associado à produção de notícias na RTP. O sQ Edit é um software NLE desenvolvido pela Quantel, que providencia funcionalidades para corrigir erros de imagens como cor, e ainda multi-camadas de composição ou masking faces.

Como foi referido anteriormente, o jornalista pode precisar de aceder aos serviços fa- cultados pelas agências de notícias. Caso a RTP não consiga cobrir uma notícia, recorre aos baskets que as agências fornecem para assim poder divulgar a notícia. Notícias in- ternacionais são muitas vezes divulgadas, tendo por base agências como a Reuters ou a AP, pois é impraticável para canais de televisão de semelhantes à RTP terem colaborado- res espalhados pelo Mundo inteiro. Quando um jornalista procura informação sobre uma dada notícia nos serviços das agências, o processo que segue é, tipicamente, o seguinte:

1. Acede ao website da agência de noticias;

2. Procura pelos assets que deseja exclusivamente pelo nome do asset; 3. Para cada asset, o jornalista tira uma nota da referência do mesmo; 4. Repete os primeiros três passos para as todas as agências que dispõe;

5. O jornalista procura os assets, no editor de vídeo, usando as referências retiradas no passo 3, para proceder à edição;

6. No final, o asset é guardado num servidor playout, para ser posteriormente adicio- nado ao bloco de notícias pelo software ENPS, em conjunto com a metadata.

Analisando o processo, é possível perceber que este é relativamente eficiente. No caso da RTP, como tem acesso a várias agências, este processo pode tornar-se moroso e propício a erros. Contudo pode ser optimizado, em virtude da necessidade de aceder aos vários baskets separadamente, ou da pesquisa pelo asset poder apenas ser feita pelo nome de ficheiro. A procura do asset é feita de forma separada relativamente à pesquisa da respectiva metadata, o que também pode originar falhas. Uma proposta de solução que visa corrigir os problemas e melhorar o workflow dos jornalistas é proposto na próxima secção.

3.2

newsRail

A solução proposta é um sistema centralizado como único ponto de acesso aos assets dos vários baskets, com pesquisa avançada de assets e respectiva metadata e possibilidade de exportação para o editor de vídeo. Providencia um melhor paradigma de pesquisa orientada não só por palavras-chave, mas também por duração, basket de origem, ou pelo estado de exportação dos assets, isto é, exportado ou não exportado. É possível organizar "vistas"com critérios de pesquisa diferenciados, para uma melhor organização da vasta informação disponível. Relativamente ao workflow dos jornalistas da RTP, o newsRail permite optimizá-lo na medida em que:

• Evita a repetição dos três primeiros passos do workflow original;

• A probabilidade de ocorrerem erros provenientes de uma pesquisa errónea é inferior; • O vídeo fica automaticamente disponível no editor de vídeo.

3.2.1 Requisitos

3.2.1.1 Requisitos Funcionais

O newsRail foi definido segundo um conjunto de requisitos functionais e não-funcionais, essenciais para uma melhor compreensão e implementação do sistema. Depois da análise efectuada ao workflow da RTP e dos problemas inerentes ao mesmo, foram descritos os seguintes requisitos funcionais:

• Geração automática das versões proxy de cada basket configurado;

• Pesquisa, filtragem, ordenação e pré-visualização dos vídeos e respectiva metadata; • Exportar os vídeos directamente para o ambiente de edição.

A primeira funcionalidade diz respeito à descoberta automática, por parte do news- Rail, de novos assets em algum dos baskets e respectivo ingest. Os vídeos que as agên- cias de notícias disponibilizam nos baskets estão em formato HD, pelo que é necessário efectuar o transcode dos vídeos para formatos de mais baixa resolução e de dimensões in- feriores, chamados de proxy. Estes vídeos proxy, são mais apropriados à pre-visualização e à edição. Além da geração dos proxys, o newsRail também deve gerar keyframes, que não são mais que imagens do vídeo original. Como o newsRail está orientado a tablets, beneficiam de vídeos de dimensões reduzidas pois estes dispositivos possuem velocida- des de transmissão de dados inferiores aos computadores desktop. Os vídeos proxy e a respectiva keyframe serão usados pela UI para efectuar as operações de pesquisa ou de filtragem.

O segundo requisito é o conjunto de operações que o utilizador poderá efectuar para uma melhor e mais precisa selecção dos vídeos a serem exportados. Para escolher os ví- deos, o sistema providencia um leque de filtros onde se inclui a data máxima e/ou mínima do asset, duração mínima e/ou máxima do asset, entre outros que serão discutidos em pormenor no próximo capítulo. A listagem dos assets, além de poderem ser filtrados de acordo com um conjunto de restrições, podem também ser ordenados por critérios como duração ascendente ou descendente. Para uma melhor visualização da metadata e do pró- prio vídeo, o sistema deve ter um modo preview. Este modo possibilita ao utilizador, ver o proxy em dimensões maiores com um grande ênfase na metadata associada. A pesquisa por palavras-chave, como em todos os sistemas de selecção e pesquisa, deve também ser possível de efectuar, não só pelo nome do ficheiro, mas também pelos campos de texto presentes na metadata.

O último requisito funcional solicita que o newsRail possa, através da acção do utili- zador, exportar os vídeos seleccionados para o software de edição de vídeo. O passo final do workflow do newsRail é dar a possibilidade de exportar os vídeos para o editor de ví- deo, para depois proceder à pós-produção das notícias. Este requisito é fundamental, pois sem ele o newsRail falha na conclusão do seu objectivo principal: melhorar o workflow dos jornalistas e ser transparente desde os serviços das agências de notícias até ao editor de vídeo.

3.2.1.2 Requisitos não-funcionais

Os requisitos não-funcionais, especificam os critérios que avaliam o sistema como um todo e não pelas suas funcionalidades. Por ser um sistema distribuído e acedido via web, são necessários determinados requisitos não-funcionais que são detalhados em seguida:

• Portabilidade - Devido ao aumento dos tablets e seus sistemas operativos, é esperado que o sistema tenha a capacidade de se adaptar facilmente a novos ambientes. As tecnologias front-end usadas no projecto e a cada vez maior adopção das mesmas é um prenúncio quanto à portabilidade do sistema.

• Usabilidade - Sendo o projecto orientado aos dispositivos tablets é importante que a UI esteja de acordo com as limitações e potencialidades inerentes a estes tipos de dispositivos. Deve providenciar uma UI simples, intuitiva e também adequada aos ambientes do jornalismo.

• Flexibilidade - O sistema deve permitir a adição de novas funcionalidades, de forma a poder evoluir confortavelmente segundo necessidades que forem surgindo. Como o newsRail foi desenhado tendo por base o workflow da RTP, este requisito torna-se vital dado a existência de vários workflows diferentes de produção de notícias.

• Interoperabilidade - Como existem várias agências de notícias diferenntes, que pro- videnciam os assets com características próprias como o formato de vídeo usado ou o tipo descrição da metadata, é desejável que o sistema tenha a abilidade de se adaptar aos diferentes requisitos impostos.

• Desempenho - O desempenho é fundamental em qualquer software, e no caso espe- cífico de sistemas de apoio à produção de notícias, este requisito ganha ainda mais importância. O newsRail visa optimizar e melhorar o workflow de produção de notí- cias, pelo que é necessário e óbvio que o sistema tenha um tempo de resposta baixo sob pena de perder as vantagens que traz aos jornalistas.

3.2.2 Workflow do newsRail

Antes de detalhar a arquitectura utilizada pelo newsRail, é necessário proceder à ex- plicação de todo o workflow do newsRail.

Figura 3.3: Workflow do newsRail

A representação do workflow do newsRail, Figura 3.3, contempla o sistema tal como foi idealizado. O estado actual do middleware não possibilita, por exemplo, utilizadores diferenciados, ou seja, só permite um administrador que tem acesso a todas as funciona- lidades que o sistema oferece. Os utilizadores acedem ao newsRail através do protocolo HTTP, usando um web browser. O newsRail está à "escuta"nos baskets configurados e quando um novo asset é adicionado a um basket é feito o seu processamento. O proces- samento inclui transcodificar o vídeo do asset para uma versão proxy e popular a base de dados com a informação do vídeo e respectiva metadata. O Rhozet Carbon Coder é o softwarede transcodificação usado na geração das versões proxy, para a UI, e das versões HD para o editor de vídeo. Para um melhor esclarecimento de todo o fluxo de trabalho, são de seguida detalhados os passos necessários:

1. Depois de devidamente configurados os baskets, o newsRail monotoriza cada basket à espera de novos assets;

2. Quando surge um novo asset, o newsRail, caso este ainda não esteja na presente na base de dados, analisa a metadata e regista a informação na base de dados e ordena ao Carbon Coder para efectuar o transcode do vídeo para a versão proxy. Além do