What is the correct way to rotate video on a vega based firestick?

i am working on an app. i am trying to take a landscape video 1920x1080 and rotate it 90 degrees while playing (obviously this video would be scaled down so its now 1080 wide by 540 high. I tried using a video tag in html loaded by the webview as well as a native call but it does not appear to be supported. is there any way to accomplish this on a firestick running Vega ?

Hi @james_bratsanos,

Welcome to Amazon Developer Community!!

Thanks for reaching out. Could you share a bit more detail so we can better assist:

  1. When you tried the WebView approach with a tag and CSS transform: rotate(90deg), what was the result - did the video play but not rotate, or did it not play at all?
  2. What do you mean by “a native call” - were you using KeplerVideoSurfaceView with React Native transforms on the container?
  3. What Vega SDK version are you using?

In the meantime, one reliable workaround is to pre-process the video to the desired orientation before playback (e.g., using ffmpeg: ffmpeg -i input.mp4 -vf “transpose=1” output.mp4). This avoids any runtime rotation and is the most compatible approach.

We’ll investigate further once we have more details on what you’ve tried.

Helpful resources:

Warm Regards,
Aishwarya

hi,

in regards to your questions:

  1. it played, it just wasn’t rotated

here is more info

Goal
Display a portrait-oriented slide on a landscape TV that’s physically mounted vertically. Slide background (text/images) is rotated correctly via CSS transform: rotate(90deg) inside a WebView. We need to render a video alongside slide content that’s rotated 90° to match.
What we tried (4 paths, all failed to rotate video pixels)

  1. Native KeplerVideoSurfaceView with React Native transform: [{rotate: ‘90deg’}] on a parent
    <View style={{position: ‘absolute’, left, top, width, height,
    transform: [{rotate: ‘90deg’}]}}>
    <KeplerVideoSurfaceView
    style={{width: ‘100%’, height: ‘100%’}}
    scalingmode=“fit”
    onSurfaceViewCreated={handle => videoPlayer.setSurfaceHandle(handle)}
    />

Observed: The parent rotates correctly (verified with a colored border on the wrapper — border renders rotated). The video’s hardware surface ignores the parent transform and renders unrotated in its layout box.
2. HTML5 with CSS transform: rotate(90deg) directly on the video element (inside Vega @amazon-devices/webview)

Observed: The video element’s bounding box rotates (verified with getBoundingClientRect() returning portrait dimensions and getComputedStyle().transform showing the rotation matrix). The video texture / decoded frames render in their original landscape orientation, ignoring the CSS transform.
3. HTML5 inheriting parent slide div’s CSS rotation (the production pattern)

Observed: The parent slide div rotates correctly (red border on the parent covers the full 1920×1080 landscape canvas after rotation). The child 's bounding box rotates with the parent (verified via getBoundingClientRect()). The video texture again ignores the rotation and renders frames in landscape.

  1. Canvas drawImage(video, …) inside the rotated parent slide div

So the box geometry is fully correct — but the video frames inside that portrait container render in landscape orientation, unrotated, suggesting the hardware video plane is composited independently of the DOM/View transform stack.

Vega SDK: 0.22.6759 (active)
Vega CLI: 1.2.22
Device: Fire TV Stick 4K Select (1920×1080 landscape physical)
NPM packages:
@amazon-devices/react-native-kepler 2.0.1758683737 (+rn0.72.0)
@amazon-devices/react-native-w3cmedia 2.2.20
@amazon-devices/webview 3.3.1769932800
@amazon-devices/expo-file-system 2.0.1758683737
@amazon-devices/kepler-file-system 0.0.4

Hi @james_bratsanos,

Thank you for the detailed write-up on the video rotation issue.

As discussed, runtime video rotation via transforms is not currently supported — the hardware video plane composites independently of the CSS/React Native transform stack.

We recommended pre-processing the video before playback (e.g., ffmpeg -i input.mp4 -vf "transpose=1" output.mp4).

We wanted to check in:

  1. Are you still facing this issue, or does the pre-processing workaround meet your needs?

  2. If the issue persists or the workaround isn’t viable for your use case, could you share more details — any errors, logs, or specifics about why pre-processing won’t work? This will help us investigate further and prioritize a platform-level solution.

Looking forward to hearing from you.

Warm Regards,
Aishwarya