Jugando con Imagenio

¿Me di ya por satisfecho? No del todo. Ahora mi intención era investigar poder prescindir del decodificador de Movistar, es decir, ver Imagenio en la tele sin ningún otro aparato. No porque el aparato fuera malo, sino porque el hecho de tener que encenderlo, cambiar la entrada de la tele, esperar a que cargue, tener que cambiar de mando, etc. no era la mejor experiencia. Vale, lo podría tener siempre encendido y configurado como receptor de TDT, pero sinceramente el integrado en el televisor es mucho mejor. Además, ¿quién quiere tener que depender de otro cacharro al lado de tele?

Al ser una Samsung Smart TV imaginé que debía haber alguna app para reproducir contenidos IPTV, como es el caso de Imagenio. Por los códecs estaba seguro que no habría problema, porque el vídeo es MPEG-4 AVC y el audio es MPEG Audio, formatos con los que es totalmente compatible. Evidentemente, en la tienda oficial no había nada, pero sí encontré por Internet varias apps desarrolladas por terceros. Para instalar este tipo de aplicaciones simplemente había que iniciar sesión en la tele como desarrollador y, de esta manera, se podía conectar a un servidor externo de apps y descargarlas. Vamos, como hacer una especie de “jailbreak” a la tele. Si hubiera sido más complicado, probablemente hubiera desechado la opción (trastear con televisores recientes son palabras mayores…), pero me sorprendió de lo sencillo que fue, la verdad.

Curiosamente, la gran mayoría de información sobre el asunto de reproducir IPTV y otros contenidos por Internet directamente en la tele está en ruso y polaco, así que tirando de traductor de Google pude sacar algunas cosas claras. Instalé varias aplicaciones, pero nStreamLmod me pareció la que mejor funcionaba y la más completa (aunque en ruso). El problema es que no parecía llevarse muy bien con los contenidos vía RTP (el protocolo por el que se ven los canales) y se veían muy pixelados. Pero era un progreso.

Icono nStreamLmod

Icono de nStreamLmod en el menú Smart TV

Ya estaba decidido a buscar una alternativa, pero descubrí una pequeña maravilla: udpxy. Se trata de un demonio que se encarga de convertir el protocolo multicast RTP a unicast HTTP. Además, es tan ligero que incluso se puede instalar en una Raspberry Pi, o directamente en un router, por ejemplo. Yo no lo hice porque ya tengo un servidor que se puede encargar de esta tarea, así que lo compilé, lo configuré para que se iniciara siempre al arranque y funcionó increíblemente bien: ahora ya se veían en la tele todos los canales perfectos sin necesidad de decodificador. Lo único que tuve que hacer fue adaptar las URL de los canales, que pasaron de ser del tipo “rtp://@239.0.X.X:8208” a “http://servidor:puerto/rtp/239.0.X.X:8208”.

Canales en nStreamLmod

Selección de canales en nStreamLmod

El sistema no es del todo perfecto, pues hay que esperar a que cargue la interfaz del Smart TV, arrancar la app correspondiente y esperar un poco a que haga buffering, pero aun así es bastante mejor que la otra experiencia; tener Imagenio integrado en el propio televisor es una gozada. Lo que sí es un claro paso atrás es la pérdida de la EPG, pero teniendo una app como SincroGuía en el móvil o tablet no es tanto problema.

Vale, pero, ¿y si la tele no es inteligente? En este caso es algo más complicado. En mi caso, una de ellas es más antigua y no dispone de más “inteligencia” que una PlayStation 3. En efecto, la PS3 también es capaz de reproducir canales de Imagenio… con un poco de ayuda. Recurrí a un viejo amigo: PS3 Media Server, que recordé que cuando lo usaba, tenía la capacidad de reproducir contenidos de Internet. Miré de ver cómo añadir las URL de los canales y premio, todos los canales funcionando vía DLNA. En este caso ni siquiera es necesario usar udpxy, pero claro, es necesario un ordenador corriendo PS3 Media Server. Evidentemente en este caso es mejor usar directamente el decodificador, pero si se está utilizando en otra televisión es mejor que nada.

Canales en PS3

Canales de Imagenio en la PS3 gracias a PS3 Media Server

Hablando de udpxy, este pequeño software me abría las puertas a otra posibilidad extremadamente interesante: ver Imagenio por VPN. Llevar multicast por VPN es posible, pero requiere conocimientos y hardware avanzados que no dispongo. Con udpxy se simplificaba todo de una manera bestial, de hecho no tuve que tocar nada en especial: conectarme por VPN y acceder a la URL del canal que quería ver, tan simple como eso. Vamos, una joya. Además, con los 10 Mbps de subida, se pueden ver perfectamente los canales HD, aunque lamentablemente las conexiones ADSL de 10 Mbps van muy justas para una reproducción fluida al proporcionar algo menos de velocidad real.

Ya para terminar de “jugar” con Imagenio, se me ocurrió que sería buena idea hacer streaming pero sólo del audio de los canales. Así, por ejemplo, si se está bajo cobertura móvil y no se quiere gastar la cantidad ingente de datos que supondría ver una emisión, que al menos se pueda escuchar a modo de radio.

Para conseguir esto, lo primero que pensé fue en echarle un ojo al código fuente de udpxy y modificarlo de forma que desechara toda señal de vídeo. Como a primera vista no parecía tan sencillo, no me calenté mucho más la cabeza y recordé que FFmpeg era el candidato perfecto para esta tarea: es la navaja suiza del streaming por Internet. Luego investigué cómo hacer que fuera compatible con HTTP Live Streaming, de modo que en iOS funcionara nativamente. Como sí que lo era, bajé la versión más reciente de FFmpeg al servidor, la compilé, creé un shell script con los comandos necesarios y, después de muchas pruebas, conseguí que funcionara. Por último, me preocupé de optimizar el comando de FFmpeg para que utilizara el mínimo ancho de banda para una calidad de sonido dentro de lo aceptable.

Una vez puesto en marcha el script, ya puedo acceder a determinada dirección y escuchar desde cualquier lugar el canal elegido. Aproximadamente consume 500 KB por minuto, unos 30 MB a la hora. Creo que son cantidades razonables, sin apenas impacto en la típica tarifa actual de 1 GB de datos al mes.

Una utilidad práctica de esto, que de hecho he probado, es poner en marcha el script y enlazar el móvil con el Bluetooth del coche para así estar escuchando en directo esa película o serie que te has tenido que dejar a medias en casa. ¿No es maravilloso?

Quería finalizar con un pequeño vídeo mostrando algunas de las cosas que he contado a lo largo del post:

En él se puede ver como, aun a pesar de estar visualizando seis canales HD simultáneamente, la velocidad de Internet apenas sale perjudicada. Hay que tener en cuenta que es un ejemplo llevado al extremo (150 Mbps entre las dos VLANs), pues en un uso normal, estar viendo Imagenio no supone en absoluto una pérdida de velocidad.

Por cierto, a pesar de que en el ordenador de sobremesa cuento con una tarjeta sintonizadora de televisión, desde que tengo Imagenio no la he vuelto a emplear. Teniendo una lista de reproducción y VLC reproduciéndola prácticamente al instante, deja a Windows Media Center en ridículo en cuanto a velocidad. Eso sí, si quiero disfrutar de funciones más avanzadas (EPG, canales en pseudo HD, time shifting…) debo seguir recurriendo a la solución de Microsoft.

Respecto a la visualización de Imagenio en dispositivos iOS, se puede ver cómo funciona la página web que comentaba y cómo son enviados cuatro canales por Wi-Fi sin problemas. En el iPhone 5 (abajo a la izquierda) se reproduce FOX HD (en este caso eran 6 Mbps, con más bitrate funciona a saltos) mientras los demás son canales en SD, más que nada porque VLC pide bastante potencia para la visualización de un canal en alta definición, potencia que no es suficiente en los otros dispositivos mostrados (iPad de 2ª y 3ª generación y iPhone 4S). En los más recientes (chip A7 en adelante) se reproducen todos perfectamente, faltaría más.

Por último, se puede ver el funcionamiento de nStreamLmod funcionando en la Samsung Smart TV. Es importante destacar que después de ese primer (y molesto) buffering, ya no lo vuelve a hacer a menos que cambies de canal, claro. Imagino que es algo que irán mejorando en posteriores versiones de la aplicación.

Y esto es todo. La verdad es que todo este asunto me mantuvo entretenido varios días, trasteando con una tecnología (IPTV) con la que no había tenido experiencia hasta el momento. ¡Ahora a disfrutarla!

Imagen interfaz Movistar TV | Noticias Bancarias

148 comentarios / Añade el tuyo debajo

  1. Buenas de nuevo.

    Finalmente me he dado (casi) por vencido en cuanto a tener ffmpeg funcionando en mi NAS. Ahora se está recompilando otra vez (y van…) pero no tengo muchas esperanzas de que funcione.

    Afortunadamente tengo siempre un Mac Mini encendido y en él instalar ffmpeg y ponerlo en marcha ha sido mucho más sencillo.

    Ya está escupiendo alegremente un fichero stream.m3u8 que se actualiza periódicamente y una serie de ficheros cortitos output_xxx.ts

    Ahora la pregunta es… ¿qué usas para reproducirlos cuando estás por la calle? ¿Los compartes en un servidor web? ¿Qué software usas para reproducirlo?

    En principio no debería ser demasiado problemático olvidarme de los segmentos, crear un solo output.ts y publicarlo en alguna URL, pero el VLC sólo reproduce el tramo que estaba creado cuando empieza a reproducirlo, no se da cuenta de que ha aumentado de tamaño.

    Supongo que por eso empleas los segmentos, pero no tengo muy claro cómo hacer eso accesible desde fuera de mi red.

    Muchas gracias de nuevo por todo.

    1. Hola Carlos,

      Junto a esos segmentos deberías también tener un archivo .m3u8, que genera una lista de reproducción automática de los segmentos y es el único archivo que debes reproducir. Para ello, como bien intuyes, los comparto en un servidor web y abro el archivo .m3u8 con Safari en el iPhone. Éste se encarga de reproducir los segmentos, uniéndolos internamente al vuelo y creando así la reproducción en vivo. Si el iPhone lo tienes enlazado al Bluetooth del coche, ya tienes el sistema al completo ;)

      Un saludo!

  2. De nuevo muchísimas gracias.

    Al final lo dejé funcionando con un servidor web sencillito en el Mac Mini

    nohup python -m SimpleHTTPServer 8000 &

    Y la instrucción que pusiste en uno de los primeros comentarios para el ffmpeg (la última tenía como salida también video, la original sólo tenía el audio).

    ffmpeg -i rtp://@IP:puerto -vn -sn -map 0:a:0 -c:a aac -ac 1 -b:a 32k -ar 22050 -f segment -segment_list stream.m3u8 -segment_time 10 -segment_list_size 30 output_%03d.ts

    El puerto 8000 en el router (NAT, port forwarding o como se quiera llamar) queda apuntando a la IP del Mac Mini y ya puedo escuchar la tele con http://IP_EXTERNA:8000/stream.m3u8

    Lo pongo tan desglosado por si entra alguien buscándolo, es evidente que tú sabes todo eso.

    Ahora la cosa es que igual que sólo controlo lo básico de Linux, me ocurre lo mismo con OS X. Ahora mismo cada vez que lo quiero usar tengo que hacer ssh al Mac Mini y poner la cosa en marcha. Tendré que buscar la forma de automatizarlo.

    Un saludo.

  3. Como curiosidad, anoche me puse otro rato y ya tengo todo tal y como quería. Este post ha sido una inspiración :)

    Al final tengo varios scripts.

    —- inicio_stream —-
    #!/bin/bash
    /Users/carlos/a/fin_stream
    nohup /bin/ffmpeg -nostdin -i $1 -vn -sn -map 0:a:0 -c:a aac -ac 1 -b:a 32k -ar 22050 -f segment -segment_list /Users/carlos/audioimagenio/stream.m3u8 -segment_time 10 -segment_list_size 30 /Users/carlos/audioimagenio/output_%03d.ts >> /Users/carlos/a/log.txt 2>&1 &
    echo $! > /Users/carlos/audioimagenio/save_pid.txt
    ——————————–

    Este script ejecuta ffmpeg dejándolo en segundo plano con la dirección rtp que se le pasa como parámetro ($1) y guarda en save_pid.txt el PID del proceso. Primero llama a otro script que limpia los posibles ficheros que haya por ahí y mata el anterior proceso ffmpeg si existe.

    —- fin_stream —-
    #!/bin/bash
    rm /Users/carlos/a/log.txt > /dev/null
    kill -9 `cat /Users/carlos/audioimagenio/save_pid.txt` > /dev/null
    rm /Users/carlos/audioimagenio/* > /dev/null
    ———————————

    —- la1 ———–
    /Users/carlos/a/inicio_stream rtp://@239.0.0.76:8208
    ———————

    Como servidor web estoy usando uno gratuito llamado Abyss Web Server.

    Y ahora lo mejor… tanto en Android como en iOS hay programitas que permiten ejecutar un script en un servidor ssh remoto dándole simplemente a un botón.

    En Android estoy usando SSH button y en iOS SimpleSSH.

    Así que una vez configurado todo, si quiero escuchar Teledeporte por la calle:

    1. Abro SSH button en Android.
    2. Le doy al botón de Teledeporte (que ejecuta el script ssh correspondiente en el Mac Mini)
    3. Abro VLC y elijo el stream.

    Cuando acabo vuelvo a abrir SSH button y le doy al botón de Finalizar stream.

    1. Muchas gracias Carlos por compartir tus scripts; no conocía los programas que lanzan comandos por SSH automáticamente y es algo que puede ser muy útil!

      Un saludo, y ahora a disfrutar de tu sistema :)

  4. Me alegro de haber sido de ayuda.

    Un par de cositas más que añadí luego.

    1. Me dejé andando uno de los scripts sin acordarme de pararlo durante 3 días y luego había tantos ficheros creados que el rm * se quejaba de que había demasiados argumentos. Para solucionarlo añadí el parámetro -segment_wrap 10 para que cuando llegue al segmento 100 vuelva empezar desde el primero.

    2. Añadí un parámetro adicional a los scripts para poder usar varios directorios. La idea era que mi mujer pudiese estar escuchando un canal y yo otro (cosa que nunca pasará, pero ya puestos…). Me encontré con el problema de que dos instancias de ffmpeg no pueden estar escuchando un stream rtp por el mismo puerto simultáneamente. Para solucionarlo sólo modifiqué los scripts que lanzan los canales para que usen el stream http que es la salida del udpxy, y no el rtp que nos llega desde Movistar.

    Saludos y hasta pronto.

  5. Muchas gracias por tu tutorial,

    A ver si me puedes ayudar.

    Estoy intentando conectar la raspberry al router Movistar+ modelo VG-8050 para convertir multicast a unicast mediante udpxy y no lo consigo.
    Estoy convencido que es alguna configuración del router y me da a mí que es problema de la configuración de IGMP, te paso una captura: http://a/imgur.com/8pY8n

    Mi configuración de IPTV de Imagenio es:
    Imagenio nueva versión (Comtrend VG-8050)
    IPTV Address 10.248.88.24
    IPTV Netmask 255.128.0.0
    IPTV Gateway 10.128.0.1

    Estoy intentando conectarme con un portátil a udpxy sin éxito a través del siguiente enlace (como ejemplo el canal Movistar+ a la IP 192.168.1.11 de la raspberryy al puerto 4022 de udpxy):
    http://192.168.1.11:4022/udp/239.0.5.185:8208
    En cambio mediante multicast sí lo consigo

    Mirando por la configuración del router hay varias cosas relacionadas que me surgen duda de la configuración adecuada:
    – “IGMP Snooping” lo tengo habilitado en las dos interfaces (eth0.2 y eth0.3) en WAN Service y luego también en LAN.
    – “Disable WMM Advertise” lo tengo sin chequear, es decir, activado.
    – “IGMP version” lo tengo por defecto en 2 (y me suena que es posible que tenga que ponerse en 3, al menos así es en OpenWRT).
    – “Enable Wireless Multicast Forwarding” lo tengo deshabilitado ya que no quiero que vaya por wifi, solo por ethernet que es a lo que conecto la raspberry pi.

    A ver si me puedes ayudar, muchas gracias por adelantado!!!

    1. Hola Magarto,

      Disculpa la demora en responderte. He visto que has pedido ayuda también en ADSL Zone; ¿has probado a cambiar el puerto de la URL que quieres reproducir por donde está escuchando tu servidor udpxy? Lo arrancas con el 4024 pero le estás solicitando la reproducción por el 4022.

      Mira a ver si es eso, un saludo!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados con *