Saltar al contenido principal

Sistema de Video en Vivo

Introducción

El sistema de video en vivo permite acceder a streams de cámaras desde dispositivos DVR remotos a través de la vista Posición de Flota. El sistema debe notificar al equipo específico que se requiere iniciar la transmisión de video.

Consideraciones Importantes

  • El pedido original proviene desde la interfaz de usuario (UI)
  • No todos los equipos apuntan a la misma máquina:
    • D5P → se comunica con Java Service
    • AIBOX → se comunica con N9M-Center
  • Estos servicios pueden estar distribuidos en múltiples máquinas

Recursos Involucrados

D2S-CENTER (Java Service)

  • Función: Manejo de video para equipos D5P
  • Deployment: Google Cloud Compute Engine (Managed Instance Group)
  • Comunicación: PubSub ↔ Backend Node.js

N9M-CENTER

  • Función: Manejo de video para equipos AIBOX
  • Comunicación: Protocolo específico N9M

D2S-MEDIA

  • Función: Servidor de streaming de video
  • IP: 35.244.252.137:8082
  • Protocolo: FLV over HTTP

Protocolos de Comunicación

PROTOCOLO REQUESTALIVEVIDEO

Estructura del Mensaje:

{
MODULE: "MEDIASTREAMMODEL",
OPERATION: "REQUESTALIVEVIDEO",
PARAMETER: {
AUDIOVALID: canal,
CHANNEL: canal,
FRAMEMODE: 0,
IPANDPORT: host,
SERIAL: getRandomInt(0, 10000000),
STREAMNAME: `${serial}-${channel}`,
STREAMTYPE: streamtype
}
}

Campos:

  • STREAMTYPE: INTEGER - Tipo de stream (0: sub-stream, 1: main stream, 2: mobile stream)
  • CHANNEL: INTEGER - Canal 1-32 (representación en bits BIT0-BIT31)
  • IPANDPORT: STRING - IP y puerto del media server (ej: 58.60.231.218:5550)

PROTOCOLO QUERYFILELIST

Estructura del Mensaje:

{
MODULE: "STOPM",
OPERATION: "QUERYFILELIST",
PARAMETER: {
STARTTIME: baseline + '000000',
ENDTIME: baseline + '235959',
CHANNEL: 0x1F, // canales 1,2,3,4 y 5
SERIAL: getRandomInt(0, 10000000),
STREAMTYPE: st,
FILETYPE: ft,
RFSTORAGE: rfst
}
}

Campos:

  • STARTTIME/ENDTIME: Rango de tiempo en formato YYYYMMDDHHMMSS
  • CHANNEL: Máscara de bits para múltiples canales
  • FILETYPE: Tipo de archivo (default: 65535)
  • RFSTORAGE: Almacenamiento RF (1 si no está definido)

Diagrama de Secuencia: Video en Vivo AIBOX/ADPLUS

alt text

Flujo Completo del Sistema

1) UI → (live video) → APIs
2) UI ← (sessionId) ← APIs
3) APIs → (live video with PUB SUB) → USER REQUEST HANDLERS
4) USER REQUEST HANDLERS → (live video with REDIS PUBLISH) → N9M-CENTER
5) N9M-CENTER → (guarda pedido) → REDIS
6) N9M-CENTER → (REQUESTALIVEVIDEO) → DVR
7) N9M-CENTER ← (MEDIATASKSTART) ← DVR
8) N9M-CENTER → (REQUESTALIVEVIDEO) → N9M-SIGNAL-PROCESSOR
9) REDIS → (pedido guardado) → N9M-SIGNAL-PROCESSOR
10) N9M-SIGNAL-PROCESSOR → (publish redis) → SOCKET
11) UI ← (sessionId, url, serie, channel) ← SOCKET
12) DVR → (stream) → D2S-MEDIA
13) UI ← (stream) ← D2S-MEDIA

Descripción del Flujo

  1. Solicitud inicial: Usuario hace click en cámara desde la UI

    • Input: {series: "00D200B144", channel: 1, userEmail: "user@domain.com"}
    • Output: sessionId generado inmediatamente
  2. Creación de sesión: APIs generan sessionId único y contexto

    • Data enviada: {sessionId: "uuid-123", status: "pending", series, channel}
    • Response al UI: sessionId para tracking posterior
  3. Distribución interna: Solicitud se propaga via PubSub

    • Mensaje PubSub: {operation: "live_video", sessionId, series, channel, userEmail}
    • Target: USER-REQUEST-HANDLER listening en topic específico
  4. Coordinación central: N9M-CENTER recibe payload completo

    • Redis Publish payload: {sessionId, series, channel, operation: "REQUESTALIVEVIDEO"}
    • Routing: Basado en serie del dispositivo (AIBOX/ADPLUS → N9M-CENTER)
  5. Persistencia: Pedido se almacena con metadatos completos

    • Redis Key: video_request:{sessionId}
    • Data: {series, channel, timestamp, userEmail, status: "processing"}
  6. Activación del DVR: N9M-CENTER envía comando específico

    • Protocolo N9M: {MODULE: "MEDIASTREAMMODEL", OPERATION: "REQUESTALIVEVIDEO"}
    • Payload: {CHANNEL: 1, STREAMNAME: "00D200B144-1", IPANDPORT: "d2s-media:8082"}
  7. Confirmación: DVR responde con estado de preparación

    • Response DVR: {OPERATION: "MEDIATASKSTART", STREAMNAME: "00D200B144-1", STATUS: "ready"}
    • Indica: Stream inicializado y listo para transmitir
  8. Preparación del procesador: N9M-CENTER coordina con signal processor

    • Message sent: {operation: "REQUESTALIVEVIDEO", streamName, sessionId}
    • Purpose: Preparar pipeline de procesamiento de señal
  9. Sincronización: Procesador obtiene contexto desde Redis

    • Redis GET: video_request:{sessionId}
    • Retrieved data: Series, channel, user info, timestamps para coordinación
  10. Notificación al cliente: Sistema push via WebSockets

    • Socket emit: {event: "videoReady", sessionId, status: "ready"}
    • Trigger: Listener en frontend para proceder con playback
  11. Entrega de URL: Frontend recibe datos completos de streaming

    • Complete payload: {sessionId, streamingUrl: "http://d2s-media:8082/live/00D200B144-1.flv", series, channel}
    • Frontend action: Configurar FLV player con URL específica
  12. Streaming directo: DVR establece conexión TCP directa

    • Connection: DVR conecta directamente a D2S-MEDIA (bypass N9M-CENTER para data)
    • Protocol: Stream raw de video frames via TCP socket
  13. Reproducción: Usuario consume stream procesado

    • Frontend: FLV.js player consume streamingUrl
    • Format: Video convertido a FLV para reproducción web
    • Real-time: Stream continuo hasta timeout/close

Componentes Clave

  • APIs: Orquestación inicial y gestión de sesiones
  • N9M-CENTER: Coordinador principal para dispositivos AIBOX/ADPLUS
  • N9M-SIGNAL-PROCESSOR: Procesador de señales y eventos
  • D2S-MEDIA: Servidor de streaming final
  • Redis: Almacenamiento temporal y coordinación entre servicios
  • Sockets: Comunicación en tiempo real con el frontend