Different players can interpret the presentation differently
A phone recording can contain display-transform information that tells a player how to present its stored picture. If one application honours that information and another workflow handles it differently, the visible orientation can change without the viewer deliberately rotating the clip. A sideways output deserves a rotation-handling check before an aspect-ratio or screen-orientation correction is applied everywhere.
Preserve the original recording and compare it with the actual exported file. Do not use the editor's preview alone as evidence of the saved result. Record which file each application opened and whether the export involved streamcopy or transcoding. Those operations can handle rotation information differently, so the processing path is part of the explanation.
A hypothetical double correction
Imagine a portrait recording that appears upright in the phone's gallery. A creator adds a manual ninety-degree rotation in an export workflow that already applies the source's display rotation. The output may now be wrong in the opposite direction. This hypothetical case shows why guessing a rotation from a thumbnail is weaker than checking the source transform and the tool's automatic behaviour.
FFmpeg documents automatic rotation based on file metadata, enabled by default, and separate display-rotation controls. Its documentation distinguishes rotation during transcoding from metadata handling when streams are copied. These are tool behaviours to check for the installed version, not a reason to paste arbitrary rotation commands into a private source workflow.
Choose one intentional representation
Decide what the delivery requires: correctly transformed picture pixels, appropriate display metadata, or both in the format expected by the destination. A target that ignores an orientation transform may need an export whose pixels already have the intended presentation. That can require re-encoding rather than simply rewriting a filename. Use the destination's documentation and a short authorised sample.
Do not solve a rotation problem by stretching the picture into a different aspect ratio. Turning the image and changing its proportions are different operations. Check that faces, circles and text retain their shape after correction. Also check any captions or graphics added by the editor; a video layer can be upright while an overlay has been rotated or positioned incorrectly.
Verify outside the editor
Open the completed output through the same route the audience will use. Compare the first scene and a later scene containing an obvious orientation cue, such as readable text. Confirm the intended width and height, caption placement and audio. A gallery thumbnail can be cached or generated through a different decoder path, so it is not the entire acceptance test.
Keep the working export settings with the project and retain the unmodified source. A clear note says which transform was applied and where the result was tested. It should not claim that every television or browser will honour the same metadata. The practical result is an upright, proportionate deliverable for the specified destination, without a hidden second rotation waiting in another stage.
Questions answered
Does an upright editor preview prove the exported file is upright?
No. Test the saved output through the audience's intended playback route and check the workflow's rotation handling.
Should I stretch the image to fix sideways playback?
No. Rotation and aspect ratio are separate. Correct the orientation while preserving the intended proportions.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.