There is one more part to patching this correctly that must be taken
into account. When setting the speed to a fractional amount to slow the
clip down (ie. 1/2, 1/3, etc), you will notice that the clip length is
not properly adjusted on the timeline even after making the suggested
changes above. To fix this I also had to modify the following around
line 892:
if speed_multiplier < original_speed:
# clip is longer now (keep the short version)
- clip_object.end_time = clip_object.start_time + original_length
+ clip_object.end_time = new_end_time
Why would you want to "keep the short version"? We are changing the
speed of the clip so setting the end_time back to what it originally was
seems to be a bad idea. Regardless, with this modification, the
automatic resizing of a clip due to slowing the speed down now works
correctly.
--
You received this bug notification because you are a member of UBUNTU -
AL - BR, which is subscribed to OpenShot Video Editor.
https://bugs.launchpad.net/bugs/1198555
Title:
In time in clip properties is not set correct
Status in OpenShot Video Editor:
New
Bug description:
Openshot 1.4.3 on Linux Sabayon.
Under the "length"-tab in clip properties there is a textbox with start time
for the clip, this time is always 0 (or actually -0.01).
The reason for this is that when clip properties dialog is loaded the
txtIn-textbox is set before txtOut-textbox which lead to that local_out is 0.0
in on_txtIn_value_changed(). The logic:
if local_in >= local_out:
local_in = local_out - 0.01
self.txtIn.set_text(str(local_in))
will then set textbox text to -0.01.
One solution to this is to switch the order for setting txtOut and
txtIn, that is set txtOut before txtIn (in
frmClipProperties::__init__()).
To manage notifications about this bug go to:
https://bugs.launchpad.net/openshot/+bug/1198555/+subscriptions
--
Mailing list: https://launchpad.net/~linux-traipu
Post to : linux-traipu@lists.launchpad.net
Unsubscribe : https://launchpad.net/~linux-traipu
More help : https://help.launchpad.net/ListHelp
