Calidad del video de la guía del servicio (QOS)
Contenido
Introducción
Este los documentos revisa el tema de la calidad de la llamada video y proporcionan una guía en las cosas para tener presente mientras que el Calidad de Servicio (QoS) se configura en una frontera unificada Cisco Element(CUBE) o un gateway del Time-Division Multiplexing (TDM).
Contribuido por Baktha Muralidharan, ingeniero de Cisco TAC, editado por Anoop Kumar.
Prerrequisitos
Requisitos
Este documento es el más beneficioso para los ingenieros familiares con la voz sobre IP (VoIP), aunque otros pudieran encontrarla útil.
Componentes Utilizados
No hay soporte físico o software específico usado para escribir este documento.
Antecedentes
El audio digitalizado en su forma más simple es un conjunto de las muestras audios, cada muestra que describe la presión sonora durante ese período. El audio conversacional se puede capturar y reproducir a un nivel alto de exactitud, con apenas 8000 muestras por second[1]. Esto entonces significa que mientras la red pueda transportar las muestras sin el Retraso excesivo, el jitter y la pérdida del paquete, audio se puede reproducir fielmente en el otro extremo.
En cambio la presentación, el proceso y el transporte del vídeo es mucho más complejos. El brillo, el contraste, la saturación de color, la sensibilidad (indicar) y la sincronización audio/video son apenas algunos de los atributos que determinan la calidad del vídeo. Las muestras video requieren generalmente un espacio mucho más grande. Naturalmente, el vídeo pone una demanda mucho más grande en el ancho de banda de la red, en la red de transporte. La calidad del audio se determina por: El Presidente del micrófono en la calidad de la llamada video de la red de transporte de la compresión de códec de las auriculares se afecta por: Compatibilidad/Interoperabilidad de la red de transporte de los códec de video del Dispositivo de visualización de la cámara
Objetivo
QoS en general es un extenso y el tema complejo que requiere la consideración de los requisitos de tráfico totales (bastante que apenas el tráfico que usted desea mejorar la calidad de) y de las necesidades de ser comprobado cada componente de la red a lo largo de la trayectoria de los media fluye. La realización del calidad del video en un Video conferencia. es aún más compleja pues implica además de los componentes de la red, del estudio y del examen de la configuración y de ajustar en los puntos finales. Ampliamente, el calidad del video exige esto:
- Punto final que adapta optimizando la configuración de los puntos finales (e.g resolución, trama por segundo)
- Optimización del transporte que optimiza la red para transportar el tráfico de video por el SLA de red.
- Las llamadas muy a menudo video de las consideraciones de la Interoperabilidad implican los puntos finales de las capacidades variadas. El diseño y configurar de los sistemas para maximizar la Interoperabilidad pueden afectar el calidad del video.
El foco específico en este documento será las consideraciones de QoS en el gateway del IOS o el CUBO al manejar el vídeo llama.
El ajustar en los puntos finales implicaría ajusta un conjunto de parámetros en los punto final de video. Esto por supuesto depende del producto pero aquí es algunos “botones generales”:
- Resolución (es decir tamaño de imagen)
- Velocidad de tramas (es decir sensibilidad/realidad del movimiento)
- El marcar con etiqueta (es decir marca TOS)
Ajustar la red para el vídeo implica generalmente el siguiente:
- Entendiendo la composición del tráfico que atraviesa el CUBO e.g enarbole el volumen etc. del [call].
- Repaso de la capacidad del link de red/del tubo
- El diseño de las directivas apropiadas de QoS, para asegurar SLA se resuelve para cada clase de tráfico
La Interoperabilidad entra en el juego cuando es heterogéneo (telefonía con video así como el TelePresence (el TP)) los sistemas participan en una llamada en conferencia. La experiencia proporcionada por un sistema TP y de teléfono con video es fundamental diferente. La Interoperabilidad entre ellos es alcanzada generalmente interligandolos usando un proceso conocido como conexión en cascada.
Qué esto no cubre
Esto no es un documento de diseño y no un documento video completo de QoS cualquiera. Este documento no cubre específicamente estos temas:
- Señalando el [protocols] de las llamadas video, más allá de qué se requiere para ilustrar los aspectos qos-relacionados.
- Punto final de video puesto/configuración
- Estudio completo de los mecanismos de Calidad de servicio (QoS) incluyendo el policing, los Datos en espera, el shaping y la explosión
- Estudio de los config de QoS en los 2 Switch de la capa o las consideraciones del límite de confianza.
Características del tráfico de la red del vídeo
El vídeo, como el audio es en tiempo real. Las transmisiones de audio están Velocidad de bits constante (CBR). En cambio, el tráfico de video tiende a ser bursty y se refiere como siendo la Velocidad de bits variable (el VBR.) Por lo tanto la velocidad de bits para el transmisión de video no será necesariamente constante, si necesitamos mantener cierto quality[2].
Imagen 1
La determinación del ancho de banda y de repartir requeridos para el vídeo es también implicada. Esto se discute más adelante en este documento.
- El tráfico de video es bursty.
- Los paquete de video pueden ser muy grandes.
- El audio es siempre CBR. El vídeo es típicamente VBR.
¿Por qué es el vídeo bursty?
Las mentiras de la respuesta en el vídeo de la manera son comprimidas. Recuerde que el vídeo es una secuencia de imágenes (tramas) jugadas para proporcionar un efecto visual del movimiento. Las técnicas de compresión usadas por el codecs video utilizan un acercamiento llamado Delta encoding[3], que trabaja salvando los valores de los bytes como diferencias (deltas) entre los valores secuenciales (de las muestras) bastante que los valores ellos mismos. El vídeo se codifica (y se transmite por consiguiente) como tramas consecutivas que llevan apenas las “piezas móviles” bastante que los toda la trama.
¿Usted se está preguntando probablemente porqué, el audio cambia ampliado también? Bien, verdad bastantes, pero el “movimiento” (o las dinámicas) no afecta el audio casi tanto como hace el vídeo. Las muestras audios de 8 bits no comprimen mejor cuando lo hace el delta codificado, las muestras video (tramas). El cambio relativo de la muestra (trama a enmarcar) a muestrear es video es mucho más pequeño que ése en el audio. Dependiendo de la naturaleza y del grado de movimiento, las muestras video pueden variar grandemente de tamaño. La imagen 2 ilustra la compresión video
Imagen 2
Una trama del ‑ I es una imagen Intra-cifrada, en efecto una imagen completamente especificada, como un archivo de imagen estático convencional.
Una trama del ‑ P (imagen prevista) lleva a cabo solamente los cambios en la imagen de la trama anterior. El codificador no necesita salvar los pixeles constantes del fondo en la trama del ‑ P, así el espacio del ahorro. Las tramas del ‑ P también se conocen como tramas del ‑ del delta.
Una trama del ‑ B (imagen BI-profética) guarda aún más espacio usando las diferencias entre la trama actual y las tramas anteriores y de siguientes para especificar su contenido.
Medida de calidad del video
El engranaje del video de Cisco no mide ni señala sobre el calidad del video como tal, así que el calidad del video se percibe bastante que medido. Hay los algoritmos estandardizados que miden la calidad mediante un MOS (Mean Opinion Score). Sin embargo, si los problemas señalados sobre la calidad del audio son cualquier indicación, los casos del calidad del video (TAC) son más probables ser abiertos porque el usuario percibió los problemas de calidad bastante que los informes por una herramienta.
Controles en los puntos finales
Los factores que afectan al calidad del video incluyen:
- los códec de video (MPEG4, H261, H263, H264 y H265)
- tamaño (a/8o pantalla, 1/4 pantalla, pantalla completa)
- tramas por segundo de la velocidad de tramas (1 a 30, valor por defecto 6)
- la configuración de la calidad de la compresión (punto bajo, media, altos)
Cada uno del antedicho es generalmente a elección/controlable en los puntos finales.
Artefactos visibles
El acolchar, el peinarse y el vendaje se acostumbran a estos términos, la taxonomía video de la debilitación de la parte de.
Red de transporte SLA para el calidad del video
El SLA de red recomendado para video[4] es como sigue:
- ≤ 150 del tiempo de espera – 300ms
- Ms del ≤ 10 del jitter – 50ms
- ≤ 0.5% de la pérdida
A propósito el SLA de red recomendado para transportar el audio está:
- ≤ 150 del tiempo de espera – 300ms
- Ms del ≤ 20 del jitter – 50ms
- ≤ el 1% de la pérdida
Controles en la red de transporte
SLA para el transporte video se puede entregar generalmente usando las directivas de QoS que son muy similares a ésas usadas para el transporte audio. Hay algunas diferencias sin embargo debido a la naturaleza del tráfico de video.
Variedades video
¿Es todo el vídeo lo mismo? Bien, no muy. Las variaciones del vídeo como media incluyen:
- Telefonía con video/videoconferencia
- Interactivo en tiempo real
- Un ancho de banda relativamente más bajo. Hasta aproximadamente 1Mbps
- TelePresence
- Interactivo en tiempo real
- Experiencia de Immersive
- Requiere mismo el ancho de banda alto
- El fluir
- Tiempo real, unidireccional
- Puede ser el unicast o el Multicast
- Ancho de banda alto
- No retardo sensible (el vídeo puede tardar varios segundos para hacer cola para arriba)
- En gran parte insensible estar inquieto (debido a mitigar de la aplicación)
- La pérdida debe ser el no más que 5 por ciento.
- El tiempo de espera debe ser no más que 4 a 5 segundos (dependiendo de las capacidades que mitigan del aplicación de video)
- Un poco de vídeo (e.g entretenimiento) se pudo considerar para el servicio del limpiador.
Codecs del tráfico de video
-
- H.261- el codificador-decodificador fue diseñado originalmente para la transmisión sobre las líneas ISDN. Con el uso de la vinculación video, las velocidades de bits video son múltiplos de 64 kbit/s.
- H.263 - El codificador-decodificador se utiliza en la Videoconferencia basada en IP así como en las redes ISDN. El H.263 requiere la mitad del ancho de banda alcanzar el mismo calidad del video que en el H.261. Como consecuencia, el H.263 ha substituido en gran parte el H.261. El H.263 se ha optimizado para una amplia gama de velocidades de bits y no apenas de 64K bits/s como con el H.261.
- H.264/MPEG-4 - Cs actualmente uno de los formatos y de las aplicaciones más de uso general medios o menos la velocidad de bits MPEG-2, H.263, o MPEG-4 de la parte 2.
- H265 - Uno de varios sucesores potenciales al H.264 ampliamente utilizado y basados en la extensión de los mismos conceptos. Soporta las resoluciones hasta 8192×4320, incluyendo 8K UHD.
Mecanismos de Calidad de servicio (QoS) para el vídeo
En principio los mecanismos de Calidad de servicio (QoS) empleados para entregar los SLA para una red de transporte video son sobre todo lo mismo que ésos para el audio. Hay algunas diferencias sin embargo, sobre todo debido a la naturaleza de congestión del vídeo y de la transmisión VBR.
Hay dos acercamientos a QoS, a saber Interated Services(intserv) y Services(diffserv) distinguido.
Piense en Intserv como actuando en el nivel y el DiffServ de señalización en el media-nivel. Es decir el modelo del intserv asegura la calidad actuando en el avión del control; el DiffServ apunta asegurar la calidad oeprating en el nivel del avión de la fecha.
En arquitectura intserv los dispositivos de red haga los pedidos las reservas de ancho de banda estáticas y mantenga el estado de todos los flujos reservados mientras que realiza la clasificación, marca y los Datos en espera mantienen estos flujos; arquitectura intserv actuar-e integrar-ambo el avión del control y el avión de los datos, y pues tal ha sido en gran parte abandonado debido a las limitaciones de ampliación inherentes. El protocolo usado para hacer las reservas de ancho de banda es RSVP (Resource Reservation Protocol).
Hay también el modelo de IntServ/del DiffServ, que es clase de una mezcla. Este modelo separa las operaciones planas del control de las operaciones del avión de los datos. La Operación RSVP se limita al control de admisión solamente; con los mecanismos del DiffServ que manejan la clasificación, marca, policing y programando las operaciones. Como tal, el modelo de IntServ/del DiffServ es altamente scalable y flexible.
Garantía de ancho de banda
El ancho de banda es obviamente el parámetro más fundamental de los qos. Esto depende de varios parámetros, especialmente:
- Codificador-decodificador usado
- Velocidad de tramas
- Tamaño de la imagen
- Volumen de llamada (pico y media)
El viejo truco del ancho de banda que lanza en el problema no es siempre la solución. Esto es especialmente verdad para el calidad del video. Por ejemplo, con CUVA (Cisco Unified Video Advantage) no hay mecanismo de sincronización entre los dos dispositivos (teléfono y PC) implicados. Así QoS se debe configurar para minimizar el jitter, el tiempo de espera, los paquetes fragmentados, y los paquetes defectuosos.
Finalmente es importante entender que el VoIP desemejante allí no es ninguna fórmula limpia para calcular el ancho de banda ampliado requerido. Ésta es porque los tamaños y las velocidades de paquetes de paquete de video varían perceptiblemente y es en gran parte una función del grado de movimiento dentro de los imagen de video que son transmitidos. Más en esto más adelante.
Envío a cola
El Low Latency Queuing (LLQ) es la política de colocación encola preferida para el audio VoIP. Dado el retardo/el jitter rigurosos los requisitos sensibles del TP y la necesidad de sincronizar audio y video para CUVA, los Datos en espera de la prioridad (LLQ) es recomendados para todo el tráfico de video también. Observe que, para el vídeo, el ancho de banda prioritario es eludido generalmente para arriba por el 20% para explicar los gastos indirectos.
Compresión de encabezados
No recomendado para el vídeo.
Fragmentación de link e interpolación
El LFI es un mecanismo popular a asegurarse que el jitter no sale del control en los links lentos, donde los retrasos de serialización pueden ser altos.
Sin embargo el Interactivo-vídeo no se recomienda para los links lentos. Esto es porque el LLQ al cual el tráfico de video se asigna, no está conforme a la fragmentación. Esto significa que los paquetes grandes del Interactivo-vídeo (tales como Yo-tramas del FULL-movimiento 1500-byte) podrían causar los retrasos de serialización para paquetes más pequeños del Interactivo-vídeo.
Prevención de congestión
Rechazo selectivo basado en el RTCP
Ráfaga
Este mecanismo de Calidad de servicio (QoS) es un importante para el tráfico de video, que, según lo mencionado anterior, es bursty.
El parámetro de ráfaga opcional se puede configurar como parte de la prioridad command[6].
Con H.264, la explosión a lo peor sería la pantalla completa del vídeo (espacial-comprimido). De acuerdo con las pruebas en profundidad en los sistemas TP, éste se encuentra para ser 64 KB. Por lo tanto el parámetro de ráfaga LLQ se debe configurar para permitir hasta 64 KB de la explosión por la trama por la pantalla. Así el sistema del CTS-1000 que se ejecuta en 1080p-Best (con el soporte opcional de un vídeo auxiliar stream[7]) sería configurado con un LLQ con un parámetro de ráfaga óptimo de 128 (2x64) KB.
¿Cuánto ancho de banda?
¿Así pues, cuánto ancho de banda se requiere para transportar una llamada video fielmente? Antes de que consigamos abajo a los cálculos, es importante entender los conceptos siguientes, que son únicos al vídeo.
Resolución
Esto refiere básicamente al tamaño de la imagen. Otros términos de uso general para esto incluyen el formato y el tamaño de la pantalla video. Los formatos video de uso general se muestran abajo.
| Formato |
Resolución de vídeo (pixeles) |
||
| SQCIF |
128x96 |
||
| QCIF |
176x144 |
||
| SCIF |
256x192 |
||
| SIF |
352x240 |
||
| CIF |
352x288 |
||
| DCIF |
528x384 |
||
|
704x576 |
||
| 16CIF |
1408x1152 |
Amplia mayoría de equipo de la videoconferencia funcionado con en los formatos CIF o 4CIF.
Referencia: http://en.wikipedia.org/wiki/Common_Intermediate_Format
Velocidad de tramas
Esto refiere a la tarifa en la cual un dispositivo de proyección de imagen produce las imágenes consecutivas únicas llamadas las tramas. La velocidad de tramas se expresa como tramas por segundo (fps).
Cálculo del ancho de banda
Los cálculos del ancho de banda para los sistemas del telefonía con video y otros sistemas de videoconferencia tradicionales tienden a ser más simples.
Como un ejemplo, considere una llamada TP con la resolución de 1080 x1920. El ancho de banda requerido se calcula como sigue
2,073,600 pixeles por la trama
colores x3 por el pixel
byte x1 (8 bits) por el color
x 30 tramas por segundo
= 1.5Gbps por la pantalla. ¡Sin comprimir!
¡Con la compresión, un ancho de banda de 4Mbps por la pantalla (el > 99% comprimido) es bastante para transportar la trama antedicha!
La tabla siguiente enumera algunas de las combinaciones
| Imagen |
Luminancia |
Luminancia |
Sin comprimir |
|||
| 10 frames/s |
30 frames/s |
|||||
| Gris |
Color |
Gris |
Color |
|||
| SQCIF |
128 |
96 |
1.0 |
1.5 |
3.0 |
4.4 |
| QCIF |
176 |
144 |
2.0 |
3.0 |
6.1 |
9.1 |
| CIF |
352 |
288 |
8.1 |
12.2 |
24.3 |
36.5 |
| 4CIF |
704 |
576 |
32.4 |
48.7 |
97.3 |
146.0 |
| 16CIF |
1408 |
1152 |
129.8 |
194.6 |
389.3 |
583.9 |
Observe eso sobre los cálculos están para un monopantella. Una llamada TP podría implicar a las pantallas múltiples y por eso, el ancho de banda total para la llamada sería un múltiplo del ancho de banda de la por-pantalla.
Refiera a https://supportforums.cisco.com/thread/311604 para una buena calculadora del ancho de banda para los sistemas de Cisco TP.
Tráfico de video el clasificar/de la marca
¿Cómo el tráfico de video identificado/se distingue? Una manera de clasificar los paquetes en el CUBO está utilizando las marcas DSCP.
La tabla siguiente ilustra las marcas DSCP por la línea de fondo así como el RFC 4594 de Cisco QoS.
| Tráfico |
Capa 3 PHB |
Capa 3 DSCP |
| Señalización de llamada |
CS3 |
24 |
| Voice |
EF |
46 |
| Video conferencia. |
AF41 |
34 |
| TelePresence |
CS4 |
32 |
| El fluir de las multimedias |
AF31 |
26 |
| Video de broadcast |
CS5 |
40 |
PHB - Per Hop Behavior. Se refiere hasta a lo que hace el router clasificación de paquetes y funciones de condicionamiento del tráfico, tales como medición, marcado, formar, y vigilancia.
Por abandono, antes de la versión 9.0 CUCM (administrador de llamada unificado Cisco) marcó cualquiera y todo el tráfico de video (TelePresence incluyendo) al AF41. A partir de la versión 9.0, CUCM preconfigura los valores siguientes DSCP:
- El TelePresence (vídeo immersive) llama en CS4 y
- El vídeo (telefonía con video IP) llama en el AF41
Configuración
El configurar a ajustar para la calidad del audio exige el ancho de banda prioritario calculador y implementar la directiva LLQ en un link WAN. Esto se basa generalmente en el volumen de llamada y los códecs de audio anticipados usados.
Mientras que los principios son lo mismo, el ancho de banda video a través de un CUBO no es tan fácilmente calculable. Esto es debido a varios factores, incluyendo:
- ¿Cómo uno calcula el ancho de banda total que diversas llamadas dadas requeridas TP (que atraviesan el CUBO) pudieron implicar diverso número de pantallas y de diversas resoluciones?
- La naturaleza de congestión y el VBR
- ¿Otra dimensión del [in bandwidth computation] de la complejidad tiene que hacer con la “Interoperabilidad llama”? Las llamadas de la Interoperabilidad utilizan al TIP. Protocolo de la Interoperabilidad del TelePresence de la significa TIP. Utilizan al TIP para multiplexar a las pantallas múltiples, el audio múltiple fluye, así como una pantalla auxiliar-DATA en dos flujos RTP, uno por cada uno para el vídeo y audio. Habilita las sesiones de punto a punto y de múltiples puntos así como una mezcla de multi-pantalla y de puntos finales monopantella. El TIP es un protocolo de propietario de Cisco. Basan al TIP en el RTCP.
Por lo tanto, el aprovisionamiento del ancho de banda para los sistema de video sucede a veces en la cantidad de la orden reversa es decir de ancho de banda que una red de transporte puede entregar, con la directiva LLQ, se determina primero y basado en ese, se configura el punto final. ¡Los sistema de video del punto final son bastante elegantes ajustar los diversos parámetros video para que haya el tamaño del tubo! Por consiguiente, los puntos finales señalan la llamada.
Dirección del ancho de banda del CUBO
¿Así pues, cómo el CUBO maneja el ancho de banda en su oferta/respuestas (del SORBO) al señalar el vídeo llama? El CUBO puebla los campos video del ancho de banda en el SDP como sigue
1. Del atributo del ancho de banda en el SDP entrante. En el SDP, existe un atributo del ancho de banda, que tiene un modificante usado para especificar qué tipo de velocidad de transmición de bites refiere el valor. El atributo tiene la forma siguiente: b=<modifier>: <value>
2. Del ancho de banda video configurado en el CUBO. Por ejemplo, el ancho de banda máximo estimado se calcula sobre la base de las características usadas por el usuario CTS y el ancho de banda estimado se preconfigura en el CUBO, usando el CLI
- tias-modifier> video del <bandwidth o
- as-modifier> del vídeo del <bandwidth
3. Ancho de banda video predeterminado (384 kbps)
El flujo de llamada mostrado abajo ilustra cómo el CUBO puebla el ancho de banda en los mensajes de señalización de llamada
Específicamente, el CUBO utiliza la lógica siguiente:
- En las ofertas (HACER las llamadas), el CUBO utiliza el configuré el ancho de banda.
- En (respuestas al FOE), el CUBO envía el ancho de banda cuyo valor es el mínimo de oferta y de configuración local.
En el nivel de la sesión SDP, el valor TIAS es la cantidad máxima de ancho de banda necesaria cuando todas las secuencias de medios declaradas son used[8].
Tipos de carga útil de los códec de video
Ésta es otra área en la cual el vídeo diferencia del audio. El Códecs de audio utiliza los tipos de carga útil estáticos. El codecs video, en cambio, utiliza los tipos de carga útil dinámicos RTP, que utilizan el rango 96 a 127.
La razón del uso del tipo de carga útil dinámico tiene que hacer con la aplicabilidad amplia del codecs video. El codecs video tiene parámetros que proporcionen un receptor con las propiedades de la secuencia que será enviada. Definen a los tipos de carga útil video en el SDP, usando el parámetro del a=rtpmap. Además, el “a=fmtp: ” atribuya PUEDE ser utilizado para especificar los parámetros del formato. La cadena del fmtp es opaca y apenas se pasa al otro lado.
Aquí está un ejemplo
m=video 2338 RTP/AVP 97 98 99 100 c=IN IP4 192.168.90.237 b=TIAS:768000 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500 a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500;packetiza tion-mode=1 a=rtpmap:99 H263-1998/90000 a=fmtp:99 custom=1024,768,4;custom=1024,576,4;custom=800,600,4;cif4=2;custom=720,480,2 ;custom=640,480,2;custom=512,288,1;cif=1;custom=352,240,1;qcif=1;maxbr=7680 a=rtpmap:100 H263/90000 a=fmtp:100 cif=1;qcif=1;maxbr=7680
Observe que los dos puntos finales implicados en una llamada pudieron utilizar diverso tipo de carga útil para el mismo codificador-decodificador. El CUBO responde a cada lado con la línea del a=rtpmap recibida en la otra pierna. Esto significa que el config “payload asimétrico” es por completo necesario para que las llamadas video trabajen.
Ancho de banda L2
A diferencia de la Voz, el tráfico de video en tiempo real IP en general es un algo bursty, secuencia de la Velocidad de bits variable. Por lo tanto el vídeo, a diferencia de la Voz, no tiene fórmulas claras para la tara de red calculadora porque los tamaños y las tarifas de paquete de video varían proporcional al grado de movimiento dentro del imagen de video sí mismo. Desde el punto de vista de un administrador de la red, el ancho de banda es siempre aprovisionado en la capa 2, pero la variabilidad en los tamaños de paquetes y la variedad de media de la capa 2 que los paquetes puedan atravesar de punta a punta hacen difícil calcular el ancho de banda real que debe ser aprovisionado en la capa 2. Sin embargo, la regla conservadora que ha sido probada a conciencia y el ampliamente utilizado está al ancho de banda video de la sobreasignación por el 20%. Esto acomoda el 10% repartido y la tara de red de la capa 2 para acodar 4.
El monitorear/que mide
Como punto final de video anteriores mencionados no señale un MOS como tal. Sin embargo las herramientas siguientes podían ser medir usada/monitor el funcionamiento de red de transporte, y monitorear el calidad del video.
IP SLA video
Una característica integrada en el IOS, IP SLA (Service Level Agreements) realiza la supervisión activa del rendimiento de la red. La operación video IP SLA diferencia de otras operaciones IP SLA en que todo el tráfico es una manera solamente, con un respondedor requerido procesar los números de secuencia y los sellos de fecha/hora localmente y esperar una petición de la fuente antes de devolver los datos calculados.
La fuente envía una petición al respondedor cuando se hace la operación video actual. Señales de esta petición el respondedor que llegarán no más de paquetes, y que la función video del fregadero en la operación video se puede apagar. Cuando la respuesta del respondedor llega la fuente, las estadísticas se leen en el mensaje, y los campos relevantes en la operación son actualizados.
Sonda IP SLA de las aplicaciones de los CiscoWorks IPM (monitor de rendimiento IOS) y MediaTrace[9] para medir el funcionamiento y los informes del tráfico de usuarios.
CUBO VQM
La característica VQM (monitor del calidad del video), disponible en el CUBO, es una gran herramienta para monitorear el calidad del video entre dos puntas del interés. Los resultados se presentan como MOS.
Éste es disponible desde IOS 15.2(1)T y arriba. Observe que VQM utiliza a los recursos DSP.
Referencia
- http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a00807ca099.shtml
- http://www.cisco.com/en/US/partner/docs/video/milticomm/h320Bonding.html
- http://www.cisco.com/en/US/docs/solutions/TelePresence_Network_Systems_1.1_DG.pdf
- http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/qos.html
- http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/basics.html
- Videotelefonía SRND IP -
- http://www.cisco.com/en/US/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
- http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/TP_InterOp_v2.html
- http://www.encoding.com/do_you_have_any_information_on_h.264_levels
- http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
- http://www.watchpointvideo.com/pdf/Measuring%20Video%20Quality%20in%20Videoconferencing%20Systems.pdf
- http://www.broadcastpapers.com/whitepapers/Why_IPTV_is_different_from_IP_data_and_VoIP.pdf?CFID=25762102&CFTOKEN=60dc627518f1a19b-3F4F563D-FC97-8A61-6169D8F641750255
- http://en.wikipedia.org/wiki/Video_compression_picture_types
- http://inst.eecs.berkeley.edu/~ee290t/sp04/lectures/coding_standards.pdf
- http://www.cs.jhu.edu/~yairamir/cs667/Multimedia/compress.gif
- http://www.wireshark.org/lists/wireshark-users/201003/msg00125.html
- http://www.networkworld.com/news/tech/2002/0923tech.html
- http://www.javvin.com/protocolH263.html
- http://www.cisco.com/en/US/docs/ios-xml/ios/ipsla/configuration/12-2se/sla_video.html#GUID-29B155B6-AFC3-4F8B-AC1D-C127C9D797F0
[1] basado en la frecuencia humano-audible audio más alta de aproximadamente 4000Hz. Referencia: Teorema de Nyquist.
[2] Velocidad de bits constante (CBR) los esquemas de la transmisión son posibles con el vídeo, pero ellos calidad del equilibrio mantener el CBR.
[3] para las compresiones de la Inter-trama
[4] observe que SLA es más riguroso para el TP.
Imágenes [5] de tamaño natural y audio de alta calidad
[6] el valor predeterminado para este parámetro es 200ms del tráfico en el ancho de banda prioritario. El algoritmo de Cisco LLQ se ha implementado para incluir un parámetro de ráfaga predeterminado equivalente al valor de 200 ms del tráfico. La prueba ha mostrado que este parámetro de ráfaga no requiere ajustar adicional para una sola secuencia de la Videoconferencia IP (IP/VC). Para las secuencias múltiples, este parámetro de ráfaga se puede aumentar como sea necesario.
[7] un secuencia de video auxiliar es un canal video del fps 5 para compartir las presentaciones o el otro frasco colateral el proyector de los datos.
[8] observe que algunos sistemas utilizan “COMO” modificante (específico a la aplicación) para transportar el ancho de banda máximo. La interpretación de este atributo es dependiente en la noción de la aplicación del ancho de banda máximo.
El CUBO es agnóstico en cuanto al modificador de ancho de banda específico (TIAS o COMO).
[9] Mediatrace es una característica del software IOS que descubre que fluyen el Routers y el Switches a lo largo de la trayectoria de un IP.
StartSelection:0000000199 EndSelection:0000000538
Comentarios
Déjenos ayudarlo
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)