When working with H.264 or H.265 RTSP live streams under unstable network conditions, high CPU usage, or right after a connection/reconnection, VideoSource.nextFrame() returns corrupted, partially decoded frames (often rendered as a solid gray background with digital artifacts/pixel distortion).
This happens because the underlying decoder starts processing predictive P-frames or B-frames before it has received a full independent Keyframe (I-frame).
As a result:
- Processor.analyze() receives useless data
- CPU cycles are wasted on trying to recognize text on a broken gray image.
Visual proof of the issue:
Expected Behavior:
VideoSource.nextFrame() should internally discard all incoming corrupted or delta-frames until it catches a clean, valid I-frame (Keyframe). Only after a successful keyframe is decoded should it start pushing frames to the C# wrapper.
When working with H.264 or H.265 RTSP live streams under unstable network conditions, high CPU usage, or right after a connection/reconnection, VideoSource.nextFrame() returns corrupted, partially decoded frames (often rendered as a solid gray background with digital artifacts/pixel distortion).
This happens because the underlying decoder starts processing predictive P-frames or B-frames before it has received a full independent Keyframe (I-frame).
As a result:
Visual proof of the issue:
Expected Behavior:
VideoSource.nextFrame() should internally discard all incoming corrupted or delta-frames until it catches a clean, valid I-frame (Keyframe). Only after a successful keyframe is decoded should it start pushing frames to the C# wrapper.