Etiqueta: codec

La Inteligencia Artificial de Meta crea algo que podría revolucionar la VoIP
Después de muchos años, la Inteligencia Artificial por fin está revolucionando muchos campos de la informática, pero uno que podría afectar también (además de mejorar considerablemente el reconocimiento de voz y la conversión de texto a audio) es la posibilidad de encontrar mejoras en la compresión hasta llegar a niveles nunca visto ni imaginado.
La empresa Meta tiene un departamento de Inteligencia Artificial que pone a trabajar su tecnología al máximo para generar patentes y nuevas oportunidades de negocio, y entre estas creaciones han inventado algo que podría revolucionar la forma de almacenar el audio tal y como lo conocemos: Encodec
Encodec es un codec que promete una calidad de audio similar a la de un MP3, pero con una tasa de compresión 10 veces mejor y sin pérdida de calidad, lo que implica enviar audio estéreo y con calidad idéntica al de un archivo MP3 pero con una tasa de transferencia de 6kb/sec. (incluso menos que G729)
Hay incluso algún ejemplo de audio con una tasa de transferencia de 3kb/sec y con una calidad realmente alucinante para esa tasa de transferencia como podéis escuchar en el ejemplo siguiente:

El esquema de la compresión puede parecer un poco compleja y se podría pensar que un móvil o un teléfono IP estándar no sería lo suficientemente potente como para codificar el audio en tiempo real y no estaría del todo equivocado.
Encodec podría utilizar los procesadores de Inteligencia Artificial del móvil
¿Por qué no se utiliza MP3 como códec en VoIP y sí se utilizan otros como Alaw o G729? Básicamente por el coste de recursos que supone comprimir y descomprimir audio. Hay que pensar que los dispositivos electrónicos suelen fabricarse intentando minimizar costes y añadir un procesador más potente o dedicado puede aumentar el coste. No obstante, los móviles de alta gama ya rondan los 1000€ por lo que incluir procesadores especiales para comprimir audio puede ser una realidad dentro de poco, lo que abriría las puertas a utilizar códecs especiales que mejorarían bastante la calidad de audio frente al típico A-Law o G.729. y ni que decir tiene que muchos teléfonos creados en los últimos años ya incluyen procesadores especiales para cálculo en tareas de Inteligencia Artificial, lo que implica que esos procesadores pueden ayudar bastante a utilizar algoritmos como Encodec que acaba de presentar Meta.
Ejemplos de audio
Los investigadores de Meta han creado una página donde se puede escuchar las típicas comparaciones de calidad de audio entre sonido RAW y sonido comprimido tanto con Lyra de Google como con Encodec de Meta. Los podéis encontrar aquí: https://ai.honu.io/papers/encodec/samples.html
El código fuente de Encodec está publicado en Github en su página para descargarlo y probarlo:
https://github.com/facebookresearch/encodec
2022-11-05
Lyra: El códec low-cost que podría sustituir a Opus
Siempre se ha dicho que la burocracia va siempre uno o dos pasos por detrás, pero cuando hablamos de tecnología, podríamos decir que incluso va años por detrás. No hay más que ver que WebRTC ha tardado más de 10 años en convertirse en un protocolo estándar oficialmente y ha pasado por muchos cambios entre los que destacan varios campos de códecs que, a medida que han ido surgiendo y comprobandose mejores (más calidad y un ancho de banda menor) los desarrolladores se han visto «obligados por la tecnología» a incluirlos dentro de la especificación.
No obstante, hay empresas como Google que corren dos carreras en paralelo y mientras apoyan ciertas prácticas avaladas por la comunidad y los estándares, juegan por otro lado a una liga propia en la que otras empresas compiten por ser la más rápida y la que primero ofrezca la mejor de las bondades a fin de conseguir adelantarse a la competencia y de paso, subir unos cuantos dólares el precio de sus acciones.
Por esta razón, cuando aún los usuarios están descubriendo un códec como Opus, Google anuncia un nuevo códec llamado Lyra, orientado principalmente al envío y compresión del audio de conversación (justamente el que nos interesa en VoIP) y es que Opus es un códec que, podríamos decir que es la «evolución del MP3» mientras que Lyra nace para convertirse en la evolución del Alaw, del Speech o del G.722.
Nota importante: El nombre «Lyra» es el nombre comercial de un software de Sangoma encargado de detectar máquinas de fax y contestadores automáticos (lo que se denomina AMD: Answer Machine Detector) pero no tiene nada que ver, por lo que si queremos descubrir más de este software, deberemos concretar y buscar «Lyrac códec» o algo así.
Comparación de calidad y ancho de banda
Sobre la calidad, es bastante mejor que la que ofrece el códec Opus con el doble del ancho de banda:
Google ha desarrollado este códec pensando en sus propios servicios de comunicación para Android (Google Duo y similares) aunque el código fuente está publicado con licencia Apache 2.0, por lo que en cualquier momento alguien puede utilizarlo para integrarlo en su propio software o en Asterisk, aunque hay alguien que ya lo ha buscado, por el momento no hay nada.
Parece que lo único importante es calidad de audio vs. ancho de banda, aunque en mi opinión el consumo de procesamiento también es importante. Existen muchos códecs que, siendo peores, son elegidos por consumir muy poco procesador y evitar que un móvil se caliente por llevar 10 minutos de conversación, pero de momento no hemos visto información sobre el consumo de procesamiento que tiene Lyra.
Ejemplos de audio
Aquí vamos a ver algunos ejemplos de audio:
Ejemplo de referencia de audio sin compresión y con máxima calidad.
Ejemplo del mismo audio de referencia comprimido con Opus a 6Kb/sec
Ejemplo del mismo audio de referencia comprimido con Lyra a 3Kb/sec
Ejemplo del mismo audio de referencia comprimido con Speech a 3Kb/sec
Nueva generación de códecs también para vídeo
Google también ha anunciado que próximamente sacará un codec de video revolucionario llamado AV1 orientado a principalmente a videoconferencia y que cuenta con muchas características muy interesantes, aunque estas no serán accesible a todo el mundo ya que requerirá de un procesamiento software lo suficientemente importante como para que únicamente los móviles de última generación y ordenadores con procesadores actualizados sean capaz de manejarlos convenientemente.
¿Y todo esto para qué?
Como decía al comienzo del artículo, el objetivo de las empresas tecnológicas es convertirse en el primero, el más avanzado y por lo tanto, conseguir una mejor reputación, opinión, apoyo popular y por ende, mejores beneficios en productos, servicios y precio de las acciones.
De momento, a mi me parece que transmitir una conversación en 3Kb/sec con esa calidad es más que suficiente como para plantear un cambio de estrategia mundial en la calidad de las conversaciones que viajan por Internet, no únicamente las redes telefónicas (que siguen ancladas en un códec Alaw con 64Kb/sec) si no en reducir a la mitad el consumo de las conversaciones entre sistemas (webRTC).
Pensad por un momento que el códec G.729 utiliza 8Kb/sec y ofrece una calidad 10 veces inferior a la del códec Opus consumiendo 6Kb/sec. Si esto no os hace replantear el uso de G729 en vuestras comunicaciones VoIP, no se qué puede hacerlo.
Está claro que al usuario normal no le importa lo más mínimo si está usando un códec u otro mientras pueda hacer una videoconferencia cómodamente y sin cortes ni pérdida de calidad y buscando una integración hasta con la lavadora.
Pero hay que pensar que los nuevos campos como IoT requieren de sistemas que envíen audio y vídeo utilizando un consumo muy bajo de procesador y ancho de banda, por lo que igual Lyra (que no he encontrado información de cuantos recursos de procesamiento requiere) puede ser una buena alternativa.
En un tiempo en el que las conexiones de alta velocidad gracias a la Fibra óptica, a las redes 5G y a los nuevos sistemas de rutado de redes inteligente, buscamos reducir al máximo el consumo del ancho de banda mientras se mejora la calidad, lo cual repercute en un ahorro de recursos, consumo eléctrico y por lo tanto, también en mejorar nuestro mundo.
Más información: https://ai.googleblog.com/2021/02/lyra-new-very-low-bitrate-codec-for.html
2021-06-05
Cual es el ancho de banda necesario para hablar por VoIP
Ahora que estamos viendo en España que los operadores de fibra óptica están ofreciendo conexiones de 300 Mb/seg y que próximamente van a empezar a ofrecer 500 Mb/seg e incluso hasta 1 Gb/seg mediante las nuevas conexiones de fibra óptica y hasta 500 Mb/seg mediante conexiones LTE.
Una de las preguntas clásicas de las personas que empiezan con la VoIP es el ancho de banda necesario para poder hacer llamadas mediante VoIP. Generalmente se utiliza la típica tabla donde, en función del tipo de códec utilizado, se informa del ancho de banda necesario «aproximadamente», incluso, en muchas páginas existe una calculadora de ancho de banda que, introduciendo el número de llamadas y el códec utilizado nos dice el ancho de banda general que hace falta o alguna tabla como la siguiente donde poder ver el ancho de banda ethernet necesario en función del códec utilizado.
Esto es útil si conocemos el códec que utiliza nuestra aplicación, es decir, si utilizamos un softphone que hemos configurado para que utilice G.729 (cuyo audio ocupa 8kb/seg) añadiéndole las cabeceras , ese tráfico consumirá 31,2kb/seg por sentido de la comunicación (31kb/seg de subida y 31kb/seg de bajada).
No obstante, según el códec este tráfico no es algo constante si no que varia ligeramente (± 10kb/seg) en función del tipo de sonido que tenga que codificar. El famoso «ruido blanco» es la señal que más ancho de banda consume al codificar (tanto procesador como en ancho de banda).
Hace poco, con la aparición de las llamadas de voz vía Whatsapp, mucha gente se preguntaba el ancho de banda que era necesario para hacer llamadas. Whatsapp utiliza el códec Opus, un códec increiblemente interesante que ajusta la calidad al ancho de banda disponible, de manera que, cuanto más ancho de banda dispongamos mejor calidad de audio, y cuanto menos ancho de banda, peor calidad, de ahí que no podamos saber exactamente el ancho de banda que utilizaremos para hacer llamadas por Whatsapp.
(más…)
2015-08-18
Códec OPUS para Asterisk
Ya hablamos en Sinologic del que tiene todas las papeletas de convertirse en el códec definitivo: OPUS, así que si no lo conoces, es el momento de que leas qué es Opus.
La pena para una gran parte de los lectores de Sinologic es que Asterisk no soporta actualmente este códec, quizá porque es bastante nuevo y porque el lanzamiento público coincidió en el tiempo con el lanzamiento de otros códecs en los que está basado Opus, por lo que todavía necesitaba algo de tiempo para poder desarrollar el soporte necesario para que Asterisk pudiera trabajar con este códec.
Otro de los motivos es que actualmente hay muy pocos softphones que soportan Opus, por lo que de momento y hasta que las pruebas no consigan que los fabricantes lo implementen en los teléfonos VoIP y en el resto de softphones, el códec, pese a ser prometedor, es difícilmente compatible.
No obstante, tenemos la suerte de que Asterisk es software libre, lo que permite que desarrolladores de todo el mundo puedan tener acceso al código fuente y la libertad para modificarlo a su gusto y sin limitaciones, por lo que a través de un tweet de Olle Johansson nos hemos hecho eco de un parche de Asterisk para permitir el uso del códec Opus (audio) y VP8 (vídeo), necesarios para WebRTC entre otras utilidades.
Lorenzo Miniero, un usuario y desarrollador de Asterisk ha creado un parche para dar soporte a Asterisk del códec Opus y VP8, por ese motivo, ha escrito un magnífico email a la lista de desarrolladores proponiendo su inclusión al código oficial.
(más…)
2013-05-27
Ha nacido un nuevo códec : OPUS
El pasado 11 de septiembre recibió la notificación que uno de los códecs más esperados: OPUS, recibía la categoría de Estándar por la IETF, concretamente la RFC 6716 una categoría que implica, no solo la disponibilidad seria para formar parte de los códecs libremente utilizables, si no que además y por comentarios de muchas personas a las que admiramos y respetamos, es uno de los mejores códecs que existen.
- Bit-rates de 6 kb/s a 510 kb/s
- Sampleado de 8 kHz (narrowband) a 48 kHz (fullband)
- Tamaño de frame de 2,5 a 60 ms.
- Soporte para bit-rate constante (CBR) y variable (VBR)
- Ancho de banda variable en todo su espectro (desde narrowband hasta wideband)
- Soporte para voz y música. 🙂
- Soporte para audio mono y estereo
- Soporte para más de 255 canales (multistream frames)
- Bitrate ajustable dinámicamente, ancho de banda y tamaño de trama.
- Buena robustez y gestión de paquetes perdidos (PLC)
Lo que viene a ser, prácticamente, el mejor códec que existe, ya que según su especificación, es un códec ajustable dinámicamente pudiendo pasar, de la mejor calidad de audio: 48 kHz y un gran consumo de ancho de banda,
Opus Codec es el códec definitivo.
hasta una calidad mínima (8kHz) y un ancho de banda minimalista que compite estupendamente con los códecs más utilizados en situaciones muy críticas (conexiones GPRS, alta latencia, etc…) Por lo que prácticamente y tal y como viene a parecer: El Opus códec es el códec definitivo.
On September 11th received notification that one of the most anticipated codecs: OPUS, received the Standard category by the IETF, RFC 6716 specifically a category that involves not only availability would be to join freely usable codecs, but in addition, and comments from many people I admire and respect, is one of the best codecs that exist.
- Bit-rates of 6 kb/s to 510 kb/s
- Sampled to 8 kHz (narrowband) to 48 kHz (FULLBAND)
- Frame size from 2.5 to 60 ms.
- Supports constant bit-rate (CBR) and variable (VBR)
- Variable bandwidth across the spectrum (from narrowband to wideband)
- Support for voice and music. 🙂
- Support for mono and stereo audio
- Support for more than 255 channels (multistream frames)
- Dynamically adjustable bitrate, bandwidth and frame size.
- Good management robustness and packet loss (PLC)
What becomes, practically, the best codec there, since according to their specification, is a dynamically adjustable codec can spend, the better quality of audio: 48 kHz and a large bandwidth consumption to a minimum quality (8kHz) and a bandwidth beautifully minimalist racing with the codecs used in critical situations (GPRS connections, high latency, etc …) As far as practically and comes to seem: The Opus codec is the codec definitive.
(más…)
2012-09-24
Asterisk será compatible con SILK
Ayer leí en el twitter de Saúl Ibarra que el equipo de desarrolladores de Asterisk acaba de terminar una primera versión del códec de Skype: SILK. Un códec que permite una compresión interesante, una calidad de audio bastante aceptable pero sobre todo es interesante en conexiones con pérdida o con microcortes.
```
SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf
Negotiation of SILK attributes in chan_sip.
```
Como hemos comentado en otras ocasiones, Skype utilizaba el códec de Global IP Sound (GIPS) para transmitir el audio y tras empezar a desarrollar su propio códec: SILK, decidió liberarlo para que se popularizase en otros entornos (está claro que si un código se libera y este es bueno, la popularidad llega sola).
Desconozco las repercusiones que puede tener este códec y si realmente será utilizado para futuras implementaciones de terminales IP o softphones, pero sin duda puede ser un códec bastante interesante para interconectar Asterisk entre sí (quizá como sustituto del G.729) por su calidad de audio, su nivel de compresión pero sobre todo por su gran tolerancia a microcortes.
Eso sí, para poder probarlo, de momento tendremos que utilizar la versión de Asterisk que hay en la rama Trunk.
Enlace: http://svn.digium.com
2011-02-23
El códec H.264 queda libre de patentes para siempre
Uno de los mayores debates del año es sin duda el establecimiento de un códec de vídeo ligero, rápido y que permita una gran compresión para transmitir vídeo a través de Internet. Adobe lleva varios años utilizando el conocido ‘flv‘ (Flash junto con H.264) para codificar vídeos y tuvo tanto éxito que fue el códec que utilizaba Youtube para reproducir los vídeos que los usuarios subían a su web. Apple por su lado, defendía la independencia de Adobe y quería imponer los vídeos ‘mov‘ codificados con H.264 y Google por su lado, empezó a desarrollar un nuevo códec llamado VP8 completamente libre para que pueda ser utilizado de forma completamente libre sin pagar patentes.
No obstante, el códec actualmente más utilizado, H.264, del que hemos hablado en varias ocasiones, parecía que iba a ser libre, luego dio varios giros de tuerca y finalmente parece que sería libre hasta el año 2016, fecha a partir de la cual, habría que volver a pagar patentes si se quería utilizar, crear o reproducir algún vídeo codificado con este códec.
Anoche, la empresa dueña de la patente del códec H.264 (MPEG-LA) anunció que el códec H.264 pasará a ser gratis para siempre (no llega a ser libre, pero sí «libre de pagar royalties»), por lo que parece que será el fin de este debate que ha durado tanto tiempo.
(más…)
2010-08-27
Guerra de códecs
Tal y como se pronosticó hace tiempo, las principales empresas informáticas empiezan a posicionar sus piezas a la espera de obtener el apoyo necesario y que los usuarios residenciales empiecen a demandar de forma multitudinaria, servicios de voz y vídeo sobre redes IP.
Estas dos semanas han sido bastante movidas en cuanto a algunas piezas clave de la VoIP como son los códecs, las patentes, permisos y licencias de manera que están surgiendo cambios que pueden hacer cambiar bastante el panorama actual tanto para bien como para mal.
Hace unas semanas, toda la blogosfera se hizo eco de la guerra abierta entre Apple y Adobe por el soporte de Flash en los productos de Mac. El CEO de Apple (Steve Jobs) dirigió duras críticas sobre el formato de Adobe y el porqué no pensaba incluir este formato dentro de sus productos portátiles. De esta forma, defendía el uso de los estándares y el uso del códec H.264 para poder ver vídeos.
Por otro lado, Google fue más allá y no sólo defendió el uso de estándares si no que le puso nombre: HTML5 y Theora, un formato que es, de hecho, la alternativa libre al códec H.264 que estuvo muy cerca de ser completamente libre pero que al final, se ve que no pudo ser.
Apple y Microsoft defienden el códec H.264 como la próxima evolución del vídeo en internet, siempre y cuando aquella empresa que quiera implementar algún software con este códec pase por caja.
Antes que alguien lo pregunte, en Europa (donde no existen patentes software) sí que existen patentes por códecs ya que lo que se patenta no es el algoritmo, si no un «método matemático de compresión» y esta sí es patentable. 🙁
Asterisk se encuentra ahora con un dilema que deberá resolver, seguir utilizando H.264 como códec a utilizar en vídeo (desconozco si sería legal utilizarlo a la vista que no es libre), o bien saltar a otros códecs más libres como Theora.
Google acaba de anunciar la liberación de otro códec de vídeo llamado VP8 cuyo contenedor está basado en Matroska -Gracias Manwe- (los famosos archivos de vídeo con extensión ‘mkv‘) además de organizar una plataforma pro-estándares-libres para la web llamada WebM que seguro que dará que hablar los próximos días.
Para colmo, la noticia saltó hace unos días cuando Google anunció que ofrecía varios millones de dólares para poder comprar la famosa empresa Global IP Sound de la que ya hemos hablado en varias ocasiones y que se dedica a la creación de códecs de audio como los que hizo famoso a Skype y que utiliza actualmente GoogleTalk. La compra de GIPS por parte de Google junto con todos los servicios que rodean la VoIP del gigante (GoogleVoice, GoogleTalk, GoogleWave, …) podrían ser los movimientos que le faltan para empezar a comer piezas y quedarse con el tablero.
Como pensamiento en voz alta, tras ver todos estos movimientos, y siguiendo con la analogía de la partida de ajedrez, intento imaginar cual podría ser el último movimiento antes del final del ‘medio juego‘ y que todo esté potencialmente decidido: Google sólo le haría falta adquirir una empresa muy conocida, y que últimamente está dando pequeños pasos a favor del software libre, que empieza por S y termina por kype y, con esta empresa y con su antigua competencia (Gizmo5) bajo su techo, tiene toda las papeletas de ser el gran gigante de la VoIP mundial para el gran público. ¿o no?
2010-05-20
Los softphones se apuntan al audio HD
La moda del audio de alta definición (audio HD) está asaltando a todos los terminales. Uno realmente no se da cuenta del cambio de calidad hasta que lo prueba y aprovechando que la inmensa mayoría de terminales soportan el G.722 (un códec libre que permite trascoding en Asterisk 1.6) muchas personas se están animando a incluirlo como códec para uso interno donde la calidad es más importante que el ahorro del ancho de banda.
Pero los terminales IP no son los únicos que ofrecen esta característica ya que recientemente han salido dos de los softphones gratuitos más utilizados (Eyebeam y Zoiper) con soporte para códecs HD como así podemos ver en sus respectivas páginas:
Concretamente Zoiper soporta estos códecs:
Imagen de Graves On SOHO VoIP
Mientras que el Eyebeam soporta estos códecs:
No todos los softphones soportan este tipo de códec de audio, pero si teneis alguno de estos softphones, os animo a que probeis a realizar una conversación con G.722 y otra con Alaw y comprobar la calidad de audio, ya me direis. ;D
2009-12-10
Broadcom lanza un códec HD con licencia GPL
Hace unos días escribí un artículo sobre el códec G.722 que ofrece el doble de calidad de voz que una llamada telefónica, por lo que es realmente interesante utilizarlo en multiconferencias de manera que permita identificar a las distintas personas que están hablando.
El códec G.722 es libre (las patentes expiraron) por lo que ahora las empresas hacen «versiones» de este códec para poder volver a patentar estas modificaciones.
Broadcom (la empresa que hay detrás de los dispositivos de red) acaba de anunciar la disposición pública y libre de un códec que muestrea a 16Khz:
BroadVoice16 (BV16) for narrowband telephone-bandwidth speech sampled at 8 kHz,
and a 32 kb/s version called BroadVoice32 (BV32) for wideband speech sampled at 16 kHz.
Las ventajas las indica claramente en su página:
- Low Delay (Latency): algorithmic buffering delay of merely 5 ms (compared with 15 to 40 ms of most competing codecs)
- Low Complexity: much lower MIPS requirements than most competing codecs (typically 1/3 to 1/2 of comparable ITU-T G.72x codecs), also lower memory requirement than most competing codecs
- High Quality: equivalent or better speech quality than most competing codecs in PESQ comparisons and in extensive formal subjective MOS listening tests conducted by AT&T Labs, COMSAT Labs, and Dynastat, Inc
- Moderate Bit-Rate: at 2 bits/sample, coding efficiency is higher than G.711, G.726, and G.722 and comparable to many other codecs
- Availability: Broadcom is providing both the floating-point and fixed-point C source code of BroadVoice16 and BroadVoice 32 under an open source license and on a royalty-free basis
Ahora sólo falta que la licencia LGPL sea suficiente para que se popularice y podamos disfrutar en nuestros sistemas de soporte para este códec.
Más detalles:
http://www.broadcom.com/support/broadvoice/
2009-11-11