The colors look wrong
What the phone can and cannot reproduce — transparency over black, untagged BT.709, no HDR, and a Windows-only downscaling difference.
The picture on the phone does not match the Program Monitor.
Some of this is expected and correct; some of it is a real limit of the current pipeline. This page separates the two so you know which parts to stop chasing. The full technical description is in Picture and color.
PreviewMonitor is a reference monitor for framing, motion and composition on a phone-shaped screen — it is not a calibrated grading display. Do not sign off a grade on it.
1. Transparency shows as black — this is correct
If a title, a Drop Shadow, an adjustment layer with no video under it, or any gap in the timeline renders as solid black on the phone, that is the intended behavior and it matches what Premiere Pro's own Program Monitor shows you.
Premiere Pro hands the plugin straight alpha: the color channels carry full intensity regardless of coverage. A Drop Shadow over an empty track arrives as pure white pixels with the alpha ramping from 0 upward. Ignoring alpha would publish a solid white block where the shadow belongs, so all three encoders composite every pixel over black before encoding — the same thing the Program Monitor does when it displays transparency.
The matte is applied before chroma subsampling, so shadow edges stay correct rather than picking up fringing.
There is no way to change this and no alpha channel on the wire. If you need to see the transparency itself, look at Premiere Pro.
2. The picture is BT.709 limited range, and untagged
The plugin converts to BT.709 limited range — luma 16–235, chroma 16–240 — using a matrix chosen on Windows to match what VideoToolbox does by default on macOS, so both platforms produce the same numbers.
Neither platform writes color-space metadata into the bitstream. No primaries tag, no transfer-function tag, no matrix tag, no nominal-range tag — on Windows or macOS. The stream is BT.709 limited range but unsignalled, so the decoder falls back to whatever the encoder happened to put in the video usability information, or to its own default.
In practice on an iPhone this decodes as BT.709 and looks right. But it is the most likely explanation for a small, consistent shift — slightly crushed blacks, slightly lifted blacks, or a mild saturation difference — that you cannot account for any other way. It is a known gap, not something you can configure.
If you see a large shift, suspect the phone's own display settings first:
Turn off True Tone — Settings → Display & Brightness. It warms the display to match ambient light, which is exactly what you do not want when judging color.
Turn off Night Shift, and check no schedule is about to switch it on.
Turn off Auto-Brightness — Settings → Accessibility → Display & Text Size → Auto-Brightness — and set a fixed brightness.
3. HDR and Rec.2020 sequences are not handled
The pipeline is 8-bit in and 8-bit out, end to end: 8-bit BGRA from Premiere Pro, 8-bit 4:2:0 on the wire. HDR, Rec.2020 and any wide-gamut or high-dynamic-range sequence is not tone-mapped, converted or tagged.
An HDR timeline will reach the phone as 8-bit BT.709-matrixed video with no signalling, which typically reads as flat, desaturated and wrongly exposed. That is the pipeline hitting a limit, not a setting you have missed.
Use PreviewMonitor on HDR work for framing and motion. Judge the image itself in Premiere Pro.
4. Fine detail differs between Windows and macOS
At any Resolution Limit below Source, Windows and macOS produce visibly different picture quality. This is a real inconsistency, not your imagination.
Premiere Pro always hands the plugin the sequence's full frame size. Whenever your Resolution Limit is lower than that, the plugin has to scale the frame down before encoding — and the two platforms do it differently:
| Platform | Downscaler | Result |
|---|---|---|
| macOS | High-quality resampling (Lanczos-class) | Fine detail averages down cleanly |
| Windows | Nearest-neighbour point sampling | Fine detail aliases — shimmer on hair, fabric, small text, fine grids |
On Windows the scaler copies one source pixel per destination pixel with no averaging at all, so anything with high-frequency detail crawls under motion.
Workaround: set Resolution Limit to Source on Windows and let the encoder work at the sequence's native size. No scaling happens, so the difference disappears. The cost is bandwidth — check The stream stutters or lags if the network cannot carry it.
On a 4K sequence, Source on Windows with H.265 selected can trip a separate bug and produce no picture at all. See The screen is black before you switch.
5. Softness is chroma subsampling, not a fault
The stream is 4:2:0 — full luma resolution, chroma at half in both directions, averaged in 2×2 blocks. That is standard for H.264 and H.265 delivery and is not adjustable.
The visible consequences are the usual ones: saturated red and blue edges look softer than they do in Premiere Pro, and fine colored text can fringe. Neither indicates a problem.
What to check when something still looks off
| Symptom | Most likely cause |
|---|---|
| Transparency is black | Correct behavior — check 1 |
| Small consistent shift in blacks or saturation | Untagged BT.709, or True Tone / Night Shift — check 2 |
| Flat, washed out, wrongly exposed | HDR or Rec.2020 sequence — check 3 |
| Shimmering fine detail, Windows only | Nearest-neighbour downscaling — check 4 |
| Soft or fringed color edges | 4:2:0 chroma — check 5 |
| Blocking, smearing, tearing | Not a color problem — see The stream stutters or lags |
Last updated on
There's no audio
The picture streams but the phone is silent. Check the Audio Stream checkbox, the speaker button's state, and the free-tier sample gate.
The transport buttons do nothing
Play, pause and frame-step on the phone have no effect. Foreground focus, the Control Surface plugin, and what After Effects can and cannot do.