> For the complete documentation index, see [llms.txt](https://docs.ndi.video/all/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ndi.video/all/using-ndi/using-ndi-with-hardware/configuration-for-speedhq-encoder-portrait-video-mode.md).

# Configuration for SpeedHQ Encoder (Portrait Video Mode)

When encoding portrait-format video through the SpeedHQ hardware encoder, using a frame resolution of 1080 × 1920 can result in a blank image, corrupted video, or an incorrectly stretched output. This issue occurs because the hardware encoder requires the frame width to be aligned to a multiple of 16. To encode a 1080-pixel-wide portrait image correctly, the capture buffer must use a padded width of 1088 pixels.

This article applies to:

* SpeedHQ hardware encoding
* FPGA-based encoding pipelines
* Portrait-format video
* UYVY 4:2:2 capture buffers
* NDI receivers such as NDI Studio Monitor

***

An incorrectly configured portrait-video stream may produce one or more of the following symptoms:

* Blank or black video
* A stream that cannot be decoded
* Corrupted bitstream errors
* Distorted or stretched video
* Inconsistent results between the capture and decoding applications

The SpeedHQ hardware encoder requires the frame width to be a multiple of 16. A width of 1080 pixels does not meet the requirement, 1080 ÷ 16 = 67.5 Internally, the encoder aligns the width using the following operation:

```
width & ~0x0F
```

For a width of 1080, this operation rounds the value down to 1072. However, neither forcing the value back to 1080 nor treating 1072 as the intended frame width provides a correct solution. 1080 is not properly aligned for the encoder. 1072 removes eight columns from the intended image. Forcing an unaligned width can cause the FPGA to generate an invalid or corrupted bitstream. Downstream receivers, including NDI Studio Monitor, may then be unable to decode the stream.

The solution is to configure the capture pipeline to use a frame width of 1088 pixels which is the next valid width above 1080 that is divisible by both 16 and 64. The frame height can remain at 1920 pixels. Check the following capture settings:

| Parameter            | Required value |
| -------------------- | -------------- |
| Frame width          | 1088 pixels    |
| Frame height         | 1920 pixels    |
| Pixel format         | UYVY 4:2:2     |
| Frame stride         | 2176 bytes     |
| Picture aspect ratio | 0              |

Stride calculation - 1088 pixels × 2 bytes per pixel = 2176 bytes

### Update the capture-side configuration

{% stepper %}
{% step %}

#### Round the frame width up to 1088

Configure the captured or allocated frame buffer as 1088 × 1920 rather than 1080 × 1920. Do not force the hardware encoder to accept a width of 1080.
{% endstep %}

{% step %}

#### Set the stride to 2176 bytes

UYVY 4:2:2 video uses two bytes per pixel. For a frame width of 1088 pixels, the correct stride is 1088 × 2 = 2176 bytes. The configured stride must match the effective frame-buffer width. A mismatch between the width and stride is a common cause of blank, shifted, or corrupted video.
{% endstep %}

{% step %}

#### Pad the additional eight columns

The original image remains 1080 pixels wide, leaving eight additional columns in the 1088-pixel capture buffer.

Fill these additional columns using one of the following methods:

* Black pixels
* A copy of the final edge pixels from the active image

Do not leave the padding area uninitialized, because this may introduce visible artifacts or unpredictable image data.
{% endstep %}

{% step %}

#### Allow NDI to derive the aspect ratio

For portrait-oriented video, set:

```
picture_aspect_ratio = 0
```

This allows NDI to derive the aspect ratio from the frame resolution. If the aspect ratio remains hardcoded to 16:9, the decoded portrait image may appear stretched or distorted.
{% endstep %}
{% endstepper %}

No changes are required in video\_compress.cpp. All required updates should be made on the capture side of the pipeline.

Configure the capture buffer for a width of 1088 pixels and a height of 1920 pixels. For UYVY 4:2:2 video, set the stride to 2176 bytes and pad the additional eight columns with valid image data, such as black pixels or replicated edge pixels. Also set picture\_aspect\_ratio to 0 so NDI derives the correct aspect ratio from the frame resolution.

After applying these changes, verify that the stream displays correctly in NDI Studio Monitor without blank video, decoding errors, or visible stretching. The encoder should receive the aligned width of 1088 pixels rather than a forced width of 1080.Code changes

No changes are required in `video_compress.cpp`. All required updates should be made on the capture side of the pipeline.

Configure the capture buffer for a width of 1088 pixels and a height of 1920 pixels. For UYVY 4:2:2 video, set the stride to 2176 bytes and pad the additional eight columns with valid image data, such as black pixels or replicated edge pixels. Also set `picture_aspect_ratio` to `0` so NDI derives the correct aspect ratio from the frame resolution.

After applying these changes, verify that the stream displays correctly in NDI Studio Monitor without blank video, decoding errors, or visible stretching. The encoder should receive the aligned width of 1088 pixels rather than a forced width of 1080.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ndi.video/all/using-ndi/using-ndi-with-hardware/configuration-for-speedhq-encoder-portrait-video-mode.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
