Video en vivo JT1078 en Traccar: cómo funciona y por qué se te corta

Este artículo no sale de la documentación: sale de una auditoría de tracker-server.log en un servidor Traccar de producción con un MDVR JT808 conectado. Si estás peleándote con el video en vivo de una cámara de flota, esto te va a ahorrar varias noches.

Tres cosas que descubrimos y que casi nadie explica bien:

1. Traccar sí hace video en vivo, pero por una vía distinta al sistema de fotos.
2. Los cortes casi nunca son culpa de Traccar.
3. En el servidor no queda ningún archivo de video, y eso es por diseño.

Si aún estás eligiendo equipo, el panorama completo está en cámaras compatibles con Traccar.

Qué pasa exactamente cuando pides video

Cuando lanzas videoStart desde la interfaz, Traccar no abre un stream. Lo que hace es mandarle instrucciones a la cámara mediante un mensaje del protocolo JT808 con ID 0x9101 (MSG_VIDEO_REQUEST), que viaja por la conexión TCP de control ya establecida. Los parámetros que lleva son:

Es decir: Traccar le dice a la cámara dónde conectarse, y es la cámara la que abre una sesión nueva contra el puerto JT1078. A partir de ahí el servidor actúa como relay del flujo RTP/H.264 hacia tu navegador.

En los logs esa segunda sesión se ve así:

[T149ced73: jt1078 < 189.xxx.xxx.xxx]

Ese jt1078 < es la confirmación de que la cámara obedeció la orden. Es el primer punto de control cuando algo falla: si no aparece, el problema está en la orden o en la red de la cámara; si aparece y aun así no ves imagen, el problema está aguas abajo.

El comando complementario es 0x9102 (MSG_VIDEO_CONTROL), y en la interfaz se corresponde con videoStop.

Cómo llega el video a tu navegador: HLS

Esta es la parte que casi nadie explica, y es la que decide si el video se ve o no.

El flujo RTP que sube la cámara no lo consume el navegador directamente. Traccar lo remultiplexa a MPEG-TS (org.traccar.media.VideoStreamWriter construye las tablas PAT y PMT, empaqueta los PES y calcula los PTS) y lo publica como HLS a través de org.traccar.api.resource.VideoStreamResource, montado en @Path("stream"). Son dos endpoints:

Fíjate en el {channel}: la ruta lleva el canal, igual que el 0x9101. Un MDVR de cinco canales expone cinco playlists distintas, una por canal, y videoStart sobre el canal 3 se consume en /api/stream/{deviceId}/3/live.m3u8. Ahí está la respuesta a "¿cómo veo la cámara lateral?".

Y de aquí salen dos fallos de despliegue muy comunes:

• El proxy inverso corta los .ts. Si pones Nginx delante y no dejas pasar /api/stream/, la playlist carga y el video no arranca nunca. Mismo cuidado con /api/media/.
• Buffering de HLS. HLS es segmentado por diseño: entre 2 y 6 segundos de latencia son normales. Si esperabas latencia de cámara IP, no es un fallo, es el formato.

Por qué se corta la transmisión

En el caso que auditamos, el video arrancaba y se caía a los pocos segundos, de forma intermitente. Las dos causas resultaron ser estas, y ninguna era un bug del servidor:

1. La red móvil del vehículo

La cámara estaba reportando en movimiento, a velocidades de entre 3,9 y 19,8 km/h. Cada salto entre celdas 3G/4G producía una caída instantánea del flujo de paquetes. El video en vivo por LTE en un vehículo circulando es, sencillamente, un escenario hostil: no hay reintento en el servidor que arregle una conmutación de celda.

2. Saturación por reintentos — la causa autoinfligida

Esta es la buena. Al no ver imagen de inmediato, el operador volvía a pulsar. En los logs se veían comandos videoStart / videoStop sucesivos con 2 a 5 segundos de separación.

El problema es que cada videoStart nuevo obliga a la cámara a cancelar la transmisión en curso y renegociar el socket TCP desde cero. Resultado: un bucle de reinicios en el que la sesión nunca llega a estabilizarse. Cuanto más insistes, menos video ves.

Cómo se soluciona

Espera de 10 a 15 segundos después de enviar videoStart antes de volver a tocar nada. El handshake TCP de JT1078 más el arranque del flujo necesitan ese margen. Es la corrección de una sola línea que resuelve la mayoría de los casos.

Usa el sub-stream en cobertura inestable. Configurar streamType al flujo secundario (menor resolución) reduce drásticamente la pérdida de frames H.264. Para verificar qué está pasando en la cabina no necesitas full HD.

Prueba primero con el vehículo detenido. Si en parado se ve estable y en movimiento no, ya tienes el diagnóstico: es cobertura, no configuración.

No hay archivos de video en el servidor (y está bien)

La tercera parte de la auditoría fue buscar los archivos. Con media.path configurado como ./media, revisamos el árbol de /opt/traccar/media:

find /opt/traccar/media -type f \( -name "*.mp4" -o -name "*.h264" -o -name "*.ts" \)

Cero resultados. Lo único que había en las carpetas eran imágenes estáticas device.jpg — que son la foto de perfil del dispositivo, un mecanismo aparte que no tiene nada que ver con las cámaras.

Esto no es un fallo de configuración. Con el decodificador JT808 tal y como viene de fábrica, Traccar opera únicamente como proxy/relay transparente en vivo. El video histórico permanece en la memoria o la tarjeta SD física del MDVR dentro del vehículo.

Ahora bien, conviene decirlo con precisión: no es una limitación de arquitectura, es una carencia del decodificador. El sistema de media de Traccar (el que usan Teltonika, Jimi o Dualcam para guardar archivos) es genérico y está disponible para cualquier protocolo; el decodificador JT808 sencillamente no lo invoca. Reconoce los tipos de mensaje multimedia, pero no escribe el archivo.

Dicho de otro modo: es implementable, y no es especialmente difícil — se trata de enganchar la ruta multimedia de JT808 al buffer de media que ya existe. Nosotros lo tenemos resuelto en nuestro servidor con esa modificación. Si dependes de esto, tenlo en el radar como desarrollo pendiente, no como un imposible.

Con el servidor sin modificar, y de cara a comprar hardware: si tu requisito es "quiero el video guardado en mi servidor aunque el camión se incendie", de serie no lo tienes. Esa conversación toca tenerla antes de firmar, no después.

Los comandos de log que deberías tener a mano

Para auditar un dispositivo concreto en producción:

# Eventos del dispositivo (sustituye por tu IMEI)
grep -E "Event id: TU_IMEI" /opt/traccar/logs/tracker-server.log

# Comandos de control de video enviados
grep "videoStart\|videoStop" /opt/traccar/logs/tracker-server.log

# Sesiones JT1078 entrantes: ¿la cámara está obedeciendo?
grep -i "jt1078" /opt/traccar/logs/tracker-server.log

Bonus: notifications: 0 no significa que algo esté roto

Durante la misma auditoría apareció esto de forma constante:

INFO: Event id: ..., time: ..., type: queuedCommandSent, notifications: 0
INFO: Event id: ..., type: deviceStopped, notifications: 0

La sospecha inicial era que el dispositivo se estaba "comiendo" alertas. No era eso: notifications: 0 significa que Traccar procesó el evento correctamente pero que no hay ninguna regla de notificación (email, SMS, webhook o push) configurada y asociada a ese dispositivo para ese tipo de evento.

El evento existe, se registra, y no dispara nada porque nadie le dijo que lo hiciera. La solución está en la configuración de notificaciones, no en la cámara — lo cubro en notificaciones en Traccar.

Checklist rápido

Si el video en vivo no funciona, en este orden:

1. ¿Aparece jt1078 en el log tras el videoStart? Si no → la cámara no obedece: revisa host/port que le estás enviando y que el puerto 1078 esté abierto de verdad.
2. ¿Estás pulsando más de una vez en menos de 15 segundos? Deja de hacerlo.
3. ¿El vehículo está en movimiento? Prueba detenido para descartar cobertura.
4. ¿Estás pidiendo stream principal? Baja a sub-stream.
5. ¿Buscas archivos en media.path? No los busques: con JT808 no existen.