Fade in/out glitches

Bug #520941 reported by Mike Ashelby
264
This bug affects 50 people
Affects Status Importance Assigned to Milestone
OpenShot Video Editor
Fix Released
Critical
Unassigned

Bug Description

Hi,

I don't know if anyone else has experienced this, but now and again (not all the time) my fades in and out glitch at the outer end: before a fade in, the image or video appears momentarily (probably just for one frame) then disappears, and the fade starts normally. Similarly at the end, with the final frame flashing up full brightness.

It also seems to some extent to happen on audio - it's like OpenShot realises a moment too late that it's not meant to be playing the audio, or that a fade is meant to be happening.

Sometimes it doesn't happen, and sometimes it fixes itself... unfortunately not on a 'quick' project I've been doing this morning!

Anyway. It's absolutely great work - I'm so impressed! Something as good as this, and non-linear (I can't understand what you can even do with linear editing!) is a joy to have!

Ubuntu 8.04
DEB 1.0.0

Again - great application. I've already done some stuff I'm really pleased with!

Cheers,

Mike

Revision history for this message
Paul Mirowsky (p-mirowsky-verizon) wrote :

Same error occurring here.
Linux 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:02:26 UTC 2010 x86_64 GNU/Linux

Using multiframed jpg images.
Just before fade-in effect (set at default) image flashes at 100%, then does fade-in.

Result is in playback and final output.

Original of start frame is off by millisecond from fade-in
causing two effects. Maybe check math for matching decimal place results or inline programming
does not allow superseding of original start with new fade-in start.
Playback is probably accurate.

Revision history for this message
Richard de Vries (richarddevries) wrote :

Same here.

Ubuntu 10.04, Linux 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:05:27 UTC 2010 x86_64 GNU/Linux
openshot: 1.2.2-lucid1

The 'flash' seems to occur BEFORE the fade-in and AFTER the fade-out and it's not consistent as in that doesn't happen on every fade I apply.

Revision history for this message
Paulo Brito (paulorsbrito) wrote :

Same here, using svg images. Openshot 1.1.3.

Ubuntu 9.04, Linux 2.6.28-19-generic #65-Ubuntu SMP Thu Sep 16 14:14:28 UTC 2010 i686 GNU/Linux

Revision history for this message
ne (office-sico) wrote :

In my project it seems to appear seldom at start and does it almost everytime later.

Revision history for this message
ne (office-sico) wrote :

WORKAROUND:
After identifying the clips in which the bug appears, just add another timeline/track and move these clips to the new track.
I found out, that if one clip glitches almost all others on the same track does it also.

The bug probably appears mostly on full-packed tracks.

After sorting and moving some clips I got my project bug-free. It runs on 7 tracks now (had 4 at first).
But I am happy not to loose all the work.

Revision history for this message
Andy Finch (fincha) wrote :

Haven't been able to reproduce this. If anyone still suffers this problem, maybe you can attach the file sequence.mlt from the hidden folder ~/.openshot, from when the problem exhibits itself (preferably on a simple project).

Revision history for this message
ne (office-sico) wrote :

I do not have a bugged project anymore. (Sure, what for?)
So I tried to make a new project, because the bug appeared in every project up to now.
After some tries I can tell you, that the bug will not show up in simple projects.
If you have the bug and remove all other clips but the bugged ones, the bug also
disappears. ;-(

Conclusion: The bug only comes up if the project reaches some complexity.
So take some clips, cut them into pieces of some seconds, choose fade in/out in all of them
and try to arrange them in 2-3 tracks. To be sure, add sound - also with cut soundclips.
I guess that with 25 or more "clip pieces" in a 5-10 minutes project the bug appears for sure
in one or more fading sequences.

I hope you can reproduce it with this infos.

I can send you the sequence.mlt but it will take some time, perhaps another user will be faster.

Revision history for this message
Hans Petter Birkeland (hanspb) wrote :

This seems to be the same as I reported in November last year, bug #680688.

Revision history for this message
Santiago Romero (sromero) wrote :

 I'm affected by the same bug. Ubuntu 10.10 x86_64.

 I've started a simple project (2 tracks, some videos and still images with no transitions and effects, just fadein / fadeout), and after starting the fadein, the image appears for 0.1/0.2 seconds and then the fade starts, breaking the effect.

 I've tested the workaround (creating a new track and moving the affected clips to it) and it works, but you could end with lots of tracks and that's not usable.

 Is this bug corrected in the development ppa branch?

 Thanks

Revision history for this message
Jürgen Schroll (jschroll) wrote :

Same here

Ubuntu Natty 32 Bit and 64 Bit

Revision history for this message
Jürgen Schroll (jschroll) wrote :

Now more details.
Excuse my english, I'm german.

I made a little movie with ogg, svg, jpg, png and avi files. If a picture or movie fade out, the last frame flashes to 100%. Thats only comes, if I change from a lower track to a upper track. I can see it exactly, if I make frame-to-frame-steps with the arrow-keys.

Revision history for this message
anders musikka (anders-musikka) wrote :

Jürgen: Maybe you have the same problem I had? To determine if this is the case, you could try and change the "length" of the clips, so that you don't use the very end of any of the raw clips.

For instance, you could take the resize-clip tool and resize all the .avi- and .ogg-clips, so that they are 0.25 seconds shorter than they were.

This fixes the problem for me. The reason is that the underlying problem in my case was that transitions (fade-ins, fade-outs, mixings, etc) were being timed correctly, but since the clip lengths weren't rendered correctly, the clip no longer matched the transition, leading to the kind of glitches described in this bug report.

Not using the ends of the clip is actually a rather viable work-around. But maybe you have a different problem.

Revision history for this message
Jürgen Schroll (jschroll) wrote :

Yes it seems to be a different problem. Resizing don't work. The last frame appears again.
 If I make the fade-outs extremly long, the last frame don't appear, but I fade from the picture/movie in the black background to the upper track.

Revision history for this message
Olivier Girard (eolinwen) wrote :

Have you try to use the last version which is out since one or two days ago. This is a maintenance version which resolve more 17 bugs. It can helps you to resolve your problems with perhaps.

Revision history for this message
anders musikka (anders-musikka) wrote : Re: [Openshot.developers] [Bug 520941] Re: Fade in/out glitches

Ah,

but you may have misunderstood me. You need to resize all clips
*before* the one for which fade-out doesn't work! The point is that no
clip on the timeline before the one with the problem, may use the last
few frames of their respective clips!

But then again, you may be seeing a completely different problem, of course

Revision history for this message
zerbob (zerbugug) wrote :

Same bug reported as #680688, #590019, #769512 (by me) (I marked them all as duplicates).
The first frame of a clip shows when it shouldn't, both in preview and final output.
As it has been already said, it occurs when the project is somewhat complex, i.e. when there are a lot of clips (with cut sequences etc...) before on the track. An effective workaround is to move the clips to a new track, which isn't very practical in the long run.
The 'first frame bug' (as I call it, it seems the 'last frame bug' is somthing else) can affect:
- Rotations, animations, scalings of clips
- Transitions (only from upper to lower track it seems)
- Cut clips (you cut out the beginning of a clip, but the first frame of the raw clip shows nevertheless. I'm not sure for this one but I think I saw it)
- Multiple tracks (first frame of lower clip shows over the upper clip)
thus preventing you from using any of those features, which makes impossible any complex project.
The bug occured for me with mlt 0.5 as well as 0.6 and 0.7, and openshot 0.9, 1.2, 1.3, on ubuntu 32 bit 10.04, 10.10 and 11.04. I think it comes from openshot and not mlt (I can't find any kdenlive bug report about it).
I think it really needs to be fixed, because it makes openshot impossible to use for large projects, whereas openshot is otherwise great software and by far the best (and the nicest) video editor available for linux (another problem with large projects is that the more complex the project, the longer the lag when you try to move the cursor, but that's not so important).

Revision history for this message
Richard Simmons (risimmonsuk) wrote :

Maybe somebody who is seeing this could put together a simple project which can reproduce this and share it (from the descriptions it only happens on 'complex' projects, but perhaps something which re-uses just a couple of clips but does lots of transitions).

Providing devs with an sure way of reproducing your problem is always going to be the fastest way to get your problem fixed, particularly when there's so many potential variables. (of course there's no guarantee that everybody sees the same results, even with the same files, but even that would tell us something interesting).

Revision history for this message
zerbob (zerbugug) wrote :

Ok I added here the beginning of my project. To reduce the size I removed the sound, the thumbnails and all what followed the first few appearances of the bug.
Since files are stored with absolute paths (I think this has been reported as a problem), and this comes from my external hard drive, you'll have to put it in "/media/Iomega\ HDD/Legos/H2G2/Fit\ the\ second/Part\ I/". Sorry for the spaces. (Another problem I noticed is that the window saying files were not found grows very very large when no files were found).
It starts with a few seconds of blank screen (there was meant to be titles).
At 0:37, 0:45 and 1:06 you'll notice that I switch to a new track with no apparent reasons. If you put the clips back to the 3rd track the bug will happen (at least it does for me), e.g. before the fade-in of the galaxy picture at 0.37 you should briefly see the whole picture, both at preview and after rendering.
Tell me if it occurs for you, or if I forgot some files.

Changed in openshot:
status: New → Confirmed
Revision history for this message
Richard Simmons (risimmonsuk) wrote :

Thanks Zerbob - I can reproduce the issue you describe with the project files you sent. The first frame of the fade-in transitions is flashing at full brightness. I haven't had a chance to investigate yet though.

Revision history for this message
Richard Simmons (risimmonsuk) wrote :

Looks to me as though there's a mismatch (off by 1) in the sequence.mlt between the start of the transition and the start of the video. I think the video is starting 1 frame before the fade in, so we end up with 1 frame of full brightness. If you move the offending clip to a different timeline then the clip-transition timings match and all is ok.

Haven't had a look in the code at what's causing this yet.

Revision history for this message
Richard Simmons (risimmonsuk) wrote :

Looks like the code which generates sequence.mlt has a bug which means it doesn't insert single frame gaps between clips (in the case that you've got them in your project). It won't even be visible that you have a single frame gap because when you play the video through it won't appear. This leads to a mismatch between the clip timing and the transition timing (which runs off a different timeline and _will_ have the additional gap).

There's a simple fix in the code though I haven't been able to fully test it yet - a workaround for now would be to extend any clips which have a 1 frame gap before the start of the next clip (though it might be hard to spot them - zerbob there's just such a gap between the second017.jpg and bulldozer.avi clips in the test project you sent).

Revision history for this message
zerbob (zerbugug) wrote :

Now that you say it I remember that another workaround I had found was lengthening a little the previous clip on the offending frame, or in the case of a fade-in, to cover it with a solid black picture on the same track. But this wasn't applicable since if you just "touch" the covered clip it will take over the covering one.
Thank you for spending some time on it. I hope you'll find a working fix. Let us know about it, anyway I suppose you'll commit it for next version.

Revision history for this message
Richard Simmons (risimmonsuk) wrote :

If you're running from the source (instructions to get the archive are on
the Download page) then you can apply the very simple fix yourself to work
around the problem until a fixed release version is available. In
/openshot/classes/clip.py you want the GenerateXML function, and on around
line 277 change;

            if blank > 1:

to

            if blank > 0:

That should fix the transitions. You'll now see the single frame blank
periods between clips which were causing the problem, so you'll need to go
and fix those in your project...

On 17 June 2011 18:56, zerbob <email address hidden> wrote:

> Now that you say it I remember that another workaround I had found was
> lengthening a little the previous clip on the offending frame, or in the
> case of a fade-in, to cover it with a solid black picture on the same track.
> But this wasn't applicable since if you just "touch" the covered clip it
> will take over the covering one.
> Thank you for spending some time on it. I hope you'll find a working fix.
> Let us know about it, anyway I suppose you'll commit it for next version.
>
> --
> You received this bug notification because you are a member of OpenShot
> Developers, which is subscribed to OpenShot Video Editor.
> https://bugs.launchpad.net/bugs/520941
>
> Title:
> Fade in/out glitches
>
> Status in OpenShot Video Editor:
> Confirmed
>
> Bug description:
> Hi,
>
> I don't know if anyone else has experienced this, but now and again
> (not all the time) my fades in and out glitch at the outer end: before
> a fade in, the image or video appears momentarily (probably just for
> one frame) then disappears, and the fade starts normally. Similarly at
> the end, with the final frame flashing up full brightness.
>
> It also seems to some extent to happen on audio - it's like OpenShot
> realises a moment too late that it's not meant to be playing the
> audio, or that a fade is meant to be happening.
>
> Sometimes it doesn't happen, and sometimes it fixes itself...
> unfortunately not on a 'quick' project I've been doing this morning!
>
> Anyway. It's absolutely great work - I'm so impressed! Something as
> good as this, and non-linear (I can't understand what you can even do
> with linear editing!) is a joy to have!
>
> Ubuntu 8.04
> DEB 1.0.0
>
> Again - great application. I've already done some stuff I'm really
> pleased with!
>
> Cheers,
>
> Mike
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openshot/+bug/520941/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openshot.developers
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~openshot.developers
> More help : https://help.launchpad.net/ListHelp
>

Changed in openshot:
milestone: none → 1.4.0
Revision history for this message
Richard Simmons (risimmonsuk) wrote :

Patch added

moimael (moimael)
Changed in openshot:
importance: Undecided → Medium
Revision history for this message
Bernd Faulstich (bernibaerchen) wrote :

Same Bug. It its not only at fadings, its if a video on lower tracks starts.

Andy Finch (fincha)
Changed in openshot:
status: Confirmed → In Progress
Revision history for this message
Santiago Romero (sromero) wrote :

  Hi.

 I'm suffering this bug and I'm almost unable to "render" my "home" videos with simple fades without "hacking" the clips to avoid this bug (moving to other tracks, leaving "gaps", and so on).

 Has been fixed in any developer/cvs version? I need to render videos correctly without this bug :(

Revision history for this message
Andy Finch (fincha) wrote :

Yes, it's in my development branch (which should be quite stable). You can get the code using the command:

bzr branch lp:~fincha/openshot/openshot-dev-1.4

Revision history for this message
Bernd Faulstich (bernibaerchen) wrote :

could i use the old Project file or save as new filename or sth. else?

Revision history for this message
Richard Simmons (risimmonsuk) wrote :

You should be able to use the old project file with this patch. Note that the bug was that gaps between clips of 1 frame were never shown in the preview/final render, but were taken into account when calculating the timings of transitions, thus leading to the glitches. So you may notice single frame gaps in your old project which you wouldn't have seen before (but were technically there all along).

So although you can use old projects, you may need to adjust them to remove the gaps which were causing the problems in the first place.

Revision history for this message
Bernd Faulstich (bernibaerchen) wrote :

I saw something strange.
I had some glitch in the begining of a fade.
Upper layer(track) = track1
Lower track = track2
Fading from Track 1 to Track 2

Track1 ==================
Fading \/ \/ \/ \/
Track2 X=============

the single frame you know about was at point X.

When i moved the track 2 to an point earlier like

==================
                                  \/ \/ \/ \/
             X=============

this single frame flashes again at point X.

So track 1 was playing but every time when a clip starts below, the first frame of this clip flashes up for one frame.

Revision history for this message
Bernd Faulstich (bernibaerchen) wrote :

Dam it ascii-art don't work. I hope you understand it

1111111111111111111|X2|1fadingTo2222222222222222222

and then

11111111|X2|111111111111fadingTo2222222222222222222

or with more clips below

111111|X2|11111111|X3|111111111

X2 and X3 are only one frame (the first frame) from the clips of track2 and track3

Revision history for this message
Bernd Faulstich (bernibaerchen) wrote :

Me again. got the 1.4 preRel. version from bzr ... (program info shows 1.3.1 but :-D)

Fading from track below to track up.
Track2 ends at 90% of fading
Track1 starts at 10% of fading
so it has to look like Track222222222222|(10%)|>>fading>>|(90%)|1111111111111

in preview with timebar (slider is invisible ;-D) it looks like
Track2222222222222|(at 10% one or two frames (the first one) of track 1)|2>>fading>>|(90%)|1111111111

if i move the begining of the Clip at track 1 to 50%
Track2222222222222|(at 50% one or two frames of track 1)|2>>fading>>|(90%)|1111111111

so i thought perhaps it's a problem of the fading and removed it (nice animation and crash :-( OK again - autosave is good) and try "clock pointer? clockwise"

Track222222222222|(at 10% first frame of track 1)|22>>clockfading>>|90%|1111111

so i think its not a problem of the specific fading, it could be a general problem of the first frames...?

Revision history for this message
Richard Simmons (risimmonsuk) wrote :

Bernd, this sounds like a related bug, but not exactly the same as what has been fixed. I think I understand what you're saying - I'll try and reproduce, but it might be easier if you could produce a short project which demos the problem and post it here.

Revision history for this message
Bernd Faulstich (bernibaerchen) wrote :

Hi Richard,
i broke down my Project.
Deleted all unneeded Tracks (only 2 left) - bug still there.
Deleted all other clips - bug not there again.
So i now have a Project with 2 tracks, 9 clips and 9 fadings.
Then i tried to remove all other clips from the filelist exept that two - bug not there any more.
Then i removed all clips exept the 9 used clips, and yes - Bug still there.
I copied the clip with that problem and the bug is there too.
I removed clip by clip, and in the end there are 3 clips and some fadings

Revision history for this message
Bernd Faulstich (bernibaerchen) wrote :

PS. is there a Problem with "ÄÖÜ" in the Videofilenames?

Revision history for this message
Bernd Faulstich (bernibaerchen) wrote :

The size of the clips is a little bit ... ähm yes. But here as a zip-file.

Revision history for this message
Bernd Faulstich (bernibaerchen) wrote :

If there are any questions, feel free to contact me.
If you think you have fixed ... please post the bzr-comand. I will try it :-)

Changed in openshot:
milestone: 1.4.0 → 1.4.1
Revision history for this message
Darren Conway (darren-conway) wrote :

Hi
I posted this in the wrong place on the duplicate bug listing. I am posting it here because it is active.

I have the bug to. I am using Ubuntu 11.04 and the latest Ubuntu Openshot package.
I have tried the work arounds.

I have 4 tracks.

I placed a clip on a track (the only clip on that track) and added a fast end fade. The clip is an image (Title screen). The clip did not overlap any other clip on other tracks. When the clip played, it faded, then the image flashed at the end of the clip. After the flash, the display went black (as expected because of the gap to the next clip on another track).

There is no flash if the fast fade is removed.

This demonstrates that the flash can occur without interacting with another clip.
I have the same problem with transitions. I get a flash at the end of the clips.

Would it help if I attached a mini-demo project?

Revision history for this message
Bounty (gregr-arsfabula) wrote :

Hi,

I've just upgraded my workstation to Ubuntu 11.11 32bit, with a default installation of Openshot 1.4.0-1 & MLT 0.7.4-3.
Started to edit a video with alternating sequences fading in & out. Adding about the 10th clip I started to get the glitches and could not get rid of them

I then started the project over again on my laptop installed with Ubuntu 11.04 64bit, Openshot 1.4.0-1, MLT 0.6.2-2, and could complete the project with no glitches

Revision history for this message
Olivier Girard (eolinwen) wrote :

I don't know if it was the reason but you must install for Oneiric the package gtk2-engines-pixbuf more than the usual (the same than the version 1.3.0).

40 comments hidden view all 120 comments
Revision history for this message
Oliver Schonrock (oliver-realtsp) wrote :

I am sorry to say that I was unable to resolve the issue in the end. I spent 3 days trying to make the libraries agree on the clip length to stop openshot getting messed up...I couldn't

I accept that my workflow is somewhat unusual, because I am effectively using "proxy clips" (see details on my workflow above) outside of openshot. I simple cannot edit my 1080p video using the raw footage..required performance is not even close..which is not helped by openshot using 30% of my CPU while idling on an empty project.

I have ordered a new machine Core i7 2600 with 8GB and a 2TB RAID 0 stripe disk because it will make life easier...however even with that my performance calculations suggest that I cannot edit using the raw mp4/libx64 clips. So proxying will remain essential

I tried with kdenlive which has proxy clips built in..and ...sorry...just worked.

kdenlive has bugs too..and it crashes...but this bug really cripples any half serious usage of openshot for me (perhaps it's caused by the bad mp4s my camera produces..although kdenlive handles them fine using the same underlying mlt).

Revision history for this message
Mikko Huhtala (mhuhtala) wrote :

For the record, I had the problem while working with 25 fps PAL DV files from one Panasonic camera and rendering with a 25 fps PAL DVD profile. The whole project was 25 fps from start to finish, so the problem seems to be more than just confusion about 30 fps vs. 29.97 fps.

Revision history for this message
Romano Giannetti (romano-giannetti) wrote :

FWIW, all my projects are 25 or 24 fps too. I do not think this is a frame-rate related problem. If the developers wants a test proyect, I can try to prepare it ---- just ask. I can put it on share on Ubuntu One.

Revision history for this message
Andy Finch (fincha) wrote :

Please provide a simple project if possible. The simpler, the better. Thanks.

Revision history for this message
Romano Giannetti (romano-giannetti) wrote :

@Andy: will try asap. I have a little bit of problems now, but I hope tomorrow to be able to prepare something (and then Murphy will bite and it will work ok ;-))

Revision history for this message
Romano Giannetti (romano-giannetti) wrote :

As told, I was unable to reproduce it in this simple test. Anyway, I have an example that shows some problem:

http://ubuntuone.com/6yRjzFWiJqT1ABhHx01SM4

1) you cannot use directly the MTS file (AVCHD), it stutters a lot. But if convert it with "ffmpeg -i 00000.MTS -sameq out.mp4" then it will work.

2) the "zoom" animation on the image come out jumpy

I have not tried to change the FPS of the project, no time left now.

Changed in openshot:
milestone: 1.4.1 → 1.5.0
Revision history for this message
eddie matejowsky (e06) wrote :

I'm not sure a "me too" type post is useful but yes - me too.
I'm using 1.4.2 in Ubuntu.

I made a 19 minute clip using mostly still images with a few videos.

The problem doesn't show up till just after half way through the video.

The first frame (I guess) of the fade comes through unaltered.

When previewing by manually moving the cursors along - the bad frame (sometimes?) seems to be before the clips starts in the timeline.

I also notice problems with audio as someone else mentioned. I had a loud clip I turned down to 15% but it seemed to come thought at full volume for a fraction of a second.

I was using a transitions to do the fades but but the same happens if I turn on fade-in in the clip properties.

The same thing happens if I use some other transition (eg circles).

Another curious thing is one of my images was displayed sideways.
I fixed it in properties but sometimes the first frame was still sideways - at least when previewed in OS.

This clip takes a fair while to render but I've found the bugs I see previewed in OS show up in the final rendered video.

Revision history for this message
eddie matejowsky (e06) wrote :

I am working around the bug by adding more tracks.
It seems like there is a limit to how many clips can be on one track before having fade glitches.
The first part of my edited video was ok. Once it started to misbehave I moved the clips from track
2 and 3 to 4 and 5.
This seems to do the trick.

Revision history for this message
eddie matejowsky (e06) wrote :

Also I do not think frame rate or codecs have anything to do with it.
You can see the bug in the OS preview before any output file is generated.

Revision history for this message
Santiago Romero (sromero) wrote :

 Hi.

 Has been this bug solved?

 I have more than 1 year of home videos waiting for processing until I discovered this bug. I was waiting for the bug to be fixed instead of moving to Kino or Kdenlive because I find openshot very intuitive and easy to use and I because thought that the bug, being ***SO CRITICAL***, would be quickly fixed.

 Is openshot still under development? Is this bug being hunted?

 Please, inform the users about this, because I can't hold more GB of "raw videos" and I need to start processing them, and If this bug is not going to be fixed I'll have to switch to kine, kdenlive, or any other videoeditor that works. I would prefer doing it in openshot, so, please, tell us something.

Revision history for this message
Santiago Romero (sromero) wrote :

 I forgot to add this to my previous comment:

 How is possible that this bug is categorized as "IMPORTANCE MEDIUM"?

 This bug prevents the user to render the final video correctly. It's not MEDIUM. It's not HIGH. It's CRITICAL.

 There is people not using openshot due to this bug, it's really important.

Revision history for this message
Andy Finch (fincha) wrote :

If it had been solved, it would have been marked as such.

When you look through the comments here you will see that there is more than one cause for this bug. Some solutions have worked for some but not others.

We think the major cause of this is a mismatch between ffmpeg & MLT in the number of frames that each reports a clip is made up of.

We think the solution to this will be our new library which will replace MLT.

Revision history for this message
Santiago Romero (sromero) wrote :

 Please, don't misunderstand me, I **really** like OpenShot. It's the first NLVE that I've ever managed to use succesfully to create my own home videos and I want to continue using it because different reasons (and, I know sounds strange, but being written in python is one of the reasons).

 I just "revived" the thread because I've been waiting for ... ¿a year? to be able to process my raw home videos that are starting to fill my hard disk drive, and I don't really want to switch to another non-linear video editor.

 Maybe I forgot to thank you all for the nice job you're doing, seriously. I just would be quite happy with this bug fix + autocollapse button + add clip between existing clips...

 The "new library which will replace MLT"... has any date for release?

Revision history for this message
Andy Finch (fincha) wrote :

There is no date set yet, it will be in the months range rather than weeks.

Revision history for this message
DAGRON Jean-Louis (jeanlouis-dagron) wrote :

Hi all,

I had the same pb with Kubuntu 12.04 but limited to fade in glitches (not fade out).
My camera is a Panasonic HDC-SD1.
Logically this camera outputs 1080i/60i.

 Curiously the problem disappear when I modify the project parameters to :
HD1080p 29,97 fps

Hope this can help some of you.

Congratulations to all contributors for this great software

Revision history for this message
Andy Finch (fincha) wrote :

There is now a fix committed for this, at least a fix for the only reproducible example provided.

Changed in openshot:
status: In Progress → Fix Committed
milestone: 1.5.0 → 1.4.3
importance: Medium → High
Revision history for this message
Malte Cornils (malte) wrote :

I've just started reencoding my "glitchy" projects with the 1.4.3-alpha branch, and it seems
to be fixed (at least for me). Well done and thank you!

Revision history for this message
Santiago Romero (sromero) wrote :

 God, Thanks!!

 How do I download the "development" branch with the fix applied?

 I'm currently using this:

[sromero@compiler:~]$ cat /etc/apt/sources.list.d/openshot_developers-ppa-oneiric.list
deb http://ppa.launchpad.net/openshot.developers/ppa/ubuntu oneiric main
deb-src http://ppa.launchpad.net/openshot.developers/ppa/ubuntu oneiric main

 Is OK, or I must change the repository / download "sources"?

Revision history for this message
Andy Finch (fincha) wrote :

See here how to get the latest source code & run it:

http://openshotusers.com/help/1.3/en_GB/ar01s29.html#sect2_84

Revision history for this message
Olivier Girard (eolinwen) wrote :

You could too use the daily PPA. See here to add this one but you must de-activate the other before.
https://code.launchpad.net/~openshot.developers/+archive/daily

Revision history for this message
Hans Petter Birkeland (hanspb) wrote :

I have the daily PPA enabled, but I have not seen the update.

Revision history for this message
Malte Cornils (malte) wrote :

BTW, after trying all my videos with the fix, one still had glitches - but only in one track, and I found out this was due to the first clip start position being slightly left of the timeline start. Repositioning it so it started at zero made the last glitches (finally!) go away. Do you need a testcase/new bug report for that?

Revision history for this message
Daniel Ellis (danellisuk) wrote :

This issue still affects 1.4.2 and trunk (1.4.3-alpha1). Attached is an example project demonstrating how a short clip of 0.1 seconds can break the rest of the track. The example project was saved using 1.4.3-alpha1 and for some reason fails to open in 1.4.2 (but that's another issue).

Revision history for this message
Daniel Ellis (danellisuk) wrote :

If you export the melt XML using the example project I posted. You see the following:-

<producer id="65ba0cac-b54d-11e1-b013-00261898a8a2" in="0" length="15000" novdpau="1" out="-1">
 <property name="resource">/home/daniel/Openshot bug 520941/thumbnail/Short Clip.svg</property>
</producer>

Note the value "-1" set in the out attribute. I would suspect that we never want to specify -1 for this attribute, clearly the behaviour is undefined. What would be a good solution to this?

Prevent the user from adding such a short clip?
Silently set this value to 0, to prevent an invalid value being used?
Warn the user that the clip is too short?

Currently it can be difficult to notice if you have accidently shortend a clip, especially if it is at the beggining of the track, or close to another clip.

Revision history for this message
Daniel Ellis (danellisuk) wrote :

It isn't just an "out" attribute of "-1" that can cause this issue. It is any producer where the "in" attribute is greater than the "out" attribute, which is also a scenario that you can currently create in OpenShot.

Revision history for this message
Daniel Ellis (danellisuk) wrote :

I have also found that PNG sequences cause this issue. See the attached example project "Openshot PNG sequence issue.tar.gz", which demonstates the issue using a PNG sequence generated via "New Animated Title".

There are two issues I can see:-

1. The final frame of the animation is not mixed correctly and so you see a flash.
2. Fades will be broken for any clips after the PNG sequence on the same track (in the example I attached, you hear a blip at the end)

Looking at the generated MLT XML, you can see a difference between image sequence "out" attribute which is "79". Whereas the transition which is added along with the image sequence has "out" set to "78".

If you change the 78 to 79 and run the XML directly with melt, then that at least fixes the flash you see at the end of the animation. But does not resolve the blip at the end of the fade.

I have played with the ins and outs, but cannot find a way to resolve the blip.

So back to the 78 vs 79 issue. I think this is a rounding error within OpenShot. I since noticed that I used the default profile NTSC, I usually use PAL, but lets investigate this anyway:

The image sequence is 80 frames. NTSC is 29.97 frames per second.
So I expect OpenShot to calculate a duration of 2.669336003 and round this to 2.67.
But OpenShot shows a length of 2.64, which happens to be what you would round to if OpenShot was calculating based on 79 frames (79/29.97 = 2.635969303)

So possibly OpenShot is getting the number of frames in a sequence out by 1?

Revision history for this message
Daniel Ellis (danellisuk) wrote :

Have resoluved the issues I found in the last few comments. Added two separate bug reports with patches.

Bug #1013029
Bug #1013035

Revision history for this message
teimcrr (marco-carrarini) wrote :

Ubuntu 12.04 with Openshot daily build.
Still not fixed. I'm trying to make a slideshow, but this way it's unusable.

Changed in openshot:
status: Fix Committed → Fix Released
Revision history for this message
Jonathan Thomas (jonoomph) wrote :

This should be fixed now in the daily build (as of a few days ago)

Changed in openshot:
status: Fix Released → Fix Committed
Changed in openshot:
importance: High → Critical
Changed in openshot:
status: Fix Committed → Fix Released
Revision history for this message
Bodo Bigalk (bib-odo) wrote :

I am using OpenShot version 1.4.3
Ubuntu 12.04
Kernel: 3.2.0-37-generic x86_64
Melt: libmlt.so.0.7.7 libmlt.so.4

and have the same issue.

Revision history for this message
Olivier Girard (eolinwen) wrote : Re: [Openshot.bugs] [Bug 520941] Re: Fade in/out glitches

Update your version of MLT. Follow this FAQ :
https://answers.launchpad.net/openshot/+faq/1861
And try again.
Thxs.

2013/2/6 Bodo Bigalk <email address hidden>

> I am using OpenShot version 1.4.3
> Ubuntu 12.04
> Kernel: 3.2.0-37-generic x86_64
> Melt: libmlt.so.0.7.7 libmlt.so.4
>
> and have the same issue.
>
> --
> You received this bug notification because you are a member of OpenShot
> Bugs, which is subscribed to OpenShot Video Editor.
> https://bugs.launchpad.net/bugs/520941
>
> Title:
> Fade in/out glitches
>
> Status in OpenShot Video Editor:
> Fix Released
>
> Bug description:
> Hi,
>
> I don't know if anyone else has experienced this, but now and again
> (not all the time) my fades in and out glitch at the outer end: before
> a fade in, the image or video appears momentarily (probably just for
> one frame) then disappears, and the fade starts normally. Similarly at
> the end, with the final frame flashing up full brightness.
>
> It also seems to some extent to happen on audio - it's like OpenShot
> realises a moment too late that it's not meant to be playing the
> audio, or that a fade is meant to be happening.
>
> Sometimes it doesn't happen, and sometimes it fixes itself...
> unfortunately not on a 'quick' project I've been doing this morning!
>
> Anyway. It's absolutely great work - I'm so impressed! Something as
> good as this, and non-linear (I can't understand what you can even do
> with linear editing!) is a joy to have!
>
> Ubuntu 8.04
> DEB 1.0.0
>
> Again - great application. I've already done some stuff I'm really
> pleased with!
>
> Cheers,
>
> Mike
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openshot/+bug/520941/+subscriptions
>
> --
> Mailing list: https://launchpad.net/~openshot.bugs
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~openshot.bugs
> More help : https://help.launchpad.net/ListHelp
>

--
Olivier
Cenwen un elfe sur la banquise/ an elve on the ice
Mon blog perso sur le multimédia, Ubuntu, Linux et OpenShot :
http://linuxevolution.wordpress.com/
Le forum d'Openshot où vous me trouverez : http://openshotusers.com/
http://openshotusers.com/forum/index.php
Nothing is lost until the last second.
The family motto : When we want, we can.
Astuces, Actualités, Logiciels, bref sur tout ce que je ne fais d'articles
dessus Google+ <https://plus.google.com/u/0/111472725110173916234/posts>

Revision history for this message
Florian Echtler (floe) wrote :

I'm also seeing this with Openshot 1.4.3 on Ubuntu 12.04 (libmlt4-0.7.6+git20120204-2). When I have a track with gaps, then the glitch only occurs at the last fade before the gap (but does that quite reliably).

Revision history for this message
Olivier Girard (eolinwen) wrote :

Same advice/thing than for Bodo. Update your version of MLT (at least the
0.8.8)

2013/4/5 Florian Echtler <email address hidden>

> I'm also seeing this with Openshot 1.4.3 on Ubuntu 12.04
> (libmlt4-0.7.6+git20120204-2). When I have a track with gaps, then the
> glitch only occurs at the last fade before the gap (but does that quite
> reliably).
>
> --
> You received this bug notification because you are a member of OpenShot
> Bugs, which is subscribed to OpenShot Video Editor.
> https://bugs.launchpad.net/bugs/520941
>
> Title:
> Fade in/out glitches
>
> Status in OpenShot Video Editor:
> Fix Released
>
> Bug description:
> Hi,
>
> I don't know if anyone else has experienced this, but now and again
> (not all the time) my fades in and out glitch at the outer end: before
> a fade in, the image or video appears momentarily (probably just for
> one frame) then disappears, and the fade starts normally. Similarly at
> the end, with the final frame flashing up full brightness.
>
> It also seems to some extent to happen on audio - it's like OpenShot
> realises a moment too late that it's not meant to be playing the
> audio, or that a fade is meant to be happening.
>
> Sometimes it doesn't happen, and sometimes it fixes itself...
> unfortunately not on a 'quick' project I've been doing this morning!
>
> Anyway. It's absolutely great work - I'm so impressed! Something as
> good as this, and non-linear (I can't understand what you can even do
> with linear editing!) is a joy to have!
>
> Ubuntu 8.04
> DEB 1.0.0
>
> Again - great application. I've already done some stuff I'm really
> pleased with!
>
> Cheers,
>
> Mike
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openshot/+bug/520941/+subscriptions
>
> --
> Mailing list: https://launchpad.net/~openshot.bugs
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~openshot.bugs
> More help : https://help.launchpad.net/ListHelp
>

--
Olivier
Cenwen un elfe sur la banquise/ an elve on the ice
Mon blog perso sur le multimédia, Ubuntu, Linux et OpenShot :
http://linuxevolution.wordpress.com/
Le forum d'Openshot où vous me trouverez : http://openshotusers.com/
http://openshotusers.com/forum/index.php
Nothing is lost until the last second.
The family motto : When we want, we can.
Astuces, Actualités, Logiciels, bref sur tout ce que je ne fais d'articles
dessus Google+ <https://plus.google.com/u/0/111472725110173916234/posts>

Revision history for this message
Florian Echtler (floe) wrote :

Did that just now, mlt is now at melt_0.8.8-0ubuntu0~sunab~precise1. Still same problem. However, as a workaround, I've found that creating an empty title (transparent text on transparent bg) and filling all gaps in my "Titles" track with "empty" clips fixed the issue.

Revision history for this message
Miguel Ángel Vilela (miguev) wrote :

Hi,
I just faced this problem with OpenShot 1.4.3 on Ubuntu 13.04, read this bug report, updated MTL to 0.8.8-2
(dpkg -l output for libmlt++3 libmlt5 python-mlt5 libmlt-data) using the Raring packages from https://answers.launchpad.net/openshot/+faq/1861 ... but the problem remains.

What else do I do to get the fix?
Thanks!

Revision history for this message
Miguel Ángel Vilela (miguev) wrote :

Somehow it was just a matter of time. I left OpenShot alone for a little while (minutes), added more clips to my project, exported to Youtube-HD and all glitches are gone :)

Revision history for this message
Olivier Girard (eolinwen) wrote :

I don't see what we could make more. You seem to have the last version of
MLT. The only thing that I see is to wait until that we come with the 2.0.0
which will come with our own video framework which will replace MLT. He is
optimized for multi-core and for being the more stable that we have never
had. Currently, he is checked by a C++ gourou since near one month ago.

2013/11/10 Miguel Ángel Vilela <email address hidden>

> Somehow it was just a matter of time. I left OpenShot alone for a little
> while (minutes), added more clips to my project, exported to Youtube-HD
> and all glitches are gone :)
>
> --
> You received this bug notification because you are a member of OpenShot
> Bugs, which is subscribed to OpenShot Video Editor.
> https://bugs.launchpad.net/bugs/520941
>
> Title:
> Fade in/out glitches
>
> Status in OpenShot Video Editor:
> Fix Released
>
> Bug description:
> Hi,
>
> I don't know if anyone else has experienced this, but now and again
> (not all the time) my fades in and out glitch at the outer end: before
> a fade in, the image or video appears momentarily (probably just for
> one frame) then disappears, and the fade starts normally. Similarly at
> the end, with the final frame flashing up full brightness.
>
> It also seems to some extent to happen on audio - it's like OpenShot
> realises a moment too late that it's not meant to be playing the
> audio, or that a fade is meant to be happening.
>
> Sometimes it doesn't happen, and sometimes it fixes itself...
> unfortunately not on a 'quick' project I've been doing this morning!
>
> Anyway. It's absolutely great work - I'm so impressed! Something as
> good as this, and non-linear (I can't understand what you can even do
> with linear editing!) is a joy to have!
>
> Ubuntu 8.04
> DEB 1.0.0
>
> Again - great application. I've already done some stuff I'm really
> pleased with!
>
> Cheers,
>
> Mike
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openshot/+bug/520941/+subscriptions
>
> --
> Mailing list: https://launchpad.net/~openshot.bugs
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~openshot.bugs
> More help : https://help.launchpad.net/ListHelp
>

--
Olivier
Cenwen un elfe sur la banquise/ an elve on the ice
Mon blog perso sur le multimédia, Ubuntu, Linux et OpenShot :
http://linuxevolution.wordpress.com/
Le forum d'Openshot où vous me trouverez : http://openshotusers.com/
http://openshotusers.com/forum/index.php
Nothing is lost until the last second.
The family motto : When we want, we can.
Astuces, Actualités, Logiciels, bref sur tout ce que je ne fais d'articles
dessus Google+ <https://plus.google.com/u/0/111472725110173916234/posts>

Revision history for this message
Hump Tee (humpty) wrote :

Ubuntu 12.04, OpenShot 1.4.3, Melt 0.7.6.
I had the last-fade flash into a gap problem.

At first I thought there were too many clips (30). So I started removing them.
Turns out there was tiny clip hidden somewhere between two clips. It can happen if you're not careful with the cutter. Removed it and all good at 30 clips now.

(another solution was to paste over the gap with a solid black title.)

Revision history for this message
Olivier Girard (eolinwen) wrote :

Try to update your MLT version, this one is probably the worse of the 0.7.x
serie. Take a look at this FAQ :
https://answers.launchpad.net/openshot/+faq/1861

2013/12/15 Hump Tee <email address hidden>

> Ubuntu 12.04, OpenShot 1.4.3, Melt 0.7.6.
> I had the last-fade flash into a gap problem.
>
> At first I thought there were too many clips (30). So I started removing
> them.
> Turns out there was tiny clip hidden somewhere between two clips. It can
> happen if you're not careful with the cutter. Removed it and all good at 30
> clips now.
>
> (another solution was to paste over the gap with a solid black title.)
>
> --
> You received this bug notification because you are a member of OpenShot
> Bugs, which is subscribed to OpenShot Video Editor.
> https://bugs.launchpad.net/bugs/520941
>
> Title:
> Fade in/out glitches
>
> Status in OpenShot Video Editor:
> Fix Released
>
> Bug description:
> Hi,
>
> I don't know if anyone else has experienced this, but now and again
> (not all the time) my fades in and out glitch at the outer end: before
> a fade in, the image or video appears momentarily (probably just for
> one frame) then disappears, and the fade starts normally. Similarly at
> the end, with the final frame flashing up full brightness.
>
> It also seems to some extent to happen on audio - it's like OpenShot
> realises a moment too late that it's not meant to be playing the
> audio, or that a fade is meant to be happening.
>
> Sometimes it doesn't happen, and sometimes it fixes itself...
> unfortunately not on a 'quick' project I've been doing this morning!
>
> Anyway. It's absolutely great work - I'm so impressed! Something as
> good as this, and non-linear (I can't understand what you can even do
> with linear editing!) is a joy to have!
>
> Ubuntu 8.04
> DEB 1.0.0
>
> Again - great application. I've already done some stuff I'm really
> pleased with!
>
> Cheers,
>
> Mike
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openshot/+bug/520941/+subscriptions
>
> --
> Mailing list: https://launchpad.net/~openshot.bugs
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~openshot.bugs
> More help : https://help.launchpad.net/ListHelp
>

--
Olivier
Cenwen un elfe sur la banquise/ an elve on the ice
Mon blog perso sur le multimédia, Ubuntu, Linux et OpenShot :
http://linuxevolution.wordpress.com/
Le forum d'Openshot où vous me trouverez : http://openshotusers.com/
http://openshotusers.com/forum/index.php
Nothing is lost until the last second.
The family motto : When we want, we can.
Astuces, Actualités, Logiciels, bref sur tout ce que je ne fais d'articles
dessus Google+ <https://plus.google.com/u/0/111472725110173916234/posts>

Revision history for this message
Florian Echtler (floe) wrote :

This is an impressively long-lasting bug. :-)

That being said, I just had the same problem again, with OpenShot 1.4.3 on Ubuntu 16.04. For me, a simple fix was to change the length of the very first title by a very small amount (-0.1 seconds). After that, the flashes in the exported video were gone.

Displaying first 40 and last 40 comments. View all 120 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.