DEV Community

Super Funicular
Super Funicular

Posted on

What Happens to a Phone's YouTube Live Stream When Mobile Data Drops? enableAutoStop, Stream Health, and the One-Minute Window

#android #youtube #streaming #mobile

If you stream a phone camera to YouTube Live over mobile data, the connection will drop at some point. A train goes past, the tower gets busy, the prepaid pack runs out, the power cuts and the router goes down with it. The phone usually reconnects within seconds or minutes.

The question this piece answers is narrower and more useful: what does YouTube do with your broadcast during that gap, and what decides whether you come back to the same live video or a new one?

Everything below comes from Google's own YouTube Live API reference and YouTube Help pages, quoted directly and linked at the end. Where the docs say nothing, I say that too, because a few of the answers people repeat on forums are not in any Google document.

What happens to a YouTube Live stream when the phone's data drops?

Short answer: YouTube stops receiving video, the stream is reported as inactive, and viewers see buffering. If the broadcast has auto-stop turned on, YouTube ends it "around one minute" after video stops arriving. After that, the live video is finished and a reconnect needs a new broadcast.

Whether a reconnect inside that minute continues the same broadcast is not documented by Google. Test it on your own channel before you rely on it (a 10-minute test is at the end).

If you use Background Camera RemoteStream: it records with the screen off to the phone's own storage, serves a live view to browsers on your own Wi-Fi, and can push to YouTube Live when you want to watch from outside. No account with us, no cloud of ours, no subscription. The YouTube behaviour below is YouTube's, and it applies to any app or encoder that streams to it.

Two objects, not one: the broadcast and the stream

Most confusion about drops comes from treating "the stream" as one thing. The YouTube Live API splits it in two, and we walked through how an app creates both in Streaming to YouTube Live From an Android Phone With the Screen Off:

  • A liveStream is the pipe. It holds the ingest address and the stream key. Your phone pushes video into it.
  • A liveBroadcast is the event viewers watch. It has a watch page, a privacy setting and, later, an archive.

The broadcast is bound to a stream. When the data drops, the pipe goes quiet. What happens to the event depends on settings on the broadcast.

The pipe usually survives. Google's reference for the isReusable property says a reusable stream "can be bound to multiple broadcasts. It is common for broadcasters to reuse the same stream for many different broadcasts if those broadcasts occur at different times." The broadcast guide says streams are reusable by default: "you can just reuse the stream ID for subsequent broadcasts."

So a drop does not mean you need a new stream key. It may mean you need a new broadcast.

What YouTube reports while the data is gone

The liveStream resource has a status.streamStatus field. Its documented values are:

Value Google's description
active "The stream is in active state which means the user is receiving data via the stream."
inactive "The stream is in inactive state which means the user is not receiving data via the stream."
ready "The stream has valid CDN settings."
created The stream "does not have valid CDN settings."
error "An error condition exists on the stream."

A dropped phone is the active to inactive case. Nothing in that list is "reconnecting".

There is also status.healthStatus.status, with four values: good, ok, bad, and noData, which Google describes as "YouTube's live streaming backend servers do not have any information about the stream's health status."

One thing I expected to be documented and is not: which health value you see during a gap. It would be easy to write "health turns red". No Google page says that. What the docs do give is a specific health issue for a weak connection, videoIngestionStarved:

"YouTube is not receiving enough video to maintain smooth streaming. As such, viewers will experience buffering."

That is the documented viewer experience of a starving stream: buffering. I could not find any Google text promising an "offline" card, a frozen last frame, or a slate. If you have seen one, that is observed behaviour, not a documented contract, and it may change.

The setting that decides it: enableAutoStop

The broadcast resource has a property called contentDetails.enableAutoStop. Google's reference describes it in one sentence:

"Indicates whether this broadcast should stop automatically around one minute after the channel owner stops streaming video on the bound video stream."

The broadcast lifecycle guide says the same thing from the other side: "YouTube will automatically end the broadcast around a minute after you stop sending video on the bound live stream."

Note the wording: "around one minute". Not 60 seconds exactly, and not a promise. Build in margin.

From YouTube's point of view, a phone that loses data and a person who deliberately stops streaming look the same. Both stop sending video. YouTube's own "Stream now" instructions say: "To end the stream, stop sending content from your encoder." That is fine for someone who means to stop. On mobile data, a dead zone does the same thing.

Once the broadcast ends, its lifeCycleStatus becomes complete, which the transition reference describes as "The broadcast is over. YouTube stops transmitting video." Moving a broadcast to live requires the stream to be active, and asking for a move YouTube does not allow returns an invalidTransition error. No Google page says in so many words "a complete broadcast can never go live again". But nothing documents a way back, and the safe plan is: after complete, a reconnect means a new broadcast, with a new watch URL.

That last part matters more than it sounds. If you sent a family member the link to watch the shop overnight, and the link pointed at a broadcast that auto-stopped at 2:14 a.m., that link now shows a finished video. The camera may be streaming again at 2:16 to a different URL.

What about enableAutoStart?

Its pair, enableAutoStart, "Indicates whether this broadcast should start automatically when you start streaming video on the bound live stream." The lifecycle guide gives its default as false. For enableAutoStop, the current reference documents no default, so check the value your app or encoder actually sets rather than assuming one.

Two more details from the docs, for anyone writing their own integration:

  • Per the lifecycle guide, auto-start and auto-stop "can't be set to true before the testing stage because the test would actually cause the broadcast to start."
  • enableAutoStop is listed as updatable. The exception is persistent broadcasts, where the invalidAutoStop error reads: "You cannot modify the enableAutoStop setting for a persistent broadcast."

Turn auto-stop off, then? Not so fast

If auto-stop ends broadcasts on every short drop, the obvious move is to switch it off. Then the broadcast stays in live while the pipe is inactive, and when the phone comes back the same event can carry on.

The cost is the other side of the same coin: if the phone never comes back (flat battery, a power cut that outlasts the backup, a prepaid pack that ran out at midnight), the broadcast stays "live" with nothing in it until someone ends it. For a camera nobody is watching, that is mostly harmless clutter. For a channel with subscribers, it is a live event showing buffering.

There is no right answer here. There is a choice that matches how your connection fails:

  • Short, frequent drops (moving vehicles, a weak signal at the edge of a tower, a busy cell in the evening): auto-stop off keeps one link working. Plan to end broadcasts yourself.
  • Long or final drops (power cuts, data packs running out, a phone left on a shelf for days): auto-stop on cleans up after itself. Accept that each reconnect is a new URL, and that anyone watching will need the new link.

We covered the power-versus-internet split in more detail in What Happens to a Phone Security Camera During a Power Cut or an Internet Outage?. The short version applies here: an internet outage and a power outage break different things, and a live stream needs both.

DVR: what viewers can do after a gap

One related setting is worth knowing. enableDvr "determines whether viewers can access DVR controls while watching the video", and Google says "The default value for this property is true." The Help Center puts it plainly: "Enabling DVR lets viewers pause, rewind, and continue during your stream."

For a camera stream, that means someone who opens the link late can scrub back a bit instead of only seeing "now". The reference also says the property "cannot be updated once the broadcast is in the testing or live state", so it is fixed before the stream starts.

Bitrate: make drops less likely in the first place

Many "drops" on mobile data are not total disconnects. The link gets too thin to carry the bitrate you asked for, and YouTube reports the stream as starved. YouTube's encoder settings page gives these H.264 figures:

Resolution Minimum Recommended
720p, 30 fps 3 Mbps 8 Mbps
480p, 30 fps 0.4 Mbps 4 Mbps

The gap between 720p and 480p minimums is large. On a weak or shared mobile connection, 480p sits much further inside what the link can hold. A bitrateLow health issue exists precisely for streams running under the recommended rate. If you see it often, dropping resolution is usually worth more than any reconnect setting.

The data side of this, including what a day of streaming costs on a prepaid pack, is in Should You Leave the SIM Card in an Old Phone Security Camera?.

The live stream is a view. The local file is the record.

A YouTube Live broadcast is a way to watch. It was never a good way to keep footage from a connection that drops. Anything that happened during a gap simply was not sent.

That is why a local recording on the phone matters more than any YouTube setting. It does not care whether the mobile network is up. Whether one phone can record to storage and stream at the same time depends on its camera hardware level. We explained how to check yours in One Camera, Two Consumers. Keeping recording running with the screen off is its own problem, covered in Why Does My Android Camera Stop Recording When the Screen Turns Off?.

A 10-minute test you can run today

Docs tell you what YouTube promises. A test tells you what your setup does. Use an unlisted broadcast so nobody else sees it.

  1. Start a stream from the phone to YouTube and open YouTube Studio's live control room on another device.
  2. Let it run for two minutes. Note the watch URL.
  3. Turn on airplane mode on the phone for 20 seconds, then turn it off. Watch what the control room shows, and whether the same watch URL picks up again.
  4. Do it again for 3 minutes. Check whether the broadcast has ended and whether a reconnect created a new one.
  5. Write down both results. That is your real reconnect window, on your phone, your app and your network.

If the 20-second gap continues the same broadcast and the 3-minute gap does not, your setup is behaving the way the documented enableAutoStop description predicts. If both continue, auto-stop is probably off. If both end, something besides auto-stop is closing the session, and it is worth checking your app's own reconnect behaviour.

Summary

  • A dropped phone moves the YouTube stream from active to inactive. The stream key survives; reusable streams are the documented default.
  • The broadcast is what can end. With enableAutoStop on, YouTube ends it "around one minute" after video stops arriving.
  • After a broadcast is complete, plan on a new broadcast and a new watch URL.
  • The documented viewer experience of a starved stream is buffering. Nothing in Google's docs promises an "offline" screen.
  • enableAutoStop has no documented default. Check what your app sets.
  • Lower bitrate prevents many drops. A local recording covers the ones you cannot prevent.

Get the app on Google Play or read more at superfunicular.com.

Sources

All pages read on 12 October 2026.

Top comments (0)