Archive for the ‘Streaming’ 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();
myStream = Stream.get("myStream");"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!

QoS Parameters for Video Streaming

When we talk about professional media streaming, there is a lot concern with the quality of service, especially when we have large volumes of requests, or when we delivery contents in high definition. In this scenario, is essential to have a fairly clear idea about what is quality of service, and how we can identify, through objective parameters, if we’re or not at an acceptable level, which ensures a high quality experience for end users.

In the case of video streaming, quality of service means that the user should watch a certain content, without interruption (rebuffering), and without degradation of video quality caused by the delivery process (loss of frames, problems in the reconstruction of b-frames and p-frames due packet loss).

Thus, the best known parameter for evaluating the quality of a streaming service is the buffer length, which is the ability to maintain the user’s buffer always at an acceptable level, being greater enough to ensure a continuous experience independent of small variations in bandwidth available, and in the bitrate of the encoded video. Associated with this parameter, we have the average rebuffering rate, which consists of a ratio between the total time used filling the buffer, and the total playing time. This parameter is very interesting to assess the quality of service for live streaming, where users can stay connected for a long time, and, of course, they would like to play the content without interruptions.

A high quality streaming service should always keep the rate of rebuffering below 0.5%, discarding the initial buffer, at normal bandwidth availability. Moreover, this parameter can be very useful to identify network bottlenecks at content distribution process.

Another key parameters are the average frame rate and the rate of frame loss. These two parameters give us an overview of the capacity, of the server to stream the video content, and, of the users to receive and decode the stream. In case of server overloading , one of the first alternatives used to maintain a continuous experience is to reduce the frame rate, or basically, drop frames. These parameters usually indicate that either the server is not able to serve the content, or, the clients do not have the minimum conditions to receive and decode the video. These problems are usually associated with intensive CPU usage, due an excess of clients in the server side, or by lack of resources for decoding the video on the client.

For Flash Media Server specifically, some parameters related with memory usage for input and output buffer, size of buckets, and use of aggregated messages, can influence directly in the video frame rate, but in this case, we can detect the problem even with a small amount of users.

Finally, we have some parameters, not least importants, to complement the set of basic checkpoints to ensure the quality of streaming video service, including, the time to establish the connection, the rate of reconnection, the sync between audio and video, and psnr between the video decoded by the user and the video that comes out of encoder (since the loss of packets may influence the reconstruction of the frames, especially for temporal video compression). Measuring and evaluating all these parameters we can identify with much more efficiency any problem that might compromise the quality of service, which is essential for professional media streaming business.

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

[Streaming Media East 2008] Novidades e Resumo do Evento

Na última semana estive no Streaming Media East 2008, em Nova York, para conferir as novidades sobre streaming de mídia na internet, e posso dizer que o evento foi bem legal, e bastante proveitoso, mesmo tendo algumas sessões lamentáveis. Porém, antes de mais nada, gostaria de pedir desculpas pois não consegui atualizar o blog com a freqüência que eu queria, já que, por incrível que pareça, existem mais hot-spots abertos no Rio que em NYC!!!

No primeiro dia de evento, assisti dois workshops de 3hrs cada: “Comparing and Using Video Codecs” e “Microsoft Silverlight”. Estava especialmente interessado no primeiro deles, já que a descrição do workshop dizia que seria apresentada uma comparação entre WMV, VP6 e H.264. Infelizmente fiquei bastante frustrado, e acredito que esta tenha sido a apresentação sobre codecs de vídeo mais rídicula e inútil que eu já vi. O palestrante foi totalmente superficial, não entrando em nenhum detalhe mais específico de nenhum dos codecs. Durante a apresentação, ele ignorou toda e qualquer solução open-source, de qualquer codec, inclusive a libx264, que é sem dúvida nenhuma a melhor implementação de H.264, inclusive quando comparamos com implementações proprietárias. Não citou o ffmpeg ou o mencoder, e ainda desconversou quando foi perguntado à respeito delas. Finalmente, para perder completamente o crédito, apresentou um comparativo de encoders com notas dadas subjetivamente para critérios que ele definiu como importante, ignorando absolutamente todos os métodos objetivos/científicos de avaliação de qualidade (PSNR, SSIM, MSE, etc). Ele ainda criticou bastante o Sorenson, e parecia um representante comercial da On2 querendo vender o VP6, apesar de não ter argumentos quando questionaram sua posição dizendo que o YouTube usa Sorenson.

O segundo workshop, de Silverlight, foi bastante proveitoso, já que confirmou todas as críticas que faço, além de reforçar minhas convicções de que ele é uma porcaria que a Microsoft está tentando empurrar para o mercado. Durante 3hrs, o Silverlight Evangelist não conseguiu fazer sequer um exemplo, conseguiu crashear o IE duas vezes, e desconversou quando pediram um comparativo com o Flash. Como mais da metade dos presentes foi embora antes de 2hrs, acho que todos estão convencidos de que não dá para fazer muita coisa com o Silverlight não, então, se vocês querem um conselho, esqueçam que ele existe.

Apesar de um primeiro dia terrível, o segundo dia valeu por cada centavo pago na inscrição. O keynote de abertura, com o CDO da NBC, foi bem legal, principalmente para saber o que grandes broadcasters como a NBC estão fazendo, e o que eles esperam do mercado. Em seguida, assisti uma mesa redonda sobre a convergência H.264, onde estavam presentes o Product Manager do Flash Media Server e o Video Architect do Yahoo!, além de um representante da Akamai e um da Move Networks. O grande ponto desta sessão foi opinião unânime de que o H.264 é o formato da nova geração de vídeos que irá ser responsável pela convergência de conteúdo entre TV, Internet e Celular. A Adobe está apostando bastante nisso, e certamente a parte de streaming/vídeo vai receber bastante investimento nos próximos anos. Um ponto importante que todos lembraram é a questão do licenciamento do H.264, que será revisado pelo MPEG/LA em dezembro de 2010, e pode impactar bastante à indústria.

Outra sessão bem interessante foi sobre os preços de CDN’s e sobre P2P, onde houve muita discussão sobre a queda que vem ocorrendo nos preços para utilização de CDN’s, e sobre as alternativas para delivery de vídeos, como P2P. Na verdade, o grande problema que todos enxergam no P2P é a necessidade de instalação de um software adicional, que realmente prejudica a experiência do usuário.

No segundo dia, fui à um keynote com o responsável pelo, onde ele apresentou como é a estrutura de publicação/produção deles. Apesar de ter uma produção bem pequena (20 vídeos por dia), foi legal ver como é o processo desde a captura no estúdio (com câmeras HD da Sony e Anycast) até a publicação na internet, depois de editar o conteúdo no Final Cut Pro.

Além disso, a pergunta que eu mais ouvi durante todo o evento é como ganhar dinheiro com vídeo na internet, ou seja, como transformar todas as iniciativas, desde VoD até Lifecasting, em um negócio rentável, principalmente através de publicidade. A verdade é que ninguém sabe ao certo como transformar toda a audiência dos sites de vídeo em dinheiro, e estão todos experimentando suas soluções. Neste ponto específico, acho que a está com um modelo bem interessante, que deve se firmar no mercado.

Em resumo, valeu bastante a ida ao evento, e recomendo para todos que tiverem algum interesse no mercado de streaming, principalmente para aqueles que estão começando agora.

Se alguém tiver interesse, algumas apresentações do evento estão aqui.

Streaming Media East 2008

Streaming Media East 2008Nesta sexta-feira (16/05) estarei embarcando para Nova York, para o Streaming Media East 2008, um evento voltado para o mercado de distribuição de mídia na internet, e acho que será bastante proveitoso. Este ano a agenda está especialmente interessante, já que teremos mais discussões sobre H.264, o que comprova mais uma vez que este será o codec da nova geração de vídeos na Web e responsável pela tão esperada convergência entre TV e Internet. Além disso, outro assunto que será bastante falado é sobre como ganhar dinheiro com a distribuição de vídeos na internet, ou seja, qual é a melhor forma de inserir peças publicitárias sem prejudicar a experiência do usuário.

Também devo assistir sessões de CDN e P2P, já que em termos de delivery o mercado ainda está bem atrasado, e, usar HTTP unicast certamente não vai atender a crescente demanda existente.

Finalmente, para ninguém dizer que eu tenho má vontade e preconceito com as soluções da Microsoft, devo assistir um workshop de Silverlight. Ainda tenho esperanças de que alguém encontre um argumento à favor do Silverlight, porque até agora está bem difícil.

Bom, irei postar diariamente sobre as novidades, então, podem conferir o que está rolando por aqui.

Escolhendo a melhor arquitetura para delivery de vídeos

Apesar de parecer algo simples, a escolha correta de uma arquitetura de delivery de mídia é tão fundamental para o serviço quanto a definição dos parâmetros de codificação, isto porque ela também pode impactar de forma decisiva na qualidade da experiência do usuário. Distribuir um vídeo que demora muito para carregar, ou que “trava” constantemente, muitas vezes é pior do que ter uma experiência contínua porém com pior qualidade. Por isso, a escolha da arquitetura de delivery está fortemente atrelada ao target bitrate escolhido.

Existem duas formas básicas de se distribuir vídeos na internet: via Streaming ou Progressive Download. O streaming é a tecnologia que permite o envio de informação através de pacotes, que são solicitados sob demanda pelo cliente, ou seja, o cliente solicita ao servidor apenas os pacotes necessários para exibir o conteúdo em um determinado momento. Uma vez consumidos, os pacotes deixam de existir na máquina do cliente. O progressive download, nada mais é que um simples download, porém com a vantagem de que o usuário pode começar a reproduzir o conteúdo sem que seja necessário que o download esteja finalizado. No progressive download, o conteúdo é efetivamente copiado para a máquina do usuário, e, de acordo com as diretivas de cache, pode ficar armazenado lá por um determinado período de tempo.

Vocês agora podem se perguntar qual dessas duas opções é melhor, e a resposta é simples: depende dos seus objetivos e das características do cenário em que a solução será utilizada. Simplificando, você deve se fazer as seguintes perguntas antes de escolher qual modelo de distribuição será utilizado:

  • Qual o target bitrate total dos vídeos que serão distribuídos?
  • Qual é a largura de banda disponível média dos usuários que irão acessar o conteúdo?
  • A segurança do conteúdo é uma prioridade? (Pirataria)
  • Os custos da infra-estrutura são um fator limitante?

Se suas respostas indicam que a largura de banda disponível média dos usuários é pelo menos 20% maior que o target bitrate total dos vídeos que serão distribuídos, então a situação é bastante confortável, e a escolha entre streaming e progressive download será decidida nas outras duas questões. Caso a segurança seja uma preocupação primordial, ou seja, o conteúdo oferecido é altamente sensível à pirataria, então recomendo fortemente a utilização do streaming. Isto porque o conteúdo distribuído via streaming não fica armazenado no cliente após a reprodução, o que dificulta um pouco as coisas para o lado de quem quer copiar. Além disso, não é possível fazer o download do arquivo através de um simples GET HTTP, já que a maioria dos servidores de streaming utilizam protocolos diferentes (rtmp para Flash e rtsp para WMV). Entretanto, não pense que será impossível copiar o conteúdo, já que existem alguns programas que “tocam” o vídeo como se fossem um player, mas na verdade estão copiando o bitstream para um arquivo local (WMRecoder, etc).

Por outro lado, ainda no cenário ideal onde a disponibilidade de banda é maior que o target bitrate, caso os custos sejam uma preocupação crítica, então a melhor opção seria o progressive download, já que podemos montar um servidor utilizando apenas tecnologias open-source (Apache), e podemos compartilhar os recursos com outras aplicações, como um web-server. Desta forma, não é necessário um hardware dedicado ao serviço, o que pode acontecer utilizando streaming, principalmente em Windows Media. Além disso, um servidor de progressive download suporta, naturalmente, mais conexões que um servidor de streaming, já que ele dispensa uma série de controles do fluxo de bits de cada conexão.

Voltando ao mundo real, o que acontece quando a disponibilidade de banda dos usuários não é lá grandes coisas? Neste caso, a melhor opção é sem dúvidas o progressive download. Caso o usuário não tenha uma banda disponível suficiente e a distribuição seja feita via streaming, a reprodução do conteúdo será interrompida constantemente para rebufferings, já que o fluxo de bits de saída é maior que o de entrada, e não há nada mais irritante para o usuário do que interrupções na reprodução. O mesmo problema acontece para o progressive download, com um porém: o YouTube ensinou uma valiosa lição para o usuário, “aperte o pause e espere carregar”! Assim, a diferença, neste caso, entre o streaming e o progressive download, está na possibilidade de pausar a reprodução até que o conteúdo esteja suficientemente carregado para uma reprodução contínua. Esta é uma “feature” que definitivamente faz toda diferença quando falamos na satisfação do usuário.

Um bom argumento daqueles que defendem o uso do streaming é a possibilidade de seek para qualquer posição do vídeo, independente da necessidade de carregamento. Entretanto, se estivermos falando de Flash Vídeo, este argumento é totalmente inválido. Com Flash Vídeo podemos implementar de forma relativamente simples uma solução de seek para qualquer posição, sem que seja necessário que a posição desejada já tenha sido recebida (mod_flv_streaming).

Resumindo, a escolha entre progressive download e streaming deve ser feita baseada nas características específicas de cada situação, e não podemos dizer para usar sempre um ou outro, pois ambos possuem vantagens e desvantagens. Na verdade, a chave para escolha da melhor arquitetura consiste na avaliação correta de todos os pontos envolvidos no processo de delivery, considerando assim os trade-offs de cada solução.

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 😦


MTV Before


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.