Práctica 2 - Radio IP (Javier de la Rica) (2016)

Pràctica Español
Universidad Universidad Politécnica de Cataluña (UPC)
Grado Ingeniería de Sistemas Audiovisuales - 3º curso
Asignatura Comunicaciones Multimedia
Año del apunte 2016
Páginas 57
Fecha de subida 01/04/2016 (Actualizado: 01/04/2016)
Descargas 22
Subido por

Vista previa del texto

Javier de la Rica Comunicaciones Multimedia Multimedia Communications Internet Radio Departament de Enginyeria Telemàtica (ENTEL) Jorge Mata Juanjo Alins Oscar Esparza José L. Muñoz 1. Introducció Internet i la distribució de continguts multimèdia són dos conceptes que estan associats.
Des de que la xarxa i els equips permeten l’intercanvi de grans volums d’informació a alta velocitat, la quantitat de continguts audiovisuals que circulen per la xarxa no ha parat de créixer any rere any. Amb la millora de les condicions de la xarxa i de l’equipament informàtic, va sorgir una tècnica de transmissió de continguts multimèdia innovadora en aquell moment: l’streaming. Aquesta tècnica permet reproduir un contingut sense haverse’l de baixar totalment abans de reproduir-lo, fet que possibilita poder escoltar i veure continguts generats en directe al moment (sumant-hi un retard). Usant streaming, es generen les primeres ràdios per Internet, essent unes ràdios que en un inici emetien un àudio típicament de baixa qualitat però que amb els anys han millorat la qualitat fins a assolir unes taxes de transmissió amb qualitats d’àudio properes a la del CD.
De ràdios IP en trobem bàsicament de dos tipus: les ràdios FM convencionals que ofereixen els continguts que emeten per aire per Internet o bé les ràdios que només emeten continguts per Internet. Les primeres, es diu que les emissores ofereixen un servei de webcasting, oferint en directe els continguts que emeten per aire. No s’ha de confondre amb el servei de podcasting, ja que aquest servei és un sistema d’àudio sobre demanda, mentre que el webcasting és un servei a temps real. Actualment es calcula que en el món hi ha 52 milions d’oients de ràdios per Internet, fet que demostra que és un servei utilitzat àmpliament per la població mundial i que es troba consolidat a dins de l’oferta de serveis IP a temps real.
Com es dissenya i es configura una ràdio IP? Aquesta és la principal qüestió d’aquests exercicis. Treballant els propers exercicis es mostra com funciona el procés de disseny d’una ràdio IP. Al llarg del recorregut es treballen els conceptes clau d’una ràdio. Cada exercici consisteix en configurar un model de ràdio IP més o menys evolucionat. La sofisticació de les ràdios IP seguirà un curs ascendent a cada exercici, assolint, al final, un model de ràdio IP amb una funcionalitat que es vol equiparar a la d’una ràdio convencional.
Javier de la Rica Comunicaciones Multimedia 2. Ràdios IP. Visió general Les ràdios IP són emissores de ràdio que distribueixen el seu contingut a través de xarxes IP. La distribució del contingut es fa a través d’un servidor d’àudio i el seu funcionament es basa en la tècnica d’streaming. Normalment són fluxos que no són interactius pel receptor, ja que les ràdios IP emeten contínuament, a temps real i sense cap retroacció disponible.
Les ràdios IP estan formades pels següents components: ● Contingut: material a transmetre a través de la xarxa. El contingut pot ser fruit del directe o provenir d’un fitxer d’àudio.
● Font de servidor: component que s’encarrega de crear el flux d’àudio a partir dels continguts i d’entregar-lo al servidor.
● Servidor: és l’agent encarregat de distribuir els continguts que li proveeix la font a altres màquines.
Per a poder escoltar el contingut de la ràdio a través del servidor, l’oient de la ràdio IP haurà d’utilitzar un reproductor d’àudio que utilitzi descodificadors compatibles amb el flux del servidor.
Figura 1: Esquema d’una ràdio IP En general, les ràdios es basen en la tècnica d’streaming. L’streaming és la tècnica de reproducció d’un material audiovisual en temps real, sense la necessitat d’haver-se d’esperar per descarregar tota la informació per tal d’accedir al contingut que es desitja veure o escoltar. Aquesta tècnica es desenvolupa entre dues màquines: una s’anomena servidor i l’altra client. El client és la màquina que demana rebre la informació, mentre que el servidor és la màquina que facilita tal informació. En l’inici del procés el client demana la informació que desitja al servidor i, si no hi ha cap inconvenient, el servidor envia la informació demanada al client.
En aquest servei hi ha un element clau que s’anomena buffer. El buffer és una quantitat de memòria de reserva que s’omple en el client amb l’informació que li arriba del servidor.
Aquesta quantitat d’informació emmagatzemada permet al client aïllar la reproducció del contingut de la variabilitat en la velocitat de recepció de la informació des la xarxa.
Javier de la Rica Comunicaciones Multimedia 2.1 Protocols usats en l’streaming 2.1.1 Protocols de transport A nivell de transport, servidor i client es poden enviar les dades seguint diferents protocols.
La tria d’un o altre protocol dependrà de les prestacions que es vulgui adjudicar al sistema d’streaming. En streaming hi ha dos conceptes a tenir en compte: la pèrdua de paquets i la latència. El sistema d’streaming ideal serà aquell que sigui més proper a una latència zero i una nul·la pèrdua de paquets.
Usar UDP, tot i ser un protocol que abaixa la latència, suposa exposar-se a pèrdues irrevocables de paquets ja que no disposa de mecanismes de correcció d’errors.
Usant TCP s’aconsegueixen connexions robustes i que eviten les pèrdues de paquets entre servidor i client, tot usant els mecanismes que manquen a UDP. Aquestes prestacions però, s’aconsegueixen en perjudici de la latència, ja que en una situació de pèrdua de paquets, es produiran retransmissions entre el client i servidor, amb el conseqüent retard d’entrega dels paquets.
2.1.2 Protocols a nivell d’aplicació Un dels protocols més utilitzats en aplicacions que usen streaming és el Real-time Transport Protocol (RTP). Va ser concebut per transferències extrem a extrem en temps real de fluxos de dades. Permet la compensació del jitter (variació del retard dels paquets), la detecció de paquets desordenats i permet fer enviaments multicast. RTP és un estàndard que defineix un protocol de transferència de dades (RTP) i un protocol de control de la transferència de dades anomenat Real-time Transport Control Protocol (RTCP). Mentre RTP s’encarrega del transport de les dades entre servidor i client, RTCP treballa per aconseguir una Qualitat de Servei especificada (QoS) i una sincronització entre fluxos multimèdia. RTP és implementat en UDP en comptes de TCP, degut a què en UDP, al contrari que TCP, prima la baixa latència davant de la fiabilitat.
El Real Time Streaming Protocol (RTSP) és un protocol de control que s’usa per establir i mantenir sessions multimèdia entre dos extrems. RTSP conté unes seqüències de control per tal de comprovar l’estat de la connexió. RSTP pot ser usat en aplicacions que usen RTP.
A diferència de RTP, l’Hypertext Transport Protocol (HTTP) s’utilitzat per a la transferència de dades. No va ser concebut per ser utilitzat usant la tècnica d’streaming i per tant, no està optimitzat per aquesta tasca. Tot i així s’usa en molts casos, ja sigui sense modificar o modificat. Un exemple d’ús d’HTTP modificat es dona en el protocol utilitzat pels servidors Icecast. Es tracta d’un protocol que, per exemple, usa la funció GET pròpia d’HTTP i que alhora té una funció anomenada SOURCE de nova creació.
2.2 Servidors Hi ha un nombre important de programes per a configurar un servidor d’àudio. L’elecció, d’un programa o altre, dependrà dels protocols d’aplicació que es vulguin usar, del tipus de fluxos que es vulguin gestionar, de les fonts de servidor que es vulguin utilitzar, del preu del programari i del sistema operatiu de la màquina que farà córrer el servidor.
Javier de la Rica Comunicaciones Multimedia A continuació hi ha una representació dels programes per a servidors de música presents al mercat: 2.2.1 ShoutCast És un programa de servidor que només gestiona fluxos d’àudio. Permet gestionar fluxos MPEG1-Layer 3 (mp3) i HE-AAC (MPEG4). Utilitza el protocol ICY. A finals de l’any 2010 hi havia 30000 ràdios IP que l’usaven com a servidor. És un programa gratuït i compatible amb tots els sistemes operatius.
2.2.2 Icecast Gestiona tan fluxos d’àudio com de vídeo: fluxos ogg (vorbis i theora), MPEG1-Layer 3 (mp3), MPEG2 (AAC), NSV (NullSoft Video). Utilitza el protocol ICY i un protocol HTTP modificat propi. És un software gratuït i compatible amb tots els sistemes operatius exceptuant Mac.
2.2.3 Wowza Media Server Programa servidor propietari ($65/mes) que permet distribuir àudio i vídeo, en directe i sota demanda, i aplicacions enriquides d’Internet. Pel què fa a protocols, utilitza RTSP/RTP i pot utilitzar ICY o HTTP Live Streaming Protocol per comunicar-se amb servidors Icecast i Shoutcast. Permet ser executat en múltiples plataformes i dispositius i els seus fluxos poden ser reproduïts per múltiples programes.
2.2.4 Ampache Proxy Servei i aplicació que facil·lita la distribució local dels continguts d’una radio.
Consulteu: http://ampache.org 2.3 Fonts de servidor Les fonts de servidor han de ser escollides segons el tipus de servidor que alimenten i segons els tipus de fluxos que el servidor pot distribuir.
A continuació hi ha una mostra de fonts de servidor presents al mercat: 2.3.1 Ices És la font de servidor que forma part del projecte Icecast (codi lliure i gratuït). Té dues variants: una usa fluxos ogg vorbis i l’altra utilitza fluxos MPEG1-Layer 3 i pot alimentar servidors ShoutCast i Icecast.
2.3.2 Darkice És una font de servidor per servidors Icecast, Shoutcast i Darwin. Pot generar fluxos MPEG1-Layer 3, MPEG2 (AAC) i MPEG4 (HE-AAC). És un programa gratuït i de codi lliure.
2.3.3 Liquidsoap Llenguatge i intèrpret que permeten generar fluxos ogg i MPEG1-Layer 3. Molt versàtil, permet fer mescles d’àudio i diverses funcions de processat. Pot generar fluxos MPEG1Layer 3 i ogg vorbis per alimentar servidors Icecast.
Javier de la Rica Comunicaciones Multimedia 2.3.4 Mixxx És una font de servidor per servidors múltiples que amb entorn gràfic que té moltes funcionalitats. Consulteu: https://www.mixxx.org/features/ 3. El servidor d’streaming Icecast L’Icecast és un programa (de codi lliure) per a servidors dedicats a la distribució de continguts multimèdia. Forma part del projecte Icecast de la fundació Xiph.org per a la generació d’eines per l’streaming lliure de continguts multimèdia. Un servidor que utilitza l’Icecast permet distribuir fluxos mp3, ogg vorbis, AAC, ogg speex, ogg flac, ogg theora o NSV. Per tant, pot distribuir tant àudio com vídeo.
Figura 2: Pàgina d’administració de l’Icecast 3.1 Funcionament L’Icecast, al ser només un servidor, necessita rebre el flux multimèdia provinent d’una font de servidor per cobrir la demanda de continguts dels clients. Pel correcte funcionament de l’Icecast, s’ha de configurar adequadament el fitxer icecast.xml o qualsevol altre fitxer de configuració en format *.xml.
Pel què fa a protocols, l’Icecast usa un protocol HTTP modificat per a la distribució de fluxos OGG. Aquest protocol l’han de saber interpretar les fonts de servidor que alimentin qualsevol servidor Icecast. A més, el servidor Icecast entén el protocol ICY. Aquest protocol és utilitzat a l’hora de distribuir fluxos NSV (NullSoft Video) i pels fluxos provinents de servidors ShoutCast.
3.2 Fitxer de configuració El fitxer de configuració icecast.xml es troba a la carpeta /etc/icecast2 del sistema de fitxers del servidor. Partint de la versió creada amb la instal·lació, es faran certs retocs segons convingui. Mitjançant aquest fitxer, l’administrador del servidor pot ajustar els següents paràmetres: ● Límits: Valors màxims de paràmetres de configuració Javier de la Rica Comunicaciones Multimedia ● Identificació i autenticació per l’accés al servidor Icecast ● Altres opcions del servidor 3.2.1 Límits Entre les etiquetes <limits>...</limits> l’administrador decideix: ● El nombre màxim de clients que pot suportar el servidor <clients>.
● El nombre de fonts del servidor <sources>.
● La mida de la cua de retransmissió <queue> en bytes.
● El temps en segons d’espera fins que es dóna la connexió per perduda per part d’una font o d’un client <source-timeout> i <client-timeout> ● La mida del burst1 <burst-size> i <burst-on-connect>.
3.2.2 Identificació Entre les etiquetes <authentication>...</authentication> hi ha els ajustos d’identificació i de seguretat: ● Les fonts (programes que alimenten al servidor) han de fer servir una contrasenya per poder connectar-se al servidor <source-password>.
● Els servidors esclaus tenen una identificació <relay-user> i una contrasenya <relay-password> per poder-se connectar al servidor mestre.
● L’administrador del servidor està identificat per l’usuari <admin-user> i la seva contrasenya <admin-password>.
3.2.3 Altres opcions del servidor ● L’adreça IP del servidor és ajustada des de l’etiqueta <hostname>.
● El port d’escolta del servidor es troba a dins de les etiquetes <listen-socket> i entre les etiquetes <port>.
● El servidor pot ser configurat com a esclau, obtenint tots els fluxos d’un servidor.
master (<master-server>, <master-server-port>, <master-server-password> i <master-update-password> ), o bé només captant-ne un de concret (<relay>...</relay>).
● El nom del punt de muntatge pot venir donat per la font del servidor (per defecte) o bé pot ser especificat pel servidor a la secció <mount>...</mount>.
● A la secció mount també es poden definir accions a fer quan un usuari es connecta o es desconnecta al servidor (<on-connect>, <intro>, <on-disconnect> etc.), canviar contrasenyes per accedir als fluxos (<username>, <password>) i programar canvis de flux quan un punt de muntatge cau (<fallback>).
● A les etiquetes que estan entre les etiquetes (<path>...</path>) hi ha especificades les rutes dels fitxers de registre i de funcionament del servidor.
● Entre les etiquetes (<security>...</security>) es pot fixar quin usuari pot utilitzar el servidor.
El següent text correspon a un exemple del fitxer /etc/icecast/icecast2.xml: Javier de la Rica Comunicaciones Multimedia <icecast> <limits> <clients>100</clients> <sources>2</sources> <threadpool>5</threadpool> <queue-size>10000</queue-size> <client-timeout>30</client-timeout> <header-timeout>15</header-timeout> <source-timeout>10</source-timeout> <burst-on-connect>1</burst-on-connect> <burst-size>1000</burst-size> </limits> <authentication> <source-password>xxxx</source-password> <relay-password>xxxx</relay-password> <admin-user>admin</admin-user> <admin-password>xxxx</admin-password> </authentication> <!-- This is the hostname other people will use to connect to your server.
It affects mainly the urls generated by Icecast for playlists and yp listings. --> <hostname>localhost</hostname> <listen-socket> <port>8000</port> </listen-socket> ...
</icecast> 4. Intèrpret i llenguatge Liquidsoap El Liquidsoap és un llenguatge de programació d’àudio pensat per crear fluxos d’àudio i vídeo per alimentar servidors Icecast creat per The Savonet Team. Pot funcionar, com altres eines que tenen la mateixa funció, a partir d’ordres que es passen per consola o utilitzant scripts i passant-los a un intèrpret.
Pel què fa a funcionalitats, és de les fonts de servidor més completes del mercat: permet barreja de recursos, canvis de recursos, amplificació del so, downsampling etc. A més, incorpora un servidor telnet per tal que l’administrador de la font pugui interactuar amb ella mentre funciona, sense la necessitat de parar-la i modificar l’script que usa.
Com es representa a la figura 3, s’ha de generar un /script/ en format *.liq*, que contingui els fluxos i les funcions que els combinen i modifiquen.
Figura 3: Esquema de funcionament de la font amb liquidsoap alimentant el servidor Icecast Javier de la Rica Comunicaciones Multimedia Qualsevol script escrit per Liquidsoap, ha de començar amb el següent shebang, com mostra l’exemple següent: #!/usr/bin/liquidsoap set("log.file",false) set("log.stdout",true) def transition(j,a,b) add(normalize=false, [ fade.initial(b), sequence(merge=true, [ blank(duration=0.2),j,fallback([])]),fade.final(a)]) end musica= input.http("http://91.250.76.19:80/wunschradio.mp3") veu= mksafe(in()) radio= add(weights= [2,1],[veu,musica]) radio=mksafe(radio) output.icecast.vorbis(host= "10.34.1.254", port= 8000, mount= "/radio5.ogg", name= "RadioCM", description="Freemusicforfreepeople", genre= "Mix", restart= true, password="xxxx",radio) Funcionament Usant Liquidsoap és molt senzill expressar una font que utilitza diversos recursos alhora per tal de fabricar un flux pel servidor. Aquesta senzillesa, juntament amb un conjunt de funcions molt útils per tractar els fluxos, fan del llenguatge Liquidsoap una eina molt poderosa per l’streaming d’àudio.
En Liquidsoap, els fluxos provinents dels recursos s’expressen en variables que no estan tipificades. A més, el flux resultant és robust als errors degut al control de fal·libilitat al que s’ha de sotmetre abans de ser transmès. El control de fal·libilitat consisteix en comprovar que el fitxer i el contingut del dispositiu que es vol transmetre existeix i es troba accessible per part de l’intèrpret.
Funcions interessants del Liquidsoap ● var=playlist(“ruta-nom”): crea un flux d’àudio a partir d’una llista de reproducció i el guarda en una variable anomenada var. El format de la llista de reproducció pot ser en format .pls o en text pla (.txt).
● var=single(“ruta/nom”): crea un flux d’àudio a partir d’una cançó i el guarda en una variable anomenada var. El flux és una reproducció infinita de la cançó.
● var=once(“ruta/nom”): crea un flux d’àudio a partir d’una cançó i el guarda en una variable anomenada var. El flux és una sola reproducció de la cançó.
● var=in(): crea un flux d’àudio a partir del dispositiu per defecte d’entrada de so i el guarda en una variable anomenada var.
● var=rotate(weights=[1,X],[ flux1, flux2 ]): genera un flux que compagina cançons de dos fluxos donats i el guarda en una variable anomenada var. En aquest exemple, per cada cançó del flux1, reproduiria X cançons del flux2.
Javier de la Rica Comunicaciones Multimedia ● var=add([flux1, flux2]): genera un flux a partir de la barreja 50%−50% de dos fluxos donats i el desa en una variable anomenada var.
● output.icecast.vorbis(host = "X.X.X.X", port = XXXX, mount = "/mountpoint.ogg", name = “radio”, description = “música lliure”, genre = “mix”, restart = true, password = "xxxx", radio): aquesta funció, envia el flux “radio” a un servidor Icecast que s’executa en el port XXXX de l’adreça X.X.X.X i té com a contrasenya “xxxx”. El punt de muntatge on s’establirà el flux és “/mountpoint.ogg” i intentarà connectar-se tantes vegades com pugui al servidor.
Aquest llenguatge també permet la inclusió d’un servidor telnet a la font. El servidor, el qual pot rebre ordres per part de l’administrador de la font, serveix per controlar la font en tot moment sense haver de parar el bombeig i modificar l’script de la font.
Exemples Un script escrit en Liquidsoap que sigui de la següent manera: #! /usr/bin/liquidsoap set("server.telnet",true) flux = playlist.safe("/etc/liquidsoap/cancons.pls") output.icecast.vorbis(host = "10.34.0.254", port = 8000, mount = "/radio.ogg", \ name = "Radio", description = "Musica 24h", genre = "Mix", password = "xxxx", flux) Crea un flux d’àudio a partir de la llista de reproducció cancons.pls i l’envia al port 8000 d’un servidor Icecast a 10.34.0.254. El flux inclou metadades pel nom, per una descripció i pel gènere. El punt de muntatge és /radio.ogg i s’habilita el servidor telnet a la font.
La funció output.icecast.vorbis ha de transmetre sempre un flux infal·lible. Un flux infal·lible és aquell que, abans de ser transmès, s’ha comprovat que conté la informació que ha de dur. Per exemple, si un flux d’àudio prové d’una llista de reproducció present a un directori, es comprova que la música que es necessita per reproduir a la llista és present a la ruta especificada.
Per verificar emetre un flux infal·lible es pot fer: ● Fer servir la funció mksafe: var = mksafe(var).
● Usar una funció playlist.safe playlist.safe(“ruta/nom.pls”).
en lloc de la funció playlist: Si es produeix un error és degut a que la llista de reproducció que s’envia no es correcta.
Per tan, el Liquidsoap decideix no emetre’l. Per poder fer un flux fal·lible es força en la instrucció output.icecast.vorbis a transmetre un flux que pot ser fal·lible. S’introdueix el paràmetre fal·lible i se li dóna el valor cert: icecast.output.vorbis(, , , fallible = true, , ,).
El mètode anterior genera un silenci quan no es pot reproduir els arxius especificats.
Un script escrit en Liquidsoap que sigui de la següent manera: #! /usr/bin/liquidsoap set("server.telnet",true) cancons = playlist.safe("/etc/liquidsoap/cancons.pls") jingles = playlist.safe("/etc/liquidsoap/jingles.pls") flux = rotate(weights=[4,1],[cancons,jingles]) output.icecast.vorbis(host = "10.34.0.254", port = 8000, mount = "/radio.ogg", \ name = "Radio", description = "Musica 24h", genre = "Mix", password = "xxxx", flux) Javier de la Rica Comunicaciones Multimedia Envia un flux d’àudio al mateix servidor que en el cas anterior, però aquest flux és el resultat de combinar una llista de reproducció anomenada cançons i una llista de jingles que s’anomena jingles. Al flux hi haurà quatre vegades més cançons pertanyents a la llista de reproducció cançons que no pas cançons pertanyents a la llista de reproducció jingles. La funció rotate és la que permet combinar cançons de diverses llistes de reproducció.
Com es pot observar en els exemples donats, la compactació de les ordres que necessita l’intèrpret de liquidosap es contraposa amb la longitud d’un fitxer de configuració d’una font Ices. A continuació, s’adjunta una relació de funcions i utilitats en Liquidsoap.
Funció var = playlist(“playlist.pls”) Descripció var conté un flux a partir d’una llista de reproducció var = single(“song.ogg”) var conté un flux (infinit) a partir d’una cançó var = once(“song.ogg”) var conté un flux (es reprodueix un cop) a partir d’una cançó var = in() var = add([flux1,flux2]) var conté un flux a partir del so provinent del dispositiu d’entrada de so per defecte var és la mescla 50%-50% de dos fluxos var = fallback([flux1,flux2]) var és el primer flux que està disponible quan l’altre falla output.icecast.vorbis(flux1...) Envia el flux flux1 al servidor Icecast Finalment s’ofereix un exemple complet de script Liquidsoap: #! /usr/bin/liquidsoap set("log.file",false) set("log.stdout",true) def transition(j,a,b) add(normalize=false, [ fade.initial(b), sequence(merge=true, [blank(duration=0.2),j,fallback([])]), fade.final(a) ]) end musica = input.http("http://streaming105.radiocat.net:80") jingle = single("./liquidsoap/jingles/radiomfs.ogg") hora = single("./liquidsoap/jingles/senyalshoraris.ogg") veu = mksafe(in()) radio = add(weights = [2,1],[veu,musica]) radio = mksafe(radio) veu = mksafe(veu) flux = fallback(track_sensitive=false, transitions = [transition(jingle)], [ strip_blank(threshold=-20.,length=10.,veu), radio ]) flux = add([flux,switch([ ({30m0s or 00m0s} , hora) ])]) flux = mksafe(flux) output.icecast.vorbis(host = "10.34.1.254", port = 8000, mount = "/radio6.ogg", name = "Radio MFS", Javier de la Rica Comunicaciones Multimedia description = "Free music for free people", genre = "Mix", restart = true, password = "xxxx", flux) 5. Eines ● Simctl ● Escenari RadioNet ● Icecast ● Mozilla Firefox ● Wireshark ● Editor vi o pico ● RadioTray ● ffmpeg ● mplayer ● vlc 6. Estudi previ A. Explica la diferència entre Webcast i Podcast. Dóna alguns exemples per cada cas.
Webcast y Podcast son dos métodos distintos de distribución de contenidos a un gran número de destinatarios mediante Internet.
Por un lado, un Webcast es una emisión similar a un programa de radio diseñado para ser transmitido por Internet mediante streaming para emitir en directo desde una estación central sin permitir grabar los contenidos.
Por otra parte, un Podcast es un archivo de audio gratuito que se puede descargar y oír.
Por tanto, el servicio de Webcasting ofrece contenido en directo emitido por aire a tiempo real, mientras que el servicio de Podcasting es un sistema de audio sobre demanda.
B. Descriu breument els formats definits per llistes de reproducció: o pls (https://es.wikipedia.org/wiki/PLS) PLS es un formato de archivo informático que almacena listas de reproducción multimedia pudiendo almacenar la información sobre el título de la canción y la longitud.
o m3u (https://es.wikipedia.org/wiki/M3U) M3U es un formato de archivo que almacena listas de reproducción de medios.
Javier de la Rica Comunicaciones Multimedia Aunque en un principio la creación y apertura de M3U era únicamente soportada por Winamp, actualmente el formato es soportado por múltiples reproductores como iTunes, Windows Media Player, VLC, XMMS… Éste formato es un archivo de texto plano que especifica las ubicaciones de uno o más archivos multimedia. Cada entrada del archivo M3U indica la ruta de un archivo multimedia y debe tener un formato que indique la ubicación de cada archivo en ese ordenador o en internet.
o xspf (https://es.wikipedia.org/wiki/XML_Shareable_Playlist_Format) XSPF es el formato XML para compartir listas de reproducción. Una lista de reproducción XSPF es una secuencia de objetos a ser representados. Dichos objetos pueden ser audio, vídeo, texto, listas de reproducción, o cualquier otro tipo de medio. La función de una lista de reproducción es identificar los objetos y comunicar su orden.
o wpl (https://en.wikipedia.org/wiki/Windows_Media_Player_Playlist) WPL es un formato de archivo que almacena listas de reproducción multimedia reproducible mediante Windows Media Player. Se puede utilizar para crear listas de reproducción dinámicas. Se almacena una lista de referencias a los archivos reales, pero no los propios archivos. Los elementos de archivo WPL se pueden utilizar en Windows Media Player 9 o superior.
C. Genera una llista de reproducció en qualsevol dels formats anteriors i, fent servir un programari de traducció (i.e. http://tvtvtv.ru/tools/plc_eng.php ), torna a codificar la llista en la resta de formats.
D. Explica perquè es fan servir el formats RSS (Really Simple Syndication) i Atom Syndication Format. Dóna un exemple senzill codificat amb cada format.
RSS se trata de un formato XML para indicar o compartir contenido en la web. Se utiliza para difundir información actualizada normalmente a usuarios suscritos a la fuente de contenidos. Dicho formato permite distribuir contenidos sin la necesidad de un navegador, utilizando un programa diseñado para leer dichos contenidos RSS como puede ser, por ejemplo, Internet Explorer. Aun así, es posible utilizar el mismo navegador para ver los contenidos RSS. Las últimas versiones de los principales navegadores permiten leer los RSS sin necesidad de un programa adicional.
Dicho formato forma parte de la familia de los XML, desenvolupado especialmente para todo tipo de sitios que se actualicen con frecuencia por medio del cual se puede compartir información y usarla en otras webs y programas, conocido como radiodifusión o sindicación web.
Javier de la Rica Comunicaciones Multimedia Figura 1. Ejemplo básico del formato RSS 2.0 Figura 2. Ejemplo básico propiedades del canal en RSS 2.0 El formato Atom hace referencia a dos estándar relacionados. El formato de radiodifusión Atom, se trata de un fichero en formato XML utilizado para la radiodifusión web. El protocolo de publicación Atom (APP) se trata de un protocolo basado en HTTP para crear y/o actualizar recursos en web.
Las fuentes permiten que los programas busquen actualizaciones de los contenidos publicados en un sitio web en concreto. Para crear uno, el propietario de una web puede utilizar un programa especializado como un sistema de gestión de contenido que publica una lista de artículos recientes en un formato estándar. La fuente web puede ser descargada por sitios web que radiodifunden el contenido mediante dicha fuente, o por un agregador que permite que los lectores en Internet se suscriban y vean los contenidos de la fuente web.
Javier de la Rica Comunicaciones Multimedia 7. Escenari L’escenari radionet representa una topologia senzilla per modelar el funcionament d’un servei de ràdio per Internet. Consta de dues màquines virtuals configurades com servidors i dos més com a font del servidor. La xarxa Net1 connecta les dos fonts amb el servidor server1 amb la qual cosa el servidor pot rebre emissions directament des d’ambdós elements simultàniament. La font source2 també pot alimentar directament el servidor server2 per la xarxa Net3. Els servidors estan directament enllaçats per la xarxa Net2 el que ens permetrà interconnectar-los per redistribuir els continguts d’un en l’altre.
La màquina host es connecta a la xarxa virtual utilitzant tres interfícies (tap0, tap1, i tap2).
La interfície tap0 la farem servir per que el host faci les funcions de client del servei de radio i puguem sentir les emissions. Les altres interfícies del host les farem servir per analitzar el tràfic intercanviat entre les aplicacions de les màquines virtuals i conèixer el detalls dels protocols que es fan servir.
Figura 4: Esquema de l’escenari RadioNet Javier de la Rica Comunicaciones Multimedia 8. Exercici 1 Aquest exercici consisteix en la correcta configuració d’una ràdio IP que reprodueix una llista de reproducció. Es parteix d’un escenari on s’han de configurar cadascun dels elements que formen part de la ràdio IP i aconseguir que la ràdio funcioni de manera correcta. Al final de l’exercici es podrà sentir el fil musical.
8.1 Objectius Es pretén que un cop acabat l’exercici s’hagin assimilat els següents conceptes: ● Servidor: entendre el funcionament i la configuració d’un servidor Icecast.
● Font de servidor: entendre el concepte d’una font de servidor Liquidsoap.
● Fitxers de registre: habituar-se a consultar els missatges d’error del programari i extreure’n conclusions útils.
● Protocol Icecast: entendre com els servidors Icecast s’associen amb les seves fonts.
8.2 Esquema En aquest exercici farem servir part del elements de l’escenari radionet. Els components per aquest exercici són dues màquines virtuals configurades, una com a servidor server1 i l’altra com a font del servidor source1.
Tal i com mostra la figura 5, l’escenari reduït té dues xarxes: Net1, que enllaça el host i el servidor, i Net0, que enllaça a les dues màquines virtuals amb el host. L’enllaç addicional tap1 entre la màquina host i les màquines virtuals es deu a la voluntat de capturar el tràfic de paquets entre les tres màquines. Amb aquesta configuració, tindrem les funcions de servidor i de font de servidor virtualitzades, mentre que la màquina host s’encarregarà d’executar el client d’àudio per captar el corrent que distribuirà el servidor.
Figura 5: Esquema de l’escenari RadioNet Javier de la Rica Comunicaciones Multimedia 8.3 Desenvolupament 8.3.1 Inici de l’escenari Utilitzem l’script simctl per a virtualitzar el servidor i la seva font. L’script, basat en VNUML, s’encarrega de configurar les interfícies de xarxa de les màquines virtualitzades (VM) i les xarxes que les uneixen. Per iniciar l’escenari, passem com a argument el nom de l’escenari al simctl: telematic@telem:~$ simctl radionet start Total time elapsed: 76 seconds Un cop el simctl ha acabat la inicialització, podrem accedir a les màquines virtuals a través d’uns pseudo-terminals, usant l’etiqueta get del simctl. Per la font farem servir l’usuari virtusr que té per password virtusr i pel server l’usuari root que te per password xxxx.
telematic@telem:~$ simctl radionet get source1 0 source1 login: virtusr Password: Last login: Mon Mar 7 18:53:41 CET 2016 on tty0 Linux dellpo 2.6.18.1-bb2-xt-4m-2 #4 Wed Apr 6 01:13:04 CEST 2011 i686 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.
telematic@telem:~$ simctl radionet get server1 0 server1 login: root Password: Linux dellpo 2.6.18.1-bb2-xt-4m-2 #4 Wed Apr 6 01:13:04 CEST 2011 i686 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.
Javier de la Rica Comunicaciones Multimedia Aquests pseudo-terminals es poden tancar sense perill de perdre la informació. Es poden obtenir de nou els pseudo-terminals tornant a invocar l’ordre get.
L’escenari està configurat per poder tenir dos terminals per cada máquina virtual. Si és vol obtenir un segon terminal per cada cas es pot fer: telematic@telem:~$ simctl radionet get source1 1 telematic@telem:~$ simctl radionet get server1 1 A la banda del host, heu de configurar correctament les interfícies de xarxa tap0 i tap1 per poder dur a terme les comunicacions desitjades. Utilitzeu la comanda ping per enviar paquets des del host fins al servidor i la font per comprovar l’accés a les dues màquines.
telematic@telem:~$ ping -c 1 10.34.0.254 PING 10.34.0.254 (10.34.0.254) 56(84) bytes of data.
64 bytes from 10.34.0.254: icmp_req=1 ttl=64 time=2.80 ms --- 10.34.0.254 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 1ms rtt min/avg/max/mdev = 2.803/2.803/2.803/0.000 ms telematic@telem:~$ ping -c 1 10.34.1.2 PING 10.34.1.2 (10.34.1.2) 56(84) bytes of data.
64 bytes from 10.34.1.2: icmp_req=1 ttl=64 time=2.03 ms --- 10.34.1.2 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.032/2.032/2.032/0.000 ms 8.3.2 Configuració del programari de l’escenari Màquina source La font del servidor, source1, és una font que reprodueix una única cançó fent servir un script simple Liquidsoap. El fitxer de configuració de la font, radio-ambient.liq, i la pista de música del directori ambient els trobareu el home del usuari virtusr .
Identifiqueu els fitxers del directori: virtusr@source1:~$ ls –l Javier de la Rica Comunicaciones Multimedia virtusr@source1:~$ ls -l total 32 drwxr-xr-x 2 virtusr virtusr 4096 Mar 8 12:09 ambient drwxr-xr-x 2 virtusr virtusr 4096 Mar 8 12:09 folk drwxr-xr-x 2 virtusr virtusr 4096 Mar 8 12:09 mix -rwxr-xr-x 1 virtusr virtusr 407 Mar 8 12:09 playlist-folk.pls -rwxr-xr-x 1 virtusr virtusr 269 Mar 8 12:09 playlist-mix.pls -rwxr-xr-x 1 virtusr virtusr 300 Mar 8 12:09 radio-ambient.liq -rwxr-xr-x 1 virtusr virtusr 274 Mar 8 12:09 radio-folk.liq -rwxr-xr-x 1 virtusr virtusr 274 Mar 8 12:09 radio-mix.liq Observeu el contigut del directori ambient: virtusr@source1:~$ ls -l ambient virtusr@source1:~$ ls -l ambient total 6864 -rwxr-xr-x 1 virtusr virtusr 7012421 Jan 27 13:58 Silent-Heart-Track2.ogg Visualitzeu i analitzeu el contingut del fitxer de configuració: virtusr@source1:~$ more radio-ambient.liq virtusr@source1:~$ more radio-ambient.liq #! /usr/bin/liquidsoap set("log.file",false) set("log.stdout",true) musica = single("/home/virtusr/ambient/Silent-Heart-Track2.ogg") output.icecast.vorbis.cbr(bitrate = 48, host = "10.34.1.254", port = 8000, mount = "/RadioAmbient.ogg", restart = true, fallible = true, password = "xxxx", musi ca) Màquina server El servidor executa automàticament un script a l’inici que carrega el fitxer de configuració predeterminat. El fitxer de configuració icecast-server1.xml el podeu trobar el directori /etc/icecast2/.
Visualitzeu i analitzeu el contingut del fitxer de configuració: server1:~# less /etc/icecast2/icecast-server1.xml Javier de la Rica Comunicaciones Multimedia server1:~# less /etc/icecast2/icecast-server1.xml <icecast> <limits> <clients>100</clients> <sources>2</sources> <icecast> <limits> <clients>100</clients> <sources>2</sources> <threadpool>5</threadpool> <queue-size>524288</queue-size> <client-timeout>30</client-timeout> <header-timeout>15</header-timeout> <source-timeout>10</source-timeout> <!-- If enabled, this will provide a burst of data when a client first connects, thereby significantly reducing the startup time for listeners that do substantial buffering. However, it also significantly increases latency between the source client and listening client.
For low-latency setups, you might want to disable this. --> <burst-on-connect>1</burst-on-connect> <!-- same as burst-on-connect, but this allows for being more specific on how much to burst. Most people won't need to change from the default 64k. Applies to all mountpoints --> <burst-size>65535</burst-size> </limits> [...] ● ● ● ● ● Se puede observar en el fichero de configuración la siguiente información: Se pueden soportar un máximo de 100 clientes.
El contenido recibido proviene de dos fuentes.
El tamaño de la cola de retransmisión es de 524288 Bytes.
El tiempo en segundos de espera hasta que se da una conexión por perdida: I.
Por parte de un cliente: 30 segundos.
II.
Por parte del servidor: 10 segundos.
● Tamaño de burst: 65535 Bytes.
Nota: Per sortir pulsa Q Poseu en marxa el servidor Icecast: server1:~# icecast2 -c /etc/icecast2/icecast-server1.xml Javier de la Rica Comunicaciones Multimedia server1:~# icecast2 -c /etc/icecast2/icecast-server1.xml Changed groupid to 65534.
Changed userid to 65534.
El servidor distribueix el contingut des del port TCP 8000.
Verifiqueu, des del segon terminal del servidor, que està en marxa el procés: ● Veient si el procés s’està executant: server1:~# ps aux | grep icecast server1:~# ps aux | grep icecast nobody 1130 0.0 3.6 10024 2228 tty0 /etc/icecast2/icecast-server1.xml Sl+ 19:08 0:00 icecast2 -c root S+ 19:10 0:00 grep icecast 1142 0.0 0.8 1712 504 tty1 Comprobamos que el proceso se está ejecutando correctamente.
● Observant si el socket d’escolta en el port 8000 del servidor està actiu server1:~# netstat --tcp -an server1:~# netstat --tcp -an Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp6 0 0 :::8000 :::* LISTEN tcp6 0 0 :::80 :::* LISTEN tcp6 0 0 :::22 :::* LISTEN Podeu trobar els fitxers de registres d’access (icecast2-access.log) i error (icecast2error.log) de l’Icecast al directori /tmp: server1:~# ls -l /tmp Javier de la Rica Comunicaciones Multimedia server1:~# ls -l /tmp total 40 drwxr-xr-x 2 root root 4096 Mar 15 22:35 admin -rwxr-xr-x 1 root root 4303 Mar 15 22:35 icecast-server1-relay.xml -rwxr-xr-x 1 root root 6473 Mar 15 22:35 icecast-server1.xml -rwxr-xr-x 1 root root 6446 Mar 15 22:35 icecast-server2.xml -rw-r--r-- 1 nobody nogroup -rw-r--r-- 1 nobody nogroup 0 Mar 15 22:55 icecast2-access.log 302 Mar 15 22:55 icecast2-error.log -rw-r--r-- 1 nobody nogroup 0 Mar 15 22:55 icecast2-playlist.log drwxr-xr-x 2 root root 4096 Mar 15 22:35 relay drwxr-xr-x 2 root root 4096 Mar 15 22:35 web Un cop tenim el servidor Icecast en funcionament, iniciarem el bombeig manualment des de la màquina source.
Procedim a la posta en marxa del bombeig de la següent manera: virtusr@source1:~$./radio-ambient.liq Analitzeu les traces que surten a la consola de la màquina source1 i verifiqueu que verifiqueu que s’ha establit la connexió amb éxit.
virtusr@source1:~$ ./radio-ambient.liq 2016/03/07 19:12:22 >>> LOG START 2016/03/07 19:12:22 [protocols.external:3] Didn't find "ufetch" 2016/03/07 19:12:22 [protocols.external:3] Found "/usr/bin/wget" 2016/03/07 19:12:22 [main:3] Liquidsoap 0.9.2 2016/03/07 19:12:22 [lang:3] flac binary not found: flac decoder disabled.
2016/03/07 19:12:22 [lang:3] metaflac binary not found: flac metadata resolver disabled.
2016/03/07 19:12:22 [decoder:3] Decoder OGG chosen for "/home/virtusr/ambient/Silent-Heart-Track2.ogg".
2016/03/07 19:12:22 [single:3] "/home/virtusr/ambient/Silent-Heart-Track2.ogg" is static, resolving once for all… 2016/03/07 19:12:22 [threads:3] Created thread "generic queue #1".
2016/03/07 19:12:23 [threads:3] Created thread "root" (1 total).
2016/03/07 19:12:23 [root:3] Waking up active nodes… 2016/03/07 19:12:23 [src_5354:3] Prepared "/home/virtusr/ambient/Silent-Heart-Track2.ogg" (RID 0).
2016/03/07 19:12:23 [/RadioAmbient(dot)ogg:3] Connecting mount /RadioAmbient.ogg for Javier de la Rica Comunicaciones Multimedia source@10.34.1.254… 2016/03/07 19:12:23 [/RadioAmbient(dot)ogg:3] Connection setup was successful.
2016/03/07 19:12:23 [root:3] Broadcast starts up! 8.3.3 Accés al portal Icecast des del host Com s’ha dit, el servidor icecast s’executa en el port 8000 de la màquina server1, o sigui que la l’adreça URL concreta on podem accedir a l’Icecast en aquest escenari és: http://10.34.0.254:8000.
Si el sistema està funcionant correctament, visiteu la pàgina del servidor i obtindreu una plana web com la mostrada a la figura 6.
Figura 6: Servidor amb el flux d’àudio corresponent Mitjançant l’enllaç Administration de l’icecast2 podeu accedir amb usuari:admin i password:xxxx a la informació del servidor com es veu a a la figura 7. Analitzeu els paràmetres que es presenten i veieu la relació amb el fitxer de configuració del servidor Icecast.
Javier de la Rica Comunicaciones Multimedia Figura 7: Administració de l’Icecast per Web Finalment, utilitzeu el reproductor mplayer per captar el flux d’àudio que distribueix el servidor Icecast directament invocant-lo pel terminal del host: telematic@telem:~$ mplayer http://10.34.0.254:8000/RadioAmbient.ogg Nota: Per tancar el reproductor mplayer prem la tecla ’Q’ amb la finestra de l’aplicació activada.
A. Observa i comenta els missatges que ofereix el reproductor a la consola referents a la informació del flux multimèdia rebut.
El reprodutor ofrece la información presente en la siguiente figura: Playing http://10.34.0.254:8000/RadioAmbient.ogg.
Resolving 10.34.0.254 for AF_INET6...
Couldn't resolve name for AF_INET6: 10.34.0.254 Connecting to server 10.34.0.254[10.34.0.254]: 8000...
Name : /RadioAmbient.ogg Genre : Misc Website: http://savonet.sf.net Public : yes Bitrate: 48kbit/s Cache size set to 320 KBytes Javier de la Rica Comunicaciones Multimedia Cache fill: 7.50% (24576 bytes) libavformat file format detected.
[ogg @ 0x9484310]Estimating duration from bitrate, this may be inaccurate [lavf] stream 0: audio (vorbis), -aid 0, Haleakala Sunset ========================================================================== Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, s16le, 48.0 kbit/3.40% (ratio: 6000->176400) Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis) ========================================================================== AO: [pulse] 44100Hz 2ch s16le (2 bytes per sample) En concreto cabe destacar la velocidad de bit, que es de 48kbit/s B. Indica la grandària del playout-buffer que fa servir el receptor mplayer.
El tamaño del playout-buffer se indica en el Cache size. En este caso está fijado a 320KBytes como se puede observar.
Cache size set to 320 KBytes C. Per què serveix aquest playout-buffer? El playout-buffer sirve para almacenar los datos recibidos y no encontrar cortes, ya que la retransmisión de la radio IP se hace mediante Streaming. La radio empieza a reproducir la canción una vez el playout-buffer está al 7.5% lleno, facor que es posible cambiar al porcentaje que se quiera con el objetivo de una reproducción sin paradas.
Dicho buffer ayuda a compensar en recepción los retardos producidos por la red con el objetivo de que la reproducción del contenido sea de una forma contínua, a una velocidad constante e interrumpida.
D. Quin és el màxim retard temporal que pot introduir aquest playout-buffer? El máximo retardo temporal introducible por dicho buffer es el tiempo que tarda un paquete en pasar por el buffer desde la última posición hasta el reproductor de manera que no se interrumpa dicha reproducción. En este caso se calcula mediante la velocidad de bit y la capacidad del buffer de la siguiente manera: (320𝑘𝐵𝑦𝑡𝑒𝑠 · 8𝑏𝑖𝑡𝑠)/(48𝑘𝑏𝑖𝑡𝑠/𝑠𝑒𝑔)= 160/3 seg = 53,333seg Javier de la Rica Comunicaciones Multimedia 8.3.4 Anàlisi del protocol Font-Servidor: Protocol Icecast I L’Icecast es comunica amb les fonts o amb altres servidors usant un protocol molt senzill derivat d’HTTP. En versions anteriors, l’Icecast emprava els protocols icy o xaudiocast. A la versió 2.3.2, la versió utilitzada en aquests exercicis, també admet el protocol ICY per comunicar-se amb fonts o servidors ShoutCast.
En l’inici de l’associació entre una font i un servidor Icecast, es produeix un handshake mitjançant el qual la font transmet les metadades del seu flux i la clau d’autorització al servidor i, el servidor, aprova o no l’associació amb la font segons les dades transmeses.
Per analitzar la connexió entre font i servidor preparem previament la captura de paquets amb el programari wireshark sobre la xarxa que els connecta, i reiniciem la posta en marxa del bombeig de la font. Donat que el bombeig funciona en foreground tan sols es necessari generar la combinació de tecles Ctrl+C per aturar-lo.
Un cop preparat el Wireshark i amb el servidor Icecast en marxa, tornem a posar en marxa la bomba d’audio: virtusr@source1:~$./radio-ambient.liq Amb el reiniciat del bombeig, verifiqueu que apareix el flux d’àudio a la pàgina del servidor Icecast: telematic@telem:~$ firefox http://10.34.0.254:8000 Utilitzeu el vlc per captar el flux que distribueix el servidor Icecast: telematic@telem:~$ vlc http://10.34.0.254:8000/RadioAmbient.ogg Si tot està ben configurat, heu de capturar el flux de dades des de la font cap al servidor amb el Wireshark.
Passats 60 segons podeu aturar la captura i fer l’anàlisi.
Analitzant la captura realitzada pel wireshark: A. Expliqueu amb el resultat presentat per l’anàlisi Analize → Follow TCP Stream els tres missatges intercanviats. En particular, l’origen i destí de cada missatges i el seu contingut.
Se pueden observar claramente dichos tres mensajes. El primer mensaje proviene de la fuente, que pide permiso para enviar datos al host. El siguiente mensaje corresponde al host, dando permiso al servidor, y finalmente el último mensaje es la transmisión de datos completa.
B. Identifiqueu quina màquina fa les funcions de client TCP i quina les funcions de servidor TCP.
En este caso la máquina source1 hace la función de cliente TCP, mientras la máquina server1 hace la función de servidor TCP.
Javier de la Rica Comunicaciones Multimedia C. Identifiqueu les adreces IP i els ports TCP del client i del servidor.
La dirección IP del cliente TCP es 10.34.1.2/24 en el puerto 8000 La dirección IP del servidor TCP es 10.34.1.254/24 en el puerto 8000 D. Fen servir els filtres del menú statistics → IOgraph del wireshark, seleccioneu en gràfiques diferents els paquets TCP que van des de la font d’audio cap al servidor d’audio (tcp.dstport == 8000) i en sentit contrari (tcp.srcport == 8000) com es mostra a la figura 8. Analitzeu el flux de bits per cada sentit i expliqueu la asimetria dels valors.
El gráfico representado representa el flujo de datos enviados entre la fuente y el servidor a través del puerto 8000. Por una parte en color verde se observa el flujo de datos correspondiente al que va de la fuente al servidor, en otras palabras, los datos de la canción reproducida, mientras que por otro lado, en rojo se observa el flujo que va del servidor a la fuente, correspondiente a los reconocimientos en recepción.
La asimetria de los valores es debida a que la cantidad de datos emitida por la fuente esmucho mayor a la cantidad de datos emitida por el servidor, ya que los reconocimientos no conllevan una cantidad tan elevada de información.
Paralelamente se observa que la transmisión no es constante, ya que en el gráfico se ven unos picos . Ésto es debido a que la transmisión se realiza mediante tramas, dejando así al emisor (cliente) en espera de los reconocimientos de las tramas anteriores antes de seguir transmitiendo.
E. Seleccionant l’opció statistics → summary del menú del wireshark, esbrineu la taxa mitja de transmissió (en kbps) de la cançó actual.
La tasa media de transmisión de la canción es de 5820.157Bytes/seg · 8 bits = 46.561256kbits/seg.
F. Compareu aquesta taxa amb la taxa de codificació de la cançó reproduïda, utilitzant la comanda ogginfo sobre el fitxer en format ogg de la cançó. Per què son diferents?. Quina té més qualitat? virtusr@source1:~$ ogginfo ambient/Silent-Heart-Track2.ogg Javier de la Rica Comunicaciones Multimedia virtusr@source1:~$ ogginfo ambient/Silent-Heart-Track2.ogg Processing file "ambient/Silent-Heart-Track2.ogg"...
New logical stream (#1, serial: 45e79cab): type vorbis Vorbis headers parsed for stream 1, information follows...
Version: 0 Vendor: Lavf56.15.102 Channels: 2 Rate: 44100 Nominal bitrate: 160.000000 kb/s Upper bitrate not set Lower bitrate not set User comments section follows...
encoder=Lavc56.13.100 libvorbis title=Haleakala Sunset artist=Karunesh album=Silent Heart TRACKNUMBER=7/7 TPA=1/1 encoded_by=iTunes v7.5 genre=New Age date=2001 Vorbis stream 1: Total data length: 7007876 bytes Playback length: 6m:07.725s Average bitrate: 152.458764 kb/s Logical stream 1 ended La canción está codificada a una velocidad de 152.458764kb/s, pero el sevidor la transmite a una velocidad de 46.561256kbits/seg.
La canción original tiene mayor calidad, pero dicha calidad es un precio a pagar con el objetivo de poder adaptarse mejor a la transmisión de la red.
Nota: Podreu accedir a les màquines virtuals mitjançant un segon pseudo-terminal, usant l’etiqueta get del simctl i demanant el terminal 1: telematic@telem:~$ simctl radionet get source1 1 Javier de la Rica Comunicaciones Multimedia Figura 8: IOgraph amb filtratge per port TCP 8.3.5 Anàlisi de l’access directe al Servidor de Radio Icecast des d’un client d’streaming Amb el servidor i la font correctament configurats, podem analitzar la interacció entre client i servidor Icecast.
Verifiqueu que apareix el flux d’àudio a la pàgina del servidor Icecast: telematic@telem:~$ firefox http://10.34.0.254:8000 Inicieu l’analitzador de paquets wireshark i analitzeu els paquets de la interfície que es troba a la xarxa 10.34.0.0/24.
Si tot està ben configurat, heu de capturar el flux de dades des del servidor cap al client amb el Wireshark quan utilitzeu el mplayer o ffplay per captar el flux que distribueix el servidor Icecast: telematic@telem:~$ mplayer http://10.34.0.254:8000/RadioAmbient.ogg Pasat 90 segons atureu la recepció de l’stream d’audio en el reproductor i atureu la captura amb el Wireshark.
Fent servir el Wireshark: A. Féu un seguiment de l’intercanvi d’informació entre el Client i el Servidor amb l’opció Follow TCP del Wireshark com es mostra a la figura 9 Javier de la Rica Comunicaciones Multimedia En el seguimiento se puede observar cómo el cliente, que en éste caso es el host (10.34.0.1/24) solicita la transmisión de datos de la radio /RadioAmbient.ogg marcado en rojo. A continuación el servidor, que en éste caso es la máquina server1 (10.34.0.254/24) acepta la conexión y envía directamente el flujo de datos hacia el host.
B. Analitzeu el flux de dades del servidor al client fent servir els filtres del menú statistics → IOgraph del wireshark. Seleccioneu en gràfiques diferents els paquets IP que van des del servidor d’àudio cap al client d’audio (ip.dst == 10.34.0.1) i en sentit contrari (ip.src == 10.34.0.1) com es mostra a la figura 10.
Figure 9: Opció Follow TCP de Wireshark Javier de la Rica Comunicaciones Multimedia Figure 10: IOGraph i Summary del flux Por una parte se puede observar, en color verde, la transmisión de datos de la canción del servidor server1 al cliente, que en éste caso es el host. Ésta transmisión se realiza mediante tramas de manera que si se pierde alguna de ellas se puede recuperar.
Torneu a fer una captura de 90 segons del flux d’àudio del servidor mitjançant el vlc: telematic@telem:~$ vlc http://10.34.0.254:8000/RadioAmbient.ogg Fent servir l’opció statistics → summary del menú del wireshark, esbrineu la taxa mitja de transmissió (en kbps) de la cançó actual.
Javier de la Rica Comunicaciones Multimedia Sense aturar el vlc ni el Wireshark: o Amb l’opció IOgraph feu servir els botons de pausa, play del VLC per veure el control del flux exercit pel TCP.
o Observeu en aquest experiment de pausa, play els paquets de reconeixement de finestre cero generats pel client VLC fent servir el Wireshark.
C. Responeu a les següents qüestions: 1. Per què s’atura el servidor?. S’atura també la font? Se detiene la transmisión del servidor de forma temporal, sin embargo no se detiene la transmisión de contenido originada por la fuente. Ésto es a causa de que puede haber más de un único cliente conectado redibiendo datos, así pues no se puede parar la fuente, ya que en caso contrario todos los clientes conectados dejarían de recibir datos.
Javier de la Rica Comunicaciones Multimedia 2. Què observarà l’usuari del servei quan es torna a reproduir desprès d’una llarga estona en pausa? La sensación del usuario dependerá de la duración de dicha pausa. Si se trata de una pausa breve en principio el usuario no tiene por qué observar ninguna alteración. Sin embargo, si dicha pausa es lo suficientemente larga, las tramas recibidas en el playour-buffer una vez reanudada la transmisión pueden no ser la continuación de las recibidas anteriormente. En éste caso el cliente puede percibir un salto en la reproducción de la canción, habiéndose perdido los datos correspondientes a la pausa realizada.
3. Si es connecta un segon client al servidor Icecast, en quant aumenta el tràfic de sortida del servidor?. Per exemple afegiu un altre client: telematic@telem:~$ ffplay http://10.34.0.254:8000/RadioAmbient.ogg Feu servir els botons de pausa, play del VLC o la tecla space en FFplay amb un dels clients per veure les variacions de la transmissió binaria del servidor als clients.
Finalitzeu la recepció dels clients de radio que esteu fent servir.
8.3.6 Anàlisi de l’access al servei Radio Icecast per metadades Un altre manera d’accedir al flux de radio es descarregant prèviament des del servidor Icecast un fitxer de metadades. Aquest fitxer conté tota la informació necessària per accedir i reproduir l’streaming d’un flux de radio.
Novament, amb el servidor i la font correctament configurats, podem analitzar la interacció entre navegador i servidor Icecast mitjançant el Wireshark.
Verifiqueu que apareix el flux d’àudio a la pàgina del servidor Icecast: telematic@telem:~$ firefox http://10.34.0.254:8000 A. Inicieu l’analitzador de paquets wireshark i analitzeu els paquets de la interfície que es troba a la xarxa 10.34.0.0/24.
B. Seleccioneu la descàrrega del fitxer M3U associat al flux RadioAmbient.ogg amb el botó de la dreta del punt de muntatge.
C. Poseu en marxa la reproducció senyalitzada per les metadades i passat 10 segons atureu la captura i reproducció.
D. Analitzant la captura amb el wireshark i fent servir l’opció Follow TCP del Wireshark responeu: Javier de la Rica Comunicaciones Multimedia A. Quin es el contingut del fitxer de metadades que descarrega el navegador ? El archivo descargado desde el navegador se trata de un archivo de texto en el que se especifican las ubicaciones de uno o más achivos multimedia.
B. Explica com es posa en marxa la reproducció del contingut d’àudio després de la descàrrega del fitxer de metadades Una vez las direcciones del contenido son obtenidas por el reproductor se realiza una conexión directa mediante el servidor para obtenerlas y reproducirlas después de la descodificación.
E. Torneu a fer una nova captura amb el wireshark i l’accés a l’stream RadioAmbient.ogg des del navegador fent servir, en aquest cas, amb el fitxer de metadades XSPF.
F. Poseu en marxa la reproducció senyalitzada per les metadades i passat 10 segons atureu la captura i reproducció.
G. Analitzant la captura amb el wireshark i fent servir l’opció Follow TCP del Wireshark responeu: A. Quin es el contingut del fitxer de metadades que descarrega el navegador ? El archivo de metadatos XSPF no contiene los archivos de audio, sino que únicamente contiene la lista de reproducción.
B. Quin tipus de sintaxi fan servir aquest tipus de fitxer ? El tipo de fichero XSPF utiliza una sintaxi XML.
Nota: Consulteu http://es.wikipedia.org/wiki/XML_Shareable_Playlist_Format H. Finalment, configureu l’aplicació RadioTray del host per conectar-se a la radio internet del Servidor Icecast amb la url: http://10.34.0.254:8000/RadioAmbient.ogg.m3u. Verifiqueu la reproducció des l’aplicació.
Javier de la Rica Comunicaciones Multimedia Figura 11: Menú RadioTray Figura 12: Nova Radio Internet en RadioTray Tanqueu l’escenari: telematic@telem:~$ simctl radionet stop Javier de la Rica Comunicaciones Multimedia 9. Exercici 2 En aquest segon exercici es configura una ràdio IP que disposa de dos canals temàtics: un canal dedicat a la música folk i l’altre dedicat a música de tots els gèneres. Assumint que s’han assimilat correctament els conceptes treballats al primer exercici, es treballa en un entorn on hi ha presents dos servidors i dues fonts. L’objectiu final serà aconseguir, de manera guiada, un servidor amb diversos canals temàtics (punts de muntatge), i per tant, aconseguir una ràdio IP amb diferents canals.
9.1 Objectius Durant el transcurs d’aquest exercici es treballaran els següents conceptes: ● Servidor: entendre el funcionament i la configuració d’un servidor Icecast amb múltiples fonts.
● Fitxers de registre: habituar-se a consultar els missatges d’error del programari i extreure’n conclusions útils.
● Relaying: entendre la subordinació d’un servidor Icecast envers un altre.
● Protocol Icecast: entendre com els servidors Icecast s’associen entre sí.
9.2 Esquema L’escenari radionet mostra una ràdio IP que disposa de dues fonts de servidor que poden alimentar de diverses maneres dos servidors. Seria un escenari útil per una ràdio IP que ofereix diversos canals alhora als seus clients. Un exemple, salvant les distàncies, seria el servei que ofereix la BBC radio via IP: la corporació britànica ofereix 11 canals temàtics més els serveis de broadcast internacional via Internet.
Tal i com podeu veure més avall, en l’escenari, la màquina host es connecta als servidors utilitzant dues interfícies (tap0 i tap1). Pel què fa a les fonts dels servidors i als servidors, source2 i server2 tenen la seva xarxa privada (Net3), mentre que source1 i server1 comparteixen la seva xarxa amb la font source2 (Net1). Aquesta última connexió permet que server1 i source2 estiguin connectades sense haver de dependre de source1.
Javier de la Rica Comunicaciones Multimedia Figura 13: Esquema de l’escenari radionet Màquina source1 És la font que subministrarà un flux de música de diversos gèneres.
Aquesta font subministrarà un flux de música mix al server1. Utilitzarà el fitxer Liquidsoap radio-mix.liq i la llista de reproducció playlist-mix.pls. Ambdós fitxers es troben al directori /home/virtusr/.
Màquina source2 Subministrarà el flux al server2 al llarg de l’exercici. Utilitzarà el fitxer Liquidsoap radio-folk.xml i la llista de reproducció playlist-folk.pls. Ambdós fitxers es troben al directori /home/virtusr/.
Màquina server1 Aquest servidor sempre rebrà el flux de música mix provinent de source1 i farà d’esclau de server2 en la configuració “master-slave” del final de l’exercici.
Acabarà essent el servidor des del qual accedirem a tots els punts de muntatge.
Màquina server2 La màquina server2 distribuirà el flux que rep de la màquina source2. En la segona part de l’exercici, entrega els seus punts de muntatge a server1 en una configuració “masterslave”.
9.3 Desenvolupament 9.3.1 Inici de l’escenari Per iniciar l’escenari radionet amb el simctl, executeu la següent comanda: telematic@telem:~$ simctl radionet start Al final de la càrrega podreu accedir a les quatre màquines virtuals usant l’etiqueta get del simctl: telematic@telem:~$ simctl radionet get source1 Javier de la Rica Comunicaciones Multimedia telematic@telem:~$ simctl radionet get source2 telematic@telem:~$ simctl radionet get server1 telematic@telem:~$ simctl radionet get server2 Recordeu que usant el simctl es creen les interfícies que connecten la màquina host amb les màquines guest, tot i que NO se les hi assigna cap adreça de xarxa.
Configureu les interfícies tap de la màquina host tal i com indica l’esquema. Comproveu que heu configurat correctament les interfícies de xarxa de la màquina host usant l’ordre ping per enviar paquets des de la màquina host fins als servidors.
telematic@telem:~$ ifconfig tap0 10.34.0.1/24 telematic@telem:~$ ifconfig tap1 10.34.1.1/24 telematic@telem:~$ ifconfig tap2 10.34.2.1/24 telematic@telem:~$ ping -c 1 10.34.0.254 PING 10.34.0.254 (10.34.0.254) 56(84) bytes of data.
64 bytes from 10.34.0.254: icmp_req=1 ttl=64 time=2.84 ms --- 10.34.0.254 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.841/2.841/2.841/0.000 ms telematic@telem:~$ ping -c 1 10.34.1.254 PING 10.34.1.254 (10.34.1.254) 56(84) bytes of data.
64 bytes from 10.34.1.254: icmp_req=1 ttl=64 time=2.45 ms --- 10.34.1.254 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.451/2.451/2.451/0.000 ms telematic@telem:~$ ping -c 1 10.34.2.2 PING 10.34.2.2 (10.34.2.2) 56(84) bytes of data.
64 bytes from 10.34.2.2: icmp_req=1 ttl=64 time=1.30 ms --- 10.34.2.2 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.309/1.309/1.309/0.000 ms Javier de la Rica Comunicaciones Multimedia 9.3.2 Configuració de les màquines virtuals Un cop configurades les interfícies de xarxa del host, s’han de verificar els fitxers de configuració de les fonts i dels servidors.
Consulteu el contingut dels fitxers de configuració Liquidsoap (radio-mix.liq i radiofolk.liq), respectivament, per les màquines source1 i source2.
Fixeu-vos especialment en la contrasenya per accedir al servidor, l’adreça IP i el port del servidor i el fitxer de playlist que hi ha configurat.
virtusr@source1:~$ more radio-mix.liq #! /usr/bin/liquidsoap set("log.file",false) set("log.stdout",true) musica = playlist.safe("/home/virtusr/playlist-mix.pls") output.icecast.vorbis(host = "10.34.1.254", port = 8000, mount = "/RadioMix.ogg" , restart = true, fallible = true, password = "xxxx", musica) virtusr@source2:~$ more radio-folk.liq #! /usr/bin/liquidsoap set("log.file",false) set("log.stdout",true) musica = playlist.safe("/home/virtusr/playlist-folk.pls") output.icecast.vorbis(host = "10.34.3.1", port = 8000, mount = "/RadioFolk.ogg", restart = true, fallible = true, password = "xxxx", musica) En els propers passos haureu d’editar fitxers de configuració. Si heu d’editar el fitxer de configuració de la font, assegureu-vos de què heu matat abans el procés de bombeig.
Per a modificar fitxers de les màquines virtuals, podeu usar la comanda joe, pico o vi.
Nota: Si canvieu la geometria del terminal s’ha d’informar a la màquina virtual amb la combinació de tecles: “Ctrl+A” i desprès “F” Javier de la Rica Comunicaciones Multimedia VMS:~# joe nom_de_fitxer_a_editar Per obtenir informació de les ordres que admet l’editor s’ha de prémer la combinació de tecles: “Ctrl+K” i desprès “H” L’editor pico és un editor petit que genera el menú d’opcions al peu del terminal. Només cal seguir l’ajuda per la edició del fitxer de text.
Figure 14: Edició amb pico També es pot fer servir la comanda vi que crida a un editor de consola. Al llarg del present i següents exercicis, haureu de tenir en compte la següent taula de funcionament de l’editor vi si el féu servir: Javier de la Rica Comunicaciones Multimedia Mode editor Tecla Insert Sortir del mode editor Tecla Esc Desar els canvis :w i tecla Enter, fora del mode editor Sortir del vi :q i tecla Enter, fora del mode editor Sortir del vi desant :wq i tecla Enter, fora del mode editor Un cop hàgiu validat l’escenari, heu d’iniciar els servidors Icecast sobre ambdós servers: server1:~# icecast2 -c /etc/icecast2/icecast-server1.xml server2:~# icecast2 -c /etc/icecast2/icecast-server2.xml 9.3.3 Una font per cada servidor Per la màquina source1 utilitzeu el fitxer de script radio-mix.liq, per la màquina source2, utilitzeu el fitxer radio-folk.liq, ambdós es troben al directori /home/virtusr/ del sistema de fitxers de les màquines virtuals. Inicieu el bombeig de les fonts.
virtusr@source1:~$./radio-mix.liq virtusr@source2:~$./radio-folk.liq Comproveu, utilitzant el Mozilla Firefox, si els fluxos de les fonts arriben als servidors.
Recordeu que els servidors s’executen al port 8000 de les màquines server1 i server2. Si els fluxos no arriben, analitzeu les traces de consola de les fonts per intentar esbrinar el problema i reconfigureu adequadament per solucionar el problema.
Desde el host no se puede observar el punto de conexión correspondiente a la dirección 10.34.3.1/34, así que accedemos al servidor server2 desde el punto correspondiente a la dirección 10.34.2.2/24 Recordeu que per veure els resultats dels canvis fets en els fitxers de configuració, cal reiniciar el programa servidor o el programa de la font del servidor, en cap cas és necessari reiniciar el simctl.
Javier de la Rica Comunicaciones Multimedia Figure 15: Flux mix al server1 Figure 16: Flux folk al server2 9.3.4 Relaying Els servidors Icecast poden ser alimentats per punts de muntatge d’altres servidors Icecast.
Aquest comportament s’anomena relaying. Amb aquest mètode, fluxos d’àudio presents en un servidor master, passen a ser enllaçats en un servidor slave. L’Icecast permet subministrar tots els punts de muntatge d’un servidor a un altre (tècnica “master-slave”), o bé només subministrar-ne un de concret (tècnica “single-broadcast”). En ambdues tècniques, només s’ha de configurar únicament el servidor que fa de relay o slave que actua com client del master. En cap cas s’ha de configurar el servidor que conté el flux que serà emmirallat.
Javier de la Rica Comunicaciones Multimedia master-slave Amb aquesta tècnica un servidor esclau (slave), integra tots els fluxos presents a un servidor subministrador (master). Per configurar un servidor slave, s’ha d’editar el fitxer de configuració del servidor configurant-ne correctament els següents camps: ● <master-server>: IP del servidor master, o subministrador.
● <master-server-port>: Port en el que s’executa el programa servidor. És el port pel qual es subministren els fluxos d’àudio.
● <master-update-interval>: és l’interval en segons usat pel servidor esclau per consultat si el servidor master ofereix nous fluxos d’àudio.
● <master-password>: contrasenya necessària per poder fer un emmirallat dels fluxos.
És la mateixa que utilitzaria una font per connectar-se al servidor master.
● <relays-on-demand>: si està activat (=1), el servidor esclau només absorbeix els fluxos d’àudio quan algun client vol sentir-los.
single-broadcast Utilitzant aquesta tècnica, el servidor slave capta tan sols un dels fluxos que emet el servidor master. Es configura el servidor slave perquè utilitzi aquesta tècnica en els següents camps: ● <relay>....</relay>: etiquetes entre les quals hi ha la configuració del servidor esclau.
● <server>: adreça IP del server master.
● <port>: port on el servidor master executa l’Icecast.
● <mount>: punt de muntatge del flux a absorbir.
● <local-mount>: punt de muntatge que es vol assignar al flux absorbit.
● <username>: nom d’usuari del servidor master.
● <password>: contrasenya del servidor master.
● <on-demand>: si està activat (=1), el servidor esclau només absorbeix el flux quan algun client vol sentir-lo.
● <relay-shoutcast-metadata>: si està activat (=1) el servidor esclau tracta les metadades del flux provinent d’un servidor shoutCast.
La figura 17 mostra els dos servidors de l’escenari treballant en mode “master-slave”. Pareu atenció en quin d’ells és el master i quin d’ells és l’slave.
A continuació, configureu les màquines de l’escenari per tal d’obtenir la configuració “master-slave” tal i com mostra l’esquema. Un cop hàgiu fet els canvis necessaris al fitxer l’icecast-server1-relay.xml, heu de tornar a posar en marxa el servidor esclau: server1:~# icecast2 -c /etc/icecast2/icecast-server1-relay.xml Javier de la Rica Comunicaciones Multimedia D’aquesta manera es reiniciarà l’Icecast amb els nous paràmetres de configuració.
Figure 17: Esquema “master-slave” Verifiqueu amb el firefox que estan els dos punts de muntatge en el servidor server1.
Se escoge al servidor server1 como slave y al servidor server2 como maste, de forma que server1 recoge tanto el flujo suministrado por el server2 como el recibido de source1 – radio-mix y radio-folk –. Para habilitar dicha opción master-slave únicamente se debe descomentar las líneas de código propias correspondientes al fichero icecastserver1-relay.xml <master-server>10.34.2.2</master-server> <master-server-port>8000</master-server-port> <master-update-interval>120</master-update-interval> <mater-password>xxxx</master-password> 9.3.5 Protocol icecast En l’exercici anterior ja vam veure en què consistia el protocol Icecast en una connexió font-servidor, ara veureu en què consisteix el protocol Icecast en una connexió entre dos servidors Icecast quan un és esclau de l’altre.
Connexió servidor-servidor Amb el wireshark capturant a la interfície correcta, reinicieu el servidor master i captureu el handshake que es produeix entre els dos servidors. Com podreu comprovar, en aquest cas si que es fa servir una funció d’HTTP (GET). Es fa servir perquè el servidor esclau pugui obtenir el llistat de fluxos que té el servidor master. En el cas que el servidor master hagi servit correctament la llista al servidor esclau, respon amb HTTP/1.0 200 OK.
Javier de la Rica Comunicaciones Multimedia Finalitzat l’anàlisi.
Podeu aturar els servidors i les fonts si heu acabat la sessió. En aquest cas també teniu que apagar la virtualització de l’escenari: telematic@telem:~$ simctl radionet stop Si continueu amb el següent exercici només cal aturar el bombeig des de la font source1.
Javier de la Rica Comunicaciones Multimedia 10.
Exercici 3 Fins ara, s’han generat models de ràdios que només permetien la distribució de música provinent de llistes de reproducció. Però, què és una ràdio sense la capacitat de captar el so provinent d’almenys un micròfon? En aquest tercer exercici hi trobareu diferents maneres per captar l’àudio provinent del micròfon i enviar-lo al servidor i com fer mescles d’àudio, ja sigui una mescla locutor-música com una mescla música-música.
10.1 Objectius L’objectiu principal d’aquest exercici és el de dissenyar una ràdio que posi música ambient a sota del locutor de la ràdio. Fins a arribar a aquest objectiu, es treballaran els següents conceptes: ● ALSA: entendre què és, funcions a dins del nucli Linux.
● Llenguatge Liquidsoap: entendre la sintaxi, comprendre algunes funcions i la interpretació.
● Protocol Icecast: comprendre el protocol de comunicació entre una font Liquidsoap i un servidor Icecast.
● Flux fal·lible: saber distingir un flux infal·lible d’un fal·lible i saber quan és necessari utilitzar un flux fal·lible.
● Mescla: entendre com es fan les ponderacions a dins de la mescla.
10.2 Esquema L’escenari utilitzat en aquest exercici és el més senzill de tots i és un petit subconjunt de l’escenari radionet. De màquines virtualitzades només se’n necessita una, ja que la font de servidor necessita el maquinari de so i, per tant, s’ha d’executar des del host.
En aquest escenari, tot i que només hi ha una màquina virtual i una de física, hi ha dues xarxes. Això es deu a que una xarxa(Net0) serà l’enllaç que durà el tràfic de pujada de dades cap al servidor, mentre que l’altra(Net1), concentrarà el tràfic de dades del servidor cap a la màquina host.
Figura 18: Esquema de l’exercici Javier de la Rica Comunicaciones Multimedia 10.2.1 Arxius de música El fitxers de música mix es troban en el següent directori: telematic@telem:~$ ls -l $HOME/vnuml/scenarios/files/radionet/local/liquidsoap/mix Com podeu observar, a dins hi han fitxers ogg de música clàssica i d’altres gèneres.
telematic@telem:~$ ls -l $HOME/vnuml/scenarios/files/radionet/local/liquidsoap/mix total 13628 -rwxr-xr-x 1 telematic telematic 2718987 2012-09-20 11:43 danzadelfuego.ogg* -rwxr-xr-x 1 telematic telematic 884736 2012-09-20 11:43 el_pc.ogg* -rwxr-xr-x 1 telematic telematic 2953859 2012-09-20 11:43 la_mort_de_cara.ogg* -rwxr-xr-x 1 telematic telematic 2836289 2012-09-20 11:43 pista1.ogg* -rwxr-xr-x 1 telematic telematic 2658663 2012-09-20 11:43 pista5.ogg* -rwxr-xr-x 1 telematic telematic 1888385 2012-09-20 11:43 tango.ogg* 10.2.2 Apunts sobre la màquina server Com ja va essent habitual, els fitxers de registre de la màquina server1 es troben als següents directoris: ● /tmp/icecast2-acces.log ● /tmp/icecast2-error.log El servidor s’executa en el port 8000 i s’escoltarà a través de la interfície que té a la xarxa Net0.
10.3 Desenvolupament 10.3.1 Inici de l’escenari En aquest execici el client només interacciona amb un servidor per la xarxa Net0. Per tal d’iniciar l’escenari, passeu el nom de l’escenari radionet al simctl: telematic@telem:~$ simctl radionet start A continuació, configureu correctament les interfícies de xarxa tap0 i tap1 del host.
Comproveu que ho heu fet correctament visitant el servidor mitjançant la comanda ping.
10.3.2 Ràdio amb locutor Com s’explica a la introducció, aquesta sessió tracta sobre com dissenyar una ràdio IP muntada en un servidor Icecast i que pugui combinar directe(locutor provinent de les connexions d’entrada de la targeta de so de la màquina host) i una llista de reproducció de música.
Javier de la Rica Comunicaciones Multimedia En aquest apartat, veureu com crear ràdios IP que gestionen un corrent de veu. Ho fareu utilitzant una font Liquidsoap. Aquestes font no pot ser virtualitzada, ja que ha de treballar conjuntament amb el servidor de so del sistema host, i per tant, amb el hardware instal·lat a la màquina host. Per això l’escenari radionet és tan minimalista.
Comprovació del maquinari Si es considera que el sistema operatiu usa l’arquitectura de so ALSA (Advanced Linux Sound Architecture), l’arquitectura de so és la part del nucli Linux que gestiona els dispositius d’àudio i els unifica en un sol sistema de control. Sobre ALSA hi corre un servidor de so de sistema com PulseAudio.
Per fer-ho, podeu utilitzar la configuració gràfica de so o bé l’ordre per configura el so des del terminal alsamixer: telematic@telem:~$ alsamixer Al terminal hi veureu els nivells de volum d’entrada i sortida dels dispositius de la targeta de so.
Figura 19: Mesclador gràfic d’àudio d’ALSA Prement F4, veureu els nivells dels dispositius d’entrada i prement F6 accedireu als menús d’informació del sistema. Mireu els diferents menús i comproveu que hi ha una configuració de so correcta. Comproveu que hi sigui present el dispositiu de so d’entrada amb un valor de volum correcte.
Endolleu el micròfon a l’entrada de micròfon de la targeta de so. A continuació, graveu sons de prova per confirmar que el maquinari està configurat correctament. Per iniciar una gravació utilitzeu l’ordre rec: telematic@telem:~$ rec prova.ogg Javier de la Rica Comunicaciones Multimedia telematic@telem:~$ rec prova.ogg Input File : 'default' (alsa) Channels : 2 Sample Rate : 48000 Precision : 16-bit Sample Encoding: 16-bit Signed Integer PCM In:0.00% 00:00:11.61 [00:00:00.00] Out:553k [ ==|== ] Clip:0 Parleu pel micròfon i observeu si el programa detecta activitat d’entrada(sabreu que hi ha activitat si veieu caràcters que es mouen al costat de la grandària del fitxer resultant). En acabar la gravació(CRTL+c) escolteu el fitxer resultant utilitzant, per exemple, l’ordre play: telematic@telem:~$ play prova.ogg telematic@telem:~$ play prova.ogg prova.ogg: File Size: Encoding: Channels: Samplerate: Replaygain: Duration: In:100% Done.
127k Bit Rate: 78.3k Vorbis Info: Processed by SoX 2 @ 16-bit 48000Hz off 00:00:12.97 00:00:12.97 [00:00:00.00] Out:623k [ -=|=- ] Hd:0.7 Clip:0 Figura 20: Programa rec captant l’àudio del micròfon Javier de la Rica Comunicaciones Multimedia 10.3.3 Liquidsoap Llista de reproducció Per a preparar el funcionament de la font Liquidsoap primer verifiquem la llista de reproducció que contenen els fitxers amb extensió pls presents a la carpeta $HOME/vnuml/scenarios/files/radionet/local/liquidsoap/: telemantic@telem:~$ cd $HOME/vnuml/scenarios/files/radionet/local/liquidsoap telematic@telem:~$ more playlist-mix.pls telematic@telem:~$ cd $HOME/vnuml/scenarios/files/radionet/local/liquidsoap telematic@telem:~/vnuml/scenarios/files/radionet/local/liquidsoap$ more playlistmix.pls [playlist] File1=/usr/share/vnuml/scenarios/files/radionet/local/liquidsoap/mix/el_pc.ogg Title1=El pc Length1=-1 File2=/usr/share/vnuml/scenarios/files/radionet/local/liquidsoap/mix/pista5.ogg Title2=Pista 5 Length2=-1 File3=/usr/share/vnuml/scenarios/files/radionet/local/liquidsoap/mix/la_mort_de_c ara.ogg Title3=La mort de cara Length3=-1 File4=/usr/share/vnuml/scenarios/files/radionet/local/liquidsoap/mix/pista1.ogg Title4=Pista 1 Length4=-1 NumberOfEntries=4 Version=2 Javier de la Rica Comunicaciones Multimedia telematic@telem:~$ more playlist-classica.pls telematic@telem:~/vnuml/scenarios/files/radionet/local/liquidsoap$ more playlist-classica.pls [playlist] File1=/usr/share/vnuml/scenarios/files/radionet/local/liquidsoap/mix/tang o.ogg Title1=Tango Length1=-1 File2=/usr/share/vnuml/scenarios/files/radionet/local/liquidsoap/mix/danz adelfuego.ogg Title2=Danza del fuego Length2=-1 NumberOfEntries=2 Version=2 Teniu les especificacions del format PLS al següent enllaç: http://en.wikipedia.org/wiki/PLS_(file_format).
Podeu comprovar que està configurat correctament si l’executeu amb un programa de reproducció de música i es reprodueix el contingut especificat a la llista.
Quan hagueu enllestit la llista de reproducció, analitzeu l’script anomenat radio1.liq que genera un flux a partir de la llista de reproducció i l’enviï al servidor Icecast.
telematic@telem:~$ more radio1.liq #! /usr/bin/liquidsoap set("log.file",false) set("log.stdout",true) musica = playlist.safe("/usr/share/vnuml/scenarios/files/radionet/local/liquidsoap/playlis t-mix.pls") output.icecast.vorbis(host = "10.34.1.254", port = 8000, mount = "/radio1.ogg", restart = true, fallible = true, password = "xxxx", musica) Javier de la Rica Comunicaciones Multimedia Com podeu observar aquest flux s’anomena /radio1.ogg.
Poseu el servidor icecast en marxa: server1:~# icecast2 -c /etc/icecast2/icecast-server1.xml server1:~# icecast2 -c /etc/icecast2/icecast-server1.xml Changed groupid to 65534.
Changed userid to 65534.
Per iniciar el bombeig del flux creat, assegureu-vos que teniu privilegis d’execució sobre l’script generat (usant l’ordre ls -l al directori on heu creat l’script) i executeu-lo.
Inicieu l’script radio1.liq.
telematic@telem:~$ ./radio1.liq telematic@telem:~/vnuml/scenarios/files/radionet/local/liquidsoap$ ./radio1.liq 2016/03/21 15:26:35 >>> LOG START 2016/03/21 15:26:35 [protocols.external:3] Didn't find "ufetch" 2016/03/21 15:26:35 [protocols.external:3] Found "/usr/bin/wget" 2016/03/21 15:26:35 [main:3] Liquidsoap 0.9.2 2016/03/21 15:26:35 [lang:3] flac binary not found: flac decoder disabled.
2016/03/21 15:26:35 [lang:3] metaflac binary not found: flac metadata resolver disabled.
2016/03/21 15:26:35 [threads:3] Created thread "generic queue #1".
2016/03/21 15:26:35 [threads:3] Created thread "root" (1 total).
2016/03/21 15:26:35 [root:3] Waking up active nodes...
2016/03/21 15:26:35 [playlist-mix(dot)pls:3] Loading playlist...
2016/03/21 15:26:35 [playlist-mix(dot)pls:3] No mime type specified, trying autodetection.
2016/03/21 15:26:35 [playlist-mix(dot)pls:3] Playlist treated as format audio/xscpls 2016/03/21 15:26:35 [playlist-mix(dot)pls:3] Successfully loaded a playlist of 4 tracks.
2016/03/21 15:26:36 [decoder:3] Decoder OGG chosen for "/usr/share/vnuml/scenarios/files/radionet/local/liquidsoap/mix/el_pc.ogg".
2016/03/21 15:26:36 [playlist-mix(dot)pls:3] Prepared "/usr/share/vnuml/scenarios/files/radionet/local/liquidsoap/mix/el_pc.ogg" (RID 1).
2016/03/21 15:26:36 [/radio1(dot)ogg:3] Connecting mount /radio1.ogg for source@10.34.1.254...
2016/03/21 15:26:36 [/radio1(dot)ogg:3] Connection setup was successful.
2016/03/21 15:26:36 [root:3] Broadcast starts up! Javier de la Rica Comunicaciones Multimedia A partir d’aquest exercici utilitzareu el programa ffplay-086 per reproduir els fluxos del servidor.
telematic@telem:~$ ffplay-086 http://10.34.0.254:8000/radio1.ogg telematic@telem:~$ ffplay-086 http://10.34.0.254:8000/radio1.ogg ffplay version 0.8.6, Copyright (c) 2003-2011 the FFmpeg developers built on Dec 15 2011 20:56:12 with gcc 4.5.2 configuration: libavutil 51.
9. 1 / 51.
9. 1 libavcodec 53.
7. 0 / 53.
7. 0 libavformat 53.
4. 0 / 53.
4. 0 libavdevice 53.
1. 1 / 53.
1. 1 libavfilter 2. 23. 0 / 2. 23. 0 libswscale 2.
2.
0. 0 / 0. 0 [ogg @ 0x9e1cf80] Estimating duration from bitrate, this may be inaccurate Input #0, ogg, from 'http://10.34.0.254:8000/radio1.ogg': Duration: N/A, start: 0.000000, bitrate: 96 kb/s Stream #0.0: Audio: vorbis, 44100 Hz, stereo, s16, 96 kb/s Metadata: TITLE : El_PC ALBUM : CD2_pom DATE : 0 ENCODER : ocaml-vorbis by the savonet team (http://savonet.sf.net/) 59.98 A-V: 0.000 s:0.0 aq= 97KB vq= 0KB sq= 0B f=0/0 En qualsevol moment, podeu aturar el bombeig utilitzant al combinació de tecles CTRL+c.
Dues llistes de reproducció Amb Liquidsoap podeu reproduir dos recursos musicals mesclats. Per aconseguir-ho, es poden mesclar dues llistes de reproducció, dues cançons o una llista de reproducció i una cançó.
En el nostre cas, veureu com es poden mesclar dues llistes de reproducció de tal manera com ho faria una taula de mescles. Usant el paràmetre weights a dins de la funció add. Per exemple, si es vol donar 4 vegades més intensitat al flux1 que al flux2 es fa de la següent manera: var = add(weights = [ 4,1 ], [ flux1,flux2 ]) Analitzeu l’script radio2.liq per veure, de forma completa, la codificació necessaria amb Liquidsoap.
Javier de la Rica Comunicaciones Multimedia Executeu l’script i confirmeu, usant el ffplay, que efectivament el flux que distribueix el servidor és resultat de mesclar les dues llistes de reproducció.
GNU nano 2.2.6 File: radio2.liq #! /usr/bin/liquidsoap set("log.file",false) set("log.stdout",true) classica = playlist.safe("/usr/share/vnuml/scenarios/files/radionet/local/liquidsoap/playlis t-classica.pls") mix = playlist.safe("/usr/share/vnuml/scenarios/files/radionet/local/liquidsoap/playlis t-mix.pls") musica = add(weights = [4,1], [classica,mix]) output.icecast.vorbis(host = "10.34.1.254", port = 8000, mount = "/radio2.ogg", restart = true, password = "xxxx", musica) telematic@telem:~$ ffplay-086 http://10.34.0.254:8000/radio2.ogg ffplay version 0.8.6, Copyright (c) 2003-2011 the FFmpeg developers built on Dec 15 2011 20:56:12 with gcc 4.5.2 configuration: libavutil 51.
9. 1 / 51.
9. 1 libavcodec 53.
7. 0 / 53.
7. 0 libavformat 53.
4. 0 / 53.
4. 0 libavdevice 53.
1. 1 / 53.
1. 1 libavfilter 2. 23. 0 / 2. 23. 0 libswscale 2.
2.
0. 0 / 0. 0 [ogg @ 0x95d7f80] Estimating duration from bitrate, this may be inaccurate Input #0, ogg, from 'http://10.34.0.254:8000/radio2.ogg': Duration: N/A, start: 0.000000, bitrate: 96 kb/s Stream #0.0: Audio: vorbis, 44100 Hz, stereo, s16, 96 kb/s Metadata: ARTIST : Erik_Helling TITLE : Falla___Ritual_Fire_Dance ALBUM : http___www_pianosociety_com DATE : 0 ENCODER : ocaml-vorbis by the savonet team (http://savonet.sf.net/) Javier de la Rica Comunicaciones Multimedia 91.30 A-V: 0.000 s:0.0 aq= 87KB vq= 0KB sq= 0B f=0/0 Mediante el reproductor ffplay se pueden escuchar claramente los dos flujos al mismo tiempo. Por un lado un piano correspondiente al flujo de música clásica classic y por otro lado una mujer cantando correspondiente al flujo de música mix.
Veu Analitzeu l’script anomenat radio3.liq. Aquest script ha de transmetre el contingut del micròfon al servidor. El punt de muntatge especificat és /radio3.ogg.
GNU nano 2.2.6 File: radio3.liq #! /usr/bin/liquidsoap set("log.file",false) set("log.stdout",true) veu = mksafe(in()) output.icecast.vorbis(host = "10.34.1.254", port = 8000, mount = "/radio3.ogg", restart = true, password = "xxxx", veu) telematic@telem:~$ ffplay-086 http://10.34.0.254:8000/radio3.ogg ffplay version 0.8.6, Copyright (c) 2003-2011 the FFmpeg developers built on Dec 15 2011 20:56:12 with gcc 4.5.2 configuration: libavutil 51.
9. 1 / 51.
9. 1 libavcodec 53.
7. 0 / 53.
7. 0 libavformat 53.
4. 0 / 53.
4. 0 libavdevice 53.
1. 1 / 53.
1. 1 libavfilter 2. 23. 0 / 2. 23. 0 libswscale 2.
2.
0. 0 / 0. 0 [ogg @ 0x9b13f80] Estimating duration from bitrate, this may be inaccurate Input #0, ogg, from 'http://10.34.0.254:8000/radio3.ogg': Duration: N/A, start: 0.000000, bitrate: 96 kb/s Stream #0.0: Audio: vorbis, 44100 Hz, stereo, s16, 96 kb/s Metadata: TITLE : Unknown ENCODER 15.23 A-V: : ocaml-vorbis by the savonet team (http://savonet.sf.net/) 0.000 s:0.0 aq= 74KB vq= 0KB sq= 0B f=0/0 Javier de la Rica Comunicaciones Multimedia Se comprueba mediante la reproducción de ./radio3.ogg que el archivo reproducido es el grabado y guardado anteriormente.
Llista de reproducció + locutor Analitzeu l’script anomenat radio4.liq. Aquest script ha de mesclar un flux provinent del micròfon amb el flux que genera la llista de reproducció de música clàssica i transmetre la mescla al servidor. El punt de muntatge especificat és /radio4.ogg.
GNU nano 2.2.6 File: radio4.liq #! /usr/bin/liquidsoap set("log.file",false) set("log.stdout",true) classica = playlist.safe("/usr/share/vnuml/scenarios/files/radionet/local/liquidsoap/playlis t-classica.pls") veu = mksafe(in()) flux = add(weights = [4,1],[veu,classica]) output.icecast.vorbis(host = "10.34.1.254", port = 8000, mount = "/radio4.ogg", restart = true, password = "xxxx", flux) telematic@telem:~$ ffplay-086 http://10.34.0.254:8000/radio4.ogg ffplay version 0.8.6, Copyright (c) 2003-2011 the FFmpeg developers built on Dec 15 2011 20:56:12 with gcc 4.5.2 configuration: libavutil 51.
9. 1 / 51.
9. 1 libavcodec 53.
7. 0 / 53.
7. 0 libavformat 53.
4. 0 / 53.
4. 0 libavdevice 53.
1. 1 / 53.
1. 1 libavfilter 2. 23. 0 / 2. 23. 0 libswscale 2.
2.
0. 0 / 0. 0 [ogg @ 0xa75ef80] Estimating duration from bitrate, this may be inaccurate Input #0, ogg, from 'http://10.34.0.254:8000/radio4.ogg': Duration: N/A, start: 0.000000, bitrate: 96 kb/s Stream #0.0: Audio: vorbis, 44100 Hz, stereo, s16, 96 kb/s Metadata: TITLE : Unknown ENCODER : ocaml-vorbis by the savonet team (http://savonet.sf.net/) 25.97 A-V: 0.000 s:0.0 aq= 32KB vq= 0KB sq= 0B f=0/0 Javier de la Rica Comunicaciones Multimedia Se puede observar que en ./radio4.liq se pueden escuchar simultáneamente el archivo grabado previamente y el flujo correspondiente a la música clásica classic.
Stream de video Finalment analitzeu el fitxer video.liq i verifiqueu el seu funcionament. Observeu els nous paràmetres que apareixen en el servidor Icescast relacionats amb el vídeo.
GNU nano 2. 2.6 File: video.liq #! /usr/bin/liquidsoap set("log.file",false) set("log.stdout",true) set("frame.video.channels",1) set("frame.video.width",352) set("frame.video.height",288) set("frame.video.fps",25) source = single("/home/telematic/streams/warriors-700-sp-VBR.ogv") output.icecast.theora(host = "10.34.1.254", port = 8000, mount = "/video.ogg", restart = true, fallible = true, password = "xxxx", source) #output.sdl(source) telematic@telem:~$ ffplay-086 http://10.34.0.254:8000/video.ogg ffplay version 0.8.6, Copyright (c) 2003-2011 the FFmpeg developers built on Dec 15 2011 20:56:12 with gcc 4.5.2 configuration: libavutil 51. 9. 1 / 51. 9. 1 libavcodec 53. 7. 0 / 53. 7. 0 libavformat 53. 4. 0 / 53. 4. 0 libavdevice 53. 1. 1 / 53. 1. 1 libavfilter 2. 23. 0 / 2. 23. 0 libswscale 2. 0. 0 / 2. 0. 0 [ogg @ 0x9af3f80] max_analyze_duration 5000000 reached at 5000000 [ogg @ 0x9af3f80] Estimating duration from bitrate, this may be inaccurate Input #0, ogg, from 'http://10.34.0.254:8000/video.ogg': Duration: N/A, start: 0.000000, bitrate: 499 kb/s Stream #0.0: Data: skeleton Stream #0.1: Video: theora, yuv420p, 352x288 [PAR 1:1 DAR 11:9], 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0.2: Audio: vorbis, 44100 Hz, stereo, s16, 499 kb/s Metadata: TITLE : Unknown ENCODER : ocaml-vorbis by the savonet team (http://savonet.sf.net/) 326.60 A-V: 0.001 s:0.0 aq= 291KB vq= 1363KB sq= 0B f=0/0 f=0/0 Javier de la Rica Comunicaciones Multimedia 10.3.4 Stream de vídeo amb font de Servidor FFMpegTheora Proveu d’enviar directament un vídeo transcodificat al servidor Icecast de la forma: telematic@telem:~$ ffmpeg2theora -x 426 -y 240 --videobitrate 700 -o /dev/stdout ~/streams/ed_hd_512kb.mp4 | oggfwd -d CM_TV -g Telematic -n ED -u www.upc.edu 10.34.1.254 8000 xxxx /videostreaming Verifiqueu la disponibilitat del nou canal en el servidor Icecast i reproduiu el video des del terminal: ffplay-086 http://10.34.0.254:8000/videostreaming A. Expliqueu què fan les comandes ffmpeg2theora i oggfwd.
ffmpeg2theora es un conversor de vídeo utilizado para realizar la conversión y reproducción de diferentes tipos de vídeo. La propia herramienta ffmpeg se puede configurar de manera que pueda soportar distintos códecs de vídeo y audio dependiendo de las necesidades de la instalación. Ffmpeg2theora se utiliza para agregar funcionalidad a ffmpeg, sobretodo en la creación de una copia OGG Vorbis del flujo de audio del vídeo.
Por otro parte, oggfwd actúa como un cliente de fuente mínima para los servidores Icecast. Dicho comando lee un flujo Ogg en la entrada estándar y lo envía a un servidor concreto especificado en la línea de comandos.
B. Cóm es comuniquen els dos programes?.
El comando ffmpeg2theora se encarga de hacer una copia del flujo de vídeo, que transmite a través del comando oggfwd al servidor que reproduce el servicio.
1 Quantitat de bytes que s’envia al client al moment de l’establiment de la connexió.
...