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

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
-
Solicitud inicial: Usuario hace click en cámara desde la UI
- Input:
{series: "00D200B144", channel: 1, userEmail: "user@domain.com"} - Output:
sessionIdgenerado inmediatamente
- Input:
-
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
- Data enviada:
-
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
- Mensaje PubSub:
-
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)
- Redis Publish payload:
-
Persistencia: Pedido se almacena con metadatos completos
- Redis Key:
video_request:{sessionId} - Data:
{series, channel, timestamp, userEmail, status: "processing"}
- Redis Key:
-
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"}
- Protocolo N9M:
-
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
- Response DVR:
-
Preparación del procesador: N9M-CENTER coordina con signal processor
- Message sent:
{operation: "REQUESTALIVEVIDEO", streamName, sessionId} - Purpose: Preparar pipeline de procesamiento de señal
- Message sent:
-
Sincronización: Procesador obtiene contexto desde Redis
- Redis GET:
video_request:{sessionId} - Retrieved data: Series, channel, user info, timestamps para coordinación
- Redis GET:
-
Notificación al cliente: Sistema push via WebSockets
- Socket emit:
{event: "videoReady", sessionId, status: "ready"} - Trigger: Listener en frontend para proceder con playback
- Socket emit:
-
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
- Complete payload:
-
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
-
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
- Frontend: FLV.js player consume
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