Ambiente Interactivo de apoio à criação em Arte Digitalpaginas.fe.up.pt/~ee98105/relatoriofinal.pdf · 1 Introdução ... 1.1 Plataforma VAF/Coral.....5 1.1.1 Como Obter ... que

Faculdade de Engenharia da Universidade do Porto Licenciatura em Engenharia Electrotécnica e de Computadores

5º Ano Projecto Seminário Trabalho de Final de

Curso – 2002/2003

Ambiente Interactivo de apoio à criação em Arte Digital

Nuno Luciano da Silva Neto [email protected] Orientador FEUP: Prof. Luís Corte-Real Orientador local: Eng. Luís Teixeira

Projecto Seminário Trabalho Final de Curso

INESC Porto

Relatório Final Página 2/71

Índice de conteúdos: Índice de conteúdos: ......................................................................................................... 2 Agradecimentos ................................................................................................................ 4 1 Introdução...................................................................................................................... 5

1.1 Plataforma VAF/Coral............................................................................................ 5 1.1.1 Como Obter .............................................................................................. 5 1.1.2 O que é de facto o Projecto Coral............................................................ 5 1.1.3 Objectivos do projecto Coral.................................................................... 6 1.1.4 Framework do Coral ................................................................................ 6

Implementação................................................................................................... 7 Arquitectura de Comunicação.......................................................................... 7 Objectivos............................................................................................................ 9 Vista geral da Aplicação ................................................................................... 9

1.2 Plataforma PD (Pure-Data) ............................................................................. 12 1.2.1 Como obter o PD? .................................................................................. 12 1.2.2 Pequena introdução sobre PD................................................................ 12 1.2.3 Apresentação da plataforma PD............................................................ 13

A janela Principal e forma de funcionamento.............................................. 13 2 Objectivo do trabalho............................................................................................. 16

2.1 Descrição resumida do trabalho a realizar ...................................................... 16 3 Trabalho Realizado ..................................................................................................... 17

3.1 Estudo da plataforma VAF/Coral e criação de um pequeno Módulo, ou Motor.. 17 3.1.1 Implementação do novo “motor” – Router................................................... 17

Algumas das alterações efectuadas para criação do Router ................... 17 3.1.2 Passos para integração do novo “motor” na plataforma VAF/Coral.......... 19 3.1.3 Resultados Obtidos ........................................................................................ 20

3.2 Estudo da plataforma PD e formas de ligação ao VAF/Coral.............................. 23 3.2.1 Formas de comunicação estudadas ................................................................ 23

Protocolo de comunicação Open SoundControl......................................... 23 Protocolo de comunicação TCP.................................................................... 24

Protocolos Orientados à Conexão ............................................................ 27 3.3 Implementação dos módulos de comunicação ..................................................... 29

3.3.1 Implementação do “motor” Net_receive....................................................... 29 Principio de funcionamento e explicação de algumas funções................ 29 Resultados Obtidos ......................................................................................... 31

3.3.2 Implementação do “motor” Net_send........................................................... 32 Principio de funcionamento e explicação de algumas funções................ 32 Resultados Obtidos ......................................................................................... 34

4 Conclusão .................................................................................................................... 37 5 Bibliografia .................................................................................................................. 38

........................................................................................................................ 39 Anexo 1 - Código da implementação do Router ............................................................ 40 Anexo 2 - Código da implementação do Net_receive .................................................... 48 Anexo 3 - Código da implementação do Net_send ........................................................ 57


INESC Porto


Ficheiro net_send.cpp ................................................................................................. 58 Ficheiro net_socket.cpp .............................................................................................. 66 Ficheiro net_socket.h.................................................................................................. 71


INESC Porto


Agradecimentos Em primeiro lugar queria aqui demonstrar os meus sinceros agradecimentos

aos meus orientadores de estágio, Eng. Luís Teixeira e Prof. Luís Corte -Real, pelas suas disponibilidades em ajudar-me no trabalho a desenvolver.

Ao INESC Porto pelos meios disponibilizados para a execução do trabalho. Quero também a agradecer a todos meus colegas que durante estes 5 anos

me acompanharam pelos bons momentos que me fizeram passar. Quero agradecer ao meu colega Lucian Ciobanu, que me forneceu preciosas

informações e incentivos quando o trabalho atravessava uma fase mais conturbada. A todos, o meu mais sincero obrigado.


INESC Porto


1 Introdução Para o a execução do trabalho a desenvolver foram utilizadas duas

plataformas existentes de processamento de objectos multimédia (nomeadamente tratamento de som e imagem). As plataformas utilizadas são VAF/Coral1 (ferramenta preferencialmente utilizada para tratamento de imagem) e PD2 (ferramenta preferencialmente utilizada para tratamento de som bem como outro tipo de aplicações variadas).

Nas próximas secções vamos ter uma breve descrição destas plataformas, bem como, forma de as obter, etc.

1.1 Plataforma VAF/Coral

1.1.1 Como Obter Para obter a plataforma VAF/Coral é necessário que consulte a página

telecom.inescn.pt/coral e a partir dela fazer um registo para obter um início de uma sessão de cliente do INESC Porto. Depois de se tornar um usuário já pode fazer o download da plataforma e seguir os passos de instalação referenciados na página.

O INESC Porto disponibiliza esta plataforma para que qualquer usuário interessado possa contribuir para o Projecto Coral. De que forma é que isso pode ser feito? Contribuindo por exemplo com as suas ideias, comentários, sugestões. Uma maneira mais útil para contribuir é testando o Software, relatando problemas do mesmo e sugerindo hipóteses de resolução.

1.1.2 O que é de facto o Projecto Coral

O Coral é uma aproximação de uma novela para análise e representação de vídeo utilizando uma nova linguagem visual de programação orientada a objectos. Cada objecto, ou como é preferencialmente chamado: o motor, executa uma tarefa específica ou diversas tarefas relacionadas tais como o armazenamento de dados, fluxo de dados ou processamento de dados e são representados graficamente por um rectângulo e pelo seu nome. Na fig.1a) podemos observar o aspecto de um motor.

A informação de controle e de dados é trocada entre Objectos usando mensagens, representadas graficamente como linhas de ligação entre os objectos (fig.1b)). Os objectos são armazenados segundo a sua tarefa como parte de uma biblioteca de forma a que possam ser reutilizados e recombinados.

1 Vídeo Analyser Framework do Coral 2 Pure-Data


INESC Porto


O coral suporta operações tais como analisar gramaticalmente vídeo e representações de vídeo com diferentes níveis de abstracção com o uso de objectos especiais: motores de vídeo.

Fig.1a) – Exemplo de um motor

Fig.1b) – Exemplo das linhas de ligação para troca de informação

1.1.3 Objectivos do projecto Coral

Um dos objectivos do projecto Coral é desenvolver uma estrutura ambiente para dinamicamente seleccionar a análise de vídeo e descrição de ferramentas de acordo com as exigências específicas das aplicações. Assim, a estrutura tem de fornecer:

• modularidade: integração rápida e fácil de novos algoritmos na

aplicação suportando a sua expansibilidade. • flexibilidade: fácil adaptação a algoritmos ou a exigências da

aplicação.

O objectivo final para a plataforma Coral, é construir um sistema dinâmico capaz de adaptar-se de acordo com objectivos do usuário e os motores de vídeo disponíveis e mecanismos de adaptação.

1.1.4 Framework do Coral


INESC Porto


Implementação

Um dos objectivos da plataforma do Coral é que o sistema siga uma aproximação usuário-centrada. Assim independentemente do sistema operativo (Linux/Windows) ou o modo da operação (distribuído / numa máquina apenas), a experiência do utilizador deve ser sempre a mesma. Os sistemas operativos diferentes implicam ambiente de programação gráfico diferente se forem usadas as línguas de programação padrão. Para evitar este tipo de problema é que foi escolhido a linguagem Java para a implementação do GUI. O Java é uma arquitectura de nível elevado com características inerentes.

Um outro problema do projecto era devido à diversidade dos formatos de vídeos e das estruturas de dados usadas nas ferramentas de vídeos. Pretendeu-se não só integrar as novas ferramentas mas também as ferramentas já existentes desenvolvidas internamente no INESC Porto e por sócios externos. A adição de novos módulos no sistema deve envolver um esforço mínimo em adaptar-se ao código.

Contudo pretende-se também que o desempenho seja maximizado e que as duras exigências impostas aos recursos do sistema pelas ferramentas de vídeo sejam minimizadas. A maioria do trabalho efectuado na análise de vídeo foi feito na língua C/C++ devido ao seu desempenho. Uma possível solução de implementação deveria incluir rotinas de C como código nativo dentro do Java, usando JNI – Java Native Interface. Esta solução acabou por ser evitada porque retardaria a execução e não permitia suportar algoritmos implementados em outras linguagens. Decidiu-se então transformar cada ferramenta em um motor que se processa autonomamente (na fig.1a) tem um exemplo de uma imagem de um motor já implementado). Cada ferramenta de vídeo individual é encapsulada com um módulo que permite a troca de informação, através de um socket, com o sistema de aplicação.

Arquitectura de Comunicação

A comunicação é feita Via Sockets UDP, seguindo a filosofia de “Um Servidor – Múltiplos Clientes” (fig. 2). O módulo do servidor, “Communications Manager”, é implementado em Java . O bloco do servidor aloca um thead e um único endereço de socket por “engine”. Os sockets são canais que os “engine” (rotinas C que efectuam todo o processamento) usam para comunicar com o lado do servidor (Java).


INESC Porto


Fig. 2 - Arquitectura do sistema

Durante o processo de inicialização, cada “engine” cria o seu próprio socket. Isto permite que o “Communications Manager” estabeleça para qualquer par de “engines” uma troca de mensagens directas entre eles. Cada “engine” tem os seus próprios inputs e outputs que são identificados com os algoritmos através dos seus números de identificação (ID numbers). Portanto é possível que um processo envie dados de um determinado output para um input de outro processo, assim os dados são enviados directamente de um algoritmo para outro.

A sincronização assenta também na troca de mensagens de eventos entre ambos os lados da aplicação.

O esquema de comunicação adoptado, para além de permitir a interacção entre o Java e o C, representa também uma solução para outro problema que já foi mencionado previamente ( a da diversidade de dados existente). De facto, os sockets suportam todos os tipos de dados digitais (dados de imagem,


INESC Porto


estatísticas de imagem, etc.), permitindo assim um nível de integração necessário para a implementação da Framework do Coral.

O uso dos recursos da rede para suportar a comunicação entre processos tem ainda outra vantagem. De facto, uma simples mudança de sockets UDP para TCP torna bastante simples a distribuição dos “engines” por diversas máquinas, o que satisfaz outro dos requisitos do Framework: capacidade de funcionamento num ambiente distribuído.

Objectivos

Uma das áreas previstas para as aplicações do Coral é a descrição e recuperação do vídeo. Por forma a descrever da melhor forma o vídeo, este deve ser segmentado. Nesta secção vou começar por descrever como o vídeo deve ser segmentado e depois vou apresentar como funciona o sistema.

O vídeo tem de ser espacialmente e temporalmente segmentado de uma forma hierárquica de acordo com o seu índice. A segmentação espacial define duas camadas: a camada mais elevada, que se relaciona à área de exposição visualizada na tela e é referente à região de exposição; e a camada mais baixa, que é referente à região do objecto. Nas regiões dos objectos têm que ser satisfeitas algumas características, tais como a textura, a cor ou o movimento. No domínio temporal também são identificados dois níveis: a camada vídeo do objecto e scene/take/shot do objecto. O nível mais baixo, a camada vídeo do objecto, agrupa regiões do objecto no domínio temporal. A camada superior é caracterizada um conjunto homogéneo de características. Esta camada é definida no shot, scene, take, ou no nível do programa.

Um descritor global é referente à camada hierárquica temporal superior. Este contém a informação aplicável à duração total do scene/take/shot e a uma combinação específica dos vídeos objectos. Pode incluir a informação a respeito da velocidade global do movimento , dos parâmetros da câmera, etc. Contem referencias dos descritores dos vídeos objectos e uma medida do impacto perceptual de cada vídeo objecto no scene/take/shot. Um descritor vídeo objecto, pode conter a referência a uma ou mais regiões do objecto em cada região de exposição. Inclui características do objecto tais como o tamanho, a forma, a complexidade, a indicação do movimento, o impacto perceptual, etc. Deve também indicar o seu tempo de execução, isto é, o período de tempo em que o descritor e o vídeo objecto são válidos.

Vista geral da Aplicação

Na fig. 3 podemos observar um exemplo de um projecto Coral. Quando é aberto um projecto Coral, o ficheiro de texto armazenado no disco é interpretado para criar uma representação gráfica na tela do computador. Quando o projecto é executado, cada objecto chama as funções escritas em C sem que o utilizador necessite de programar em C, isto porque o nível de complexidade da programação está escondido do utilizador.


INESC Porto


Fig. 3 – Exemplo de um projecto Coral

O primeiro bloco, do Exemplo da fig. 3, representa o ficheiro de entrada, neste caso vídeo. Descrevendo e analisando o diagrama, a sequencia de vídeo de entrada está “alimentar” três motores que processam paralelamente . De cima para baixo, o primeiro é apenas o Original, o segundo é composto por um bloco de binarização seguido de um detector de contornos e o último é composto por um detector de movimento óptico (algoritmo de Lucas-Kanade) e o seu gerador de imagens de vectores correspondente. Como podemos observar existem também mais dois tipos de blocos um pouco diferentes que são o file e os testpoints, estes blocos são uma espécie de motores especiais, em que o bloco file serve apenas para colocar um ficheiro de entrada e o testpoint para podermos visualizar o que temos nas saídas dos “engines”.

A fig. 4 apresenta os resultados obtidos com o sistema da fig. 3. No canto superior esquerdo temos uma frame da sequência original. No canto superior direito temos o resultado da binarização da imagem. Canto inferior esquerdo, podemos observar a imagem “vectorizada” da saída do bloco FlowImage e finalmente no canto inferior direito temos a saída do bloco detector de contornos.


INESC Porto


Fig. 4 – Janela de resultados do projecto Coral exemplificado


INESC Porto


1.2 Plataforma PD (Pure-Data)

1.2.1 Como obter o PD?

A plataforma PD é muito fácil de obter, basta consultar, por exemplo, a página www.pure-data.org e através dela fazer o download da plataforma, ou se preferir fazer uma pesquisa numa página de buscas, por exemplo, www.goole.pt e pesquisar pure-data. Apartir das páginas fornecidas deve ser também muito fácil de obter a plataforma PD.

1.2.2 Pequena introdução sobre PD

PD é um ambiente de programação gráfico em tempo real para processamento áudio e gráfico e que foi criado por Miller Pucket. O PD foi desenvolvido numa tentativa de remediar algumas deficiências de um programa já existente, que era o Max/MSP, mantendo no entanto as suas virtudes e os seus pontos fortes. Por isso o PD é muito semelhante ao sistema Max/MSP mas é muito mais simples e mais portátil. Tem também duas características ainda não utilizadas no Max/MSP. A primeira é que através do pacote Mark Dank’ GEM, o PD pode ser usado para animação e áudio simultaneamente no computador. A segunda, é a grande facilidade experimental que é fornecida para definir e acessar estruturas de dados.

O PD é um sistema open source com uma grande colaboração entre uma larga comunidade de usuários e colaboradores. Este facto tem os seus prós e contras. A grande vantagem é que é grátis e está constantemente a ser mudado e actualizado. O grande contra é que existe uma grande falta de documentação sobre o PD relativo ao desenvolvimento efectuado e o conhecimento que existe actualmente. PD é de tal forma um software aberto que os utilizadores que trabalham arduamente com ele, raramente tem a oportunidade de documentar adequadamente o que estão a trabalhar e desenvolver. E mesmo quando o trabalho é documentado, tende a ser dispersado por toda a Internet, não sendo portanto fácil de encontrar uma larga documentação sobre todos os desenvolvimentos da plataforma PD.

Os programas para o PD são “escritos” usando programação por objectos gráficos em vez de texto. È uma poderosa forma de trabalhar na qual o utilizador pode definir blocos de código para fazer coisas bem definidas e reutiliza-los continuamente. Esses blocos, ou objectos, contêm eles próprios saídas e entradas e podem ser ligados a outros objectos que fazem outras coisas. Os blocos ou objectos PD são criados por programação em C.


INESC Porto


1.2.3 Apresentação da plataforma PD

A janela Principal e forma de funcionamento Quando o PD é inicializado, são lançadas duas janelas (fig. 5):

Fig.5 - Janelas do PD

A janela esquerda é a janela principal do PD. Nela há peak levels e clip indicators para entrada e saída de áudio. Podemos ver também um botão DIO que permite, se pressionado, ver uma lista de erros recentes.

A janela esquerda é a forma como o PD comunica connosco: contudo não é possível escrever nada directamente sobre ela. È nesta janela que o PD vai exibir-nos as mensagens.

Para criar um programa novo tem de ser aberto um novo patcher. Isto é feito seleccionando o menu File e escolhendo New. Posto isto, o PD cria uma nova janela chamada Patcher Window (fig. 6).

Fig. 6 – Nova PD Patcher


INESC Porto


Toda a programação é feita numa ou mais janelas Patcher. No topo da janela Patcher tem o menu que pode ser usado para inserir ou remover objectos, salvar os Patcher, etc.

Como já foi mencionado, PD é uma linguagem de programação gráfica orientada a objectos, e os ícones, ou objectos, são representações gráficas de acções programadas (como também já foi dito, estas acções são programadas em C). Através da ligação entre vários objectos podemos criar vários programas, por exemplo, na próxima figura (fig. 7) podemos ver a forma como pode ser implementado um cronometro digital utilizando apenas os objectos existentes na plataforma PD.

Fig. 7 – Exemplo da programação de um cronometro digital

Na próxima imagem podemos observar a resposta ao cronómetro programado no patcher da fig. 7.


INESC Porto


Fig. 9 – Resposta obtida do cronómetro digital Com a plataforma PD podem ser criados diversos programas, uns mais

simples e outros mais complicados, que podem ser muito vantajosos para o trabalho do nosso dia a dia. Uma das boas aplicações em que o PD é utilizado é o tratamento áudio.


INESC Porto


2 Objectivo do trabalho

O objectivo deste trabalho é desenvolver módulos de comunicação para uma plataforma distribuída de processamento de objectos multimédia existente (VAF/Coral), de forma a permitir a comunicação e troca de informação com outras plataformas existentes.

2.1 Descrição resumida do trabalho a realizar

• Familiarização com a plataforma de processamento de objectos multimédia existente (VAF/Coral, esta tarefa inclui o desenvolvimento de pequenos módulos).

• Estudo da plataforma PD e estudar formas de comunicação entre as duas plataformas, nomeadamente a comunicação OSC3 e comunicação TCP.

• Criação dos módulos de comunicação (no VAF/Coral) para comunicação com a plataforma PD.

• Testar os módulos de comunicação criados.

3 Open SoundControl


INESC Porto


3 Trabalho Realizado

3.1 Estudo da plataforma VAF/Coral e criação de um pequeno Módulo, ou Motor

Depois da instalação da plataforma do Coral, o primeiro passo foi estudar a sua forma de funcionamento, observar e testar alguns “motores” já existentes na plataforma, estudar as formas de inserção e implementação de novos “motores” e passar isto para a prática, ou seja começando por criar um novo “motor”.

Este novo motor criado é uma espécie de router. As suas funcionalidades são apenas ler o ficheiro que tem na entrada e coloca-lo numa das suas saídas, escolhida segundo um algoritmo que permite escolher uma das portas aleatoriamente.

3.1.1 Implementação do novo “motor” – Router

A criação deste novo “motor” denominado Router, foi baseado num “motor” já existente, o “motor” Original. Este “motor” já existente, na prática, o que faz é apenas passar o que tem no ficheiro de entrada para a sua saída. Ora o que se pretende que o Router faça é exactamente o mesmo, só que em vez de colocar numa saída, vai ter de seleccionar uma das suas quatro saídas que possui. È de notar aqui o facto de o Router não passar tudo o que tem na entrada para uma das saídas seleccionadas, mas sim colocar cada frame (no caso de um vídeo de entrada) na saída seleccionada aleatoriamente, permitindo assim um efeito visual bastante interessante.

Algumas das alterações efectuadas para criação do Router

No Anexo 1 pode ser observado a totalidade do código de criação do Router. De seguida temos umas breves explicações de código e algumas das alterações efectuadas ao “motor” Original para a criação do Router.

main (int argc, char *argv[]) { int saida=0, i; Inic_Random(); … … for (current_frame_number = 0; current_frame_number < nrframes;

current_frame_number++) { load_input_set(input_buffer_set); // lê a informação da entrada


INESC Porto


saida = 1+rand()%NO_SAIDAS; //selecciona a saída wait_for_process_command(); … …

Para começar foram criadas mais algumas variáveis auxiliares e uma

nova função denominada Inic_Random (). As funcionalidades desta função são apenas lançar uma semente aleatória, a partir do relógio do sistema, permitindo assim que a variável saída não tenha sempre a mesma semente e por conseguinte tenha uma sequência aleatória sempre diferente. Por outras palavras, se fosse utilizada uma semente fixa os números gerados aleatoriamente tinham sempre a mesma sequência deixando, por isso, de ser tão aleatório quanto se pretende. Esta função apresenta um código bastante simples que podemos observar de seguida.

void Inic_Random() { long ultime; time(&ultime); srand((unsigned) ultime); }

Outra alteração necessária para o bom funcionamento do Router é na parte em que é necessário passar os atributos da entrada para cada uma das saídas. for(i=0; i < NO_SAIDAS; i++) // para cada saida

{ output_buffer = getBufferFromSet(output_buffer_set, i); yuvImage_out = (YUV_Image *)get_data_in_next_slot(output_buffer, 0); if (!are_yuvImages_equal(2, yuvImage_in, yuvImage_out)) { #ifdef PRINT_ERR fprintf(stderr, "yuvImage params need to be updated!!\n"); #endif get_yuvImage_attributes(imgAttr_out, yuvImage_in); set_yuvImage_attributes_in_buffer(output_buffer, imgAttr_out);

} }

Depois foi alterado um parâmetro da função appendDataInBufferSet (o

parâmetro alterado é o que está sublinhado), pois é esse parâmetro que indica qual é a saída seleccionada. Esta função é que passa a informação para a saída.

appendDataInBufferSet (output_buffer_set, saida - 1, yuvImage_in, 1, 0);


INESC Porto


Por fim foi alterada a função add_output. Nesta função apenas foram

acrescentadas mais umas linhas, para esta funcionar de acordo com o número de saídas, que são quatro.

void add_output(int output_id) { switch (output_id) { case 0: output_buffer = allocate_generic_buffer(IMG,1,output_id); addBufferToSet(output_buffer_set, output_buffer); break; case 1: output_buffer = allocate_generic_buffer(IMG,1,output_id); addBufferToSet(output_buffer_set, output_buffer); break; case 2: output_buffer = allocate_generic_buffer(IMG,1,output_id); addBufferToSet(output_buffer_set, output_buffer); break; case 3: output_buffer = allocate_generic_buffer(IMG,1,output_id); addBufferToSet(output_buffer_set, output_buffer); break; default: break; } }

3.1.2 Passos para integração do novo “motor” na plataforma VAF/Coral

Para a integração do novo “motor”, foi criado um novo projecto denominado Router, em que foi incluída a biblioteca LibIntegration_Static, necessária para a compilação do mesmo. Após as alterações já referidas no código e após compilação do projecto adicionou-se o algoritmo à Framework do Coral. Para isso foi criado um ficheiro de texto – Router.txt (fig.10) que descreve as propriedades necessárias para o funcionamento do “motor”, nomeadamente, o seu nome, localização, numero e tipo de inputs e outputs.


INESC Porto


Fig.10 – Router.txt

3.1.3 Resultados Obtidos

Após efectuada a integração do novo “motor” na Framework do Coral, efectuaram-se alguns testes de simulação utilizando para isso alguns ficheiros de vídeo, já testados em outras aplicações do VAF/Coral.

Para isso foi criado um novo projecto e com a seguinte forma:

Fig.11 – Projecto utilizado para testar o Router Como podemos observar na fig. 11, para além do “motor” Router temos

também quatro “motores” originais. Estes quatro “motores” estão incluídos no projecto apenas para podermos diferenciar mais facilmente as saídas, pois sem a sua existência todas as saídas tinham o nome de router 0.

De seguida podemos observar diferentes figuras que nos demonstram, não da forma mais evidente pois visualizando os resultados ao vivo temos uma


INESC Porto


muito melhor percepção do que acontece, alguns dos resultados obtidos com este projecto.

Fig.12

Nesta fig. podemos observar que a primeira saída seleccionada foi a 2 (de 0 a 3) e por conseguinte ficou a com a 1ª frame do vídeo de entrada.

Fig.13

Agora a saída seleccionada foi a 0 e esta ficou com a frame respectiva. É de notar que devido ao facto de as saídas serem seleccionadas ao acaso, pode ocorrer que sejam seleccionadas em vezes consecutivas, o que ainda ñ aconteceu neste caso. È de salientar também que apesar das imagens serem


INESC Porto


iguais na realidade elas são diferentes, são frames diferentes. Este facto pode ser observado numa fase de teste mais adiantado como o que acontece na fig.14.

Fig.14

Aqui numa fase já mais avançada do teste podemos observar com mais evidência a diferença entre as diferentes saídas. Na próxima fig.15 vamos observar o mesmo facto, mas agora com um novo vídeo de entrada.

Fig.15

Como já foi referido, observando os resultados directamente do computador tem-se uma melhor percepção dos resultados, permitindo também observar o interessante efeito criado.


INESC Porto


3.2 Estudo da plataforma PD e formas de ligação ao VAF/Coral

Depois da instalação da plataforma PD, a primeira tarefa foi estudar a sua forma de funcionamento, fazendo testes com objectos existentes, criando pequenos projectos de exemplos e observando os resultados, de forma a ter uma noção do que consiste a plataforma e para que pode servir.

Em seguida foi feito um estudo de que forma poderia o PD ser ligado ao VAF/Coral. Entre outras formas, foram estudas a ligação via OSC e via TCP (que foi a que foi implementada). De notar que a plataforma PD já possui estes dois tipos de comunicações, pelo é apenas necessário implementar na plataforma VAF/Coral.

3.2.1 Formas de comunicação estudadas

Protocolo de comunicação Open SoundControl Open SoundControl é um protocolo aberto, eficiente, de transporte

independente, baseado em mensagens desenvolvido para comunicação entre computadores, sintetizadores de som, e outros dispositivos multimédia que optimizados para a tecnologia moderna do networking.

Sendo o OSC um protocolo de transporte independente, significa que os dados podem ser enviados através de uma variedade de tecnologias de networking existentes. Essas tecnologias que hoje em dia estão amplamente disponíveis e económicas incluem barra-ônibus de alta velocidade tais como PCI e as LANs de média velocidade como por exemplo, USB, IEEE-1394 (“Firewire”), Ethernet, e Ethernet rápida. Embora o OSC não tenha sido projectado com uma camada de transporte em particular, o projecto reflecte as características compartilhadas por tecnologias modernas do networking.

Prevê-se que o OSC seja transmitido num sistema com largura de banda na escala de 10+ Mbits/seg. A largura de banda MIDI, em contraste, é somente 31.25 kbits/seg, aproximadamente 300 vezes mais lento. Como consequência, no projecto OSC não há preocupação em comprimir a informação musical num número mínimo de bytes. No projecto OSC os dados numéricos são codificados em quantidades 32-bit ou 64-bit,o endressamento é simbólico, as mensagens são do tipo time-tag, e em geral o uso da largura de banda, para características importantes, é mais liberal.

No OSC os dados são entregues em pacotes (a.k.a. “datagrams”) melhor que um fluxo de dados viajando ao longo de uma ligação estabelecida. Isto conduz a um protocolo o mais simples possível: melhor do que assumir que o receptor prende algum estado de uma comunicação anterior, a informação é enviada em grandes pedaços auto -suficientes que contém a informação relevante num lugar. Este modelo de entrega baseado em pacotes fornece um mecanismo para o synchronicity: isto é, as mensagens no mesmo pacote (por exemplo, mensagens para começar cada uma das notas em uma corda)


INESC Porto


podem ser especificadas para fazer com que os seus efeitos ocorram ao mesmo tempo que as outras.

Pacotes OSC A unidade de transmissão do OSC é um pacote OSC. Toda a aplicação

que emite pacotes OSC é um cliente OSC, qualquer aplicação que receba pacotes OSC é um servidor OSC.

Um pacote OSC consiste em seus conteúdos, em um bloco contíguo de dados binários, e no seu tamanho. O tamanho de um pacote OSC é sempre múltiplo de 4. A rede subjacente que entrega um pacote OSC é responsável pela entrega, quer dos seus conteúdos quer do seu tamanho, à aplicação OSC. Um pacote OSC pode naturalmente se representado por um datagram por um protocolo de rede como o UDP. Num protocolo como o TCP, o fluxo deve começar com um int32 que dá o tamanho do primeiro pacote, seguido pelos conteúdos do primeiro pacote, seguidos pelo tamanho do segundo pacote, etc.

Os conteúdos de um pacote OSC devem ser ou uma mensagem OSC ou um pacote OSC. O primeiro byte dos conteúdos é que distingue qual das alternativas se refere o pacote.

Esquema de Endereçamento O modelo de endereçamento de mensagens no Open SoundControl é um

conjunto hierárquico de objectos dinâmicos que incluem, por exemplo, síntese de vozes, canais de saída, filtros, e um gerente de memória. As mensagens são dirigidas a uma característica de um objecto em particular ou um conjunto de objectos através de um namespace hierárquico, similar à notação URL, por exemplo, /voices/drone-b/resonators/3/set-Q. Este protocolo não proscreve nada sobre os objectos que devem estar nesta hierarquia ou como devem ser organizados. Cada sistema que pode ser controlado por Open SoundControl definirá a sua própria hierarquia de endereço. Este mecanismo evita as limitações de endressamento inerentes em protocolos como MIDI e ZIPI.

Conclusão O projecto Open SoundControl tem tido bons resultados transmitindo este

protocolo sobre UDP e Ethernet para controlo em tempo real de síntese de som e SGI workstations do MAX.

Protocolo de comunicação TCP

O TCP é o protocolo da camada de transporte orientado à conexão, que oferece um serviço confiável. Frequentemente aparece como parte da pilha TCP/IP da arquitectura Internet, mas é um protocolo de propósito geral que pode ser adaptado para ser usado com uma variedade de sistemas.

Este protocolo tem como principal objectivo realizar a comunicação entre aplicações de dois hosts diferentes. O protocolo TCP é um protocolo de nível de transporte muito utilizado que trabalha com mensagens de reconhecimento, especificação do formato da informação e mecanismos de segurança. Ele garante que todos os PDU's (Protocol data Unit) serão enviados com sucesso,


INESC Porto


pois realiza transmissões orientadas à conexão. Além disso, ele possibilita o uso de várias aplicações voltadas à conversação.

Quando executado, utiliza o protocolo IP, não orientado à conexão. O TCP então fica responsável pelo controle dos procedimentos da transferência segura de dados. Cabe salientar que o IP não é o único protocolo não orientado à conexão que pode ser utilizado pelo TCP. Para maior eficiência nas comunicações, o TCP engloba várias funções que poderiam estar nas próprias aplicações, como processador de texto, base de dados e correio electrónico. Ele foi criado com o intuito de ser um software universal contendo essas funções.

Existem ainda outros serviços do TCP: Controle de fluxo – O controle de fluxo atribui uma janela de transmissão

ao host de origem. Essa janela limita o número de bytes transmitidos por vez. O controle de fluxo em si está na possibilidade de atribuir diferentes valores às janelas.

Segurança na transmissão – A confiabilidade nas transmissões via TCP

está baseada no fato de que este protocolo é orientado à conexão e trabalha com números de reconhecimento sequenciais e positivos.

O TCP do host origem transfere os dados em forma de octetos, onde a cada octeto vão sendo atribuídos números em sequência. O TCP do host destino analisa então esses números para garantir a ordem e a integridade da mensagem enviada. Se a transferência for perfeita, o TCP do host destino envia uma mensagem de reconhecimento à origem. Caso contrário, é enviada uma sequência numérica para o TCP do host origem que informará o tipo do problema, bem como ordenará uma nova transmissão.

Os números em sequência podem ser utilizados ainda para eliminar octetos duplos, que por causa da transmissão não orientada à conexão, podem ocorrer. O TCP da origem possui um timer para garantir que não se perca muito tempo entre uma mensagem errada e sua correcção. Então, quando o TCP origem recebe uma mensagem de erro, ocorre um "time-out" e o reenvio da mensagem. A margem de tempo do "time-out" é controlada pelo administrador do host.

Comandos de OPEN/CLOSE – Por meio de todos os dispositivos físicos,

o TCP pode estabelecer uma conexão virtual, a partir do comando OPEN. Nesse momento, o TCP realiza o "three-way handshake", que é um processo onde os TCP's origem e destino trocam mensagens de reconhecimento que possibilitam a conexão.

No momento em que a transferência de informações terminar, qualquer host (origem ou destino) poderá fechar a conexão virtual, a partir do comando CLOSE.

A figura abaixo mostra em detalhes o "three-way handshake" do TCP, a comunicação é feita seguindo as setas vermelhas e seguindo a ordem de cima para baixo, note-se que as setas estão “activas” uma de cada vez:


INESC Porto


Fig.16 – Estabelecimento de conexão Virtual

Gerenciamento da informação nas transmissões orientadas a conexão – O protocolo TCP pode controlar todos os aspectos da informação que esta sendo transmitida, pois é um protocolo de transmissão orientada à conexão. A acção do TCP se estende a toda a trajectória da info rmação, onde ele procura garantir o sucesso da transmissão.

Prioridade e segurança – O protocolo TCP permite que o administrador do

host controle os níveis de segurança e permissão de acesso, bem como as prioridades nas conexões. Essas características não estão presentes em todas as versões, embora estejam definidas nos padrões TCP.

Transferência orientada a "stream" – Os aplicativos de nível de interface

em geral enviam dados ao TCP de forma orientada a "stream", onde a informação é transmitida byte a byte, um após o outro. Quando a informação chega ao TCP, é então agrupada em pacotes e assim enviada aos demais níveis de transmissão.

O protocolo TCP pode utilizar-se de várias formas de envio de mensagens. Ele pode ser utilizado com linhas telefónicas, redes locais ou ainda redes de fibra óptica de alta velocidade.

A estrutura do Header TCP é a seguinte:


INESC Porto


Fig.17 – Estrutura do Cabeçalho TCP

onde: Source Port: Número da Porta de origem Destination Port: Número da Porta de destino. Sequence Number: O número de sequência do primeiro octeto de dados do segmento (excepto quando SYN está presente). Se o SYN está presente, o número de sequência é o número de sequência inicial (ISN) e o primeiro octeto de dados é ISN +1. Acknowledgment number: Se o bit de controlo ACK está accionado, o campo contém o valor do próximo número de sequência que o destinatário do segmento está esperando receber. Data offset: Indica onde inicia o campo de dados dentro do Header TCP. Reserved: 6 bits reservados para uso futuro, pode ser zero Control bits: O bit de controle pode ser (da esquerda p/ direita): U (URG): Informa à aplicação a chegada de dados urgentes, que devem ser processado antes no buffer. A (ACK): Indica que o campo Acknowledgment é significante. P (PSH): Função Push. R (RST): Reinicia a conexão. S (SYN): Sincroniza os números de sequência. F (FIN): Indica o fim da transmissão de dados. Window: 16 bits. O número de octetos de dados que o destinatário está aguardando receber, iniciando com o octeto que indica o campo acknowledgment. Checksum: 16 bits. Controle de erros.

Protocolos Orientados à Conexão Em uma transmissão orientada à conexão, é necessário que se faça uma

chamada e conexão antes de cada transmissão. Nesse tipo de transmissão os pacotes não precisam possuir overheads, como ocorre nas transmissões não orientadas à conexão. Isso é possível pois logo no início da conexão, a origem e o destino trocam todas as informações necessárias à transmissão.

O modo de transmissão orientado à conexão é mais seguro pois possui mecanismos de reenvio de pacotes mal transmitidos, bem como mensagens de reconhecimento.


INESC Porto


As figuras abaixo ilustram uma conexão sendo negociada e posteriormente estabelecida.

Fig.18

Na figura 18 vemos a negociação de um estabelecimento de conexão,

primeiro há uma pedido para estabelecer uma conexão (setas vermelhas) e depois há uma resposta para estabelecer a conexão (setas pretas), e a partir daqui a conexão fica estabelecida. Depois pode ser iniciada a transmissão de dados (fig.19).

Fig.19 – Transmissão de dados


INESC Porto


3.3 Implementação dos módulos de comunicação Depois de estudadas algumas das formas de comunicação possíveis para

ligar a plataforma VAF/Coral e a plataforma PD, optou-se por criar módulos de comunicação (“motores”) com base no protocolo TCP.

3.3.1 Implementação do “motor” Net_receive

Principio de funcionamento e explicação de algumas funções

Tendo como base de comunicação o protocolo TCP, o “motor” net_receive foi implementado da seguinte forma.

Quando é inicializada a comunicação no VAF/Coral é criado um Socket TCP, de seguida são-lhe passados os parâmetros para a sua estrutura e é feito o bind ao socket, isto é, é atribuído ao socket o endereço de Internet (pode ser “any”) e a porta de comunicação. De seguida o socket é colocado à espera de estabelecer conexões e caso surja um pedido ele é aceite, isto se não existir já um pedido aceite. Depois de aceite a conexão o “motor” está pronto a receber as mensagens enviadas pelo cliente, ou seja pela Plataforma PD.

À que realçar aqui a abordagem que teve de ser realizada para podermos observar, ou passar para a saída, as mensagens recebidas. Para que isso fosse possível o “motor” net_receive teve de ser estruturado com uma entrada (de vídeo por exemplo) e por cada frame de entrada é lida e colocada na saída uma mensagem vinda do “cliente”. Esta frame de entrada não influencia em nada a mensagem recebida, pois o que é colocado na saída é apenas o que é recebido do “cliente”.

Esta forma de implementação deve-se ao facto de a comunicação no VAF/Coral ter certas especificações e por mais que tenha tentado implementar o net_receive de forma a não ser preciso uma entrada para colocar as mensagens recebidas na saída, isso não foi possível.

É de notar que, devido à forma como foi implementado o net_receive, o “motor” fica sempre em funcionamento a menos que seja parado, isto é, as frames do vídeo de entrada nunca chegam ao fim pelo que o “motor” pode continuar a receber as mensagens.

Quando o net_receive é parado os sockets são fechados. Abaixo podemos ver algumas funções que fazem algumas das tarefas

descritas em acima. No Anexo 2 podemos também ver a totalidade do código do net_receive.

sd = socket( AF_INET, SOCK_STREAM, 0 ) – Cria o socket com: - Família (ou domínio): UNIX, Internet, XNS - Tipo: stream, datagrama, puro - Protocolo: TCP, UDP Os parâmetros sublinhados são os que foram adoptados.


INESC Porto


Passagem dos para metros para a estrutura do socket: memset( & sin, 0, sizeof(sin) ) sin.sin_family = AF_INET sin.sin_port = htons( SERV_PORT ) sin.sin_addr.s_addr = htonl( INADDR_ANY )

e = bind( sd, (struct sockaddr *)& sin, sizeof(sin) ) Atribui ao socket: - Endereço Internet (pode ser “any”) - Porta de comunicação

e = listen( sd, 1) Declara: - Que está pronto para receber conexões - Até quantas é que devem ser enfileiradas

s = accept( sd,(struct sockaddr *) & from, & fromlen ) - Bloqueia até que haja pedido de conexão - Quando houver algum aceita

n = recv( s, msg, RECV_BUFF, 0 ) - Recebe as mensagens envidas pelo “cliente”, neste caso PD

e = shutdown(sd, SD_BOTH) - Encerra a conexão e fecha ambos os sockets, “servidor” e “cliente” As outras funções existem para além destas no código implementado para

o net_receive já foram vistas no ponto 3.1.1. Depois de compilado o projecto, este foi integrado no VAF/Coral (a forma

de integração também já foi explicada no ponto 3.1.2), tendo como ficheiro para integração o apresentado na fig.20.

Fig.20 – net_receive.txt


INESC Porto


Resultados Obtidos

Após compilado e inserido o novo “motor”, net_receive, procedeu-se ao teste. O projecto Coral implementado para teste tem o formato da fig.21.

Fig.21 – Projecto efectuado para testar o net_receive

Com o net_receive em funcionamento, ligou-se então o PD ao VAF/Coral para enviar mensagens (fig.22).

Fig.22 – Patcher para a ligação e envio de mensagens do PD ao net_receive


INESC Porto


Posteriormente à ligação do PD ao “motor” ne t_receive, foram enviadas mensagens para testar a recepção do net_receive. Na fig.23 podemos ver na janela de resultados do net_receive.

Fig.23 – Janela de resultados do net_receive

Como podemos observar na fig. anterior as mensagens enviadas pelo patcher PD são correctamente recebidas pelo net_receive e enviadas para a sua janela de resultados.

3.3.2 Implementação do “motor” Net_send

Principio de funcionamento e explicação de algumas funções Para uma maior compreensão e uma maior facilidade de leitura, para a

criação no “motor” net_send, formam criados três ficheiros, dois Source files e um Header file. Num dos Source files está o programa principal (net_send.cpp), este chama algumas funções que estão implementadas no outro Source file (net_socket.cpp) e o Header file é o elo de ligação entre eles.

O modo de funcionamento do “motor” net_send é o seguinte: após a inicialização de comunicação no VAF/Coral o “motor” cria o seu próprio socket e liga-se ao servidor de forma a começar a transmissão dos dados, caso o servidor não esteja activo ou disponível é mostrada uma mensagem de erro. Depois do socket criado e da ligação ao servidor estabelecida é iniciada a transmissão dos dados. Sendo os dados a enviar um vídeo, este é enviado frame a frame. Posto isto, por cada frame de entrada, é enviado em primeiro lugar as características da imagem (nº da frame, type, width, height, chroma) depois enviadas as características da imagem, é enviada a “informação”, ou


INESC Porto


seja, a própria imagem. Esta informação é dividida em três parâmetros, Y, U e V. A respectiva informação que a imagem contém em relação a cada parâmetro é enviada separadamente, primeiro Y, depois U e por fim V. Após o envio da informação, termina o processamento desta frame e passa-se a uma nova frame. Quando terminar a transmissão da totalidade do vídeo o socket do “motor” é fechado, deixando livre o “receptor” para novas transmissões.

Abaixo temos uma breve explicação de algumas funções utilizadas: Depois de iniciada a comunicação VAF/Coral

(init_communication((unsigned short) port), é chamada a função: create_socket(SERV_PORT) – esta função encontra-se no file net_socket.cpp e a sua funcionalidade é : Criar um socket para o “motor” (s=socket( AF_INET, SOCK_STREAM,0 )), em seguida obter o numero de porta e IP a que se vai ligar, por fim, fazer a ligação ao servidor (e = connect( sd, (struct sockaddr *)& sin, sizeof(sin) )).

Após efectuadas estas operações voltamos novamente ao file net_send.cpp e inicia-se o envio do vídeo frame a frame. Para isso são obtidas as características da frame e a sua informação, e estas são enviadas através da função send_to_socket(local_msg, 0) e send_to_socket(msg, 1) respectivamente. Esta função também se encontra no file net_socket.cpp e a sua tarefa é enviar as mensagens para o servidor. Há no entanto nesta função duas formas diferentes de envio das mensagens, dependendo da flag. Se esta estiver a “0” a mensagem é logo enviada para o servidor. Caso a flag se encontre a “1”, as mensagens são guardadas num buffer com 512 bytes e só quando este estiver cheio ou terminar a informação a enviar é que a mensagem contida no buffer é enviada.

Tendo sido processadas todas as frames, tendo portanto sido enviados todos os dados, é fechado o socket do “motor” através da função: int close_socket().

O anexo 3 apresenta a totalidade do código implementado para o “motor” net_send. Outras das funções existentes no “motor” net_send já foram descritas em “capítulos” anteriores. A forma de integração do net_send na plataforma VAF/Coral é também a mesma explicada anteriormente (no ponto 3.1.2), mas desta vez o ficheiro utilizado para essa integração do “motor” é o seguinte:

Fig.24 – net_send.txt


INESC Porto


Resultados Obtidos

Após ter sido devidamente integrado na plataforma VAF/Coral, com o apoio da plataforma PD, procedeu-se ao teste do “motor” net_send. Para isso foi utilizado o projecto Coral apresentado abaixo.

Fig.25 – Projecto para teste do “motor” net_send

Para podermos colocar em funcionamento o net_send, tínhamos de ter uma servidor à espera de receber uma ligação e as mensagens a enviar. Foi então colocado um Patcher PD (fig.26) com essas funcionalidades.

Fig.26 – Patcher PD “servidor” Após efectuada a ligação entre o net_send do VAF/Coral e o netreceive

do PD, este detecta a ligação e faz o update do número de conexões abertas, no fim da transmissão volta a coloca-lo a zero. Na fig. seguinte podemos observar o que acontece quando existe uma conexão aberta.


INESC Porto


Fig.27 – Patcher PD “servidor” com uma ligação a um cliente

Após efectuada a conexão ao servidor o net_send inicia o envio dos dados. Como já foi referido é enviado um conjunto de dados por cada frame do vídeo.

Na fig.28 temos um exemplo dos dados que foram recebidos pelo netreceive do PD. Neste caso apenas enviamos duas frames e reduzimos o tamanho da imagem de forma a não termos uma extensão muito elevada de dados recebidos.

Fig.28 – Dados recebidos do net_send, no netreceive do PD

Como podemos observar pela imagem anterior, por cada frame, em primeiro lugar são recebidos os parâmetros da imagem e em seguida a informação da imagem, valores de Y, valores de U e por ultimo valores de V. É de notar que o número de valores de V e U é metade do número de valores de Y. podemos também observar na imagem que são recebidos vários valores


INESC Porto


dentro do mesmo pacote (como já tinha sido referido anteriormente). Para melhor compreensão da imagem falta referir que por cada tcp que aparece na imagem corresponde a uma mensagem recebida.

Nota: Para observarmos a imagem recebida no PD, em vez de observar só os dados, teria quer ser ligado um outro “programa” ao PD denominado por GEM.


INESC Porto


4 Conclusão

Depois do estudo das Plataformas, VAF/Coral e PD (novas para mim), posso dizer que elas podem ser bastante úteis. Nomeadamente para tratamento de imagem, no caso da plataforma VAF/Coral, e tratamento de áudio no caso da Plataforma PD.

Estas ferramentas são um grande apoio para a criação de objectos em arte digital. Pois possuem diversas formas, quer de tratamento de imagem, quer de tratamento áudio.

O que se pretendeu com este trabalho foi ligar ambas as plataformas, por forma a que o que não pudesse ser tratado numa, pudesse porventura ser tratado na outra. Outro objectivo é poder colocar áudio e imagem num único bloco. Para isso acontecer, as mensagens enviadas de um lado para o outro tem de ser tratadas da devida forma (talvez um trabalho a ser desenvolvido futuramente).

No que diz respeito ao trabalho realizado, a forma de ligação escolhida foi usando o protocolo TCP, pois este já era suportado pela plataforma PD e permite ter a certeza na entrega das mensagens. Também poderia ter sido escolhido o protocolo de comunicação OSC. A vantagem desta possível forma de ligação é que seria uma ligação mais genérica, permitindo a ligação da plataforma VAF/Coral, não só ao PD mas também a outras aplicações como Flash, MAX, Direct, etc. No entanto esta forma de comunicação era mais difícil de tratar e não era garantido a entregas das mensagens.

Este trabalho foi-se demonstrando, ao passar do tempo e a medida que me familiarizava melhor com as plataformas, cada vez mais interessante. È pena o facto do tempo começar a escassear e não ser possível fazer coisas ainda mais interessantes. Contudo penso que o objectivo, que era criar módulos de ligação entre as plataformas foi atingido.


INESC Porto


5 Bibliografia Ø Página web da Framework Coral:

http://telecom.inescn.pt/coral

Ø Documentos sobre PD www.pure-data.org

http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm Ø Estudo da comunicação OSC

http://cnmat.cnmat.berkeley.edu/OSC/ Ø Livro

A. Richard Stevens, TCP/IP Illustrated: The Protocols Ø Textos soltos


INESC Porto



INESC Porto


/* \file Router.c * * Router.c - copies an YUV image from input to one of four output buffers. frmame by frame \n * 1 input: 1 YUV image \n * 4 output: 4 YUV image \n */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <time.h> /** \file integration.h * Header file including all other headers for YUV image processing. It is the main header * file which needs to be included in your application \n */ #include "integration.h" #define NO_SAIDAS 4 long input (int, char **); void add_input (int input_id); void add_output (int output_id); void Inic_Random(); int port = 0; long nrframes = 1000; YUV_Image *yuvImage_in = NULL; YUV_Image *yuvImage_out = NULL; IMG_Attr *imgAttr_max = NULL; IMG_Attr *imgAttr_in = NULL;


INESC Porto


IMG_Attr *imgAttr_out = NULL; GenericBuffer *output_buffer = NULL; GenericBuffer *input_buffer = NULL; long current_frame_number = 0; int finish = 0; main (int argc, char *argv[]) { int saida=0, i; Inic_Random(); /* allocate the buffer sets */ input_buffer_set = allocateBufferSet(); output_buffer_set = allocateBufferSet(); /* process the input parameters */ if ((input (argc, argv)) < 0) { fprintf(stderr, "( Router.c ) - input function returned ERROR!!\n"); return (-1); } /* initialize communication */ init_communication((unsigned short) port); // image array fprintf(stderr, "( Router.c ) - end of init_communication!!\n"); for (current_frame_number = 0; current_frame_number < nrframes; current_frame_number++) { /* wait for commands to load the input BufferSet */ load_input_set(input_buffer_set); /* wait for a 'process' message */


INESC Porto


wait_for_process_command(); /* select de output*/ saida = 1+rand()%NO_SAIDAS; /* get the input linear buffer */ yuvImage_in = (YUV_Image *)get_data_in_next_slot(getBufferFromSet(input_buffer_set, 0), 1); switch (verify_data(yuvImage_in)) { case EOS: fprintf(stderr, "\n\n( Router.c) - yuvImage_in data is EOS...\n"); finish = 1; break; case NOT_READY: fprintf(stderr,"\n\n\t( Router.c ) - Buffer slot not ready!!\n\n"); break; default : break; } /* test the finish flag */ if (finish) { printf("\n End of sequence. I am cleaning up now!"); break; } // veryfies if the image parameters have been changed, and updates info for output image if necessarry imgAttr_out = get_yuvImage_attributes(imgAttr_in, yuvImage_in);

#ifdef PRINT_ERR fprintf(stderr,"(Router) - setting attributes (%d,%d,%d) for VAF_Frame\n", imgAttr_in->width,imgAttr_in->height,imgAttr_in->height); #endif


INESC Porto


for(i=0; i < NO_SAIDAS; i++) // para cada saida { output_buffer = getBufferFromSet(output_buffer_set, i); yuvImage_out = (YUV_Image *)get_data_in_next_slot(output_buffer, 0); if (!are_yuvImages_equal(2, yuvImage_in, yuvImage_out)) { #ifdef PRINT_ERR fprintf(stderr, "yuvImage params need to be updated!!\n"); #endif get_yuvImage_attributes(imgAttr_out, yuvImage_in); set_yuvImage_attributes_in_buffer(output_buffer, imgAttr_out ); } } appendDataInBufferSet(output_buffer_set, saida - 1, yuvImage_in, 1, 0); send_message("process complete\0"); } exit_display(); return (0 } void Inic_Random() { long ultime; time(&ultime); srand((unsigned) ultime); } /* INPUT: function reads input parameters * usage: input (argc, argv) */


INESC Porto


long input (int argc, char *argv[]) { long n;

long argIndex = 1; int id = 0; setbuf(stdout,NULL); setbuf(stderr,NULL); /* process the parameters from the command line */ for (n = argIndex; n < argc; n++) { /* get the server port */ if (strcmp (argv[n], "-serverport") == 0) { fprintf(stderr, " (Router.c , input) - serverport indicated in command line\n"); if (++n == argc || argv[n][0] == '-') { #ifdef Original_MSG printf("(Router.c , input) - serverport value not present in command line\n"); #endif exit_display(); } if ( (int)sscanf(argv[n],"%d",&port) != 1){ #ifdef Original_MSG printf("(Router.c , input) - Error while reading server socket port value!!\n"); #endif exit_display(); } else{ #ifdef Original_MSG fprintf(stderr, " (Router.c , input) - Server connected to port : %d!!\n\n",port); printf("Router : Server connected to port : %d!!\n\n",port); #endif } } else if ( (int)sscanf(argv[n],"-I%d",&id) == 1){ add_input(id);


INESC Porto


#ifdef Original_MSG fprintf(stderr,"Connected input with ID %d,!!\n", id); #endif } else if ( (int)sscanf(argv[n],"-O%d",&id) == 1){ add_output(id); #ifdef Original_MSG fprintf(stderr,"Connected output with ID %d,!!\n", id); #endif } else { #ifdef PRINT_ERR fprintf(stderr, "(collor.c , input) - unknown parameter in command line : '%s'\n", argv[n]); #endif exit_display(); } } return (0); } void add_input (int input_id) { switch (input_id) { case 0: input_buffer = allocate_generic_buffer(IMG,1,0); addBufferToSet(input_buffer_set, input_buffer); break; } } void add_output (int output_id) { switch (output_id ) { case 0: output_buffer = allocate_generic_buffer(IMG,1,output_id); addBufferToSet(output_buffer_set, output_buffer);


INESC Porto


break; case 1: output_buffer = allocate_generic_buffer(IMG,1,output_id); addBufferToSet(output_buffer_set, output_buffer); break; case 2: output_buffer = allocate_generic_buffer(IMG,1,output_id); addBufferToSet(output_buffer_set, output_buffer); break; case 3: output_buffer = allocate_generic_buffer(IMG,1,output_id); addBufferToSet(output_buffer_set, output_buffer); break; default : break; } }


INESC Porto



INESC Porto


/** \file net_receive.c * * net_receive.c - receive the msg from PD and copies to outpup buffer \n * 1 input: 1 YUV image \n * 1 output: 1 Txt\n */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/types.h> #include <io.h> #include <memory.h> #include <winsock2.h> #define SERV_PORT 3000 #define RECV_BUFF 200 #ifdef VAF #include "integration.h" int port = 0; long input (int, char **); void add_input (int input_id); void add_output (int output_id); GenericBuffer *output_buffer = NULL; GenericBuffer *input_buffer = NULL; long current_frame_number = 0; int finish = 0; long nrframes = 10; YUV_Image *yuvImage_in; #endif


INESC Porto


int main(int argc, char *argv[]) { int e ,sd, n,s; struct sockaddr_in sin ; char msg[RECV_BUFF]; struct sockaddr_in from ; int fromlen = sizeof( from ) ; WORD wVersionRequested; WSADATA wsaData; int err; #ifdef VAF /* allocate the buffer sets */ input_buffer_set = allocateBufferSet(); output_buffer_set = allocateBufferSet(); /* process the input parameters */ if ((input (argc, argv)) < 0) { fprintf(stderr, "( Original.c ) - input function returned ERROR!!\n"); return (-1); } /* initialize communication */ init_communication((unsigned short) port); // image array #endif wVersionRequested = MAKEWORD( 2, 2 ); err = WSAStartup( wVersionRequested, &wsaData ); if ( err != 0 ) { /* Tell the user that we could not find a usable */ /* WinSock DLL. */ return -1; }


INESC Porto


/*creat a Socket*/ sd = socket( AF_INET, SOCK_STREAM, 0 ) ; if( sd < 0 ) { perror("socket:") ; exit(1) ; } printf("Socket created.\n"); memset( & sin, 0, sizeof(sin) ) ; sin.sin_family = AF_INET ; sin.sin_port = htons( SERV_PORT ) ; sin.sin_addr.s_addr = htonl( INADDR_ANY ) ; printf("addres - %d\n", sin.sin_addr); e = bind( sd, (struct sockaddr *)& sin, sizeof(sin) ) ; if( e < 0 ) { perror("bind:") ; exit(1) ; } printf("Bind.\n"); e = listen( sd, 1) ; if( e < 0 ) { perror("listen:") ; exit(-1) ; } printf("Listen. \n"); s = accept( sd,(struct sockaddr *) & from, & fromlen ) ; if( s < 0 ) {


INESC Porto


perror("accept:") ; exit(1) ; } printf("Accepted.\n"); #ifdef VAF for (current_frame_number = 0; current_frame_number < nrframes; current_frame_number++) { load_input_set(input_buffer_set); wait_for_process_command(); printf("Ok, the input buffer is read...\n"); input_buffer = getBufferFromSet(input_buffer_set, 0); yuvImage_in = (YUV_Image *)get_data_in_next_slot( input_buffer, 1); if (finish){ printf("\n End of sequence. I am cleaning up now!"); break; } if (current_frame_number > 0) current_frame_number--; #endif printf("Receiving ..."); n = recv( s, msg, RECV_BUFF, 0 ); if(n > 0 ) { msg[n]='\0'; printf("Msg=\"%s\", n=%d.\n", msg, n); }


INESC Porto


else { fprintf(stderr, "Connection failure !\a"); break; } #ifdef VAF /* append the output linear buffer to the output buffer set */ appendDataInBufferSet(output_buffer_set, 0, msg, strlen(msg), 0); send_message("process complete\0"); } #endif printf("\nClosing the socket ...\n"); e = shutdown(sd, SD_BOTH); if( e < 0 ) { perror("shutdown:") ; exit(1) ; } WSACleanup(); #ifdef VAF exit_display(); #endif return 0; } /*! \brief input(): * function reads input parameters * usage: input (argc, argv) */


INESC Porto


long input (int argc, char *argv[]) { long n; long argIndex = 1; int id = 0; setbuf(stdout,NULL); setbuf(stderr,NULL); /* process the parameters from the command line */ for (n = argIndex; n < argc; n++) { /* get the server port */ if (strcmp (argv[n], "-serverport") == 0) { fprintf(stderr, " (Original.c , input) - serverport indicated in command line\n"); if (++n == argc || argv[n][0] == '-') { #ifdef Original_MSG printf("(Original.c , input) - serverport value not present in command line\n"); #endif exit_display(); } if ( (int)sscanf(argv[n],"%d",&port) != 1){ #ifdef Original_MSG printf("(Original.c , input) - Error while reading server socket port value!!\n"); #endif exit_display(); } else{ #ifdef Original_MSG fprintf(stderr, " (Original.c , input) - Server connected to port : %d!!\n\n",port); printf("Original : Server connected to port : %d!!\n\n",port); #endif } } /* get the ID of the input image */


INESC Porto


else if ( (int)sscanf(argv[n],"-I%d",&id) == 1){ add_input(id); #ifdef Original_MSG fprintf(stderr,"Connected input with ID %d,!!\n", id); #endif } /* get the ID of the output image */ else if ( (int)sscanf(argv[n],"-O%d",&id) == 1){ add_output(id); #ifdef Original_MSG fprintf(stderr,"Connected output with ID %d,!!\n", id); #endif } else { #ifdef PRINT_ERR fprintf(stderr, "(collor.c , input) - unknown parameter in command line : '%s'\n", argv[n]); #endif exit_display(); } } return (0); } /*! \brief add_input(): * function allocates memory for the input buffer */ void add_input (int input_id) { switch (input_id) { case 0: input_buffer = allocate_generic_buffer(IMG,1,0); addBufferToSet(input_buffer_set, input_buffer); break;


INESC Porto


} } /*! \brief add_output(): * function allocates memory for the output buffer */ void add_output (int output_id) { switch (output_id ) { case 0: output_buffer = allocate_generic_buffer(CHAR,1,0); addBufferToSet(output_buffer_set, output_buffer); break; } }


INESC Porto



INESC Porto


Ficheiro net_send.cpp #include <stdio.h> #include <stdlib.h> #include <string.h> #include <io.h> #include <sys/types.h> #include <memory.h> #include "net_socket.h" #define SERV_PORT 3000 #ifdef VAF #include "integration.h" long input (int, char **); void add_input (int input_id); void add_output (int output_id); GenericBuffer *output_buffer = NULL; GenericBuffer *input_buffer = NULL; long current_frame_number = 0; int finish = 0; long nrframes = 1000; YUV_Image *yuvImage_in; YUV_Image *yuvImage_out ; #endif int main(int argc, char *argv[]) { int i, j; int width; int height;


INESC Porto


char msg[100]=""; char str[10]=""; char local_msg[256]=""; for(i=0; i < argc; i++) printf(" %dª argumento - %s\n", i+1, argv[i]); #ifdef VAF /* allocate the buffer sets */ input_buffer_set = allocateBufferSet(); output_buffer_set = allocateBufferSet(); /* process the input parameters */ if ((input (argc, argv)) < 0) { fprintf(stderr, "( Original.c ) - input function returned ERROR!!\n"); return (-1); } /* initialize communication */ init_communication((unsigned short) port); // image array #endif if(!create_socket(SERV_PORT)) return 0; //cria o socket e estabelece a ligação com o servidor #ifdef VAF for (current_frame_number = 0; current_frame_number < nrframes; current_frame_number++) { /* wait for commands to load the input BufferSet */ load_input_set(input_buffer_set); /* wait for a 'process' message */ wait_for_process_command();


INESC Porto


/* get the input linear buffer */ input_buffer = getBufferFromSet(input_buffer_set, 0); yuvImage_in = (YUV_Image *)get_data_in_next_slot( input_buffer, 1); sprintf(local_msg,"\nsending data(frame_nr=%d,type=%d,width=%d,height=%d,chroma=%d,)\0\n" ,current_frame_number,IMG,yuvImage_in->width,yuvImage_in->height,yuvImage_in->chroma); switch (verify_data(yuvImage_in)) { case EOS: fprintf(stderr, "\n\n( Original.c) - yuvImage_in data is EOS...\n"); finish = 1; break; case NOT_READY: fprintf(stderr,"\n\n\t( Original.c ) - Buffer slot not ready!!\n\n"); break; default : break; } /* test the finish flag */ if (finish ) { printf("\n End of sequence. I am cleaning up now!"); break; } output_buffer = getBufferFromSet(output_buffer_set, 0); yuvImage_out = (YUV_Image *)get_data_in_next_slot(output_buffer, 0);


INESC Porto


appendDataInBufferSet(output_buffer_set, 0, yuvImage_in,1, 0); send_to_socket(local_msg, 0); width=yuvImage_in->width; height=yuvImage_in->height; /* A enviar a informação da image_y*/ sprintf(msg,"\nSending values Y\n"); send_to_socket(msg, 1); for(i=0;i<height ; i++) { for(j=0;j<width;j++) { sprintf(msg,"\n(%u)\0\n", yuvImage_in->img_y[i][j]); send_to_socket(msg, 1); } } send_to_socket("", 1); /* A enviar a informação da image_u*/ sprintf(msg,"\nSending values U\n"); send_to_socket(msg, 1); for(i=0;i<height /2; i++) { for(j=0;j<width/2;j++) {


INESC Porto


sprintf(msg,"\n(%u)\0\n", yuvImage_in->img_u[i][j]); send_to_socket(msg, 1); } } send_to_socket("", 1); /* A enviar a informação da image_v*/ sprintf(msg,"\nSending values V\n"); send_to_socket(msg, 1); for(i=0;i<height /2; i++) { for(j=0;j<width/2;j++) { sprintf(msg,"\n(%u)\0\n", yuvImage_in->img_v[i][j]); send_to_socket(msg, 1); } } send_to_socket("", 1); send_message("process complete\0"); } // end proccessing frames #endif close_socket(); #ifdef VAF exit_display();


INESC Porto


#endif return 0; } /*! \brief input(): * function reads input parameters * usage: input (argc, argv) */ long input (int argc, char *argv[]) { long n; long argIndex = 1; int id = 0; setbuf(stdout,NULL); setbuf(stderr,NULL); /* process the parameters from the command line */ for (n = argIndex; n < argc; n++) { /* get the server port */ if (strcmp (argv[n], "-serverport") == 0) { fprintf(stderr, " (Original.c , input) - serverport indicated in command line\n"); if (++n == argc || argv[n][0] == '-') { #ifdef Original_MSG printf("(Original.c , input) - serverport value not present in command line\n"); #endif exit_display(); } if ( (int)sscanf(argv[n],"%d",&port) != 1){ #ifdef Original_MSG printf("(Original.c , input) - Error while reading server socket port value!!\n"); #endif exit_display();


INESC Porto


} else{ #ifdef Original_MSG fprintf(stderr, " (Original.c , input) - Server connected to port : %d!!\n\n",port); printf("Original : Server connected to port : %d!!\n\n",port); #endif } } /* get the ID of the input image */ else if ( (int)sscanf(argv[n],"-I%d",&id) == 1){ add_input(id); #ifdef Original_MSG fprintf(stderr,"Connected input with ID %d,!!\n", id); #endif } /* get the ID of the output image */ else if ( (int)sscanf(argv[n],"-O%d",&id) == 1){ add_output(id); #ifdef Original_MSG fprintf(stderr,"Connected output with ID %d,!!\n", id); #endif } else { #ifdef PRINT_ERR fprintf(stderr, "(collor.c , input) - unknown parameter in command line : '%s'\n", argv[n]); #endif exit_display(); } } return (0); }


INESC Porto


/*! \brief add_input(): * function allocates memory for the input buffer */ void add_input (int input_id) { switch (input_id) { case 0: input_buffer = allocate_generic_buffer(IMG,1,0); addBufferToSet(input_buffer_set, input_buffer); break; } } /*! \brief add_output(): * function allocates memory for the output buffer */ void add_output (int output_id) { switch (output_id) { case 0: output_buffer = allocate_generic_buffer(IMG,1,0); addBufferToSet(output_buffer_set, output_buffer); break; } }


INESC Porto


Ficheiro net_socket.cpp #include <stdio.h> #include <winsock2.h> #include "net_socket.h" int sd; int create_socket(int port) { int e, error; struct sockaddr_in sin ; struct hostent *hp ; WORD wVersionRequested; WSADATA wsaData; int err; wVersionRequested = MAKEWORD( 2, 2 ); err = WSAStartup( wVersionRequested, &wsaData ); if ( err != 0 ) { /* Tell the user that we could not find a usable */ /* WinSock DLL. */ return 0; } sd = socket( AF_INET, SOCK_STREAM, 0 ) ; // cria o socket printf("Socket created1\n"); if( sd < 0 ) { perror("socket:") ; return 0 ; }


INESC Porto


hp = gethostbyname( "localhost" ) ; if( !hp ) { perror ("gethostbyname:") ; return 0 ; } printf("hostname %s\n", hp->h_name); memset( &sin, 0, sizeof( sin)); sin.sin_family = AF_INET ; sin.sin_port = htons( port ); printf("port %d\n", sin.sin_port); memcpy( & sin.sin_addr, hp->h_addr, hp->h_length); e = connect( sd, (struct sockaddr *)& sin, sizeof(sin) ) ; // conecta com o servidor printf("Socket connected\n"); if( e == SOCKET_ERROR ) { printf(" valor de e = %d\n", e); perror("connect:") ; error = WSAGetLastError (); printf("Error code: %d \n", error); return 0; } return 1; }


INESC Porto


int send_to_socket(char *buffer, int spool) { static char spool_buff[MAX_BUFF_SIZE]; if(!spool){ if(strlen(spool_buff)) fprintf(stderr, "Spool buffer not empty !\n\a"); strcat(buffer,";"); if(send(sd, buffer, strlen(buffer) + 1, 0) == SOCKET_ERROR) { perror("send:") ; return 0 ; } else return 1; } else // spool { if(strlen(buffer)!= NULL) { if(strlen(spool_buff) + strlen(buffer) <MAX_BUFF_SIZE) { if(strlen(spool_buff)!=NULL) { strcat(spool_buff,buffer); } else { strcpy(spool_buff,buffer); } } else {


INESC Porto


strcat(spool_buff,";"); if(send(sd, spool_buff, strlen(spool_buff) + 1, 0) == SOCKET_ERROR) { perror("send:") ; return 0 ; } strcpy(spool_buff,""); strcpy(spool_buff,buffer); } } else { strcat(spool_buff,";"); if(send(sd, spool_buff, strlen(spool_buff) + 1, 0) == SOCKET_ERROR) { perror("send:") ; return 0 ; } strcpy(spool_buff,""); } } return 1; } int close_socket() { int e; e = shutdown(sd, 2 ) ; if( e < 0 ) { perror("shutdown:") ;


INESC Porto


return 0 ; } e = closesocket( sd ) ; if( e < 0 ) { perror("close:") ; return 0 ; } WSACleanup(); return 1; }


INESC Porto


Ficheiro net_socket.h define MAX_BUFF_SIZE 512 int create_socket(int); int send_to_socket(char *buffer,int spool); int close_socket();

Documents

Ambiente Interactivo de apoio à criação em Arte Digitalpaginas.fe.up.pt/~ee98105/relatoriofinal.pdf · 1 Introdução ... 1.1 Plataforma VAF/Coral.....5 1.1.1 Como Obter ... que