Dev.to Security 🔐 Cybersecurity 👁 0 📖 10 min read

Why Does My Phone Security Camera Show Dark Rolling Bands Under Tube Lights? 50 Hz Power, Android's Anti-Banding Setting, and What Actually Fixes It

You point an old Android phone at the shop counter, start recording, and check the footage that evening. The picture is sharp and the colours are fine, but there are soft dark stripes across the frame, slowly crawling up

You point an old Android phone at the shop counter, start recording, and check the footage that evening. The picture is sharp and the colours are fine, but there are soft dark stripes across the frame, slowly crawling upward, like a television from the 1990s. In daylight they're gone. Under the tube light, every time.

The phone isn't broken and the app isn't corrupting anything. The phone is recording your electricity supply.

This guide explains where the bands come from, what Android's camera system does about them (and when it can't), and the practical fixes. It's written for people running a phone as a local-only, no-cloud security camera in a shop, storeroom or home lit by tube lights or cheap LED panels, especially in countries on 50 Hz power: India, Bangladesh, Pakistan, Iraq, Algeria, Egypt, Nigeria and most of the world outside the Americas.

Why does my phone camera show dark bands under tube lights?

Because the light is switching on and off very fast, and the phone's sensor reads the picture one row at a time.

Lights powered from the mains don't shine at a constant brightness. Mains electricity is alternating current, and many lamps get brighter and dimmer with every half of the AC cycle. A U.S. Department of Energy report on flicker puts it plainly: for many traditional light sources the dominant flicker frequency "is simply twice the input-line-voltage frequency." So:

Your mains supply Light flickers at One flicker cycle lasts
50 Hz (India, Bangladesh, Pakistan, Iraq, Algeria, Egypt, Nigeria) 100 times a second 10 ms
60 Hz (USA, Saudi Arabia, Philippines) 120 times a second 8.33 ms

Your eyes average that out and see steady light. A phone camera doesn't. Most phone sensors use a rolling shutter: they expose and read the image row by row, top to bottom, not all at once. If one row's exposure catches more of the bright part of the flicker and the next row catches more of the dim part, the rows come out at different brightness. Stack those rows up and you get horizontal bands.

Android's own camera documentation describes exactly this: some fluorescent lights "flicker at the rate of the power supply frequency (60Hz or 50Hz, depending on country)," and if the camera picks the wrong exposure time, the flicker appears "as a set of variable-brightness bands across the image."

Why the bands move instead of sitting still

Banding comes from the exposure time. The movement comes from the frame rate.

At 30 frames per second, each frame takes 33.3 ms. Under 100 Hz flicker, that's 3.33 flicker cycles per frame. Not a whole number, so each new frame starts at a different point in the light's cycle, and the band pattern shifts a third of a cycle every frame. On playback that looks like stripes rolling up or down the picture.

At 25 frames per second the arithmetic changes: 40 ms per frame is exactly 4 cycles of 100 Hz flicker. Any bands would sit still. That's one reason television in 50 Hz countries historically ran at 25 frames a second.

The important thing: if the exposure time is right, there are no bands at all, whatever the frame rate. The frame rate only decides whether bad banding stands still or crawls.

The rule: expose for whole flicker cycles

If every row of the sensor collects light for a whole number of flicker cycles, every row receives the same total amount of light, and the bands disappear.

  • On 50 Hz power the flicker period is 10 ms, so safe exposure times are 10 ms, 20 ms, 30 ms: in camera-app terms 1/100 s, 1/50 s and about 1/33 s.
  • On 60 Hz power the period is 8.33 ms, so safe times are 1/120 s, 1/60 s, 1/40 s.

Notice the trap. 1/60 s is the "safe" speed people learn from American photography advice, and under 50 Hz lighting it is wrong. 16.7 ms is 1.67 cycles of 100 Hz flicker, so it bands. The same is true the other way: 1/50 s under 60 Hz light is 2.4 cycles, and that bands too.

What Android does about it: the anti-banding setting

Android's Camera2 API, the low-level camera interface most serious recording apps use, has a setting built for exactly this: CONTROL_AE_ANTIBANDING_MODE. It tells the phone's auto-exposure system to choose only exposure times that don't cause banding. It has four values:

  • OFF: "The camera device will not adjust exposure duration to avoid banding problems."
  • 50HZ: adjust exposure "to avoid banding problems with 50Hz illumination sources."
  • 60HZ: the same for 60 Hz.
  • AUTO: "automatically adapt its antibanding routine to the current illumination condition."

According to the reference, "AUTO mode is the default if it is available on given camera device." So on many phones the camera handles this for you without any app asking. If you've never seen banding, that's usually why.

So why do some phones band anyway? The same reference leaves three gaps.

Gap 1: AUTO is not guaranteed

Not every phone offers every mode. The list a given camera supports is published in CONTROL_AE_AVAILABLE_ANTIBANDING_MODES, and the documentation says plainly that "not all of the auto-exposure anti-banding modes may be supported by a given camera device."

When AUTO isn't there, the reference says: "the default will be either 50HZ or 60HZ, and both 50HZ and 60HZ will be available." It does not say which one a phone picks.

That matters if you buy second-hand phones. A handset first sold in a 60 Hz market and resold in a 50 Hz one could, on a phone without AUTO, be defaulting to the wrong frequency. The documentation doesn't promise that happens, and it doesn't rule it out. The only way to know is to test the phone under your actual lights (below).

Gap 2: manual exposure switches it off

This is the gap people trip over most. The reference says that if manual exposure control is enabled, "this setting has no effect, and the application must ensure it selects exposure times that do not cause banding issues."

In plain terms: the moment you use a "pro" or manual mode and set the shutter speed yourself, Android's anti-banding stops protecting you. If you set 1/60 s in a shop in Dhaka or Lahore, you will get bands, and it's your setting causing them, not the phone.

Gap 3: auto-exposure has limits too

Anti-banding works by limiting exposure to multiples of the flicker period. Under 100 Hz flicker, the shortest safe exposure is 10 ms. In a brightly lit room the camera may want to expose for less than that, and then it has to trade off against brightness. The documentation doesn't say how a phone resolves that trade-off, so I won't claim a behaviour. If you see bands only in the brightest part of the day under artificial light, this is a likely suspect, and the lighting fixes below apply.

For developers: asking for anti-banding explicitly

If you're writing a Camera2 recording app, the defensive pattern is to check what the camera supports and request it explicitly, instead of trusting the default:

// Read what this camera actually supports
val modes = characteristics.get(
    CameraCharacteristics.CONTROL_AE_AVAILABLE_ANTIBANDING_MODES
) ?: intArrayOf()

val wanted = when {
    CaptureRequest.CONTROL_AE_ANTIBANDING_MODE_AUTO in modes ->
        CaptureRequest.CONTROL_AE_ANTIBANDING_MODE_AUTO
    // No AUTO: fall back to the local mains frequency, which you
    // have to know or let the user choose. 50 Hz in most of the world.
    CaptureRequest.CONTROL_AE_ANTIBANDING_MODE_50HZ in modes ->
        CaptureRequest.CONTROL_AE_ANTIBANDING_MODE_50HZ
    else -> null
}

wanted?.let {
    requestBuilder.set(CaptureRequest.CONTROL_AE_ANTIBANDING_MODE, it)
}

Two extra notes from the reference:

  1. There is a diagnostic. CaptureResult.STATISTICS_SCENE_FLICKER reports what the camera thinks the scene's light frequency is: NONE, 50HZ or 60HZ. The docs suggest it for apps doing manual exposure, so they can pick a safe shutter time. But the key is marked optional: it "may be null on some devices." Treat a null as "unknown," not "no flicker."
  2. Manual exposure is your problem. If your app exposes a manual shutter control, round the user's choice to a multiple of 10 ms (50 Hz) or 8.33 ms (60 Hz), or at least warn them.

A hard-coded 50HZ fallback is a guess. In a 60 Hz market it's the wrong guess. If AUTO is missing, the honest design is to let the user choose, with a hint such as "50 Hz in most of Asia, Africa and Europe; 60 Hz in the Americas."

For the wider set of Camera2 settings that need care on a phone recording in the background, see our earlier guide: Camera2 API: Handling Orientation, Focus, and Exposure in Background.

For shop owners: a 2-minute banding test

You don't need to know any of the above to fix this. Run this test once, with the phone in its real position, under the lights it will really be using.

  1. Turn off daylight if you can: close the shutter or test after dark. You want the tube light or LED panel to be the main light.
  2. Start recording the way you normally would, and leave it for 30 seconds. Include a plain wall or the ceiling in the picture; bands are easiest to see on flat surfaces.
  3. Play it back on a bigger screen, not just the phone. Look for soft horizontal stripes, steady or crawling.
  4. If you use a live view, watch that too. The same exposure feeds both.
  5. Repeat with only one type of light switched on if your shop has a mix. Often only one fitting is the problem.

No bands? You're done. The phone's default is handling it.

Bands? Fixes in order of cost

1. Undo any manual shutter setting. If you or a camera app has set the shutter speed by hand, switch back to auto exposure. If you must stay manual, use 1/50 s or 1/100 s on 50 Hz power, never 1/60 s.

2. Try a different phone. Since the default behaviour depends on the device, a second old phone may simply not band under the same light. If you have two candidates, this test is a good way to choose. Our second-hand phone buying checklist covers the other checks to do at the counter.

3. Change what's lighting the scene. The DOE report notes that electronically ballasted fluorescent lights are "the predominant exception" to strong mains flicker, and that for LEDs, flicker "is generally determined by the LED driver." In practice:

  • An old tube light with a choke (magnetic ballast) is a common flicker source. A tube with an electronic ballast, or a decent LED batten, usually flickers much less.
  • The cheapest LED bulbs and panels sometimes have very simple drivers that pass a lot of 100 Hz ripple through. A different brand on the same holder can make the bands vanish.
  • Daylight doesn't flicker at mains frequency at all, so a window in the frame is the free fix during opening hours.

4. Re-aim the camera. Bands show most on bright, flat surfaces lit directly by the flickering lamp. Pointing the phone so the counter and the door fill the frame, rather than the ceiling near the tube, reduces how visible they are.

5. Accept mild banding if the footage still does its job. For a security camera, the question is whether you can see who came in and what they did. Light, slow-moving bands are ugly but rarely hide a face. Fix what you can for free; don't buy new lights just for looks.

Does this affect night recording?

Indirectly, yes. At night, artificial light is all the camera has, so flicker matters more, and in dim light the camera usually picks longer exposures, which spans more flicker cycles per row and tends to make bands fainter. If your problem is darkness rather than stripes, read Can an Old Android Phone See in the Dark?, and for what Android now offers to brighten live video, our low-light correction piece.

Where Background Camera RemoteStream fits

Background Camera RemoteStream turns an old Android phone into a camera that keeps recording with the screen off, stores footage on the phone (no cloud account, no subscription, no credit card), and serves a live view from a small web server on the phone itself, so you can watch from another phone or laptop on the same Wi-Fi, with no internet plan needed. It can also stream to YouTube Live if you want an off-site view.

Banding is a property of the lights and the phone's camera hardware, so the test above applies to any camera app, ours included. Run it once in the real spot before you rely on the footage. For the full setup of a phone watching a shop without an internet plan, see How to Watch Your Shop With an Old Android Phone.

More guides and the app: superfunicular.com

Sources

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.

Share 𝕏 Twitter ✈ Telegram ↗ Reddit 🟧 HN
← News 🔐 Cybersecurity 🏠 Home