Picture and color

What the phone shows versus the Program Monitor — pixel format, alpha handling, BT.709 conversion, missing color tags, and the two platforms' scalers.

This page exists so you can decide how far to trust the image on the phone. The short version: PreviewMonitor reproduces what Premiere Pro's Program Monitor shows, in BT.709 limited range, 8-bit, 4:2:0 — but it writes no color-space tags into the bitstream, and it does not handle HDR at all. Use it for framing, safe zones, motion, legibility and relative grade. Do not use it as a calibrated color reference.

The pipeline in one line

Premiere Pro renders the program frame → hands it to the plugin as 8-bit BGRA → the plugin mattes it over black → downscales if your Resolution Limit is below Source → converts to 8-bit 4:2:0 → encodes as H.265 or H.264 → the phone decodes and draws it.

Input pixel format

The plugin accepts exactly one pixel format from Premiere Pro: PrPixelFormat_BGRA_4444_8u — 8 bits per channel, blue-green-red-alpha.

A frame in any other format is dropped, with one line in the log naming the four-character format code it got instead. This is the format Premiere Pro delivers to Mercury Transmit devices in practice; if you ever see it drop frames for this reason, that is a bug worth reporting, not a setting.

There is no 10-bit path. The pipeline is 8-bit in and 8-bit out.

Alpha: Premiere Pro's convention, and why the plugin mattes over black

Premiere Pro's alpha convention is straight, not premultiplied (alphaStraight in the SDK's alpha-type header). In a straight buffer, RGB carries full intensity regardless of coverage — a pixel that is 15% covered still stores whatever color it would be at 100%.

Every color conversion in the pipeline reads only B, G and R. Without a matte, a partially transparent region in the final composite — a Drop Shadow over an empty track, a clip at less than 100% opacity with nothing beneath it — would reach the phone at full intensity, turning a soft gradient into a flat block the size of the shadow's bounding box.

The measurement

This was not inferred from appearance. The plugin carries a probe that samples the incoming buffer and counts pixels violating max(R,G,B) <= A.

That inequality is the discriminator, and it is an invariant rather than a heuristic: premultiplied RGB can never exceed its own coverage, so max(R,G,B) <= A must hold for every pixel of a premultiplied buffer. A single violation proves the data is straight.

Measured on a Drop Shadow over an empty track:

Observation	Value
Shadow pixel color	`B = G = R = 255`
Shadow pixel alpha	ramping `0` to `38`
Non-opaque pixels violating `max(R,G,B) <= A`	12.9%

Zero violations would have been consistent with premultiplied data. 12.9% is not.

The fix, and the ordering rule that goes with it

All three converters — the Windows scalar path, the Windows GPU compute shader, and the macOS path — matte RGB over black (RGB × A / 255) before doing anything else. Premiere Pro's own Program Monitor draws transparency as black, so matting over black is what reproduces what you see in the application.

The matte must happen before any filter that combines pixels. Chroma subsampling and resampling both average neighboring pixels, and

avg(RGB) × avg(A)   ≠   avg(RGB × A)

wherever both color and coverage vary across the block — that is, along exactly the soft edge the matte exists to render correctly. Matting after a resample leaves a halo on the shadow's edge at every Resolution Limit below Source. Both platforms therefore matte first, then scale, then convert.

The Windows scalar routine and the Windows GPU shader use identical fixed-point rounding, so the two paths are bit-identical. The macOS matte uses Accelerate's own premultiply routine, whose rounding can differ from the Windows one by a single least-significant bit — invisible, and smaller than the difference the two platforms' color conversions already introduce.

Color conversion

The two platforms reach YUV by different routes, deliberately aimed at the same result.

	Windows	macOS
Converter	the plugin's own BGRA → NV12 routine (scalar or D3D compute shader)	VideoToolbox, from a 32BGRA pixel buffer
Matrix	BT.709 limited range — Y in 16–235, chroma in 16–240 — applied as explicit Q8 fixed-point coefficients	VideoToolbox's own default conversion
Chroma	4:2:0, 2×2 averaging, no chroma siting offset (co-located, the NV12 default)	VideoToolbox's own
Depth	8-bit	8-bit

The Windows matrix was chosen specifically to match VideoToolbox's default, so the two platforms' bitstreams decode to the same colors. The plugin's BT.709 matrix never runs on macOS — VideoToolbox does that conversion itself.

No color-space tags are written

Neither platform writes color signaling into the encoder's media type or the pixel buffer. Specifically, none of these are set anywhere in the plugin:

MF_MT_VIDEO_PRIMARIES
MF_MT_TRANSFER_FUNCTION
MF_MT_YUV_MATRIX
MF_MT_VIDEO_NOMINAL_RANGE
the VideoToolbox equivalents: ColorPrimaries, TransferFunction, YCbCrMatrix

The picture is BT.709 limited range, but it is unsignalled. The decoder on the phone infers primaries, transfer function and matrix from whatever VUI the encoder happens to emit, and different encoders emit different things.

In practice, for BT.709 HD content on an iPhone, the inference lands on BT.709 and the picture looks right. But it is an inference, not a declaration, and it is the most likely explanation if you ever see a small, consistent offset between the phone and the Program Monitor. This is a known gap, recorded in the project's issue list.

Do not grade to the phone. Use it to judge framing, safe-zone clearance, motion, text legibility and how a grade reads at phone size and phone brightness — the things a laptop-sized Program Monitor cannot tell you. Judge absolute color on a calibrated display.

HDR and Rec.2020 are not handled

There is no HDR path. The pipeline is 8-bit BGRA in and 8-bit 4:2:0 out, with no transfer-function handling, no tone mapping and no wide-gamut support.

An HDR or Rec.2020 sequence still streams — Premiere Pro hands the plugin 8-bit BGRA and the plugin encodes it — but what arrives on the phone is whatever Premiere Pro's own conversion to 8-bit BGRA produced, decoded as if it were BT.709 SDR. Treat the result as indicative of framing only.

Downscaling differs between Windows and macOS

Whenever your Resolution Limit is below Source, the plugin scales the frame down before encoding. The two platforms do not use the same scaler.

Platform	Scaler	Result
Windows	nearest neighbor — one pixel copied per destination pixel, no averaging	Aliasing on fine detail: hair, fabric weave, small text, thin lines, dense titles
macOS	Lanczos, via Accelerate's high-quality resampling	Clean, correctly filtered downscale

This is a real, visible difference in picture quality between the two hosts at any rung below Source, and it is a known gap rather than a design choice.

If fine detail matters for what you are checking on a Windows host:

Raise the Resolution Limit — the artifact scales with how far down you are scaling, and disappears entirely at Source.
Or judge fine detail at Source and switch back down for everything else.

At Source no scaling happens on either platform, so the two are equivalent.

What the phone can and cannot tell you

Trust the phone for	Do not trust the phone for
Framing and composition at phone size	Absolute color accuracy
Safe-zone and platform-UI clearance	Fine gamma or contrast decisions
Motion, cadence, and cuts	Highlight or shadow detail at the extremes of the range
Text legibility and title size	Anything HDR
Whether a grade reads at phone brightness	Fine detail, on a Windows host below Source

On this page