Direct answer
Green or blocky frames usually point to missing reference data, unsupported codec parameters or packet loss. Compare the same stream over TCP and UDP, then test a lower H.264 profile and a forced keyframe.
Why this happens
Inter-frame codecs depend on reference frames. Lost packets, a decoder that rejects the advertised profile, or joining between keyframes can corrupt the picture even when RTSP control is healthy.
Separate stream availability, media description, transport, decoding and timing before changing camera settings.
A controlled test
Reproduce on one camera and one client. Note whether the image recovers at the next keyframe and whether TCP eliminates the corruption.
Change one variable at a time. Keep the camera model, firmware, endpoint and account recorded; then test network reachability, protocol response, media transport and decoding as separate layers.
Use a dedicated view-only account and a trusted local diagnostic tool. Redact credentials, private addresses and identifying data before sharing output.
Diagnostic sequence
| Check | Action | Evidence of progress |
|---|---|---|
| Transport | Force TCP and compare with the failing UDP result. | Packet-loss artifacts disappear or remain unchanged. |
| Keyframe | Restart the stream or request an IDR where supported. | The picture recovers at a fresh reference frame. |
| Codec | Switch from H.265 or high-profile H.264 to a compatible H.264 substream. | The simpler profile decodes cleanly. |
| Load | Reduce resolution and concurrent tiles. | Decoder pressure is separated from network loss. |
Evidence to keep
The strongest report includes transport, codec, profile, resolution, keyframe interval and whether the next keyframe repairs the image.
Boundary and safety note
Do not permanently lower quality until you know whether the limiting layer is the network, decoder or camera encoder.
For remote viewing, use a managed VPN instead of exposing RTSP or camera administration ports directly to the public internet.
SmartRTSP
SmartRTSP is a camera-focused RTSP and ONVIF viewer for Apple devices, Windows and Android. It fits direct viewing, discovery and multi-camera checks; keep a dedicated NVR or VMS when continuous recording, evidence export or centralized enterprise controls are required.
Frequently asked questions
Why is an RTSP stream green?
The decoder may be missing valid reference data or may not support the exact codec parameters.
Can TCP fix blocky video?
It can help when UDP packet loss is the cause, but it will not add support for an incompatible codec.
Why does the image recover after a few seconds?
A later keyframe can provide a new clean reference for decoding.
Primary references
- IETF RFC 7826 — Real-Time Streaming Protocol 2.0
- FFmpeg — RTSP protocol options and examples
- MDN — Media container and codec formats on the web
Related SmartRTSP guide
Open related guideA controlled test for green frames, macroblocking and tearing in camera streams without random setting changes.