Gop=1 when using both main and secondary streams with analytics
Hi,
I'm developing support for displaying up to 16 camera screens with NX analytics overlay, using GStreamer (C#).
After adding logs, I see that although the camera is configured for GOP=40, I receive only bursts of I-frames: about 5 I-frames, then 100-300 ms (varies with FPS - 15/25) with no frames, then I-frames again.
It appears I don't receive any P-frames. I understand NX sends transcoded data with GOP=1, likely the default.
The camera server is set to GOP=40.
Am I missing something in the pipeline configuration to prevent NX from “downgrading” the connection to GOP=1?
How can I receive frames with GOP=40, including P-frames?
Example logs (only I-frames received):
12-08 10:03:20,717 [14] DEBUG App - [timing] SLOW frame: 59.7ms gap
2025-12-08 10:03:20,856 [14] DEBUG App - [timing] FAST frame: 0.0ms gap
2025-12-08 10:03:20,915 [14] DEBUG App - [timing] SLOW frame: 58.5ms gap
2025-12-08 10:03:21,003 [14] DEBUG App - [timing] FAST frame: 0.0ms gap
2025-12-08 10:03:21,004 [14] DEBUG App - [timing] FAST frame: 1.0ms gap
2025-12-08 10:03:21,007 [14] DEBUG App - [timing] FAST frame: 3.0ms gap
2025-12-08 10:03:21,008 [14] DEBUG App - [timing] FAST frame: 1.0ms gap
2025-12-08 10:03:21,011 [14] DEBUG App - [timing] FAST frame: 3.0ms gap
2025-12-08 10:03:21,012 [14] DEBUG App - [timing] FAST frame: 1.0ms gap
2025-12-08 10:03:21,013 [14] DEBUG App - [timing] FAST frame: 1.0ms gap
2025-12-08 10:03:21,015 [14] DEBUG App - [timing] FAST frame: 2.0ms gap
2025-12-08 10:03:21,321 [14] DEBUG App - [timing] SLOW frame: 305.9ms gap
2025-12-08 10:03:21,415 [14] INFO App - [fps] Measured FPS:27.22 fps:28 frames in 1.029
2025-12-08 10:03:21,415 [14] INFO App - [fps] IRREGULAR FPS:27.22!!!!!!
2025-12-08 10:03:21,416 [14] INFO App - [network] Data rate:122.48 Mbps 16,128 KB in 1.029
2025-12-08 10:03:21,464 [14] DEBUG App - [timing] FAST frame: 1.0ms gap
2025-12-08 10:03:21,520 [14] DEBUG App - [timing] SLOW frame: 56.0ms gap
2025-12-08 10:03:21,574 [14] DEBUG App - [timing] SLOW frame: 54.0ms gap
2025-12-08 10:03:21,620 [14] DEBUG App - [timing] FAST frame: 1.0ms gap
2025-12-08 10:03:21,717 [14] DEBUG App - [timing] SLOW frame: 51.3ms gap
2025-12-08 10:03:21,852 [14] DEBUG App - [timing] FAST frame: 0.0ms gap
2025-12-08 10:03:21,914 [14] DEBUG App - [timing] SLOW frame: 62.0ms gap
2025-12-08 10:03:22,003 [14] DEBUG App - [timing] FAST frame: 0.0ms gap
2025-12-08 10:03:22,004 [14] DEBUG App - [timing] FAST frame: 1.0ms gap
2025-12-08 10:03:22,005 [14] DEBUG App - [timing] FAST frame: 1.0ms gap
2025-12-08 10:03:22,006 [14] DEBUG App - [timing] FAST frame: 1.0ms gap
2025-12-08 10:03:22,006 [14] DEBUG App - [timing] FAST frame: 0.0ms gap
2025-12-08 10:03:22,008 [14] DEBUG App - [timing] FAST frame: 2.0ms gap
2025-12-08 10:03:22,014 [14] DEBUG App - [timing] FAST frame: 6.0ms gap
2025-12-08 10:03:22,322 [14] DEBUG App - [timing] SLOW frame: 308.2ms gap
2025-12-08 10:03:22,459 [14] INFO App - [fps] Measured FPS:24.91 fps:26 frames in 1.044
2025-12-08 10:03:22,459 [14] INFO App - [network] Data rate:112.20 Mbps 14,976 KB in 1.043
-
Hi Itzik kleiman,
Thanks for your question. However, the description seems to be missing a few critical details.
- How exactly are you obtaining the stream? Which API or method are you using?
- How did you measure the FPS? The log does not appear to be generated by our system, so we’re unable to understand what it represents. Thank you for sharing it, but unfortunately it isn’t usable for analysis.
To understand your question further, please provide more details about your implementation and elaborate on your test scenarios.
Thanks for your cooperation.
0 -
Hi Itzik kleiman,
Just a quick response and notice.
If the stream truly contains only I-frames, then this would indicate a potential issue or a non-standard implementation, because a valid video stream is expected to contain a proper GOP structure (I/P/B frames) unless explicitly configured otherwise (e.g., MJPEG-style encoding).To understand this properly, could you please clarify:
1. Which interface is being used to obtain the stream?
* RTSP (raw stream),
* HTTP/MJPEG,
* WebRTC
* SDK / proprietary API2. What codec and profile are configured on the device?
* H.264 / H.265
* GOP length / Intra period
* CBR vs VBR3. How was the frame type verified?
* Encoder statistics (If any)Some interfaces may expose only I-frame–equivalent data by design, which can appear as “I-frames only” but is not actually a video stream in the traditional sense.
Once the exact interface and verification method are confirmed, we can determine whether this is an actual encoder bug or expected behavior for that specific interface.
Thanks.
0
Please sign in to leave a comment.
Comments
2 comments