The path from live view to recording

When someone clicks Play, AKStream.Next checks the channel and viewing permission, then asks the chosen MediaServer for a suitable media output. The user sees video only after the browser connects to that output and decodes frames. An HTTP success earlier in the path does not prove the final step worked.

sequenceDiagram
    participant User as Browser or app
    participant API as AKStream.Next
    participant Media as MediaServer
    participant Camera as Camera
    User->>API: Request playback for a channel
    API->>API: Check channel and permission
    API->>Media: Find or start the target stream
    Media->>Camera: Pull or receive media
    Camera-->>Media: Send audio and video
    Media-->>User: HLS / HTTP-FLV / WebRTC output
    User-->>User: Decode and display frames

Recording adds more steps: a schedule or manual command starts a session, bytes reach disk, the platform indexes files, and Recording Center can finally find and play them. If any step fails, the UI may show a recording session while no searchable file exists. Recording file missing gives the checks in order.

Playback protocols determine how clients receive media. HLS is broadly compatible but often has higher delay. HTTP-FLV is common for desktop monitoring. WebRTC supports low-latency interaction and depends on HTTPS, ICE, and network conditions. RTSP is commonly used by VLC, NVRs, and SDKs; browsers do not play RTSP directly. Source codecs must still match the player. A returned URL does not imply automatic transcoding.

Follow Connect your first video to walk the path, then use Feature guides when a particular layer fails.