AKStream.Next · 文档中心

Open live video and choose a playback protocol

Open live video and choose a playback protocol

Live view is not a direct camera-to-browser connection. MediaServer first establishes the source stream, then the platform creates an address the browser can use. Troubleshoot in the same order.

Double-click the video or use the player fullscreen button to show only the video canvas. Protocol selectors, playback addresses, and hints no longer reserve space. Fullscreen on either the outer control shell or the browser-native <video> element fixes the player root, canvas, and active video layer to the complete available viewport, independent of the normal 16:9, compact-height, and URL-row layout; no normal-page blank region remains below the native controls. The picture keeps its original aspect ratio and remains centered. Symmetrical letterboxing is normal when screen and source ratios differ; the image is not cropped or distorted to fill the screen. Exiting fullscreen restores the normal controls and address area.

Where the video travels

flowchart LR
    A[Camera] --> B[RTSP / GB28181 / ONVIF URL]
    B --> C[Stream on MediaServer]
    C --> D{Browser protocol}
    D --> E[HLS]
    D --> F[HTTP-FLV / fMP4]
    D --> G[WebRTC / WHEP]

First live view

  1. Select an activated channel in the resource tree or Asset details.
  2. Click Live view and wait for the stream-start command to finish.
  3. Confirm that the inspector shows the channel online and note the MediaServer node carrying the stream.
  4. When video appears, observe first-frame time, audio, and whether timestamps keep advancing.
  5. Close the view and confirm that an on-demand stream is released according to policy.

If there is no video, ask first: does this stream exist on MediaServer? If yes, inspect browser delivery; if no, inspect device onboarding.

Choose a protocol

Protocol Typical latency Best for Main limitation
HLS 3–15 seconds Compatibility and broad distribution Segments add latency
HTTP-FLV / fMP4 1–3 seconds Low-latency desktop viewing Depends on MSE and long connections
WebRTC / WHEP Subsecond to several seconds Low-latency monitoring and interaction Requires HTTPS, ICE, STUN/TURN
RTSP Low VLC, NVR, SDK, service-to-service Browsers do not play it natively
RTMP Low Publishers and service-to-service Browsers do not play it natively

Camera GOP, transcoding, network, and player buffering all affect final latency. When low latency matters, measure end to end rather than relying on the protocol name.

Return to the live edge after backgrounding

A background browser tab may freeze video, MSE, or flv.js while old data remains buffered. When the page becomes visible again, live view, management video wall, standalone display wall, and parameter preview rebuild the live connection, discard accumulated data, and restart from the current live edge. Multi-view players recover with a bounded 1.2-second stagger so sixteen streams do not reconnect at once.

If the user paused before leaving, that pause is preserved and no automatic reconnect occurs. This behavior addresses browser background suspension; persistent packet loss, source latency, or proxy buffering still requires normal playback-path troubleshooting.

Multiple nodes and reverse proxies

The playback URL must use the public host and port of the node carrying the stream. The API host is not necessarily the media host.

  • HLS must allow playlists and segments with correct HTTPS and CORS settings.
  • HTTP-FLV/fMP4 needs inappropriate proxy buffering disabled and long timeouts.
  • WebSocket requires the Upgrade header.
  • MP4 playback requires Range and Content-Length to be preserved.
  • An HTTPS page cannot load HTTP media resources.

An ordinary HTTP reverse proxy does not automatically proxy RTSP, RTMP, RTP, or ICE media ports.

For multi-view HLS in an external page, each player may generate a unique UUID v4 ak_viewer and keep it stable across that player's playlist and segment requests. Real playback permission still comes from the short-lived ak_ticket; never place the ticket in logs or permanent links.

Acceptance check

  • Play continuously for at least 15 minutes from the real user network.
  • Test network recovery, background-and-return, and browser refresh.
  • Play the maximum intended view count and verify acceptable CPU, bandwidth, and node connections.
  • A low-privilege account cannot play an unauthorized channel.
  • Closing the page releases player, ticket, and on-demand stream according to policy.

If it still fails, continue with No video or playback failure.