> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/es/faq-and-troubleshooting/gps-devices/input-control/why-does-a-black-screen-appear-during-live-streaming-on-jimi-jc-cameras.md).
# ¿Por qué aparece una pantalla negra durante la transmisión en vivo en las cámaras Jimi JC?
Una pantalla negra durante la transmisión en vivo de las cámaras Jimi JC es el comportamiento esperado, no una falla. Cubre el límite de RTMP de una sola sesión y las prácticas recomendadas.
### Visión general
Es común que los centros de monitoreo tengan varios operadores supervisando la misma Flota simultáneamente. Como resultado, más de un usuario puede intentar abrir la transmisión de video en vivo de la misma cámara al mismo tiempo o dentro de un periodo breve.
En estas situaciones, los usuarios pueden experimentar ocasionalmente una pantalla negra en lugar del video en vivo. Aunque esto puede parecer un fallo de la plataforma, es un comportamiento esperado causado por la forma en que las cámaras de la serie Jimi JC administran las sesiones de transmisión en vivo.
### ¿Es este un problema de integración? No
Las cámaras JC261 y JC400 utilizan la integración nativa de Jimi IoT de Navixy. El video en vivo se establece directamente entre la plataforma y la cámara mediante comandos de Jimi (SMS/RTMP), no a través de integraciones de video de terceros.
Dado que estas cámaras se comunican directamente con Navixy, la pantalla negra no se debe a la integración en sí, sino a la arquitectura de transmisión implementada por el dispositivo.
### ¿Por qué ocurre la pantalla negra?
El comportamiento es el resultado de tres factores diferentes que actúan en conjunto.
#### 1. Limitación de la cámara (causa principal)
Las cámaras JC están diseñadas para mantener solo una sesión activa de transmisión RTMP a la vez.
Cuando un usuario inicia la vista en vivo, la plataforma envía comandos que instruyen a la cámara a comenzar la transmisión.
Cuando el usuario cierra el video, la plataforma envía otro comando que instruye a la cámara a detener la transmisión.
| Acción del usuario | Comando enviado a la cámara |
| ----------------------------- | --------------------------- |
| Abrir la transmisión en vivo | RTMP,ON |
| Cerrar la transmisión en vivo | RTMP,OFF |
Cuando varios usuarios abren y cierran repetidamente la misma cámara dentro de un periodo breve, se envían casi simultáneamente varios comandos RTMP ON/OFF.
Esto puede dejar la cámara en un estado de transmisión inconsistente en el que:
* La cámara reconoce correctamente los comandos.
* La sesión RTMP se vuelve inestable.
* La transmisión de video se interrumpe.
* Los usuarios reciben una pantalla negra en lugar de video en vivo.
En investigaciones anteriores, Jimi confirmó mediante los registros del dispositivo que la cámara responde correctamente con RTMP:OK, pero las solicitudes consecutivas y rápidas de transmisión aún pueden hacer que la transmisión se detenga inesperadamente.
#### 2. Arquitectura de transmisión de Navixy
A diferencia de las plataformas tradicionales de transmisión de video o de las CDN (Content Deliverable/Distribution Network), Navixy no recibe una sola transmisión y la redistribuye a múltiples espectadores.
En cambio, cada sesión de Vista en vivo interactúa directamente con la cámara.
Esto significa que cada operador que abre o cierra la transmisión en vivo puede generar nuevos comandos para el dispositivo.
Según la documentación de la plataforma:
Después de que termine de ver la transmisión en vivo, cierre la pestaña de monitoreo de video o la pestaña del navegador. Entonces la plataforma dejará de recibir video de su dispositivo.
Por lo tanto, la sesión de video está directamente vinculada con la interacción de cada usuario.
Si varios operadores solicitan la misma transmisión en vivo simultáneamente, pueden enviarse comandos de transmisión concurrentes a la cámara.
#### 3. Limitaciones de la red celular
La transmisión de video en vivo también depende de:
* Calidad de la señal celular
* Ancho de banda disponible
* Latencia de la red móvil
* Limitaciones del plan de datos
Incluso en condiciones normales, la transmisión en vivo requiere una conexión móvil estable.
Cuando se emiten múltiples solicitudes de transmisión simultáneamente, el dispositivo debe establecer y terminar sesiones RTMP repetidamente mientras también transmite video a través de la red celular, lo que aumenta la probabilidad de interrupciones o pantallas negras temporales.
### Prácticas recomendadas
Para garantizar la experiencia de transmisión en vivo más estable, recomendamos las siguientes pautas operativas:
* Espere aproximadamente 10–15 segundos después de cerrar una transmisión en vivo antes de iniciar una nueva.
* Evite hacer clic repetidamente en los botones Vista en vivo o Calendario, ya que esto puede generar varios comandos RTMP consecutivos.
* Asegúrese de que la cámara tenga una conexión celular estable con suficiente ancho de banda antes de iniciar una transmisión en vivo.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://navixy.com/docs/expert-center/es/faq-and-troubleshooting/gps-devices/input-control/why-does-a-black-screen-appear-during-live-streaming-on-jimi-jc-cameras.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.