DEV Community: Fuad Laguda

The iOS camera lies for about a tenth of a second, and that is why nobody noticed it

Fuad Laguda — Fri, 18 Sep 2026 16:19:39 +0000

Now, two weeks ago I wrote that the iOS camera track reports 1920 by 1080 while the browser draws portrait, and that you should measure the picture instead of trusting the track. Now, altough that is true, it turns out to be half the story, and the missing half is this.

The track does not lie all the time, so maybe I have to change the title of my first post.

But it does lie for about a tenth of a second, and that is exactly why it was not noticed.

The first piece is here: Why your web teleprompter records sideways on iPhone, and the fix.

I was trying to give the fix away

I had the fix working in my own product and I had put it on GitHub under MIT and I wanted a library to take it, to save the next person three nights.

So I checked four libraries

Project	Merged pull requests	What that told me
react-webcam	0 merged since January 2025	will not merge my work
videojs-record	6 merged since January 2025, all dependabot	no human contributions
react-media-recorder	2 merged, then silent for 13 months	effectively dead
livekit/client-sdk-js	125 merged against 10 closed unmerged since 1 May 2026	alive

The test said there was no bug four times.

I built a small page against livekit-client 2.22.3 and ran it on my iPhone 15, iOS 26.6.

LiveKit's default 720p preset: the track said portrait, the picture was portrait. The 1080p preset: same. Microphone in the same call: same. My own exact constraints with no LiveKit in the path at all: same.

Four runs, no mismatch anywhere, then I sat with that for a while. I had a published article saying the track lies, and my own test was telling me it does not.

The fact that would not fit

Same phone, same ten minutes, I opened the demo with the fix switched off and recorded a take, and there it was the bug.

Those two things cannot both be true, if the track reports portrait, the fix has nothing to trigger on, and fix on and fix off would produce the same file, but they did not, so the phone was not wrong it is my test.

The window

I stopped waiting for the preview and read the track the moment it existed, then kept reading. Again it was there I noticed something, it was quick, but i saw a flip because my android lags a lot. so I decided to check the numbers.

track created                     +1059 ms
track.dimensions immediately       1920 x 1080   landscape
waitForDimensions() returned       1920 x 1080   at +1071 ms
track.dimensions after 1st frame   1080 x 1920   portrait, at +1473 ms

A second, separate run: 1920 by 1080 at +1377 ms, then 1080 by 1920 at +1516 ms. A gap of 139 ms against 112 ms in the first run, same behaviour, different number.

Keep that in mind, it matters later.

So the camera reports the raw sensor frame until it has actually produced a picture, then it corrects itself. Read inside that window and you get landscape, then read outside it and you get portrait, so both of my earlier claims were true, they were just true at different milliseconds.

Why the bug hides

Every one of my four clean tests waited for the preview to appear before reading the numbers. That is the most natural thing in the world to write. It is also the one thing that puts you on the wrong side of the window every single time. If not for the fact that my Android is slow and lags, I would not have noticed that.

A test written without knowing the window exists cannot see the bug, no matter how carefully it is written.

That is not an iOS or Android lesson, any time a value is eventually right, a test that waits for things to settle will pass, and the code that did not wait will fail in production.

The year-old issue this explains

LiveKit had issue 1377, "Incorrect orientation of a remote video track's dimensions", opened in January 2025. Three separate people reported it over thirteen months. A core engineer replied, reopened it once when the bot closed it, and then it was closed again with nothing changed. Their comment on it was honest and nearly right: "browsers report wrong initial resolution on iOS."

Here is the mechanism. waitForDimensions sleeps 10 ms on iOS and then polls until dimensions exist. They exist immediately, and they are wrong, so it returns at about +12 ms with the landscape pair. That pair goes out to the room as req.width and req.height. A portrait phone announces itself as landscape, and everyone on the call lays it out sideways.

Nobody had the window and without it, the bug looks like a flaky report that never reproduces.

Why a longer sleep is not the fix

112 and 139. Those are two runs on the same phone, minutes apart. The window changes with the device, the camera, the requested resolution and how busy the phone is. Any fixed delay is a race you will eventually lose, and it taxes every user who did not need the wait. The signal is the first frame, not the clock.

What to do instead

Two shapes, and I have used both.

Wait for a frame, not a duration. A detached video element with requestVideoFrameCallback fires when the first frame has actually gone through the pipeline. Safari 15.4 and up, Chrome too, nothing needs to be in the DOM.

const v = document.createElement('video')
v.muted = true
v.playsInline = true
v.srcObject = new MediaStream([track])
await v.play()
await new Promise<void>((done) => v.requestVideoFrameCallback(() => done()))
const { width, height } = track.getSettings() // now correct

Or stop trusting the report at all, draw one frame onto a 16 by 16 canvas and look at which corner got paint. One drawImage, one getImageData, deterministic. That is the probe in camera.ts in the repo, and it is what my product ships.

What happened when the window was written down

I filed the measurement as issue 2099 on 14 September with the timing table above and the first shape as a suggestion. A LiveKit engineer replied the same day and opened PR 2100, which waits for the first frame on iOS. I ran their branch on the phone, normal power and Low Power Mode, and posted the readings as a review. One thing did not sit right: the gate was getBrowser().os === 'iOS', and an iPad sends a Mac user agent, so iPads would skip the wait. PR 2100 merged on 17 September.

I filed the iPad gap as issue 2107 with two possible shapes. They measured the first, found the first frame can take 500 to 1000 ms on macOS, and took the second, which is treat Safari with a Mac user agent and more than one touch point as iPadOS. PR 2110 went up on 18 September and I ran that build on the iPhone and on an Android and posted the numbers.

So, the first report to first fix was six hours. First report to second fix, four days.
Thirteen months before that, with three reporters and nothing changed. The difference was not effort or skill on anyone's part, it was one measurement that nobody had taken, and who would care about what happened in the tenth of a second? Silly enough my app did.

The probe, the planner and the wait for the first painted frame are now a package you can get here: npm install portrait-camera, MIT, no dependencies. Source at github.com/lagudafuadtosin/portrait-camera.

Why your web teleprompter records sideways on iPhone and Android. Here is the fix

Fuad Laguda — Sun, 06 Sep 2026 12:48:57 +0000

I built a teleprompter that runs in the phone's browser and records the take with the front camera behind the script. The scrolling part took an evening but the recording part took three nights, and every one of them was the same bug wearing a different hat as the take came out sideways, or zoomed into one eye, or both.

If you have ever asked getUserMedia for a portrait video on a phone and got a landscape file back, this is what was going on, and here is what fixed it. The code is on GitHub: web-teleprompter. MIT, no dependencies beyond React.

The setup

A phone, held upright, front camera. The page asks for the camera, shows the preview in a <video>, and records with MediaRecorder. Nothing exotic. The preview looked a bit off to me hadd my suspicions, but felt it was all in my head, and recorded it anyway without digging much into it. It was later I realised the file was wrong.

Wrong theory one: I need to ask for portrait

My first request was the obvious one, because that is what I wanted

navigator.mediaDevices.getUserMedia({
  video: { facingMode: 'user', width: { ideal: 1080 }, height: { ideal: 1920 } },
})

Now, the preview on screen looked funny but I recorded anyway, and it was the day of live testing that I saw that the file came back landscape, on its side, and badly off. This was tested On iOS 26.6 Safari and on Android 15 Chrome, that request gives you the sensor's wide preset, 1920 by 1080, unrotated. exact instead of ideal gave the same thing or an error. aspectRatio: 9/16 gave the same thing. Now the phone does not have a portrait preset, it is landscape presets and it rotates the picture on screen to match how the phone is held, and the recorder saves the unrotated one.

That is the bug, I asked for portrait, got a landscape file.

Wrong theory two: make it portrait myself

If the file is landscape, cut a portrait out of it, was my thought. So, I recorded through a canvas that always took the centre 9:16 out of the reported size. But that gave a 608 by 1080 slice out of a 1080 by 1920 picture, and a horrible three times zoom on an eye and a nose. That was the "zoomed in" half of the bug, and I own this error, it was entirely mine.

What fixed it: ask in landscape numbers

I only tried this to check the picture quality, because I had given up trying to debug the issue. I asked for landscape, expecting a landscape file I could at least look at, and the file came out portrait.

{ video: { facingMode: 'user', width: { ideal: 1920 }, height: { ideal: 1080 }, frameRate: { ideal: 30 } } }

Ask for landscape and you get portrait, because the phone picks a real preset and turns the picture to match how it is held. That is what the WebRTC samples do, which I found out after two nights. So the lesson for me was, read the samples first.

Belt and braces: measure the picture, not the track

Even with the landscape request, the video track reports the sensor size. getSettings() says width 1920 and height 1080 while the frame on screen is portrait. So the shipped code does not trust the reported size, it draws one frame onto a sixteen pixel canvas and looks at which corner got paint.

function measureDrawnFrame(video, reportedW, reportedH) {
  const big = Math.max(reportedW, reportedH)
  const S = 16
  const c = document.createElement('canvas')
  c.width = S
  c.height = S
  const ctx = c.getContext('2d', { willReadFrequently: true })
  ctx.scale(S / big, S / big)
  ctx.drawImage(video, 0, 0)
  const px = ctx.getImageData(0, 0, S, S).data
  const painted = (x, y) => px[(y * S + x) * 4 + 3] > 0
  const wide = painted(S - 1, 1) && !painted(1, S - 1)
  const tall = painted(1, S - 1) && !painted(S - 1, 1)
  if (wide) return { w: big, h: Math.min(reportedW, reportedH) }
  if (tall) return { w: Math.min(reportedW, reportedH), h: big }
  return null
}

If the bottom left is painted and the top right is not, the picture is tall. That is the whole probe. With it the recorder picks one of three plans.

Portrait picture, and the track agrees - record the raw stream, because that is the best quality, nothing to do.
Portrait picture, but the track says landscape - draw the picture to a canvas at its own size and record the canvas stream.
Wide picture on a portrait screen - (Now that is a result from my Android device) Record what the preview shows, the centre cut to 9:16 at the frame's own height.

const plan = planRecordingStream(video, stream) // raw | canvas-whole | canvas-crop
const rec = new MediaRecorder(plan.stream, { mimeType: pickMimeType(), videoBitsPerSecond: 10_000_000 })
rec.onstop = () => plan.stop()

planRecordingStream is about forty lines and it is in the repo with the dead ends left in as comments, because the dead ends are the useful part.

One more thing: Baseline

MediaRecorder.isTypeSupported on Safari says yes to H.264 Baseline and to High. If your candidate list has Baseline first, you get Baseline, and every take looks soft. Put the High profile first.

'video/mp4;codecs=avc1.640028,mp4a.40.2'

The bug report

I filed it as WebKit bug 323550. Apple's triage retitled it a regression the same day, imported it to Radar, and added three engineers. The history, from their own tracker: WebKit's MP4 recorder has written a rotation transform into the file since a 2020 fix, and Apple's April 2025 commit for the WebM fix still describes mp4 as carrying that metadata. Reports of sideways front camera files start in June 2025 on an Apple Developer Forums thread. Then I ran ffprobe on my own file. It carries a displaymatrix of minus 90 degrees, and with it the file plays upright, in landscape. The same page with the fix produces a file with no note, and it plays upright in portrait.

Why I was doing this at all

The teleprompter is part of Postbarrel, which interviews you about what you want to say and writes the script in your own words, then scrolls it over your camera so you can say it. The recording never leaves the phone, so the camera fix had to work in the browser with no server to fall back on. It does now. The standalone component and demo are here: github.com/lagudafuadtosin/web-teleprompter. If it saves you a night, a star helps other people find it.