Guías y solución de problemas Preguntas frecuentes relacionadas

1 Contenido

2 Introducción

3 Problemas comunes

3.1 Problemas de conexión de red

3.1.1 Error de conexión

3.1.2 Error de DNS

3.1.3 Ruta no válida

3.1.4 No autorizado

3.1.5 Transmisión detenida

3.1.6 Conexión terminada

3.1.7 Fin de la transmisión

3.1.8 Conexión no válida

3.2 Problemas de decodificación

3.2.1 Transmisión no compatible

3.2.2 Transmisión no válida

3.3 Tartamudeo y corrupción de vídeo

4 Solución de problemas avanzada

4.1 Habilitar el registro

4.2 Recuperar registros

4.3 Detección de pérdida y fluctuación de paquetes

4.4 Problemas de multidifusión IGMP

5 Apéndices

5.1 Tipos de registro

5.1.1 Registro SQX

5.1.2 Registro de GStreamer

5.1.3 Registro de canalización

5.1.4 Registro de paquetes

2 Introducción

Este documento describe la funcionalidad orientada al soporte que se ha implementado dentro de la tarjeta ActiveSXQ y el proceso que Datapath A continuación, utilizaremos estas funciones para investigar y solucionar rápidamente cualquier problema que se pueda encontrar al implementar ActiveSQX.

El documento describe los pasos que se deben seguir cuando una fuente de transmisión IP no funciona con la tarjeta ActiveSQX. Una transmisión IP puede pasar a través de un conjunto diverso de componentes de hardware y software y existe una cantidad igualmente grande de razones por las cuales la transmisión puede no funcionar. El documento cubre los problemas potenciales en orden del más común al menos común. Los problemas comunes podrían ser diagnosticados por el usuario final o por el soporte de primera línea sin demasiados problemas; sin embargo, algunos de los problemas menos comunes deberán derivarse a Datapath para una mayor investigación y los procesos involucrados en eso también se describen.

3 Problemas comunes

Cuando se abre una ventana por primera vez para mostrar una transmisión IP, aparecerá "Conectando" en la ventana. Esto indica que la tarjeta ActiveSQX está intentando establecer una conexión con la fuente de transmisión IP. Esto puede tardar desde una fracción de segundo hasta medio minuto, dependiendo de la calidad de la red y la fuente.

En caso de problemas de red, es posible que se muestre un error en la ventana inmediatamente o que el software se agote después de aproximadamente 30 segundos y luego muestre un mensaje de error en la ventana.

Los diferentes tipos de problemas de red se describen en la sección 3.1. Suponiendo que la conexión de red se pueda establecer correctamente, se pueden encontrar varios problemas con la decodificación, como intentar decodificar una transmisión que utiliza un formato de codificación o una característica específica de ese formato que ActiveSQX no admite. Estos se describen en la sección 3.2.

3.1 Problemas de conexión de red

Si hay problemas con la red, puede aparecer uno de los siguientes errores:

3.1.1 Error de conexión

Esto significa que ActiveSQX no pudo establecer una conexión con la dirección IP y el puerto de origen. En algunos casos, puede ser que la fuente haya rechazado la conexión debido a un nombre de usuario y contraseña no válidos (consulte la sección 3.1.4) o que la IP de origen haya alcanzado su número máximo de conexiones admitidas.

3.1.1.1 Verificar la conexión física

Asegúrese de que haya un cable Ethernet conectado al ActiveSQX y que esté en una red que tenga acceso físico a la dirección IP de la fuente.

3.1.1.2 Comprobar la dirección IP

Si se utiliza DHCP, asegúrese de que ActiveSQX haya obtenido una dirección IP, verifique esto abriendo el administrador de dispositivos y haciendo doble clic en la tarjeta ActiveSQX en "Dispositivos de sonido, video y juegos". Vaya a la pestaña "Configuración" y busque una dirección IP en el campo de dirección IP atenuado como se muestra en la Figura 1. Si la pestaña "Configuración" no está presente, entonces ActiveSQX no pudo establecer una conexión con la máquina host. Si este es el caso, intente apagar y volver a encender; si la pestaña aún no aparece, entonces la tarjeta está defectuosa o se ha colocado en una máquina host no compatible.

Figura 1 Configuración del administrador de dispositivos ActiveSQX

El campo de dirección IP solo se actualizará cuando el cuadro de diálogo se abra por primera vez, por lo que si posteriormente se conecta un cable Ethernet al ActiveSQX, el cuadro de diálogo debe cerrarse y volverse a abrir para que se actualice. Si una dirección IP no aparece en el cuadro de diálogo, verifique que el servidor DHCP se esté ejecutando correctamente. Si es necesario, utilice un rastreador de paquetes como Wireshark en otra máquina conectada a la misma red para verificar que se estén transmitiendo los paquetes DHCP. Si el servidor DHCP no funciona correctamente, intente asignar una dirección IP estática. Sin embargo, si se asigna una dirección IP estática, asegúrese de no elegir una dirección dentro del rango reservado para DHCP para evitar conflictos de direcciones IP.

3.1.1.3 Hacer ping a direcciones IP

Una vez que ActiveSQX tenga una dirección IP, verifique que responda a las solicitudes de ping de otra máquina en la red escribiendo "ping xxxx" usando un símbolo del sistema, reemplazando xxxx con la dirección IP de ActiveSQX. También verifique que la fuente responda a las solicitudes de ping a su dirección IP. Siempre que las solicitudes de ping tengan éxito, verifique que el número de puerto ingresado para la dirección de origen sea correcto. También verifique que se pueda acceder a la transmisión desde otra máquina en la misma red utilizando un reproductor multimedia de software como VLC.

3.1.2 Error de DNS

Si se ingresa un nombre de dominio, en lugar de una dirección IP, para la fuente de IP y no se resuelve, se mostrará este error. Compruebe que el nombre de dominio sea correcto y que se pueda acceder a él mediante el comando ping. De lo contrario, puede deberse a que ActiveSQX no puede conectarse al servidor de nombres de dominio. La dirección de 1 o 2 servidores DNS se puede especificar explícitamente a través de la página de propiedades de ActiveSQX en el administrador de dispositivos si el DNS no se puede establecer automáticamente a través de DHCP.

3.1.3 Ruta no válida

Este error se produce cuando se estableció la conexión con la fuente IP pero la fuente rechazó la ruta proporcionada. Verifique la ruta en Wall Control abriendo el cuadro de diálogo “Configuración de cámara IP” y seleccionando la pestaña “Modelos de cámara”. Seleccione la ruta correspondiente. camera, haga clic en “Modificar…” y verifique que la ruta sea correcta.

3.1.4 No autorizado

Este error indica que la fuente IP ha rechazado la conexión. Esto puede deberse a un nombre de usuario o contraseña no válidos. Verifique el nombre de usuario y la contraseña en Wall Control abriendo el cuadro de diálogo “Configuración de cámara IP” y seleccionando la pestaña “Cámaras”. Seleccione la opción correspondiente. camera, haga clic en “Modificar…”, seleccione el botón de opción “Nombre de usuario” e ingrese las credenciales de inicio de sesión.

3.1.5 Transmisión detenida

Este error indica que no se han decodificado fotogramas de vídeo en el último segundo. Esto puede deberse a una falla temporal de la red, como la desconexión de un cable, y puede recuperarse siempre que la conexión de red se restablezca antes de que se agote el tiempo de conexión. Esto también puede ocurrir si se excede la capacidad máxima de decodificación del ActiveSQX; consulte la hoja de datos para conocer los límites.

3.1.6 Conexión terminada

Este error se producirá en situaciones en las que la conexión se pierda durante un período prolongado (es decir, unos 30 segundos). Esto puede deberse a varios motivos diferentes:

• Un cable desconectado en algún lugar entre la fuente y el ActiveSQX
• Es posible que la fuente haya dejado de transmitir si estaba apagada, por ejemplo.
• Si la fuente fue multicast puede deberse a una mala configuración en los ajustes de red IGMP en
  los interruptores (ver sección 4.3 para más detalles)

3.1.7 Fin de la transmisión

En realidad, esto no es un error, simplemente indica que la transmisión IP de origen ha finalizado. Normalmente, este mensaje sólo se mostrará si la fuente era un archivo de vídeo que tenía una duración fija en lugar de una transmisión en vivo interminable.

3.1.8 Conexión no válida

Este error indica que se ha producido un error de red genérico. Se requiere más investigación como se describe en la sección 4.

3.2 Problemas de decodificación

Si hay problemas para decodificar la transmisión IP de origen, es posible que se muestre uno de los siguientes errores:

3.2.1 Transmisión no compatible

Este error generalmente indica que el formato de codificación del flujo IP de origen no es compatible o también puede indicar un protocolo de transporte no compatible. Consulte la hoja de datos de ActiveSQX para obtener una lista de formatos compatibles. En algunos casos, es posible solucionar el problema configurando la transmisión IP de origen en un formato compatible. Si se desconoce el formato de codificación de la fuente, se puede verificar utilizando un reproductor multimedia de software como VLC.

3.2.2 Transmisión no válida

Este error indica que se ha producido un error de transmisión genérico. Se requiere más investigación como se describe en la sección 4.

3.3 Tartamudeo y corrupción de vídeo

En algunos casos, es posible que se vean varios marcos teñidos de verde cuando se conecta por primera vez, que luego se corregirán solos después de un tiempo. En el caso del vídeo codificado H264, esto se debe a que no se recibió un I-Frame de la fuente IP cuando se realizó la conexión por primera vez. La fuente de IP debe enviar un I-Frame al conectarse, pero no todas las fuentes de IP lo hacen. Lamentablemente, ActiveSQX no puede hacer nada al respecto.

Otro problema común con las transmisiones IP es ver el video entrecortado y/o artefactos de decodificación. Dado que la decodificación de cuadros a menudo depende de haber decodificado exitosamente los cuadros anteriores, las transmisiones IP son muy sensibles a cualquier interrupción y esto a menudo se manifiesta en corrupción de video.

Los artefactos de decodificación generalmente son causados ​​por la pérdida de paquetes de red; para confirmar que este es el caso, es mejor intentar hacer que la ruta desde la fuente al ActiveSQX sea lo más corta posible. Si hay acceso físico a la red disponible, intente conectar la fuente y el ActiveSQX directamente al mismo conmutador y desconecte todos los demás puertos innecesarios para ver si los problemas persisten. El interruptor o el cableado también pueden estar defectuosos; intente utilizar varios interruptores y cables diferentes si es posible. Si esto aún falla, la fuente podría ser defectuosa, intente usar diferentes fuentes de IP. Si el acceso físico a la red no está disponible, intente medir la pérdida de paquetes utilizando las técnicas de registro descritas en la sección 4.

El vídeo entrecortado también puede deberse a la pérdida de paquetes de red, pero normalmente también está asociado a artefactos de decodificación. Si el vídeo entrecortado está presente sin artefactos, puede deberse a que los paquetes tardan diferentes cantidades de tiempo en transmitirse desde la secuencia IP de origen hasta ActiveSQX. ActiveSQX almacenará en caché los paquetes de forma predeterminada durante 200 milisegundos antes de decodificarlos, lo que permitirá una reproducción fluida aunque los paquetes no se reciban a una velocidad fluida, siempre que la diferencia en el tiempo de tránsito entre el paquete más lento y el más rápido no supere los 200 ms. Este valor se puede configurar en Wall Control abriendo el cuadro de diálogo "Configuración de la cámara IP" y seleccionando la opción cameraHaz clic en “Modificar…”, luego en “Avanzado” y cambia el valor de Caché. Intenta aumentar el valor hasta que desaparezca el tartamudeo. Ten en cuenta que aumentar este valor añadirá un retardo entre la fuente en directo y el vídeo mostrado. Si el problema persiste al cambiar el valor de Caché, es posible que la causa sea la fuente IP. Intenta decodificar la misma fuente con un reproductor multimedia como VLC para comprobar si se presenta el mismo problema.

4 Solución de problemas avanzada

En los casos en los que el problema no pueda identificarse en la sección 3, será necesario utilizar la funcionalidad de registro incorporada de ActiveSQX. De forma predeterminada, el registro está deshabilitado por razones de rendimiento, durabilidad y seguridad, pero es invaluable para depurar problemas complicados.

El registro debe estar habilitado y luego el problema debe reproducirse abriendo el flujo de IP problemático (o realizando los pasos necesarios). Los archivos de registro pueden luego analizarse para determinar la causa del problema o enviarse de vuelta a Datapath para un análisis más detallado si es necesario.

4.1 Habilitar el registro

El registro se puede habilitar utilizando la herramienta de línea de comandos cmd183.exe desde un símbolo del sistema. Como punto de partida, las advertencias y errores de registro SQX con el registro de nivel INFO de GStreamer y el volcado de canalización deben habilitarse mediante la siguiente línea de comando:

archivo de registro de configuración cmd183.exe –s 2 –g 4 –p

Estos registros no contendrán ninguna información confidencial y son bastante ligeros. Para obtener más detalles sobre los diferentes tipos de registro y cómo utilizar la herramienta cmd183, consulte la sección 5.1.

4.2 Recuperar registros

Los registros también se recuperan utilizando la herramienta de línea de comandos cmd183.exe. Primero cree una carpeta en la máquina host donde se deben almacenar los registros. Luego ejecute "cmd183.exe getlogs", donde se sustituye por la ubicación de la carpeta creada. Una vez que los registros se recuperen exitosamente, se borrarán de las tarjetas ActiveSQX. Todos los archivos de registro tienen una fecha y hora adjuntas al nombre del archivo, así como una identificación, de modo que cada ventana del cliente tenga su propio archivo de registro único. El contenido de la carpeta se puede comprimir y enviar de nuevo a Datapath para un análisis más detallado. Dependiendo del resultado Datapath Puede solicitar más registros con diferentes opciones para reducir el problema.

4.3 Detección de pérdida y fluctuación de paquetes

Si la red parece estar sufriendo pérdida de paquetes y/o fluctuaciones porque el video muestra artefactos de decodificación, habilite el siguiente registro:

archivo setlog cmd183.exe –g rtpsource:5

Abra la transmisión IP y déjela funcionando durante aproximadamente un minuto, luego recupere los registros usando el comando getlogs. En sqx-client-child_xxx.log busque líneas como esta:

rtp_source_get_new_rb: fracción 0, pérdida 1, extseq 120132, jitter 98

fracción indica el número de paquetes perdidos en el rango de 0 a 256, para convertirlo a un porcentaje dividido por 2.56. perdido indica la cantidad de paquetes perdidos desde el último informe. Lamentablemente, incluso pequeñas cantidades de pérdida de paquetes pueden provocar grandes artefactos de decodificación. Tomemos, por ejemplo, un vídeo codificado H264 transmitido utilizando paquetes RTP a una velocidad de bits de 8 Mbit/s a 30 fotogramas por segundo con un tamaño de GOP de 30. Muchas fuentes IP codificarán fotogramas completos en una única unidad NAL H264, por lo que cada fotograma por lo tanto, tendrá una media de aproximadamente 34 KB. El tamaño máximo de transmisión de un paquete suele ser de alrededor de 1.5 KB, por lo que una trama debe dividirse en alrededor de 23 paquetes RTP. Debido a la forma en que funciona el protocolo RTP, si alguno de esos 23 paquetes se pierde, todos deben descartarse. Por lo tanto, en este ejemplo, un solo paquete perdido puede provocar que se descarten 23 paquetes. Tan pronto como se pierde un fotograma, todos los fotogramas siguientes sufrirán artefactos de decodificación hasta que llegue el siguiente fotograma I, que podría tener hasta 29 fotogramas en este ejemplo. Una pérdida de paquetes de apenas el 0.1 % podría provocar que hasta un 66 % de las tramas estén corruptas (0.1 * 23 * 29). Por lo tanto, para lograr una reproducción de vídeo fluida y sin artefactos, es importante minimizar la pérdida de paquetes tanto como sea posible, idealmente eliminarla por completo.

jitter es la variación en el retraso de los paquetes recibidos en el flujo en unidades de velocidad de reloj. Se mide comparando el intervalo en el que se enviaron los paquetes RTP con el intervalo en el que se recibieron. Por ejemplo, si el paquete 1 y el paquete 2 salen con una diferencia de 50 milisegundos y llegan con una diferencia de 60 milisegundos, entonces la fluctuación es de 10 milisegundos. Cuanto menor sea el valor de jitter, mejor; los valores altos de jitter indican que los paquetes no llegan a intervalos regulares y que se necesita más almacenamiento en caché para lograr una reproducción fluida. La fluctuación generalmente es un problema menor en comparación con la pérdida de paquetes, ya que ActiveSQX puede compensarla aumentando el almacenamiento en caché.

4.4 Problemas de multidifusión IGMP

Si una transmisión IP de multidifusión se corta después de un cierto período de tiempo, desde unos pocos minutos hasta horas o incluso días, entonces puede deberse a un problema de configuración con los conmutadores que se utilizan para transmitir los paquetes de multidifusión. Si ese es el caso, aparecerá un error de "Conexión terminada" en la ventana, podemos verificar que los paquetes RTP ya no se reciben habilitando el siguiente registro:

cmd183.exe archivo setlog –s 2 –g rtpsource:5 –n igmp

Abra la transmisión IP y déjela funcionando hasta que se interrumpa, luego recupere los registros usando el comando getlogs. En sqx-client-child_xxx.log busque las líneas "No se transfieren tramas durante más de 1 segundo" y "Tratar el final de la transmisión como tiempo de espera", entre ellas se puede ver la cantidad de paquetes RTP que se reciben. Si ese número no ha aumentado entre el último cuadro que se decodifica y el tiempo de espera, entonces significa que no están llegando nuevos paquetes RTP y podría indicar que un conmutador está filtrando los paquetes.

Suponiendo que los paquetes se hayan detenido, podemos observar los paquetes IGMP para ver si se comportan como se esperaba. Abra sqx-client_xxx.pcap con Wireshark y busque los paquetes "Consulta de membresía, general" provenientes del conmutador. Asegúrese de que cada consulta sea respondida mediante un "Informe de membresía" dentro del tiempo máximo de respuesta indicado por el paquete de consulta para la dirección de multidifusión conectada. Si otro dispositivo responde con un informe antes que ActiveSQX, ActiveSQX tampoco enviará una respuesta (esto es parte del estándar del protocolo IGMP). En algunos casos, ActiveSQX puede recibir un informe de otro dispositivo que no debería recibir, esto indica un problema con la configuración de red.

5 Apéndices

5.1 Tipos de registro

Los archivos de registro pueden almacenarse en ActiveSQX o enviarse en vivo a la máquina host a medida que se generan y visualizan usando DebugView o un depurador del kernel. Escribir en archivos en ActiveSQX tiende a ser más rápido y no interfiere tanto con el proceso de decodificación, pero ActiveSQX tiene espacio limitado para iniciar sesión (aproximadamente 1.4 GB). Por el contrario, la visualización de los registros en DebugView no está limitada por el espacio en disco de ActiveSQX, pero puede afectar gravemente el rendimiento si se habilita el registro muy detallado.

Hay varios tipos diferentes de registro que se pueden habilitar:

• SQX: registrar mensajes originados en DatapathEl código propietario.
• GStreamer: registra mensajes que se originan a partir del código GStreamer de código abierto.
• Tubería GStreamer: representación gráfica de la tubería GStreamer.
• Captura de paquetes de red: capturas de paquetes de red sin procesar que se pueden ver en Wireshark.

Dependiendo de la naturaleza del problema, se puede habilitar cualquier número de estos registros a la vez teniendo en cuenta las limitaciones de espacio en disco y el impacto en el rendimiento. El mejor enfoque es comenzar con un nivel de registro bastante ligero y buscar errores y advertencias en ellos. Luego, a medida que la fuente del problema se vuelve más evidente, se pueden activar mayores niveles de registro.

5.1.1 Registro SQX

El registro SQX viene en 4 niveles: 0 a 3. 0 representa ningún registro, 1 es solo errores, 2 es errores y advertencias y 3 es todo registro. El nivel de registro 2 es un buen nivel para empezar, ya que no debería llenar el disco demasiado rápido. Ejemplo: archivo setlog cmd183.exe –s 2

5.1.2 Registro de GStreamer

El registro de GStreamer es más complicado e incluye 10 niveles de registro del 0 al 9. Además del nivel de registro, GStreamer tiene varias categorías de depuración diferentes para diferentes componentes dentro de la arquitectura de GStreamer. Es posible, por ejemplo, habilitar el nivel de depuración 9 específicamente para la categoría rtpsource y dejar todas las demás categorías deshabilitadas. Para obtener más información, consulte la variable GST_DEBUG en http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html. El nivel 4 en todas las categorías es generalmente un buen punto de partida, ya que logra un equilibrio entre brindar suficiente información y no llenar el espacio en disco demasiado rápido. Ejemplo: archivo setlog cmd183.exe –g 4 o archivo setlog cmd183.exe –g rtpsource:5

5.1.3 Registro de canalización

GStreamer también tiene la capacidad de generar la canalización en un archivo .dot que, una vez procesado por Graphviz, proporciona una representación gráfica de la canalización que proporciona una buena indicación de qué formatos de codificación y protocolos de transporte utiliza una fuente de IP determinada. Ejemplo: archivo setlog cmd183.exe -p

5.1.4 Registro de paquetes

Si el problema no se puede diagnosticar únicamente con los archivos de registro, es posible que sea necesario capturar paquetes de red sin procesar y analizarlos en Wireshark. Para problemas intermitentes, también puede ofrecer una forma conveniente de reproducir problemas que ocurren con poca frecuencia. Sin embargo, cabe señalar que si se capturan todos los paquetes, es posible que el espacio en disco se llene muy rápidamente. Para ayudar a aliviar este problema y brindar un nivel de privacidad a los clientes, es posible filtrar los paquetes capturados según criterios determinados. Tcpdump se utiliza para la captura de paquetes y la sintaxis del filtro se describe en detalle aquí http://www.tcpdump.org/manpages/pcap-filter.7.html. Ejemplo: archivo setlog cmd183.exe –n “src 10.20.0.1” o archivo setlog cmd183.exe –n “ ” para no filtrar.

El modo promiscuo está deshabilitado para evitar capturar el tráfico de red general no destinado al ActiveSQX. Sin embargo, dado que la captura de paquetes opera a un nivel bajo, puede capturar información potencialmente confidencial dependiendo de qué información se envía a través de la red si no se filtra explícitamente. También es posible reproducir vídeo de las capturas de paquetes y se debe informar a los clientes de esto antes de pedirles que envíen las capturas de paquetes a Datapath. Por estos motivos, la captura de paquetes generalmente debe utilizarse como último recurso para problemas de depuración.