What works with what
Which ways of publishing play in which players, with sound or without, and where the LL-HLS fallback exists.
What a viewer gets depends on two things: how the stream was sent, and what plays it. This page puts both together.
Publish method and player
"Tested" means run end to end through the service on our test hosts; the SDK repository records each run. "Expected" means built for it and covered by automated tests, but not run end to end that way yet.
| Sent with | Chrome on a computer (MoQ) | Other MoQ browsers | Safari, iPhone, iPad (LL-HLS) | React | Native Windows app |
|---|---|---|---|---|---|
| SRT: an encoder, ffmpeg | video and sound, tested (ffmpeg) | expected | video and sound, expected | expected | video, expected |
| RTMP or RTMPS | video and sound, expected | expected | video and sound, expected | expected | video, expected |
| WHIP | video only, expected | expected | video only, expected | expected | video, expected |
nearglass publish (a file, a camera) | video only, tested (a file) | expected | cannot play: no LL-HLS | expected | video, expected |
The C library (ingest: ["sdk"]) | video only, expected | expected | cannot play: no LL-HLS | expected | video, expected |
The columns:
- Chrome on a computer: where every browser run so far was made, in
headless Chrome on Linux and Windows. Sound was played from an ffmpeg SRT
source with Opus and with AAC; a file sent with
nearglass publishwas played in every quickstart run. - Other MoQ browsers: Edge, Firefox on a computer, Chrome for Android and Samsung Internet. They have what the player needs (WebTransport and WebCodecs), and the player plays over MoQ in them, but none has played a stream end to end in our tests yet. On Android the phone's H.264 decoder has to take the stream.
- Safari, iPhone, iPad (LL-HLS): every browser on an iPhone or iPad, Safari on a Mac, Firefox for Android, and any browser on a network that blocks UDP. These play the LL-HLS fallback, which is further behind than MoQ. The player's switch to it has been tested in a desktop browser made to look like Safari, and the LL-HLS the ingest makes has been checked on its own, but the fallback has not been played through the service on a real iPhone yet, and its delay on phones is not measured (Phones and Safari).
- React:
@nearglass/reactwraps the same player, so it behaves as the browser it runs in does. Its own tests run without a real React. - Native Windows app: the C library plays over MoQ only, video only, with no fallback. It has played streams on Linux; it has not been built or run on Windows yet.
- RTMP: an ffmpeg RTMP source was checked on the LL-HLS side only; RTMPS and WHIP have run in the ingest's own tests, not through the whole service.
Why the rows differ
- LL-HLS is made by the ingest gateway, from the video an encoder sends
it.
nearglass publishand the C library send to the relays directly, so there is nothing to make it from: a viewer whose browser needs the fallback sees "cannot play". Send from an encoder over SRT or RTMP when Apple devices must watch. - Sound travels only over SRT and RTMP today, as AAC-LC or Opus (Audio). WHIP, the file replay, the camera and the C library carry the picture only.
- Driving a machine needs MoQ. A controller page sends its commands over the same connection, so driving works only in the "Browser over MoQ" column. Watching works wherever the stream plays.
Settings that are not enforced yet
max_kbpsis recorded with the stream and handed to the ingest gateway, but the gateway does not enforce it: a higher bitrate is accepted. Set your encoder's bitrate yourself.
What has been tested, and how, is on Feature status.