wm host / queue reliability test

Put a watermark on the playlist,
two segments before it plays.

Enter the text for the mark. The service opens a session-scoped HLS playlist and plays it immediately. Every third 4 s segment is planned for watermarking; its job enters the queue when the segment two positions earlier is requested.

Start a session

1–16 characters, A–Z / a–z / 0–9 / space / . _ : -

The mark is burned into the video by the measured C splicer. The black text plate is rendered per segment at that segment’s scheduled 128×32 absolute position, then probe-checked and strict-decoded before it is served.

What happens

  1. A random key scopes the stream. The player page and playlist stay on this origin, so the browser has no cross-scheme media request.
  2. Segment URLs are fixed. Every media URL is /video/<key>/segNNNN.ts. The key changes per session; the segment identifier does not.
  3. Queue lead is exactly two segments. Requesting segment N queues the planned watermark for N+2, roughly eight seconds before playback needs it.
  4. Fail open, visibly. If a job misses its window, the original segment is served and the page records a late or fallback event.

The source is 180 independent 1080p H.264 segments (12 minutes, 4 s each). The page labels the result as a recorded HLS delivery, not a live encoder.

Service state

state
loading…

Live counters. The queue and all media are served by the same process; open the player page to watch per-segment jobs move through scheduled → queued → running → done.