No Video or Playback Failure

These types of failures are most efficiently diagnosed using a four-layer approach: channel, real stream, media address, and player. Identify the first failing layer and address it.

flowchart LR
    A[1 Channel available?] --> B[2 Stream on MediaServer?]
    B --> C[3 Media URL reachable?]
    C --> D[4 Browser can decode and play?]

Layer 1: Is the channel available?

• The channel exists, is enabled, and has not been soft-deleted.
• The current account has playback permissions.
• The device is online or the source address is accessible.
• The start operation was not rejected due to unauthorized online stream quotas.
• The asynchronous command has reached a final success state, not just a request acceptance.

Layer 2: Does the MediaServer have a real stream?

Query by media node using vhost/app/stream. If no stream is present:

• ONVIF/RTSP: Check StreamUri, credentials, TCP/UDP, and device connection limits.
• GB28181: Check INVITE, SDP, RTP IP/port, and whether packets are being received.
• Custom push: Check the pushing end, authentication, and target node.

If the API returns success but the MediaServer has no stream, the problem has not yet reached the browser layer.

Layer 3: Is the direct media address accessible?

Test the HLS/FLV/RTSP/WHEP address of the correct node using the same network as the end user. Common issues:

• Incorrect media domain used in multi-node setups;
• Inconsistency in app/stream/vhost;
• Incorrect concatenation of proxy paths, Host, or ports;
• Expired playback tickets or incorrect permission scopes;
• HTTPS pages loading HTTP/WS being blocked by the browser;
• Incorrect CORS, Range, proxy buffering, or timeouts.

Layer 4: Player and Encoding

If the direct address is playable on one client but not on the target browser, check:

• Whether the browser supports the target protocol and codec;
• Whether HLS has generated segments and keyframes;
• Whether HTTP-FLV has MSE and whether the proxy maintains a long connection;
• WebRTC ICE, TURN, SDP, and secure context;
• Whether autoplay policies require a user gesture;
• Page console and Network/Media/WebRTC logs.

Browsers cannot natively play RTSP; a converted browser-compatible protocol must be selected.

Symptom Quick Reference

Post-Recovery Verification

Play continuously for at least 15 minutes, test brief network disconnection and reconnection, and confirm that the player and on-demand stream are released after closing the page. Record the first failing layer and the fix applied to avoid mistaking an accidental reconnection for the root cause resolution.