Live Video on a Business Website: Can Viewers Rewind, or Only Watch What Is Available Now?
Before adding a live player to an event page, decide whether viewers may rewind, how the interface identifies a delayed position and whether a separate replay will be published. A live stream is not automatically a recording that can be played from the beginning. The player should offer only navigation that the current media service actually supports.
This guide concerns the playback timeline, not event admission, caption production or streaming-platform selection. It describes requirements to verify with your chosen delivery system; it does not claim that a particular provider has a rewind or replay feature.
Do not force every stream into a finite progress bar
MDN's documentation for an HTML media element's duration property distinguishes a known length from missing or unbounded information. If no media data is available, the property returns NaN. Media without a known duration, such as live streams, can return Infinity.
For the brief, this means “unknown” and “zero seconds long” are not interchangeable states. A player should not display a completed zero-length event or divide a playback position by an invented total just because it has not obtained a finite duration.
Agree what appears while loading and during live delivery. If your design uses a custom timeline, ask the developer to explain which information it represents. For an embedded third-party player, verify the provider's actual controls instead of assuming your page can override them.
Available to seek is not the same as event duration
The separate MDN seekable documentation describes the ranges a browser can seek to when the property is accessed. It returns a static snapshot of those currently available ranges, not a promise about the complete event history.
A commissioning requirement should therefore ask what is available now. Can a late arrival start at the beginning? Can someone go back only within a limited window? Is seeking unavailable? Obtain the answer from the implemented stream and delivery service, not from the presence of a draggable bar.
Where availability changes during delivery, the interface needs current information rather than relying indefinitely on an earlier snapshot. The source documents what the property reports; the exact available window and update policy depend on your implementation and service.
Pausing and being at the live position are different states
If the supported stream lets a viewer pause or move backwards, decide how the player explains the resulting position. “Playing” does not necessarily mean “at the current live position”. A useful interface can distinguish watching behind the live point from returning to the most recent playable point.
Do not label a return control as zero-delay access to the physical event. Playback and delivery have their own delays, and the narrow browser references cited here establish no end-to-end latency guarantee. Define the label according to what the chosen player can actually do.
Also decide what happens if a paused position is no longer available when the viewer resumes. A silent jump can be confusing. Ask for an understandable explanation and an explicit supported recovery route. That is a recommended product behaviour, not an automatic guarantee from the media properties.
Publishing a replay is a separate promise
An event ending does not establish that a durable replay exists. If you advertise a recording afterwards, specify who prepares it, where it is published, how access works and what the event page says while it is unavailable.
Keep the live page and replay identity understandable. A button that still says “Watch live” should not quietly open an unrelated older recording. If the replay is edited, give it an appropriate description rather than implying it is necessarily the complete original stream.
Captions and other media alternatives need their own planning for both the event and the eventual recording. A seekable timeline does not settle those requirements or establish accessibility conformance.
Exercise the timeline using a controlled event
Have the developer demonstrate the real delivery arrangement with nonconfidential test material. Join after the test has started and try every offered timeline action. Check the earliest available position, return to the most recent playable point and confirm what the labels mean.
Pause for long enough to exercise the service's actual retention behaviour, if it has a bounded window. Do not invent a test duration without first learning that policy. Verify what happens when the chosen position becomes unavailable, and record any feature the service cannot reproduce in your test environment.
Then end the test event. Confirm the waiting, ended and replay states that are actually in scope. Check the same actions on the agreed phone and desktop browsers, including keyboard access to custom controls. A successful page load alone does not exercise the timeline.
These are proposed acceptance checks. No live event, stream delay or replay availability was measured for this article.
Does a live player always let late arrivals start from the beginning?
No such guarantee follows from the browser properties. Confirm the available seek ranges and the delivery service's supported behaviour.
Does an infinite duration mean there is an error?
Not necessarily. MDN documents Infinity for media without a known duration, including live streams. The interface needs to handle that state meaningfully rather than pretending it is a finite recording.
Is rewind support evidence that the replay will remain available tomorrow?
No. Current seek availability and later publication are separate requirements. Specify the replay commitment explicitly if you need one.
Put the expected viewing journeys in your website project brief. For a custom event page or player integration, bring the delivery service and supported controls to a website project discussion.