Bug 350948 - git master 2015-08-04 - changing project framerate does not update number of frames in source clips
Summary: git master 2015-08-04 - changing project framerate does not update number of ...
Status: RESOLVED DUPLICATE of bug 368962
Alias: None
Product: kdenlive
Classification: Applications
Component: User Interface (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Jean-Baptiste Mardelle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-04 07:54 UTC by Evert Vorster
Modified: 2018-03-26 08:26 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Evert Vorster 2015-08-04 07:54:19 UTC
When a clip that has a different framerate than the project is imported into a project, it's number of frames is translated to the number of frames it would have had if it was at the project's fps. 

When changing the projetc's framerate, the number of frames for each clip should be updated. 



Reproducible: Always

Steps to Reproduce:
1. Start a project with a low framerate.
2. Import a clip, and note down the number of frames.
3. Adjust the framerate of the project.
4. Look at the clip again, it still has the same number of frames, effectively making it shorter.
5. Remove clip from project, and import again
6. Clip now has the proper number of frames for the project.

Actual Results:  
Clips' number of frames stay constant when the project's framerate is changed. 

Expected Results:  
Clip number of frames should be updated to give the same duration at the new framerate

Just hitting "reload clip" does not work, the clip has to be removed from the project bin, and added in again. 
This, of course, removes any segments of the clip in the timeline. 
Updating the framerate will of course shift the segment along the producer, as the segments are specified in frames. (I saved the file and looked in the xml.) Which means that each segment have to be translated from the old frame to the new frame, too.
Why is kdenlive not using timestamps in the producer clips to specify the segments?
Comment 1 Evert Vorster 2015-08-04 08:02:13 UTC
I just tested it the temporal shifting...

Start a project at 30fps. 
Import a clip, and select a memorable segment in the clip.
Put the segment on the timeline. 
Now, change the project's framerate to 60fps. 
Take a look at the segment on the timeline, it is now of a completely different part of the source clip.
Comment 2 Dainius Masiliūnas 2015-09-09 20:58:56 UTC
Confirmed. In fact, it's a problem in 15.08 even when you just start with a 30 FPS project, then set the project to 60 FPS, then import audio/video files, they still show up as the wrong length (and there's a disconnect between the current view line in the timeline and the triangle that is supposed to be above it).
Comment 3 Evert Vorster 2015-10-05 07:02:33 UTC
Still an issue as of 2015-10-05

When a project's framerate is changed, every clip has to be re-read to have the new framerate, as the number of frames in each clip is calculated by it's duration and the framerate of the project, not the clip's own framerate. 

Effects applied need to be translated the new framerate, too. 

Until these bugs are fixed, one should not be even able to change the project's framerate, considering how thoroghly it breaks the usability of kdenlive.
Comment 4 Jim Shipman 2015-11-19 07:24:39 UTC
I ran into the opposite problem.  I started with 60 fps, loaded clips, then changed the frame rate to 30 fps.  Now the project monitor shows the clip to the half way point and then shows a still of the last frame for the remaining half of the time.  The time indicator on the monitor shows double the actual length of the clip so the clip "freezes" at the proper time, but the monitor time line is now twice as long as the actual clip.
Jim Shipman
Comment 5 Evert Vorster 2016-01-01 13:50:49 UTC
Ah, here it is. 
I remember writing a report about this. 
After having run into it many times, I can describe exactly how to hit the problem. 

When a clip is opened in the Project bin the first time, it's duration is converted into a number of frames at the project's frame rate. When the clip has the same frame rate as the project, this approach works beautifully. 

Where it all comes crashing down is that when the project's frame rate is updated, the number of frames for each clip is not updated. 
This is clearly not right, and is causing all kinds of weirdness, like clips stopping playback halfway through, or not being able to display the entire clip, depending on whether the frame rate of the project was increased or decreased. 

The workaround currently is to delete the clip out of the Project bin, and loading it again, which will give it the correct number of frames for the project's frame rate. Unfortunately, hitting the "Reload Clip" button does not update the number of frames for the clip. Also, when a clip is deleted out of the Project bin, it is also removed from the timeline, which is a PITA. 

So, updating the number of frames for each clip currently in the Project bin every time is updated is a necessity. 

To carry on, every time there is a change in the frame rate, a dialog pops up, saying that transitions and such will shift. Fixing this problem is related to re-reading the clips... The items on the timeline are all specified in frame numbers. This includes all transitions and effects. 
So, in order to avoid things shifting around temporally, every frame reference on the timeline also needs to be converted to the new framerate. 

ie: if an event happens at frame 100, and the project's frame rate is changed from 25fps to 30fps, that event has to move: frame 100 to (100/25)*30 = frame 120
Of course, frames are integers, so no fractional frames. 

So, to get rid of that horrible dialog, and make changing the framerate of a project bulletproof, 
all the clips need to have their frame numbers re-calculated, and then every frame reference in the timeline also needs to be converted to the new framerate.
Comment 6 Evert Vorster 2016-01-01 13:58:20 UTC
I will attempt to write a bash script that will read and convert a kdenlive save file from one frame rate to another.
Comment 7 Jean-Baptiste Mardelle 2016-01-01 15:58:52 UTC
Git commit 964b9ef8ce36e9c73bd32ed790b3e1dd59656d2c by Jean-Baptiste Mardelle.
Committed on 01/01/2016 at 15:58.
Pushed by mardelle into branch 'master'.

Reload all bin clips on project's fps  change. There is a small but in MLT causing the displayed clip length to be wrong, but it's only a display bug

M  +15   -0    src/bin/bin.cpp
M  +2    -0    src/bin/bin.h
M  +1    -1    src/bin/projectclip.cpp
M  +3    -0    src/doc/kdenlivedoc.cpp

http://commits.kde.org/kdenlive/964b9ef8ce36e9c73bd32ed790b3e1dd59656d2c
Comment 8 Jean-Baptiste Mardelle 2016-01-01 16:20:22 UTC
Git commit 353d7c21e75916fa0f944732e837abd927bd3853 by Jean-Baptiste Mardelle.
Committed on 01/01/2016 at 16:20.
Pushed by mardelle into branch 'master'.

Correctly update bin clip's length when changing project fps

M  +3    -0    src/bin/bin.cpp
M  +7    -7    src/mltcontroller/clipcontroller.cpp
M  +0    -1    src/renderer.cpp

http://commits.kde.org/kdenlive/353d7c21e75916fa0f944732e837abd927bd3853
Comment 9 Jean-Baptiste Mardelle 2016-01-01 16:35:44 UTC
Ok, then some progress was made on this issue, but the timeline is still broken after an fps change. MLT does not handle fps change, so we will need to manually move all clips in timeline to new positions and adjust the out points for each clip too. Not sure we can manage it easily without risking to have frame offsets every now ant then in our timeline...
Comment 10 Evert Vorster 2016-01-02 01:05:13 UTC
Excellent work!

Because frames are integers, any event that happen on the same frame in the time line, will go have the same frame number on the new time line at the new frame rate. 

The one corner case is if one frame follows directly behind another, you have a small chance of two frames trying to occupy the same space, or have a gap between the two key frames, depending on whether the project's frame rate was decreased or increased. 

One way around this would be to check for situations where key frames are directly following each other, and then in the new time line just keep that relationship, rather than try to convert the two key frames separately.

Unfortunately, there is not much more that can be done, as there are physically more or less frames, and we have to aim for a logical best fit.
Comment 11 Evert Vorster 2016-01-02 01:43:37 UTC
Just pulled from git, and there is just one small niggle. 

The displayed number of frames in the clip properties is not updated with the change of the project's frame rate. 

The clips now play to the proper number of frames, which makes me a very happy person. Thanks fir this fix, it's already improved the usability of kdenlive when mixing clips of different framerates. 

I have a couple of clips that I specifically made to test this. 
I have a clip of 100 frames at 30fps. 
When I load it into a project with 25fps frame rate, it correctly displays 80 frames in length. 
The clip also plays to frame 80, (with the proper frames dropped)
If I then change the project's frame rate to 30fps, the clip now plays to frame 100, but in the clip properties it still says 80 frames. 

Like I said, it's a small niggle, but it might make troubleshooting some other error in the future more easy if this is also corrected.
Comment 12 Jean-Baptiste Mardelle 2016-01-03 21:15:39 UTC
Git commit a61f25b905f6f1c95800f2b8d7cfc7067ddb966f by Jean-Baptiste Mardelle.
Committed on 03/01/2016 at 21:15.
Pushed by mardelle into branch 'master'.

Update clip properties panel on fps change

M  +4    -5    src/bin/bin.cpp
M  +1    -1    src/bin/bin.h

http://commits.kde.org/kdenlive/a61f25b905f6f1c95800f2b8d7cfc7067ddb966f
Comment 13 Evert Vorster 2016-01-18 05:52:34 UTC
It's fixed now...
Comment 14 Bob 2018-03-21 00:16:55 UTC
There seems to be a regression of this bug in v17 (17.12.0). I created a 1080p @ 29fps project into which I imported clips of 720p @ 59fps. Having created a lengthy edit, I then changed the project settings to 720p @ 59fps to match the clips. This caused all the edit in/out points to shift to completely different points in the clips.
Comment 15 Evert Vorster 2018-03-26 08:26:50 UTC
Hi there!

I believe that this bug "changing project framerate does not update number of frames in source clips" is still fixed, as that does happen. 

What does not happen, and should, is that the in and out set points also need to be updated when a project changes framerate, and that is a separate and very old bug. 
Have a look at 368962. I'll set this one to resolved again.

*** This bug has been marked as a duplicate of bug 368962 ***