OpenShot
Vertical FHD profiles don't work correctly
Beschreiben Sie den Fehler When starting Open Shot and choosing any of the FHD vertical profiles, and then importing a FHD vertical mp4, Open Shot gets the resolution wrong and displays it as having a much smaller resolution.
Schritte zum Reproduzieren des Verhaltens
- Start Open Shot
- Choose any of the FHD vertical profiles
- Import a vertical FHD 1080p video file, put it on the timeline
- ...And the bug appears
- See below: the mp4 file is 1920x1080, the profile fhd vertical, but the resolution is displayed incorrectly in Open shot with big black margins. The Scaling option also doesn't help.
Systemdetails
- OpenShot Version: 3.3.0
- libopenshot Version: 0.4.0
- Platform: Windows-10-10.0.22621
- Processor: AMD64 Family 23 Model 160 Stepping 0, AuthenticAMD
- Machine: AMD64
- Python version: 3.8.9
- Qt5 version: 5.15.2
- PyQt5 version: 5.15.4
- Qt Detected Languages: ['de-DE', 'en-US']
- LANG Environment Variable:
- LOCALE Environment Variable:
- Daily Build: Not able to verify issue still exists in daily build
Logdateien
- openshot-qt.log (5 KB)
- libopenshot.log: Datei zu klein oder leer (nicht hochgeladen)
Ausnahme / Stapelverfolgung
No stacktrace found in log files
Bildschirmfotos (Optional) Wenn möglich, fügen Sie Screenshots zur unterstützenden Erklärung Ihres Problems hinzu. Sie können Screenshots einfügen, indem Sie diese kopieren und auf Github einfügen oder durch Drag and Drop zur GitHub-Seite hinzufügen. Alle Bilder sind öffentlich zugänglich, posten Sie deshalb keine Screenshots die persönliche Informationen enthalten.
Hello @gilando There is a fix for this in the latest dev daily build. Go to openshot.org/download/#daily and get the latest available.
Please note this is a daily build and currently there are 2 known bugs with the Tracker effect and the Object Detector effects. As long as you don't need thes 2 effects, then give this daily build a try and see if it resolves your issue.
@Colorjet3
Thank you. The problem still persists in the daily build but now there is a scaling option that solves it. However, the video is still initially shown in the wrong resolution and if you set no scaling option, it remains way too small, even worse than before.
Thank you @gilando for all the information you provided. I am assigning this to the lead developer for his review.
I also have this issue (Actually, it's always been there I thought), but on the latest build
I see the blue bounding box in the wrong place. This doesn't happen in the 3.3.0 release.
oaded modules from: /tmp/.mount_OpenShMfk1k6/usr/bin
INFO app: ------------------------------------------------
INFO app: Sat Jun 28 22:07:53 2025
INFO app: Starting new session
INFO app: ------------------------------------------------
INFO app: OpenShot (version 3.4.0)
INFO app: ------------------------------------------------
INFO app: openshot-qt version: 3.4.0
INFO app: libopenshot version: 0.5.0
INFO app: platform: Linux-6.14.0-22-generic-x86_64-with-glibc2.4
INFO app: processor: x86_64
INFO app: machine: x86_64
INFO app: python version: 3.8.10
INFO app: qt5 version: 5.12.8
INFO app: pyqt5 version: 5.14.1
INFO app: Frozen version info from build server:
{
"build_name": "OpenShot-v3.4.0-release-candidate-13951-22cd5633-0b018e34",
"date": "2025-06-18 02:53",
"libopenshot": {
"CI_COMMIT_REF_NAME": "release-20250612",
"CI_COMMIT_SHA": "22cd56331f2328edf522868db57cdfc7dd38f56e",
"CI_JOB_ID": "43456",
"CI_PIPELINE_ID": "13948",
"CI_PROJECT_NAME": "libopenshot",
"SO": "28",
"VERSION": "0.5.0"
},
"libopenshot-audio": {
"CI_COMMIT_REF_NAME": "release-20250612",
"CI_COMMIT_SHA": "0b018e347c7973e4253e29ec41394f3dfa87df4d",
"CI_JOB_ID": "43309",
"CI_PIPELINE_ID": "13911",
"CI_PROJECT_NAME": "libopenshot-audio",
"SO": "10",
"VERSION": "0.5.0"
},
"openshot-qt": {
"CI_COMMIT_REF_NAME": "release-20250612",
"CI_COMMIT_SHA": "29d7879a6e7d9b22362194884da113e885d87253",
"CI_JOB_ID": "43471",
"CI_PIPELINE_ID": "13951",
"CI_PROJECT_NAME": "openshot-qt",
"SO": null,
"VERSION": "3.4.0"
}
}
I'm also still confronting this same problem with (apparently most current on Windows) version 3.3.0. Furthermore, it's pretty weird that none of the Property > Scale options (Crop, Best Fit, Stretch, None) can match a vertical 1080p video to a 1080p profile (I have to enter a manual X&Y scaling factor of 0.56). I might suggest that could now be a top blocker for uptake of OpenShot, as this is likely the most common use-case for people nowadays.
Please give the latest v3.4.0-Release-Candidate-14734 a try. I am not having this issue any longer with vertical videos.
By the way, if you are still seeting the blue handles in the incorrect location then please share your video here so I can test with it. If the problem persists, I will need to share that with the lead developer as we need something that is reproduceable.
I'm using the latest version today OpenShot-v3.4.0-release-candidate-14746-0932af2c-0b018e34. This was filmed in vertical, and on import it says rotation 90 degrees. You can see the Scale values are wonky. I need to change them to 1.77 to make the video fit correctly.
Same thing happens when the original video is 1920 × 1080 and has 90 degree rotation.
In Linux, this might be just Gnome not looking at the rotation but it has width as the wider value.
ffprobe for the video component gives me
Stream #0:2[0x3](eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709, progressive), 3840x2160, 48154 kb/s, SAR 1:1 DAR 16:9, 29.92 fps, 30 tbr, 90k tbn (default)
Metadata:
creation_time : 2025-10-03T04:28:01.000000Z
handler_name : VideoHandle
vendor_id : [0][0][0][0]
Side data:
displaymatrix: rotation of -90.00 degrees
So it just seems the scale value isn't right.
Thank you so much for all the details. I just checked the queue and found a documented bug regarding the Tracker effect and vertical videos. This issue seems to be related to the bug reported in this post.
So, I added this issue to that same bug in the queue for the lead developer to look into. I think once this issue is resolved, it will most likely fix the Tracker effect issue as well.