Image gets stretched when changing from 4:3 --> 16:9 aspect ratio

Setup

• Leipzig SDK v1.4.1 (Programming Guide rev 1.05), KL730-based platform
• VMF_VSRC_APP_MODE_NORMAL, single sensor, native resolution 2592×1944 (4:3)
• One VMF_VSRC + one VMF_BIND, multiple VMF_VENC instances bound to it at different resolutions (per section 5.3 of the Programming Guide)
• Trying to switch one stream's output between a 4:3 encode and a 16:9 encode (e.g. 1920×1080) at runtime via VMF_VENC_Config

Goal

When switching from 4:3 to 16:9, we want the horizontal field of view to stay exactly the same — i.e. crop rows off the top/bottom of the 4:3 sensor image to get a 16:9 slice, then deliver that at the target encode resolution. We do not want the image squeezed/stretched.

What we tried

1. Just changing dwEncWidth/dwEncHeight to 1920×1080 with bEnableCropping = 0: the full 4:3 frame gets non-uniformly scaled into 16:9 → horizontal stretch. (Figure 1 = correct 4:3 reference, Figure 2 = the stretch)
2. Enabling bEnableCropping = 1 with dwCropStartX = 0, dwCropStartY = 243, and setting dwEncWidth/dwEncHeight directly to the crop rectangle size (2592×1458, the 16:9-equivalent height for the full sensor width): this crops the right rows, but the result comes back letterboxed inside a canvas still shaped like the original 4:3 frame (black bars top/bottom) rather than filling a clean 1920×1080 16:9 frame — see Figure 3.

Where we're stuck

Table 7-1 in the Programming Guide separately documents dwRequestWidth/dwRequestHeight ("Request image width/height from VSRC") from dwEncWidth/dwEncHeight ("Encoding image width/height"), which suggests the former should define the crop source rectangle and the latter the final scaled output — but there's no worked example showing both used together for a crop-then-resize, and no detail on how they interact once bEnableCropping = 1. We also note bKeepRatio is documented as "valid only on resized stream" (video_encoder.h) — does that imply this crop+independent-resolution flow only works correctly for a VENC stream that VMF_BIND treats as a "resized" branch, and not for whatever VMF_BIND considers the "primary" stream (i.e. does stream ordering/binding affect whether this works at all)?

Question

1. Is the correct pattern: set dwRequestWidth/dwRequestHeight = crop rectangle size (e.g. 2592×1458), dwCropStartX/dwCropStartY = crop offset, and leave dwEncWidth/dwEncHeight = final target resolution (e.g. 1920×1080) — with the encoder internally scaling the cropped region to the encode size?
2. Does this behave differently depending on whether the VENC stream is bound as VMF_BIND's "primary" stream vs a "resized" stream?
3. Any constraints on dwCropStartY alignment beyond the documented 2-pixel alignment that would affect a crop offset like 243 → 242/244?