Comment 72 for bug 520941

Revision history for this message
Oliver Schonrock (oliver-realtsp) wrote :

PROBLEM SOLVED!! ...at least for me!

I too have been plagued by this issue. When adding many clips to a project the clips would start not to line up properly and then blank frames started appearing and the fades/transitions would "skip" / show the wrong frames at the start of the transition...in short all of the symptoms described above...it was driving me mad...and it was happening in every 2nd project.

BTW I am using Ubuntu Oneiric with Openshot 1.4 and melt 0.7.4 (i also tried 0.7.6, but no joy).

So I took a "broken" project and started reducing it to a minimal version. The clearest example I had were 4 clips with 2 transitions about 20 seconds apart using the same 2 Tracks.ie like this (hope that's readable):

                22222222 444444444444
                ^^^ ^^^^
1111111111 333333333

The project had nothing else in it just 4 clips and 2 transitions..and it was still "broken"..ie the second transition would display an incorrect frame at the start of the transition (makes it look like it "jumps/flickers").

I made a new project and added the same 4 clips and 2 transitions. The new project worked! so now I had a good and a bad copy. I started exporting the XML and comparing the 2 versions (I am a software developer so this stuff comes easily..only very amateur with video though).

The only significant differences in the xml were the paths the producer Ids and the "in/out" timings (because I had created them "by hand" in the new project).

So I opened 2 copies of openshot and copy/pasted the in/out timings for all 4 clips and 2 transitions from the broken project to the new one. and....the new project broke! Then I played with the in/out setting of each piece and figured out it was clip 2 (see ascii diagram). It had an out timeof 17.02s when broken, but if I set it to 17.00 it worked fine. All this time I kept thinking "rounding error", because that happens a lot when you add lots of floating point number together. At first I thought openshot was introducing the rounding error..then I stumbled upon the key. 29.97 is almost 30 but not quite and might be introducing this "rounding error".

So I checked the manual of my video camera (Panasonic HX-WA10). It says 30fps. Both projects were 30fps (1080p blah blah). So I ran

ffmpeg -i filename

which allows you to inspect what ffmpeg says is in the raw file direct from the camera. It said 29.97fps!!!

mplayer -endpos 0 filename

also said 29.97fps. They also reported 510 frames exactly (there is no such thing as a half frame!), and 510 / 29.97 = 17.02!

I know that you are supposed to match the project profile to the raw source material so I re-saved the project as 29.97fps 1080p and voila! All the problems went away. The clips lined up nicely, the black frames were gone and the transitions worked as expected, first time. Without spreading them over many tracks etc...

Openshot was missing the odd frame on its timeline and that was breaking the transitions etc...

So the moral of the story is:
a) don't trust your camera manual's frame rate! check it with ffmpeg!
b) be very very sure that your project profile matches the raw material

Questions to the developers of openshot
---------------------------------------
I don't understand enough about video editors to know if openshot could compensate for this.

- Should it be possible to edit "wrong frame rate" source material reliably?

- What if you are mixing different source material?

- Could openshot at least warn you if you try to add source material with the wrong frame rate..ie "don't do this because your transitions will turn purple!"

I did check and on a previous project the final exported file was faithfully turned into 30fps eventhough the raw source was 29.97 as I now know. This meant that openshot/ffmpeg must have interpolated the odd frame here and there or just sped them up slightly (or slowed the sound track down).

So maybe this is a genuine bug that can be fixed..maybe not.

Anyway, for me, fortunately the problem appears to be solved.

Hope this helps someone...

Oliver