Archive for the ‘Flash’ Tag

Publishing RTSP Streams on FMS! How?

For those who have ever used the Flash Media Server for video streaming, the idea of publishing a stream encapsulated in RTSP (Real Time Streaming Protocol) may seem quite strange, maybe even impossible. This is because the basic (and only) protocol used for FMS client-server communication is the RTMP (and its variations), a proprietary protocol for media streaming, from Adobe. However, in some circumstances the use of an RTMP input is almost impossible, especially when this input stream comes from legacy systems, or from external services. These specific cases require an approach where the content from a RTSP source is delivered using RTMP, that is, a translation from RTSP to RTMP via content repackaging.

The easiest way to perform this translation is using Wowza Media Server, an alternative to FMS that has many interesting features, including the RTSP input support. The problem is that sometimes is impossible to change the video architecture from FMS to other solution, especially when we have developed several applications, or when the whole environment is integrated, up, and running.

In this situation, the intuitive solution would be: we can setup a layer of Wowza Media Server before FMS Servers, working like a translation layer. With this layer, the FMS would receive a RTMP stream exactly like it receives from Flash Media Encoder, making the translation fully transparent. The challenge of this solution is that the Wowza Server cannot publish streams on FMS, so, it cannot act like a FME (from FMS perspective).

To deal with this limitation, we need to change the stream flow paradigm from push to pull, or, in other words, we need to force FMS to get the stream from Wowza. With this architecture configuration, the FMS is no longer a passive component. It is its responsibility to, not only get the video stream, but to perform the failover of the input streams, which can be done through stream multiplexing.

This change in FMS role is only possible if we use server side action script, to connect to Wowza, and to pull the stream flow. Basically, we use NetConnection and Stream classes, to establish a remote connection and to play some content (Wowza stream) through it:

myRemoteConn = new NetConnection();
myRemoteConn.connect("rtmp://wowzaserverhost/streamtest");
myStream = Stream.get("myStream");
myStream.play("my_stream.sdp", 0, -1, true, myRemoteConn);

As we can see, we can use the FMS to delivery RTSP streams without great architecture changes. With Wowza Media Servers and some server side AS, it’s not too hard to make the impossible, possible!

Advertisements

Stream Multiplexing for FME Failover in Flash Media Server

As some may wonder, I decided write my posts in English from now, so, anyone can follow the ideas that are discussed here. To start this new era, I decided to talk a bit about how we can do the failover of live streams in Flash Media Server through internal multiplexing of signals, that is, how we can use a single live stream as a backup of several others, without burdening bandwidth available between the Flash Media Encoder and the Flash Media Server.

To get the goal of this idea a little clearer, let’s suppose that we want to perform a live transmission, where we have 3 servers running an instance of Flash Media Encoder each, and we have 3 different signals (eg cameras), linked to a each encoder. If one of these servers crashes, the stream will no longer be published on Flash Media Server, and inevitably users connected to this content will have their experience interrupted. In order to avoid this problem, we can detect that a stream is no longer running, and then send to users the signal of another encoder, in a transparent way, without playback interruption (lost of connection or rebuffering). This approach dispenses the use of a backup server for each active server, which significantly reduces the investment in hardware and bandwidth, in environments with high availability needs.

The main concept behind this approach is the separation between the publishing streams and the viewing streams, which means that the users should not connect directly into the stream published for Flash Media Encoder. In fact, users should connect to a fake stream, and the published content will be dynamically linked to it via a server side Action Script. This idea is very well explained in the article “Building a Live Video Switcher with Flash Communication Server MX“, which was the base of multiplexing for failover concept. To automate this association between publisher stream and viewers, we can use the application.onPublish and application.onUnpublish events, which are triggered when a signal is, or ceases to be published in Flash Media Server.

The challenge now is how to control, automatically, which is the backup stream and which is the main, that is, not simply store a list of active streams, we need to know which stream will be displayed to users if a failure occurs in main stream. One approach is to isolate each stream in a different instance of application, and, in addition, create two different types of applications, one for the main streams (master) and one for the backups. Each master instance will have only one stream available so that users can connect, which means that we will need to have as many instances as the number of live signals.

The main application should store/remove from a list all the active/inactive live streams (via events), so that the first stream of the list always will be associated with the stream being viewed by users. If this stream is unpublished, the application should join the users stream to the next item, which means that the backup will always be the next stream on the list.

The backup application should receive a live signal and publish it in the main applications, performing an internal multiplexing. These internal streams will be stored on main instances as backups, so, all main applications will have the same backup streams. This internal multiplexing can be implemented in a very simple way using the NetConnection and NetStream classes, also available for server side scripting.

To make clear the idea presented above, let’s take a look at this picture:

Failover for FME Streams

Failover for FME Streams

As we can see, this approach is a simple and efficient way to implement the failover of streams published by FME, which is very important in environments where high availability is a imperative requirement, and where the investment resources for bandwidth and hardware are limited.

More information about Flash Media Server Development can be found in Adobe Developer Connection

God Damm Flickering!

Nos últimos dias, estava realizando uns testes de reprodução de vídeo no flash player, e percebi algo extremamente desagradável: havia um flickering absolutamente irritante quando estávamos reproduzindo um vídeo de alta qualidade, com grandes dimensões, e com bastante movimento, principalmente vertical. Certo de que este era um problema específico da minha máquina (Linux Ubuntu), não me preocupei muito, e continuei meus testes, até que resolvi testar um vídeo em um Windows rodando em um Dual Quad Core com placa de vídeo de 256MB. Por incrível que pareça, o maldito flickering ainda estava lá.

Reproduzindo os mesmos vídeos em outros players não obtive problemas, o que me leva a desconfiar bastante do flash player. Finalmente, para ter certeza de que não estava fazendo nada errado, resolvi testar as versões HD dos principais sites de vídeo (YouTube, Vimeo, etc)  vendo vídeos com bastante movimento, e o que eu descobri é que todos eles tem o mesmo problema.

Flickering

Se for realmente um problema de Flash Player, aí as coisas ficam realmente complicadas. Como a Adobe quer que as pessoas utilizem o flash player para distribuição de H264 se o vídeo fica flickando?

Vídeos no Flickr!!!!

O Flickr liberou hoje pela manhã a possibilidade de upload de vídeos, além das fotos que já conhecemos. Com isso, não precisamos mais subir nossos vídeos para o YouTube, e podemos deixar tudo junto em um lugar só. Essa feature era uma das mais esperadas de todos os tempos, e não sei porque eles demoraram tanto para implementar essa funcionalidade (provavelmente devido aos investimentos em infra!!!). Talvez pela falta de uma infra-estrutura robusta existe um limite de 90seg por vídeo, o que é ruim, mas já dá para quebrar o galho.

Eles também estão utilizando Flash Vídeo em progressive download, o que já é mais do que padrão no mercado. O codec de vídeo escolhido foi o VP6, com 800kbps (muito alto para os padrões brasileiros), sem conversão de aspect ratio ou frame rate. Já para o áudio, temos 64kbps MP3, com 44100Hz, stereo.

Este é sem dúvida nenhuma um passo importantíssimo do Flickr, sendo mais um diferencial bastante considerável em relação aos seus concorrentes.

Para saber mais, é só ir no Blog do Flickr

MTV lança novo player de Vídeo

A MTV lançou recentemente a nova versão de seu Player de Video na Internet exclusiva para Full Episodes. Utilizando streaming via Flash Media Server, ela abandona o delivery via progressive download, o que definitivamente é uma evolução em termos de segurança, já que não há cache local, e de “qualidade”, uma vez que eles utilizam um processo de detecção de banda para servir um target bitrate mais adequado para a conexão do usuário (temos variações desde 350kbps até 1.2Mbps). Apesar disso, essa “qualidade” está entre aspas porque todos sabemos que a experiência do usuário em delivery via streaming pode ser terrivelmente ruim, principalmente se você estiver próximo do target e se sua velocidade não é suficientemente estável. Nestas circunstâncias, o vídeo irá fazer rebuffering constantemente, o que é absolutamente irritante. Além disso, a possibilidade de pausar e aguardar o carregamento para uma reprodução contínua não é possível, o que vai contra ao comportamento do usuário, principalmente devido à experiência proporcionada pelo YouTube.

Com relação à qualidade do vídeo, ela está realmente muito boa, e melhorou bastante em relação à versão antiga. A imagem está mais nítida, com menos blur, o que indica um processo de codificação mais eficiente. Como o Flash 9.r115 não é um requisito mínimo, acredito que eles estão utilizando VP6 para codificar os vídeos. Entretanto, dada a qualidade da imagem em relação ao bitrate utilizado, não duvido nada que também exista uma versão H264 que é enviada apenas para os usuários com esta versão de Flash Player. Infelizmente não podemos saber ao certo, já que não consegui copiar o vídeo para minha máquina 😦

Antes:

MTV Before

Depois:

MTV After

Outra observação interessante é a utilização de inserções comerciais ao longo do vídeo, que são representadas na barra de progresso com pequenas barras cinza. Eu particularmente achei que ficou meio ruim de ver as marcações, além de que a interrupção da reprodução para exibição de um comercial é extremamente inconveniente do ponto de vista do usuário. A verdade é que os grandes players do mercado ainda estão estudando a melhor forma de realizar publicidade em vídeo distribuído na internet, mas isso é um assunto para um outro post.