STREAMING DE MSICA

Eric Herji, N76182

Jos Dias, N75532
Rodrigo Verssimo, N76971
Instituto Superior Tcnico
Av. Rovisco Pais, 1049-001 Lisboa, Portugal
E-mail: {eric.herji, jose.requeijo.dias, rodrigo.verissimo}@tecnico.ulisboa.pt
5. TECNOLOGIA
5.1. Arquitetura Global de Servio
A arquitetura de uma rede de streaming um
esboo da cadeia de transmisso, que pode ser dividida em
trs partes: emisso, canal e receo, e est exemplificada na
figura 1.
Na emisso existe como backbone um servidor de
streaming (i.e. a conjugao de um servidor Web comum e
software especfico para o efeito) com um arquivo musical
digital. O contedo presente no arquivo musical sofreu um
processo de codificao e/ou compresso a priori, pelo que
estes esto prontos para serem transmitidos.
Passando para o canal, existem quatro aspetos
fulcrais a ter em conta quando se especifica um canal: (i.) o
ritmo de transmisso disponvel (assunto que ir ser
abordado mais adiante); (ii.) a modulao e a codificao de
canal (temas que no iram ser abordados neste artigo); (iii.)
a criptografia (os principais mtodos criptogrficos esto
explicitados na figura 1, pelo que no iremos abordar este
assunto em grande pormenor); (iv.) os protocolos que sero
utilizados nas diferentes camadas de OSI (assunto que
iremos desenvolver de seguida). Todas estas caratersticas
devem ser balanceadas de forma a pender o trade-off entre
eficincia de transmisso e resilincia a erros.
No fim da cadeia de transmisso existe o mdulo
da receo, que pode ser dividido em duas componentes: (i.)
o recetor contempla qualquer tipo de dispositivo eletrnico
capaz de descodificar contedos multimdia (e.g. PC,
Smartphone, Tablet, Smart TV); (ii.) o cliente software
capaz de reproduzir o contedo multimdia descodificado
(e.g. Rdio, Spotify, Tidal, Apple Music, entre outros).
5.2. Protocolos
Um protocolo um conjunto formal de regras,
convenes e estruturas de dados que governa o modo de
troca de informao, numa dada rede, de computadores e de

outros dispositivos de rede. No caso do streaming de

msica, os protocolos servem para fazer o transporte de
informao do ficheiro de udio codificado, proveniente do
servidor de streaming, e o envio do mesmo pela WAN (Wide
Area Network), e novamente entre a WAN e o
recetor/cliente, sendo que este pode ser um dispositivo
genrico.
Para melhor entender como atuam os protocolos
necessrio remeter subdiviso da rede pelo modelo OSI
(Open Systems Interconnection), algo que no faremos neste
artigo pelo que o conhecimento bsico de hierarquizao de
redes tido como presente por parte do leitor.
Dentro das camadas de OSI, podemos sublinhar quatro
delas que so fundamentais no que toca o streaming de
msica (a existncia de verses autenticadas dos protocolos
no discutida neste artigo):
Endereamento de rede (camada de sesso) IP, RTCP,
i.e. Internet Protocol, Real Time Transport Control
Protocol;
Transporte (camada de transporte) UDP, TCP, STCP,
i.e. Transmission Control Protocol, User Datagram
Protocol, Stream Control Transmission Protocol,
respetivamente, so os mais utilizados;
Apresentao (camada de apresentao) RTP, RTSP,
i.e. Real Time Transport Protocol, Real Time Streaming
Protocol, respetivamente.
Aplicao (camada de aplicao) HTTP, HLS, HDS,
MSS, DASH, i.e. Hypertext Transfer Protocol, Apple
HTTP Live Streaming, Adobe HTTP Dynamic
Streaming, Microsoft Smooth Streaming, Dynamic
Streaming over HTTP, respetivamente, so os mais
utilizados.
Uma grande parte das atividades que se realizam por
meio do acesso WAN tm como base o protocolo TCP. Tal
facto prende-se com a prpria gnese do protocolo, que foi
concebido numa altura em que a transmisso de pacotes era
ineficiente devido a erros no canal, e como tal o protocolo

Figura 1 Exemplo Genrico da Arquitetura Global de Servio Streaming

Tabela 2 Comparao entre protocolos TCP e UDP (Fonte: tech.ebu.ch, 2015)

centra os esforos na tentativa de transmisso de pacotes

(SYN) mesmo quando estes no chegam ao recetor (ACK).
Hoje em dia a gnese da WAN feita com base em canais
cujo erro de transmisso mnimo, e portanto, no de
estranhar que a maioria dos servios de streaming de msica
modernos tenham, na sua gnese, o protocolo UDP como
base de fornecimento do servio, ou seja, todos os
protocolos de camadas mais elevadas (camada de
apresentao e camada de aplicao) tm, na sua grande
maioria, uma base UDP. Uma comparao entre o UDP e o
TCP feita na tabela 1.

Posto isto, necessrio entender as diferenas entre os

protocolos nas camadas imediatamente acima camada de
transporte.
O protocolo RTP foi o primeiro protocolo real-time
a ser desenvolvido, e definido pela recomendao IETF
RFC 3550. Este protocolo tem por base, na camada de
sesso, os protocolos IP e RTCP (este ltimo para efeitos de
QoS feedback), e na camada de transporte, o UDP
(maioritariamente).
Por outro lado, o protocolo RTSP uma verso
aprimorada do protocolo RTP, e definido pela

recomendao IETF RFC 2326. Este protocolo nasce numa

altura em que a indstria pretende fazer a transio entre o
download progressivo e o streaming tal como o conhecemos
hoje. Para tal necessrio acoplar transmisso de
contedos o feedback de/para o utilizador, traduzindo-se na
transmisso de metadados e receo de sinais de controlo do
utilizador, por parte do servidor de streaming. Para tal, o
desenvolvimento deste protocolo teve por base o protocolo
RTP com a adio de novas features. de notar que todos
estes protocolos operam em portas especficas, mas
diferentes (se o RTP operar na porta N, ento o RTSP
operar em N+1), o que poder levar a constrangimentos em
clientes protegidos por meio de um SDI (Sistema de
Deteo de Intruso) e/ou Firewall, algo que no iremos
abordar neste artigo.
Passando para a camada de aplicao, notria a
larga quantidade de protocolos existentes. A explicao para
tal facto que existe uma tentativa de otimizao acrescida
na transmisso de dados por parte de alguns fabricantes, aos
dispositivos produzidos per si, e nos quais os contedos so
rececionados, como o caso da Apple e da Microsoft. Do
mesmo modo, algumas companhias tentam fazer uma
integrao horizontal de servios (desde o servidor, at ao
utilizador), o que permite uma melhoria do QoE e QoS, e
portanto, a necessidade de protocolos proprietrios, como
novamente o caso da Apple e Microsoft. Finalmente, o facto
de uma grande parte dos utilizadores comuns estar
fidelizado a um determinado software no dispositivo em que
receciona os contedos faz com que seja possvel a obteno
de royalties da parte dos fornecedores de software para
servidores de streaming, o que por si s um negcio
lucrativo e que permitiu o desenvolvimento de protocolos
diversos, aumentando a concorrncia e inovao tecnolgica
e acabando por beneficiar, eventualmente, o consumidor
final.
Focando agora nas especificaes dos protocolos
da camada de aplicao o HTTP porventura o protocolo
mais conhecido atualmente, definido na sua verso
primordial pela recomendao IETF RFC 1945. Talvez a
caracterstica mais conhecida seja o facto de carregar de
forma eficiente pginas HTML e possuir uma ligao
bidirecional (point-to-point) entre o utilizador final e o
servidor de streaming, o que por si s permite uma grande
flexibilidade. As verses mais atualizadas deste protocolo
abordaram o desenvolvimento genrico nas capacidades de
feedback, no entanto, estas melhorias nunca estiveram
vocacionadas tendo em vista o modelo de streaming, pelo
que podemos considerar o HTTP como um protocolo
generalista.
Seguidamente, o protocolo HLS um protocolo
proprietrio, definido pela recomendao IETF BCP 78/79,
e assente em HTTP com suporte para ritmos binrios
adaptativos, ou seja, possvel enviar mltiplas streams do
mesmo contedo a ritmos de transmisso diferentes, e de

acordo com a largura de banda disponvel do lado do

utilizador, o cliente pode escolher uma das streams. Outra
grande mais-valia na utilizao deste tipo de protocolo o
facto do servidor web no necessitar de software dedicado,
uma vez que este assenta sobre o HTTP.
Da mesma forma, o protocolo HDS (tambm
proprietrio) est em conformidade com a recomendao
IETF BCP 78/79 e assenta em HTTP. Este protocolo
necessita, em paralelo, da tecnologia proprietria Adobe
Flash Player para poder operar corretamente, o que fez
com que fosse o protocolo mais utilizado na transmisso de
contedos na primeira dcada do sculo XXI, uma vez que
existia uma grande compatibilidade entre os ambientes
desktop e o prprio Adobe Flash Player, algo que no
acontece de forma to evidente hoje em dia devido ao
crescimento do mercado de dispositivos mveis. de notar
que a utilizao deste protocolo requer a utilizao de
software especfico (tambm este, proprietrio) do lado do
servidor.
O protocolo MSS um protocolo proprietrio
definido pela recomendao IETF RFC 6983. Este
protocolo, tal como o anterior, requer a utilizao de
software proprietrio no lado do servidor, de forma a
possibilitar um maior controlo sobre o contedo a transmitir.
Tal como o HLS, este protocolo suporta ritmos binrios
adaptativos, e ainda, para alm de monitorar a largura de
banda disponvel, monitoriza tambm a utilizao do CPU
por parte do cliente. Esta feature acrescida particularmente
interessante quando falamos de dispositivos mveis uma vez
que a gesto da bateria tende a ser o mais eficiente possvel,
e para tal, o protocolo utiliza diversos mtodos para o efeito,
tais como: (i.) a mudana on-the-fly de codificador entrpico
para outro com menor complexidade algoritmica, e logo,
diminuindo os recursos dispendidos pelo CPU do cliente;
(ii.) a reduo do ritmo binrio do ficheiro a ser transmitido,
ao fazer uma partio do contedo original em camadas e,
consoante a largura de banda disponvel, escolher quais as
camadas a transmitir.
Finalmente, o protocolo DASH, certificado com a
referncia ISO/IEC 23009-1, um protocolo de cariz
internacional, e est estandardizado, caracterstica
fundamental para o requerimento da interoperabilidade, algo
que falaremos no captulo 6. Assenta, tal como o HLS e o
MSS, no HTTP, e compatvel com a grande maioria do
software/cliente existentes hoje em dia, algo que tem
promovido a sua rpida adoo por parte dos grandes
conglomerados tecnolgicos, um pouco por todo o mundo.
Uma comparao dos diferentes protocolos pode
ser vista na tabela 2:

Tabela 2 Comparao entre protocolos utilizados em Streaming

(Fonte:
bitcodin.com,
2015)

udio, processo que resulta num sinal codificado e

descodificado diferentes, diferena essa impercetvel ao
sistema auditivo humano mas percetvel ao nvel dos
recursos necessrios transmisso do sinal.
de notar que um codec lossless no melhor nem
pior que um codec lossy uma vez que existem muitas
variveis em jogo no que toca perceo de qualidade e
medio de qualidade, algo que no iremos aprofundar neste
artigo.
Referindo concretamente transmisso de udio via
streaming, os codec lossless mais utilizados em streaming
so:
FLAC
ALAC
WAV

Os codecs lossy mais utilizados so:

MP3
AAC
AC-3
Ogg Vorbis
Tabela 3 Comparao entre Codecs udio utilizados em Streaming

5.3. Guerra de Codecs

A palavra codec deriva da aglutinao de duas
outras: encoder e decoder, ou seja, um codec codifica e
descodifica um sinal de udio digital, com o objetivo de
representar o mesmo com alta-fidelidade e a quantidade
mnima de bits.
Para o efeito, existem dois tipos de codec: lossless
(sem perdas) e lossy (com perdas). O tipo lossless explora a
redundncia das amostras de um determinado sinal de udio,
e logo, o sinal codificado e o descodificado so
matematicamente equivalentes; j o tipo lossy explora, para
alm da redundncia, a irrelevncia das amostras do sinal de

A comparao dos codec acima descritos feita na

tabela 3.
possvel observar que os codec variam bastante
em termos de especificaes. Primeiramente, a taxa de
amostragem, relaciona a largura de banda de um sinal de
udio audvel (aproximadamente 20 kHz, sem bandas de
guarda), com o teorema de Nyquist. Ora para uma correta
amostragem do sinal necessrio que a taxa de amostragem
seja, no mnimo, duas vezes superior frequncia mxima
da sinusoide mais frequente do sinal, ou seja, uma taxa de
amostragem mnima de aproximadamente 40 kHz (tambm,
sem bandas de guarda). Neste aspeto, os codec WAV, MP3 e
AC-3 cumprem as especificaes mnimas
audveis, o que resulta numa eficincia acrescida face aos
outros codec.
Seguidamente, o nmero de bits/amostra refere-se
ao processo de quantizao. Este processo tem por base a
irrelevncia da preciso numrica dos valores que as
amostras das sinusoides que compem o sinal tomam, pelo
que, ao quantificarmos estas amplitudes em intervalos de
valores discretos, simplificamos em muito o processo de
quantizao binria, e como tal, a diminuio do nmero de

bits transmitidos. Tipicamente uma quantizao de 16

bits/amostra (referente a 216=65.536 nveis de quantizao
positivos) suficiente para representar os valores de uma
determinada amostra, com um limiar de erro abaixo da
perceo auditiva do ser humano. No entanto, alguns codec
elevam este patamar para 24/32 bits/amostra (tipicamente os
codec lossless). Neste aspeto, os codec lossy e WAV so os
mais eficientes.
6. INTEROPERABILIDADE
6.1. Explicao de Conceito
Um conceito que est intimamente relacionado
com a eficincia de um codec a interoperabilidade.
Interoperabilidade, no mbito das Tecnologias de
Informao e Comunicao, pode ser definida como a
capacidade de mltiplos sistemas trocarem e reutilizarem
informao sem custo de adaptao, preservando o seu
significado (fonte: iap.gov.pt).
importante notar que este conceito adquiriu com
o passar dos tempos uma importncia acrescida uma vez que
a disseminao de dispositivos (PC, Tablet, Smartphone,
Smart TV, etc.) cada vez mais intensa e cada vez mais a
interoperabilidade um requisito obrigatrio para uma boa
experincia de utilizao.
6.2. Condies para Interoperabilidade
Apesar do conceito ser extremamente simplista, o
caminho para o atingir nem sempre fcil, uma vez que
necessrio considerar os seguintes aspetos fundamentais: a
certificao; o custo de acesso; as partes interessadas; as
partes envolvidas, e a estandardizao.
Para uma tecnologia ter alta penetrao no mercado
multimdia fundamental que exista, em primeiro lugar,
uma parte interessada com uma quota suficientemente alta
de mercado que possa comear por introduzir a tecnologia
nos seus dispositivos (e.g. Sony e Nokia, e o formato AAC).
Se a tecnologia representar de forma inequvoca o melhor

que se faz na indstria, ento o processo de certificao por

uma entidade certificadora credenciada (e.g. ISO, IEC,
ATSC) straightforward, com o objetivo de definir o
conjunto de ferramentas mnimas para que qualquer outra
entidade possa utilizar o codec de forma correta e eficaz. A
esta conjunto de regras d-se o nome de standards, e
consequentemente, a passagem de um codec certificado para
um estandardizado facilitada. O fator monetrio tem de ser
sempre tido em conta pois, a partir da certificao possvel
que as partes envolvidas criem um modelo de negcio
assente em royalties (como o caso do MP3, AAC e AC-3),
algo que prejudica, eventualmente, a disseminao da
tecnologia e o utilizador final.
Fazendo a ponte entre o captulo 5.3 e o modelo de
negcio assente em royalties, no de estranhar que, dos
codec listados na tabela 3, apenas os lossy sejam pagos,
uma vez que so estes os mais utilizados hoje em dia (e
principalmente em streaming). Por outro lado, na
implantao de royalties nestes codec lossy est inerente um
fator que preciso ter em linha de conta, a inovao
tecnolgica - para comprimir um determinado contedo
necessrio levar em linha de conta o funcionamento do
sistema auditivo humano e perceber a variao da
sensibilidade auditiva com a frequncia e com a amplitude,
ao passo que a codificao lossless no tem este grau de
complexidade acrescido.
Posto tudo isto, existe claramente um codec que se
destaca atualmente - o MP3, devido sua eficincia na
compresso
de
contedos
musicais,
devido

estandardizao e inexistncia de royalties, o que permite

que seja o codec de eleio na transmisso via streaming,
mas tambm no armazenamento mvel de contedos, sendo
que todos estes fatores conjugados promovem a existncia
de condies timas para que um codec possa ser
amplamente interopervel.
Referncias:
Network Protocols Handbook. Saratoga, CA.: Javvin
Technologies, 2007. Print.