Real Time Messaging Protocol (RTMP) é um protocolo desenvolvido pela Adobe para streaming de áudio, vídeo e dados para internet totalmente voltada para o Flash player.
O protocolo é muito simples e trafega em TCP na porta 1935. Também é possível usar o protocolo RTMPT que usa pequenos pacotes HTTP para burlar os Firewall, RTMPS e RTMPTS que são os mesmo protocolos, mais em conexão segura.
A Adobe travou muitas brigas, em projetos que quebraram o protocolo, mais em 15 junho de 2009 Adobe liberou a especificação RTMP. (Foi liberado apenas o protocolo, não funcionalidades).
Então, com o código aberto várias projetos surgiram, sendo o mais popular o Red5, gratuito em Java e o Wonza, em Java e pago.
Abaixo segue toda a lista que possuo de projetos que usar o RTMP e o link para chegar até eles:
Com o protocolo RTMP eu trabalho com o Red5 e FMS, sendo o FMS mais simples de implementar e mais confiável, e o Red5 tem apenas o preço a oferecer. O Wonza nunca utilizei, mais dizem que é bom e o FluorineFX é péssimo, tanto para live vídeo como para interactive data.
Basicamente o Flash abre um socket persistente com o server através do NetConnection e gerência o Streaming de áudio/vídeo pelo NetStream e a transferência de dados pelo SharedObject.
Em uma app em Flex você deve usar apenas uma instância do NetConnection, independente de quantos SharedObject e NetStream você tiver.
Para garantir interactividade em tempo Real (Ral Time), o sistema mantém uma conexão persistente com o servidor. Para garantir esta interactividade o protocolo divide o vídeo e os dados em fragmentos. O tamanho dos fragmentos utilizados podem ser negociadas de forma dinâmica entre o cliente e o servidor, e até mesmo completamente desativado se desejar, embora os tamanhos padrão são fragmento de 128 bytes para tipos de dados de vídeo e de 64 bytes para dados de áudio.
Fragmentos de diferentes streaming podem então ser intercalados e multiplexados em uma única conexão. Na prática, no entanto, fragmentos individuais geralmente não são intercalados. Em vez disso, a intercalação emultiplexação é feita no nível do pacote, com pacotes RTMP através de vários canais diferentes ativos sendo intercaladas de forma a assegurar que cada canal cumpre a sua largura de banda, latência e outra qualidade do serviço. Pacotes intercalados desta forma são tratados como indivisível, e não são intercalados no nível de fragmentos.
O RTMP define vários canais em que os pacotes podem ser enviados/recebidos, e que operam independentemente um do outro. Por exemplo, existe um canal dedicado para manipulação de solicitações RPC e respostas, um canal para transmitir dados de vídeo, um canal para transmitir dados de áudio, um canal para transmitir as mensagens de controle (banda negociação dos tamanhos dos fragmentos, etc).
Durante uma conexão, vários canais podem estar ativos simultaneamente em um dado momento. Quando os dados são empacotados, um cabeçalho do pacote é gerado. O cabeçalho do pacote especifica, entre outras coisas, a identificação do canal que está a ser enviado em diante, a hora em que foi gerada (se necessário), e do tamanho da carga útil do pacote. Isto é seguido pela carga útil do pacote, que é fragmentado de acordo com o atualmente acordado tamanho dos fragmentos antes que ele seja serializado pela conexão. O cabeçalho do pacote em si nunca é fragmentado, e seu tamanho não conta para os dados no primeiro fragmento do pacote. Em outras palavras, somente os dados da carga real do pacote está sujeito à fragmentação.
O protocolo RTMP é muito bloqueado em redes corporativas, redes de acesso gratuito e laboratórios de informática. Então pode se alterar o tipo de protocolo para quetrafegue em HTTP:
- RTMPT(RTMP Tunneled), neste caso o RTMP é encapsulado e transmitidos em HTTP. Por padrão o server deve escutar a, porta 80.
- RTMPS (RTMP Secure), neste caso o RTMP é encapsulado e trocado por HTTPS. Por padrão o server deve escutar a porta 443.