DEV Community

Ankush Banyal
Ankush Banyal

Posted on

NDI, SCTE-35 and MoQ in Ant Media Server: Three Protocols, Three Different Problems

#streaming #webrtc #video #quic

Three protocols keep coming up in conversations with teams building live video right now: NDI, SCTE-35, and MoQ. They solve completely unrelated problems. NDI is about getting video off a production LAN. SCTE-35 is about telling an ad server when to cut. MoQ is about what live delivery looks like in five years.

Ant Media Server supports all three today, at different levels of maturity. This post covers what each one does, how it is wired up, and where the edges are.

NDI: getting video out of the studio

NDI moves uncompressed or lightly compressed video over a local network. If you have vMix, OBS, a Blackmagic switcher, or a PTZ camera on your gigabit LAN, they probably speak it. It is the default plumbing inside most production facilities.

The problem is that NDI stops at the LAN boundary. It was designed for high-bandwidth local networks, not the public internet. So the moment you want that studio feed to reach browsers, you need something to pick it up and re-deliver it.

That is the job AMS does here. NDI is one of the supported ingest protocols alongside WebRTC, RTMP, SRT, RTSP and WHIP. Once the feed lands, it goes through the same pipeline as everything else: transcoding, adaptive bitrate ladder, recording to MP4, delivery over WebRTC, HLS, LL-HLS or DASH.

The practical shape of a deployment looks like this:

vMix / OBS / PTZ camera
        |
        |  NDI over the studio LAN
        v
  Ant Media Server  ---->  WebRTC (sub-second)
                     ---->  LL-HLS (CDN scale)
                     ---->  MP4 recording
Enter fullscreen mode Exit fullscreen mode

Nothing exotic. The value is that the studio side keeps working the way the production team already works, and the delivery side becomes a browser problem instead of a broadcast problem.

SCTE-35: the cue card the ad server needs

SCTE-35 is a signalling standard. It marks the exact points in a live stream where an ad break starts and ends. Without those markers, an ad insertion server has no idea when to swap content. It is flying blind.

Ant Media Server does not insert the ads. It preserves the markers and passes them downstream so a real SSAI platform can do the stitching. That distinction matters when you are scoping a build.

Support arrived in v2.17.0 as a plugin. The mechanics:

  1. Ingest an SRT stream that carries SCTE-35 data in its MPEG-TS payload
  2. The plugin parses the payload looking for splice commands, table ID 0xFC
  3. It injects #EXT-X-CUE-OUT and #EXT-X-CUE-IN tags into the HLS manifest

Your original segments stay in the manifest. The plugin wraps existing content with markers rather than removing anything, so the stream still plays fine even with no ad server attached. Your own segments act as slate during the break.

Once the manifest carries the cues, any SSAI platform that reads HLS with SCTE-35 will work. AWS Elemental MediaTailor, Google Ad Manager, Broadpeak, Yospace. In a MediaTailor setup the pattern is:

Original:     http://your-ams/YourApp/streams/stream1.m3u8
MediaTailor:  https://your-mediatailor-endpoint/streams/stream1.m3u8
Enter fullscreen mode Exit fullscreen mode

MediaTailor becomes the base URL and reads your manifest as the content source. One thing that trips people up: MediaTailor wants port 80, so your AMS needs to be reachable over plain HTTP for that integration.

Because the stitching happens server side, viewers get no player reload and no buffering at the break. It also means the ads are considerably harder to block than client-side insertion.

MoQ: early access to what comes next

Media over QUIC is an IETF working group protocol built on QUIC and WebTransport. The pitch is that it collapses a tradeoff the industry has lived with for a decade: sub-second latency like WebRTC, and CDN relay scaling like HLS, in one protocol.

Google, Cisco, Akamai and Cloudflare are all behind it. At NAB 2026 it was on a lot of booths.

AMS ships MoQ support as a plugin, and it is worth being clear about what that means. The implementation is based on moq-lite, a deployable subset of the spec, not the full IETF moq-transport. The standard is still moving. Treat this as early access.

Requirements are specific:

  • AMS 3.0.0 or later
  • Linux x86_64
  • A Chromium-based browser for playback. Safari does not work. Firefox is unstable.
  • Port 4443 open for UDP and TCP, where the embedded relay listens
  • HTTPS on the server, because browsers only allow WebTransport over HTTPS. Localhost is the exception.

Install is a script plus copying the player pages into your application:

sudo unzip MoQPlugin-release.zip
cd MoQ-Plugin
sudo chmod +x install-moq-plugin.sh
sudo ./install-moq-plugin.sh

sudo mkdir -p /usr/local/antmedia/webapps/live/moq
sudo cp -r moq-ams-player-build/* /usr/local/antmedia/webapps/live/moq

sudo service antmedia restart
Enter fullscreen mode Exit fullscreen mode

After the restart you get a publisher and a player page:

https://your-server:5443/live/moq/publish.html
https://your-server:5443/live/moq/play.html
Enter fullscreen mode Exit fullscreen mode

You can also publish from any moq-lite compatible client straight to the relay:

moq://your-server:4443/moq/streamId/publish
Enter fullscreen mode Exit fullscreen mode

AMS then picks the stream up as a normal broadcast, which is the part that makes this useful rather than a demo. Recording, the REST API and adaptive bitrate all keep working.

On the playback side you pick a track:

moq://your-server:4443/streamId/source
moq://your-server:4443/streamId/720p
Enter fullscreen mode Exit fullscreen mode

source is the original quality as published. 720p and 480p appear if you have ABR renditions transcoded. There is also a publish track, which is the browser publisher's stream going direct and bypassing AMS entirely. Lowest overhead, but you lose ABR, recording and everything else in the pipeline.

Configuration is optional. The plugin runs on defaults. If you want to point at an external relay instead of the bundled one, add this under customSettings in Settings → Advanced:

{
  "customSettings": {
    "plugin.moq": {
      "useEmbeddedRelay": true,
      "ingestEnabled": true,
      "externalRelayUrl": "https://relay.example.com:9000/moq",
      "ingestPollIntervalMs": 2000
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

useEmbeddedRelay set to false switches to externalRelayUrl. ingestPollIntervalMs controls how often AMS polls the relay's /announced endpoint for new streams, defaulting to two seconds.

Codec support is currently H.264 and H.265 for video, AAC and Opus for audio. VP8 and AV1 are not supported yet.

Where this leaves you

If you are running production gear, NDI ingest means you do not rebuild your studio workflow to reach browsers.

If you are monetising live content, SCTE-35 support means AMS slots into an existing SSAI stack instead of replacing it.

If you are watching MoQ, you can build against it now on real infrastructure and find out where it breaks, which is more useful than reading the draft spec. Full moq-transport support is on the roadmap, and MoQ playback is planned to move into the main AMS web player rather than a separate page.

WebRTC is not going anywhere. For interactive video where latency under 500ms is the requirement, it is still the answer. MoQ is interesting where you want that latency with CDN economics, and that is a different set of use cases.

Docs for each of these are at docs.antmedia.io. If you are building something on the MoQ plugin, the community forum is where that conversation is happening.

Top comments (0)