System Details:
Issue Description and steps to reproduce:
I was editing 30 sec long video.
I added 'Fade out fast' and it works well on the preview, fade out takes a few last seconds.
But when I exported video (1080p 30fps) fade out starts to early and takes 5-6 last seconds.
Then I decided to try older version 1.4.3 from Ubuntu software center and fade out works correctly in both preview and exported video.
So this bug is exist in 2.2.0 but not in 1.4.3.
I have a similar problem, hence the comment here rather than a new bug report.
My system details:
Lenovo Ideapad 310 - i7 Quadcore, 12 GB RAM, 1TB HDD.
Ubunutu 16.04
Openshot 2.2
Firstly, the auto cross-fades that are inserted when overlapping video clips on the same track only apply to video, not audio, therefore I used the keyframes to fade the audio in and out on both clips at the transition. Transition length was 0.5 seconds.
My video consists of photos for the first 30 seconds, followed by a few minutes of vids. After editing all the photos with all sorts of cool zooming and panning (thanks to the really cool bezier curves), and applying the audio cross fades on the video clips and then exporting as mp4, each clip's audio fades out about 4 seconds before the transition to the next clip.
Now, I have selected clips and dragged them left or right at some stage while inserting and deleting photos in that 1st 30 second block. What I can't be sure of is that the net result of shifting those clips after applying the audio cross fades, is a -4 second shift and for whatever reason the renderer was using outdated keyframe locations to fade the audio. Further evidence is that the audio for the second clip starts abruptly, without fade-in, suggesting the entire cross-fade was shifted left by 4 seconds and the fade-in of the second clip was hidden behind the last 3 or 4 seconds of the first clip before the beginning of the second clip.
When using preview the audio fades correctly at the transition. Shifting clips left and right also brings the keyframes along correctly. Just wondering if it's possible that the original keyframe locations are stored and incorrectly referenced by the renderer when exporting.
Is this similar enough to the description of the OP or does it warrant a separate bug report?
I'm seeing this audio volume fade-out problem on
beta v2.2.0-41-g51b7333-49-608-x86_64 and
beta v2.2.0-42-g6aba801-49-609-x86_64
I'm making a mix of 20 short films one after the other, accompanied by some background music (three different MP3 music tracks one after the other).
Windows 8.1 64 bit.
I also have this issue. Installed openshot 2.3.4 on windows a few weeks ago. When I export to HDV720 24p, the audio is fine. When I export to HD 720p 29.97 fps, all my fast audio fadeouts start a few seconds too early. I could try it on my linux machine also to see if that helps, but don't think it's worth the effort.
FYI: The reason I have to export to 29.97 fps is that all the footage from my camera is 29.97fps & I'm migrating the rest of my project to Blender & want all my input footage to have the same frame rate. The reason I'm migrating to Blender is that openshot is so crashy on the 3 minutes I've edited so far that I don't want to deal with it for the entire 100 minutes of my project.
Same problem here using OpenShot 2.3.4 on Ubuntu 16.04.
Similar issue with 2.3.4 - duration of fast fade in and fast fade out varies based on project frame rate. Changing project frame rate will mess up fades so that they need to be removed and readded.
Similar issue (V2.4.0 Ubuntu 17.04) fadeout (either image or sound) in the preview works well but on the generated video the effect take several seconds more. This issue take me all day trying to fix it with no luck. It depens of the selected video profile, in my case I have the same issue with 720 or 640.
Same issue here (V2.4.0 - Linux Mint 17.3). Using volume fade out at end of track. In the preview it works as expected, but after exporting the audio fade out happens several seconds before. Tried with different videos and various export settings, always the same result. Hope it gets fixed soon as it's an awesome piece of software (apart from this bug).
@ttarakanoff - Is this issue present in v2.4.1?
@DylanC - I can't test it now, sorry.
@DylanC I believe this bug is likely the same one that is causing the issues reported in at least https://github.com/OpenShot/openshot-qt/issues/1041 , https://github.com/OpenShot/openshot-qt/issues/1034 and https://github.com/OpenShot/openshot-qt/issues/640
@N3WWN - Thanks
I ran into the issue @crowdpublishtv mentioned above - one of my clips 1 second fades happened 10 seconds early on the end of the first clip. The 1 second fade in on the second clip happened at the beginning of the video as indicated in the project. This project is 640x480 VGA NTSC, OpenShot version is v2.4.1 (Windows 10 x64), clips are x264 codec in a M4V with MP3 as audio...
the same error
I use Ubuntu 16.04.3 and other so-based distros. And OpenShot v2.4.1 handles fades pretty well...
I have the same issue (or almost... unlike what's mentioned here, the "length" of the fadeout is correct, but it starts much too early). The "fade out" starts about 1/5th of the videoclip earlier than it should in export (both "fast" and "slow" fadeouts have the same issue).
So, for a 33-second long videoclip, it starts about 8 seconds before the end. For 4:08-long videoclip, it starts about 52 seconds before the end. I'm using the latest dev version (Apr.14, 2018) in Windows 7 64-bit.
This is a problem both for audio and for video fadeouts, together or separately. E.g. if I use only visual "fade-out" at the end of a clip, the last 5th of the video will be black in export, but the audio will keep playing.
Is this pretty much a known issue, or would uploading my log files or the videoclip I used help? The smallest videoclip is 13mb, not too big.
I can work around the visual fadeout bug by putting a black GIF image in the layer above, and having that fade in/out. However, there's nothing I can do about the audio - so it seems that audio fadeouts are no longer possible unless I edit the audio separately in Audacity for each videoclip...
@Esn024 Are you exporting the video at the same frame rate as set in the project? Or perhaps changing the frame rate of the project after adding the fades?
Unless the fades are added when the project is set at the same frame rate as it will be exported at, the fades will not occur where you think they will.
This is a known issue, but will need a lot of internal work to resolve as the manner in which keyframes are stored likely needs to be overhauled.
Well, the source files are 30fps, and I'm exporting at 29.97fps. Is that REALLY the cause of the difference? 0.03fps? One thing I did notice is that the default export FPS is always set at 24fps, so I have to change it before I export. That sounds more like the right number to account for what's going on. Maybe that's the real cause? Maybe the fades are automatically set at 24fps in the timeline, no matter what fps is later used for the final video export? Maybe that will be an easy fix? (add an option to change the default export setting?)
EDIT: AAaaahhh!... I just realized that this was already an option! [speculation here: Ok, I'm pretty sure this is exactly what caused the problem. I wish it was mentioned somewhere that this is extremely important! Maybe it should be mentioned in a little pop-up box when the user is exporting, or importing his first video file in the project ("make sure your default project export setting is the same fps as your final export setting & what your videos use, or all of the effects will look wrong!")]
Ok... it seems that
Edit>Preferences>Profiles> changing the default profile
doesn't actually change the default profile in
File>Export Video
(it's still set to "HDV 720 24p (1280x720)" by default)
What then is the purpose of having that menu option?
Ok, interesting... it seems that the default only changes if I reboot my computer. This has also fixed the issue with the fadeouts - they now appear exactly where they should in the export.
It seems then, that the solution to this "bug" is to change the default profile to a setting with the same fps (frames per second) as your final video, and then reboot your computer. Just closing & reopening Openshot isn't enough.
I suggest adding a warning message right before export if OpenShot detects that the default profile is not set to the same fps as the video that's about to be exported. It should warn that all of the effects are about to be mistimed, and the user should change the default profile and then reboot their computer before attempting export.
I am really really annoyed by this bug. It took me a week to edit 14 minutes which I had cut in less than 1 hour. I am trying workarounds in this thread but I was not rebooting my PC between them.
@Esn024 commented:
Ok... it seems that
Edit>Preferences>Profiles> changing the default profile
doesn't actually change the default profile in
File>Export Video
(it's still set to "HDV 720 24p (1280x720)" by default)What then is the purpose of having that menu option?
The default profile in the Preferences is the default profile for new projects, not existing ones.
If you change your default profile, create a new project and export that new project, the main window title and the Export Video dialog will appear to be using your new default profile, but, in fact, they're actually displaying the profile that is set in the project.
Existing projects do not use a default profile, they use the profile that is stored within the project.
You can test this by setting your default profile to whatever you'd like, create a new project, save the project and then change the default profile again. The main window title will not reflect any change in profile, nor will the Export Video dialog. That is because the profile for the existing project has already been applied to the project.
The Export Video dialog uses the project profile, which is the profile displayed in the main window title.
If you wish to change profiles after you have started a project, the best thing (at this time) is to select another profile with the same frame rate.
For instance, if your current project is using a 30 FPS profile, you could change your profile from/to HD 1080p 30 fps, HD 720p 30 fps, 2.5K QHD 1440p 30 fps or 4K UHD 2160p 30 fps without your keyframes being altered.
Likewise for 24 FPS profiles, you can freely change between the HD 1080p 24 fps, HD 720p 24 fps, HDV 720 24p, 2.5K QHD 1440p 24 fps and 4K UHD 2160p 24 fps profiles.
I hope this helps to clear up the confusion.
The problem is also if the video you are importing (cutting) is 60 FPS, while your project is 30 FPS the fades do not work. Then I switched the profile to 60 FPS (restarted the whole PC, because it did not work otherwise), redid the fades, and then exported to 60FPS.
This means that I need to convert all videos to same framerate before importing them to the project. It also means I cannot export to any framerate, which means menu should have grayed out profiles when doing it (to improve user experience). This might be the easiest fix (to gray out profiles you are not able to use with current project configuration), with message when you hover over the grayed out profiles telling you to read either this thread or copy paste above explanation into the docs.
@Letme wrote:
The problem is also if the video you are importing (cutting) is 60 FPS, while your project is 30 FPS the fades do not work. Then I switched the profile to 60 FPS (restarted the whole PC, because it did not work otherwise), redid the fades, and then exported to 60FPS.
I'm trying to understand the exact order of operations performed.
From the text that I quoted, it sounds like you were doing this:
Is that correct?
If so, I would expect this to fail due to exporting the project to video at a different frame rate than used within the project.
It then sounds like you did the following, which should work just fine because you're not changing the frame rate of the exported video:
The following should work just fine, also:
The key difference here are:
If any of what I am stating is NOT actually working for you, please let us know and provide steps for us to exactly duplicate the bug.
But, what I stated as working should work perfectly as I work on projects almost every week which contain clips of varying frame rate (still images, 24, 30, 60 and 100 FPS) and resolution (various still image sizes, 720p, 1080i, 1080p) which contain fades, transitions, etc and are exported at either 30 or 60 FPS, depending on the target device for the video.
The 2nd and 3rd example do not work unless you restart whole computer (not just OpenShot) after changing the profile. And 3rd (importing 60FPS clip to 30FPS profile and then exporting to 30FPS) did not work for me (as that is what I started with). It is also true I did not really do it systematically, since I did not know there is any problem.
From instinct I imported the 60FPS video to 30FPS default profile. I was cutting and making a slow-mo all in Track0, when it was all done I added fades. At export of 30FPS the screen went black after couple of seconds and stayed that way until after the slow-mo. I thought fades were problem so I removed them. Then I thought all on Track0 is a problem, so I moved cut clips to different tracks. Without Fades it worked (slow-mo was still image or black though), with fades again it went to black screen after couple of seconds. Once I removed slow-mo it all started to improve. In between I googled a bit and found this issue where I tried workarounds. Only after whole reboot it started to work. Let me also add that OpenShot crashed while exporting video on couple of occasions, unless I rebooted the PC and ran only OpenShot and export video (then it always works). So having a computer working for some time and trying to export video, it fails on random timeframe, leaving you with partial video and closed OpenShot - without any information (I must admit I did not check dmesg and other logs). Anyway I think I can replicate (saved project somewhere in the middle) and add some logs.
@Letme ,
I'm very surprised that you have to restart the computer for a change in profile to take effect. Can you tell us a little more about your system, also?
At minimum, we need this info from you:
System Details:
If you can attach the logs, that'll be very helpful, too! 馃槂
For the 3 scenarios that I detailed, I've been using the daily builds (as they are released) of OpenShot 2.4.1 on Fedora Linux and never have to restart OpenShot, let alone restart the entire OS.
Thanks!
@N3WWN
Please note that I pointed out exactly the same issue in an earlier post in this topic:
https://github.com/OpenShot/openshot-qt/issues/519#issuecomment-383276477
Operating System / Distro: Windows 7 Professional SP1 64-bit
OpenShot Version: 2.4.1-dev1 (launch.exe is dated April 14, 2018)
I also wish to once more bring attention to my suggestion to reduce frustration for ordinary users until a more permanent fix is made (this may be a really critical and frustrating bug for many people): _I wish it was mentioned somewhere that this is extremely important! Maybe it should be mentioned in a little pop-up box when the user is exporting, or importing his first video file in the project ("Make sure your default project export setting uses the same frames-per-second (FPS) as your final export setting & what your videos use, or all of the effects will be mistimed! And please restart your computer after changing the project export setting, because on some machines it won't take effect otherwise.")_
@N3WWN I was also surprised about that, especially since it is on Linux (I would expect it from Windows). I upgraded the PC to Ubuntu 18.04 few days ago, but I can check if it is still a problem (and attach a project file for that - in case it is useful).
System Details:
Something to keep in mind: GPU on PC is very poor, yet CPU is decent Intel-i5 7th generation
I have this issue also, here is a little PHP script that will convert all the keyframes from 30fps positions to 60fps positions.
<?PHP
$input = 'input.osp';
$output = 'output.osp';
$oldFPS = 30;
$newFPS = 60;
function search(&$sub)
{
global $oldFPS, $newFPS;
foreach($sub as $k => &$v)
{
if ($k === "co")
{
$v['X'] = ($v['X'] / $oldFPS) * $newFPS;
continue;
}
if (is_array($v))
search($v);
}
}
$project = json_decode(file_get_contents($input), true);
search($project);
file_put_contents($output, json_encode($project));
?>
I am very disappointed with this bug. I created a project with 60fps profile, then exported video at 30fps. Then I had spent 3 hours trying to figure out why audio fading is lost in exported video.
Ubuntu Studio 19.04, OpenShot 2.4.3 - This is definitely a problem, and it is not intuitive or explained to the user (in the user interface). Wasted many hours exporting to different profiles. Will see tonight whether any of these suggestions work for me... Never thought the profile decision I made at the very first step (default profile setting) would affect me so much when it asks/offers profiles at the export step!
That said, any word on whether OpenShot 2.4.4 has fixed/dealt with this issue?
EDIT: Just noticed the release notes for OpenShot 2.4.4 - It looks like it should be fixed! Will test soon...
Just thought I'd confirm for posterity - 2.4.4 works perfectly (for this issue).
My project (created in 2.4.3 with incorrect "default" profile of 60fps), which had mixed stills and video of mixed framerates, and various keyframes and 'animations' was able to be exported in both 60fps and 30fps with minimal modification, namely two still images were removed from their tracks during the conversion process, and just needed to be re-inserted - no hassle at all.
Great work!
Closing as fixed by... some commit, I can't even find it now.