Poor Video Performance With Odd Pixel Dimensions

[micpool]

A recent post in the FB group highlighted a potential cause of poor playback performance with video files containing an odd number of pixels in any dimension, which can reduce the playback performance of a file by 50% or more.

In the example screen recording attached is a test file that simulates the sort of file you might use if you were using 2 4K projectors with a 20% overlap.

The odd pixels  file is rendered 6143x2160 and the bottom file  6144x2160, both ProRes 422

The even pixels file plays back perfectly.

The odd pixel file drops over 50 percent of the frames.

On an M1 Max this is only apparent with large Pixel dimensions. 1920x1080 and 1919x1080 both perform well even when playing 8 cues using each file.

It's also worth noting that if you apply a video effect to these files the stage renderer drops to less than half the usual refresh rate on the file with odd pixels, but renders perfectly with the file with even pixels.


Moral of this story. If you are experiencing poor video performance with large pixel dimension files, it's worth checking that you don't have an odd number of pixels.

Mic

[Sam Kusnetz]

In case anyone is curious, the reason for this performance issue is that the low-level macOS video toolboxes that QLab uses do not actually support video files with odd pixel dimensions.

Our choices for how to handle this are: don’t play the video at all, crop the video by one row or column, or scale the video.

We opted to scale the video, because we want QLab to display every pixel of your source video if you ask it to. This scaling costs processing power, and so it has a negative impact on performance.

The reason Mic’s tests show that it’s only really a problem with large files is simply due to the fact that larger files take more processing power in any case, and that of course means that QLab’s scaling trick takes yet more processing power.

Yours

Sam

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com

--
Contact support anytime: sup...@figure53.com
User Group Code of Conduct: https://qlab.app/code-of-conduct/
 
Instagram: https://www.instagram.com/Figure53
TikTok: https://www.tiktok.com/@QLab.app
Bluesky: https://bsky.app/profile/qlab.app
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/qlab/12e94c6b-6342-4edc-a89e-25255dcba819n%40googlegroups.com.

[micpool]

Thanks Sam,

I'm not entirely understanding the explanation. 

Quicktime Player can play the odd pixel mov and scale it to any resolution without any performance hit. Is this because it's not reliant on Metal?

QLab can similarly scale huge even pixel videos e.g 8000 x8000  to any size including a stage with an odd number of pixels in both dimensions  without a performance hit.  Presumably this bit of the rendering pipeline isn't subject to the same restrictions as the initial file decode.

If the scaling method QLab uses to get an even number of pixels, which presumably can't be using Metal, because that can't handle odd pixel numbers,  results in 50% dropped frames on large odd frame dimensions, and cropping by one pixel doesn't, then losing .0001%  to 0.0002%  of an image would seem to be a small price to pay to not have an unusable number of dropped frames.

Or have I misunderstood?

Mic

[Sam Kusnetz]

On Feb 19, 2026 at 6:47:12 PM, micpool <m...@micpool.com> wrote:

Quicktime Player can play the odd pixel mov and scale it to any resolution without any performance hit. Is this because it's not reliant on Metal?

Since Quicktime Player is closed-source, I cannot say how it works or why. What I know for sure, though, is that Quicktime Player just decodes a video file and plays it in window, which is analogous to only the first step of several that QLab undertakes when playing video. We cannot put an experimental fuel into a lawn mower and then conclude how that fuel will perform in a fighter jet engine.

I also know that Quicktime Player often drops frames or adjusts playback speed by a small percentage in order to give visually smooth playback. QLab does not do this; we prioritize accuracy.

QLab can similarly scale huge even pixel videos e.g 8000 x8000  to any size including a stage with an odd number of pixels in both dimensions  without a performance hit.  Presumably this bit of the rendering pipeline isn't subject to the same restrictions as the initial file decode.

That is accurate. The specific thing that Metal and Core Image do not support is a video file whose width or height is an odd number of pixels. Stages, windows, etc. can be odd sizes, as can indivisual scaled images placed within a rendered raster.

If the scaling method QLab uses to get an even number of pixels, which presumably can't be using Metal, because that can't handle odd pixel numbers,  results in 50% dropped frames on large odd frame dimensions, and cropping by one pixel doesn't, then losing .0001%  to 0.0002%  of an image would seem to be a small price to pay to not have an unusable number of dropped frames.

I haven’t done enough testing to give a thorough response to the 50% dropped frame number, nor have I done testing on whether a single pixel crop has any effect on performance or not. It could be that cropping one pixel out while decoding has just as significant a performance penalty.

But I do feel, rather strongly, that whether or not it “seems a small price to pay” should be a decision that QLab does not make for you, and instead should be a decision you get to make for yourself. We make QLab as easy to use and accessible as we can, but ultimately it is a professional level tool and many QLab users have an expectation that it will do exactly what they ask it to. If you’re outputting video to an LED wall, sometimes even the slightest adjustment to the image dimensions can result in obvious picture quality issues.

Far and away the best solution to performance issues that stem from video files with odd pixel dimensions is to use a video editing tool to crop or resize the video so that it has even pixel dimensions.

Best

[Richard Williamson]

While I agree with a lot of Sam’s points, I do feel that qlab should be warning the user that this scaling (and possible performance impact) is happening, so the user is able to respond appropriately - it’s definitely not a widely known restriction, and I can imagine it taking a lot of work to diagnose 

Richard 

Sent from my iPhone

On 20 Feb 2026, at 14:50, Sam Kusnetz <s...@figure53.com> wrote:



--
Contact support anytime: sup...@figure53.com
User Group Code of Conduct: https://qlab.app/code-of-conduct/
 
Instagram: https://www.instagram.com/Figure53
TikTok: https://www.tiktok.com/@QLab.app
Bluesky: https://bsky.app/profile/qlab.app
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qlab/CAOOK5AYuAnNs_c0FHru0dgF0-P37C%3DXXc2YgK2Gs%2Bebupvm4Bg%40mail.gmail.com.

[Chris Ashworth]

Filed in the issue tracker; thanks.  

I think there’s a bit of gray area to this idea because it starts to raise the question “will QLab be warning me about any file that might perform badly? when and under what circumstances?” to which the answer would be “no, we can’t reasonably do that” and then this stands out as an exception. 

Our standard suggestion for video files is to run them through Compressor, which has solved countless video encoding issues over the years (and does not generate files with odd pixel dimensions, to the best of my knowledge).  So another way to think about this problem is “are we trying to force people to use an encoding path? are we responsible for re-encoding files ourselves? are we responsible for warning about certain kinds of files? when?” etc.  I think it’s a deceptively thorny design question, but I get the impulse.

-C

[micpool]

I think perhaps the  specific case of the performance hit with  large odd numbered  pixel dimensions is an outlier that perhaps does require an exception with regard to warnings, or at least a much clearer presence in the QLab 5 manual, which  far as I can see makes no mention of this problem.

The combination of the severe performance hit of the scaling process on large dimension frames which renders the playback effectively unusable, and the fact that smaller, yet still quite large,  pixel  dimensions seem completely  unaffected by having odd numbered dimensions is somewhat counterintuitive, particularly as the performance hit can occur when playing a single video file.

Presumably the scaling process is a double operation, because after decoding the video frame exists in QLab at its original odd numbered size which would suggest it is scaled back again after decode.

It also appears that after decoding the odd pixel dimension can also severely affect the rendering to stages when video fx are applied, again potentially dropping the frame rate to less than half.

A further aspect of this which I haven’t investigated is whether to squeeze every last drop of performance fron QLab when playing large numbers of high resolution video files, there is any advantage in making the video file,dimensions strict multiples of,the ProRes macroblock size of 16x16 pixels.

Mic

[Sam Kusnetz]

Mic

May I ask, what is process that you’re using that generates odd-sized videos to begin with? Doing some quick experimentation, I find…

• None of my cameras generate odd sizes
• Compressor won’t generate odd sizes
• Syphon Recorder won’t generate odd sizes
• macOS screen capture won’t generate odd sizes

I’m not doubting you! I’m just trying to figure out how common it truly is that folks end up with odd sized video.

Best

Sam

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com

--
Contact support anytime: sup...@figure53.com
User Group Code of Conduct: https://qlab.app/code-of-conduct/
 
Instagram: https://www.instagram.com/Figure53
TikTok: https://www.tiktok.com/@QLab.app
Bluesky: https://bsky.app/profile/qlab.app
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qlab/1cfa9f6f-64b7-4d1b-8988-20e989d18de0n%40googlegroups.com.

[Richard Williamson]

Generally we would look to render content which fits the final surface (be that a wall or a piece of set) - which rarely is a “standard” resolution, in the past i don’t think we;ve really thought about the need for even numbers of pixels, but it sounds like we should be. 

--

Richard Williamson
www.richard-williamson.com
ric...@richard-williamson.com
07957 457 362

To view this discussion visit https://groups.google.com/d/msgid/qlab/CAOOK5AasHsLDkKbADpaMQt6%3DnOqSW3PGP8i5RNANZweKuRnxiw%40mail.gmail.com.

[Sam Kusnetz]

On Feb 20, 2026 at 12:19:41 PM, Richard Williamson <ric...@theatre.support> wrote:

Generally we would look to render content which fits the final surface (be that a wall or a piece of set) - which rarely is a “standard” resolution, in the past i don’t think we;ve really thought about the need for even numbers of pixels, but it sounds like we should be. 

Thank you Richard.

I would like to gently push against the use of the word “we” here… for example, I am also a projection designer, and I do not create video in exactly this way. Many people have different workflows!

[Richard Williamson]

I meant we as in the people I work with - rather than every video designer in the world

--

Richard Williamson
www.richard-williamson.com
ric...@richard-williamson.com
07957 457 362

--
Contact support anytime: sup...@figure53.com
User Group Code of Conduct: https://qlab.app/code-of-conduct/
 
Instagram: https://www.instagram.com/Figure53
TikTok: https://www.tiktok.com/@QLab.app
Bluesky: https://bsky.app/profile/qlab.app
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qlab/CAOOK5Ab15FEajZ%3Dr0x41CZf9fxQfpUdwhwXGuBoURbKRykkaqQ%40mail.gmail.com.

[Sam Kusnetz]

On Feb 20, 2026 at 12:29:30 PM, Richard Williamson <ric...@theatre.support> wrote:

I meant we as in the people I work with - rather than every video designer in the world

Splendid. I of course had no way of knowing that, so I appreciate you clarifying!

[micpool]

Generally, I don't create videos (for shows)  with odd pixel dimensions because I started video design in the era of Sorenson and cinepak codecs, where everything had to be a multiple of 16!

However,

Our first correspondence on QLab 5 and odd numbered pixel dimensions was in February 2022, during the beta test phase of QLab 5, where I had stumbled across the fact that some Videos that played fine in QLab 4 would not play at all in QLab 5 and we narrowed it down to the odd number pixel problem. In this case the videos I found that had this problem were created using a fairly common method which many video content makers might sometimes employ, capturing a portion of a screen using the Macs built in screen recorder. When you define the portion of the screen to be recorded you are as likely to draw a box with an odd number of pixels as you are to draw one with an even pixel numbers. I am not sure why you think it will only allow even numbered selections.

More commonly, users will create videos that they have calculated the pixel dimensions of based on the physical dimensions of the surface they are going to project onto maximising the resolution by making either the horizontal or verftical dimension match a projector's resolution. e.g. a 9500mm x 2500mm  might be filled by a 1920 x 505 video frame or more likely by 2 projectors which depending on overlap might produce an odd horizontal pixel dimension if the height was matched to the 1200 pixel vertical resolution of a projector.

Creating a multi output  stage in QLab 5 using the multi output stage   might also suggest an odd numbered Horizontal pixel dimension for videos to be sent to that stage  e.g 2 projectors with a 24% overlap

  

I  imagine that one of these scenarios was responsible for the Facebook post which highlighted this problem again where James Lanius wrote:

I'm working on a show with a lot of 6k video (really 6663x2160). I've rendered it all in ProRes 422 Proxy, as per usual and it plays back great on my M3 Max, no problem. Not doing any effects or scaling in qlab. It's all baked into the renders.For some reason, on the client's show computer - which is an M2 Ultra - it really doesn't play back well at all. I'm seeing 1/2 frame rates pretty consistently.

Generally all my show content is finished in Adobe After Effects which will allow the production of video files of any dimensions.

I also think you and Chris are mistaken in your belief that Apple Compressor will not produce files with an odd number of pixels e.g.

and Final Cut and just about any other NLE will also allow projects with odd number pixels. e.g 

Best

Mic

[micpool]

On Friday, February 20, 2026 at 4:32:26 PM UTC s...@figure53.com wrote:

• Syphon Recorder won’t generate odd sizes

That's not completely true. Syphon recorder if set to h264 will crop the output to the next lowest even number. If you select Apple Prores as the output codec it will capture faithfully to any pixel numbers.

[Chris Ashworth]

Thanks for this Mic! (I was basing my comment about it on the discussion recorded in our original issue when resolving the original bug, but I haven’t tried to test it in Compressor recently.)

I’ve added all your notes to the issue tracker.

It’s certainly something we could document better, and I do see the reasoning behind trying to surface an advanced warning about it somehow.  

-C

On February 20, 2026 at 1:12:32 PM, micpool (m...@micpool.com) wrote:

I also think you and Chris are mistaken in your belief that Apple Compressor will not produce files with an odd number of pixels e.g. and Final Cut and just about any other NLE will also allow projects with odd number pixels. e.g 

[micpool]

On Friday, February 20, 2026 at 2:50:49 PM UTC s...@figure53.com wrote:

But I do feel, rather strongly, that whether or not [cropping by 1 pixel]  “seems a small price to pay” should be a decision that QLab does not make for you, and instead should be a decision you get to make for yourself.

That makes complete sense. So let me adjust my suggestion.

As QLab restores the original frame size of an odd pixel dimensioned  video file after the decode, would the alternative method to scaling provided by Apple to deal with odd pixel dimensions, i.e padding by one pixel (and presumably then removing the padding after decode) be faster, and avoid or reduce the performance hit?

Best

Mic

 

[micpool]

On Friday, February 20, 2026 at 4:26:32 PM UTC micpool wrote:

A further aspect of this which I haven’t investigated is whether to squeeze every last drop of performance fron QLab when playing large numbers of high resolution video files, there is any advantage in making the video file,dimensions strict multiples of,the ProRes macroblock size of 16x16 pixels.

I've now looked at this and have concluded that there is no advantage in making ProRes video files that have dimensions that are exact multiples of 16, e.g., 640, versus those that aren't, e.g 638. You can play a lot of files simultaneously of both dimensions and the results are practically identical. So the only important requirement seems to be ensuring that the dimensions are even numbers.

I did find some surprising results for odd-number dimensioned files, including much better performance  in ProRes 4444XQ than in ProRes 422  and a  dimensional cliff edge between playing at half frame rate and playing normally

On an M1 Max:

A single ProRes 4444XQ 6663x2160  plays normally

however

A ProRes 422 6663x2160  plays jerkily  at around half frame rate

There is little improvement with 

A ProRes 422 3663x2160  (again, plays jerkily  at around half frame rate)

However reduce  the horizontal pixels by 2 and you get

A ProRes 422 3661x2160  playing normally (as does any smaller horizontal dimension)

Screen recording attached

Mic

[Richard Williamson]

That makes sense - what I don’t understand is how Apple actually store the data for an odd sized file - if it’s 4:2:2 do they pad the bytes and then remove them? 

Sent from my iPhone

On 25 Feb 2026, at 01:24, micpool <m...@micpool.com> wrote:



--
Contact support anytime: sup...@figure53.com
User Group Code of Conduct: https://qlab.app/code-of-conduct/
 
Instagram: https://www.instagram.com/Figure53
TikTok: https://www.tiktok.com/@QLab.app
Bluesky: https://bsky.app/profile/qlab.app
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qlab/665db511-1541-4099-b23d-6d2ec96feb43n%40googlegroups.com.

<Screen Recording 2026-02-25 at 01.20.40-HD 1080p.mov>

[micpool]

The maths is a bit beyond me but..

Picture data "are divided into macroblocks and then further into blocks. Macroblocks are 16×16 arrays of pixels, and blocks are 8×8 arrays of video component samples. For 4:2:2 sampling, each macroblock thus consists of four Y′ (luma) blocks, two Cb blocks, and two Cr blocks; for 4:4:4 sampling, each consists of four Y′ blocks, four Cb blocks, and four Cr blocks. ... Finally, the macroblocks of a picture are grouped into slices. Each slice consists of 1, 2, 4, or 8 contiguous macroblocks all in the same macroblock row. ... Each slice can be encoded and decoded independently, which facilitates parallel encoding and decoding."