Reconnect Windows and Clean Stream Exits

The Internet is not always the most reliable thing in the world, and live streaming inherits a lot of that. When running a live event, production teams often have to take into account the vagaries of windstorms, fiber-seeking backhoes, and somebody spilling a coffee on a router in Iowa.

The good news is that Mux recognizes that sometimes Stuff Happens and it's important to help you provide your viewers with as seamless an experience as we can in situations where packets aren't quite showing up on time. To this end, Mux implements reconnect windows. We'll send out any video that we currently have from you, and we'll have a seamless resumption of content if you've reconnected before we run out of buffered video. If your encoder doesn't reconnect before we run out of buffered video, players will stop receiving new video segments and will stall--freezing in place--until your encoder reconnects. And then, if your encoder doesn't reconnect at all until that window expires, Mux will finalize the asset, set the stream back to idle, and when you go live again you'll begin a new asset within Mux.

This can be really helpful if you have a stray blip in your stream; your stream may hitch, but players will pick back up where they left off when your encoder reconnects and the VOD that Mux saves afterwards will be uninterrupted.

There's a tradeoff to this, however, and it is one that you as a developer or a producer need to be aware of. We're working on some ways to make this smoother, but at the moment, intentional stream termination is indistinguisable from network failure. If you finish your broadcast, sign off, and immediately stop streaming, your stream will buffer for its reconnect_window and probably leave your viewers hanging halfway through your sign-off.

There are a few ways to deal with this, each with some tradeoffs to consider.

Fade to black or run an end screen slate

This is probably the simplest option: leave the stream to Mux running for some time after the conclusion of your content (about 30 seconds should be sufficient). Mux will go into wait-for-reconnect mode, but without anything changing there should be little impact on your content. To avoid odd behavior at this point, your stream should probably not be playing any audio, as when the reconnect window closes the final few frames, and any audio associated with them, will be played out and that could be confusing or distracting.

Beyond this potential confusion, there's a technical drawback to be aware of, too. If you are using this live stream in a more elaborate setup, such as part of a rich media application, your video stream won't be officially terminated (technically speaking, the HLS playlist will lack an EXT-X-ENDLIST tag) until the reconnect window has finished. Your player will not emit an ended event (or equivalent) until this window has closed and the stream is terminated. As such, you could find that your application is hanging until you've reached this point.

Use the Mux API to call signalComplete

We provide the signalComplete API call to allow you to immediately tell Mux "we're done here". It will flush all video buffers and end the stream. This can be done while the stream is still running, so you won't see a frame skip, but there's an important catch: since signalComplete will disconnect your encoder, your encoder may interpret this as "the ingest server has gone away" and attempt to reconnect. That reconnection will start a new Mux asset, will fire all your webhooks again, and so on and so forth.

To avoid restarting the stream and potentially causing yourself some grief, you can disable the live stream and disallow your encoder from reconnecting to it. You'll need to re-enable the live stream when you want to stream again, but this will prevent any undesirable behavior out of your encoder during sign-off.

If you're using the API directly you'll need to call disable yourself after signalComplete; if you're using the Mux CLI, you can just do the following:

# when you're ready to sign off... (-d also works)
$ mux live:complete --disableAfterCompletion YOUR_STREAM_ID

# ...and later, before you try to go live
$ mux live:enable YOUR_STREAM_ID

Enable reduced_latency to opt out of reconnect windows entirely

The final option is to disable reconnect windows entirely. This is done through enabling reduced latency mode when you create your live stream, as in the following example call to POST https://api.mux.com/video/v1/live-streams:

{
  "playback_policy": ["public"],
  "reduced_latency": true,
  "new_asset_settings": {
    "playback_policy": ["public"]
  }
}

(If you're creating your stream through the Mux dashboard you can just paste that JSON blob right into it.)

This will disable reconnect windows entirely. When your encoder stops, your stream will stop. This does, however, create an important consideration: you are relying on your encoder's uplink to be stable. If your encoder's Internet connection flakes, or one of the dozen-plus routers between your encoder and our ingest server decides to take a nap, your stream will cut and upon reconnection Mux will generate a new asset. This will fire off your webhooks again; your VOD files, too, will be separated, and you'll have to do your own work to stitch them together.

In many cases, this can be acceptable behavior--what I've described here is not unlike what streaming to Twitch with disconnect protection off is like. But in an application that's tightly coupled to the Mux live-to-VOD workflow, this may create unexpected and undesired behavior. It's up to you to decide what works best for your application.

I hope this breakdown of your options with regards to clean stream exits in Mux helps you plan and operationalize your project. If you have any questions, please feel free to click the chat-bubble icon in the bottom right corner of every page on the Mux site to get in touch with a support engineer.

Thanks for using Mux!