Codecs y Formatos - Historial de revisiones

SirLouen en 16:45 6 jul 2014

2014-07-06T16:45:03Z

SirLouen: /* Compromisos */

2012-06-07T19:22:20Z

Compromisos

SirLouen: /* Reconocimiento */

2012-06-07T19:21:29Z

Reconocimiento

SirLouen en 19:20 7 jun 2012

2012-06-07T19:20:07Z

SirLouen en 19:19 7 jun 2012

2012-06-07T19:19:34Z

SirLouen en 11:47 11 may 2012

2012-05-11T11:47:07Z

SirLouen: Página creada con «{{Format}} {{ToDo}} Como es común en toda comunicación de múltiples medios (multimedia), es necesario utilizar un "lenguaje" común durante la trasmisión, y en caso de...»

2012-05-11T11:20:03Z

Página creada con «{{Format}} {{ToDo}} Como es común en toda comunicación de múltiples medios (multimedia), es necesario utilizar un "lenguaje" común durante la trasmisión, y en caso de...»

Página nueva

{{Format}}
{{ToDo}}

Como es común en toda comunicación de múltiples medios (multimedia), es necesario utilizar un "lenguaje" común durante la trasmisión, y en caso de querer almacenarla en nuestro sistema algun tipo de formato.

Para ello Asterisk utiliza toda una serie de Codecs y Formatos, tanto de video, como de audio, incluso de Imagen segun veremos a continuación

__TOC__

== Reconocimiento ==

Para poder conocer que codecs y formatos es posible usar en nuestro sistema, accediendo a la [[CLI]] con el siguiente comando:

{{CLI| core show codecs}}

Nos aparecerá una lista especificando algunos datos con respecto a los mismos, concretamente útiles, el identificador asociado, el nombre utilizado por asterisk, el tipo y una pequeña descripción.

Para ampliar detalles, por ejemplo del codec ULAW, consultando, el identificador número 4:

{{CLI| core show codec 4}}

Nos aparece la información específica del mismo.

== Compromisos ==

[[Image:triangulo_compromiso.png|thumb|Triangulo de Compromisos|right|200px]]

En términos generales un codec básicamente es un algoritmo de compresión y descompresión, que aprovecha la potencia de las CPU para realizar una labor de mejor o peor calidad.

Como todos los algoritmos, nos encontramos ante un triangulo en el cual, si preferimos optar por tender hacia un vértice, sacrificamos el resto. En este caso los vértices serían:

* Uso de recursos de CPU
* Consumo de Ancho de Banda
* Calidad de la comunicación

Si creamos un algoritmo muy sofisticado que sea capaz de comprimir bastante el medio, y nos ofrezca una calidad de comunicación bastante aceptable, lo más probable es que estemos sacrificando una gran cantidad de Recursos de la CPU

En contrapartida, si queremos utilizar un algoritmo bastante lineal, y conservar la calidad en la comunicación, lo típico sería que el consumo de ancho de banda sea demasiado alto.

Si elegimos sacrificar la calidad en la comunicación entonces podremos permitirnos un consumo de ancho de banda ajustado, y un algoritmo relativamente lineal.

Eventualmente existen algoritmos muy sofisticados que son capaces de rendir en términos generales (menor uso de recursos, menor consumo, y máxima calidad) mucho mejor que otros menos elaborados. Pero como suele venir siendo común estos códecs están protegidos detrás de licencias de uso bastante caras y que eventualmente será decisión nuestra valorar el coste general (TOC) de la solución dado que si manejamos un alto nivel de comunicaciones, el rendimiento global podría verse afectado, y con el pago de esas licencias, conseguir un ahorro de costes a nivel de infraestructura tanto de Servidor como de Comunicaciones.

== Codecs ==

=== Audio ===

==== ulaw ====

Este codec, es realmente conocido como [http://www.itu.int/rec/T-REC-G.711-198811-I/en G.711] pero en su versión específica para Estados Unidos. Es el tipo de codificación que utilizan los teléfonos en la red clásica de telefonía en EEUU y Canadá. Ofrece un flujo de datos de 64 kbit/s lo que puede resultar bastante alto comparado a sus "competidores" (aunque para la telefonía estándar, es un flujo de datos común). Esos 64 kbit/s recuerdan al ancho de banda, obtenido por los MODEM que se utilizaban antiguamente para conectarse a Internet y es justamente por esto, las lineas de voz, ocupaban el 100% de su ancho de banda utilizando este códec.

==== alaw ====

Es equivalente al codec ulaw, pero es el utilizado en Europa. Para configuraciones hechas en España es muy conveniente permitir este codec, y forzar los dispositivos a utilizar este códec, (u otro mejor) para intentar evitar la transcodificación.

==== gsm ====

Este codec es muy reconocido dado que se utiliza regularmente en los canales de las lineas móviles. Sus siglas hacen referencia a Global System for Mobile communications, es decir, Sistema Global para las comunicaciones móviles. Realmente no prima en la calidad sino en la cantidad, ya que el flujo de datos en una conexión Full-Rate es de solo 13kbit/s. Es un buen método para ahorrar ancho de banda ya que es casi consume 5 veces menos que el códec alaw, aunque si trabajamos en conexiones de mala calidad a nivel de tiempo de respuesta (tiempo que tarda en ir y volver un paquete enviado) o de jitter (desviación estándar del tiempo de respuesta), la voz podría llegar a distorsionarse tanto hasta ser incomprensible.

==== ilbc ====

Uno de los codecs más interesantes, creado por una empresa que compró Google, y aplicable a múltiples programas conocidos de conversación por voz, como un softphone muy popular en Linux llamado Ekiga, la convertida empresa Gizmo5 al conocido Google Voice, y como no podía ser menos, Google Talk.

Puede llegar a ofrecer niveles de calidad superiores al poderoso G729.a (vemos más adelante), y a cambio es distribuido con una licencia no Open Source, pero si de uso bastante libre, incluso es posible modificar el código. Si el dispositivo lo permite, sin duda es una gran opción permitir el uso de este códec. El flujo de datos es de tan solo 13,3 kbit/s, equivalente a GSM pero con infinita mayor calidad. El problema como suele ser lógico, es que a no ser que tuviese el algoritmo definitivo (que no es el caso), consume demasiados recursos en la CPU comparativamente al resto de los codecs.

==== speex ====

Otro códec bastante interesante desarrollado por la comunidad Xiph (también conocida por formatos reconocidos como Vorbis, Flac), y por el hecho de ser uno de los pocos 100% Open Source (Licencia BSD), y muy ajustable a nivel de nuestro sistema Asterisk. Cuando hablamos de ajustable, nos referimos a nivel de configuración (codecs.conf) podríamos elegir variar el compromiso de consumo de CPU a costa del consumo de ancho de banda o la calidad y llegar a conseguir la ajustada cantidad de solo 2kbit/s en caso que fuera necesario <ref>[http://www.speex.org/ Speex Codec], Fundación Xiph</ref>

== Referencias ==

<references />

== Véase también ==

* [[SIP]]
* [[IAX]]

== Enlaces Externos ==

* [http://www.xiph.org Fundación Xiph] es una comunidad para el desarrollo de códecs y formatos de alta calidad Open Source.

[[Categoría:General]]

← Revisión anterior		Revisión del 16:45 6 jul 2014
Línea 4:		Línea 4:

	Para ello Asterisk utiliza toda una serie de Codecs y Formatos, tanto de video, como de audio, incluso de Imagen segun veremos a continuación		Para ello Asterisk utiliza toda una serie de Codecs y Formatos, tanto de video, como de audio, incluso de Imagen segun veremos a continuación
		+
		+	{{Centrar\|{{#Widget:AdSense}}}}

	__TOC__		__TOC__

← Revisión anterior		Revisión del 19:21 7 jun 2012
Línea 24:		Línea 24:

	En teoría si en un punto, tenemos un teléfono última generación con un codec muy eficiente, y en el otro punto tenemos un teléfono IP muy antiguo, que utiliza un códec obsoleto, nos encontramos ante otro problema adicional. Si decidimos que el teléfono nuevo por defecto utilice el codec de máxima calidad, al llegar el audio a nuestra máquina Asterisk, esta debe convertirlo (transcoding) al estilo del códec del dispositivo más antiguo, y esta conversión en ocasiones puede suponer un consumo de CPU aun superior, que el de la propia codificación y descodificación de los medios.		En teoría si en un punto, tenemos un teléfono última generación con un codec muy eficiente, y en el otro punto tenemos un teléfono IP muy antiguo, que utiliza un códec obsoleto, nos encontramos ante otro problema adicional. Si decidimos que el teléfono nuevo por defecto utilice el codec de máxima calidad, al llegar el audio a nuestra máquina Asterisk, esta debe convertirlo (transcoding) al estilo del códec del dispositivo más antiguo, y esta conversión en ocasiones puede suponer un consumo de CPU aun superior, que el de la propia codificación y descodificación de los medios.
		+
		+	En cuanto a los formatos, la forma de conocer cuales tenemos disponibles sería utilizando el comando dentro de la [[CLI]] siguiente:
		+
		+	{{CLI\|core show file formats}}

	== Compromisos ==		== Compromisos ==

← Revisión anterior		Revisión del 19:20 7 jun 2012
Línea 122:		Línea 122:

	El formato más conocido entre todos, hace referencia a MPEG Layer III, y posee licencias muy especiales de distribución. Es por estas por lo que su desarrollo dentro de Asterisk ha de hacerse de forma individual, y es altamente recomendable transformar los ficheros MP3 a otro formato más práctico para Asterisk antes de trabajar con ellos. Se considera al igual que OGG, un formato de compresión, con significativas perdidas de calidad en función de la misma		El formato más conocido entre todos, hace referencia a MPEG Layer III, y posee licencias muy especiales de distribución. Es por estas por lo que su desarrollo dentro de Asterisk ha de hacerse de forma individual, y es altamente recomendable transformar los ficheros MP3 a otro formato más práctico para Asterisk antes de trabajar con ellos. Se considera al igual que OGG, un formato de compresión, con significativas perdidas de calidad en función de la misma
−
−	~~====~~

	== Referencias ==		== Referencias ==

@@ Línea 33: / Línea 33: @@
 [[Image:triangulo_compromiso.png|thumb|Triangulo de Compromisos|right|200px]]
-En términos generales un codec básicamente es un algoritmo de compresión y descompresión, que aprovecha la potencia de las CPU para realizar una labor de mejor o peor calidad.
+En términos generales un '''codec''' básicamente es un algoritmo de compresión y descompresión, que aprovecha la potencia de las CPU para realizar una labor de mejor o peor calidad. Lo mismo se aplica para los '''formatos''' pero concretamente en el momento de escritura en fichero de almacenamiento.
 Como todos los algoritmos, nos encontramos ante un triangulo en el cual, si preferimos optar por tender hacia un vértice, sacrificamos el resto. En este caso los vértices serían:

@@ Línea 1: / Línea 1: @@
 {{ToDo}}
@@ Línea 89: / Línea 88: @@
 Podríamos considerar el uso de codecs libres u Open Source como los comentados anteriormente, pero nos encontramos ante la dificultad que muchos terminales no lo soportan. Si los teléfonos no pasan por un sistema Asterisk intermedio, y conectar directamente con la central, hay que tener en cuenta, que este codec suele venir implícito en una gran cantidad de teléfonos físicos, lo que aporta un valor añadido aún superior.
 == Referencias ==
@@ Línea 98: / Línea 133: @@
 * [[SIP]]
 * [[IAX]]
 == Enlaces Externos ==

@@ Línea 21: / Línea 21: @@
 Nos aparece la información específica del mismo.
 == Compromisos ==
@@ Línea 68: / Línea 72: @@
 Otro códec bastante interesante desarrollado por la comunidad Xiph (también conocida por formatos reconocidos como Vorbis, Flac), y por el hecho de ser uno de los pocos 100% Open Source (Licencia BSD), y muy ajustable a nivel de nuestro sistema Asterisk. Cuando hablamos de ajustable, nos referimos a nivel de configuración (codecs.conf) podríamos elegir variar el compromiso de consumo de CPU a costa del consumo de ancho de banda o la calidad y llegar a conseguir la ajustada cantidad de solo 2kbit/s en caso que fuera necesario <ref>[http://www.speex.org/ Speex Codec], Fundación Xiph</ref>
 == Referencias ==
@@ Línea 84: / Línea 102: @@
 * [http://www.xiph.org Fundación Xiph] es una comunidad para el desarrollo de códecs y formatos de alta calidad Open Source.
 [[Categoría:General]]