Hi there. Thanks for all the hard work you are doing on kdenlive. Mixing clips of various frame rates in a project was always a little troublesome, as was changing the framerate of the project. Unfortunately, I am running into this problem hard. I am doing a project where I have a mixture of 30fps, 29.9fps, 25fps and 24fps footage. My default is full HD, 25fps, but as most of the footage is in 24fps, that is what I am editing in. So, far, the experience is horrible. After carefully selecting segments of video clips to add to the timeline, when I do some basic operation on another unrelated clip, like extracting a zone, all the segments have moved temporally along the clips. Also, clips with a higher framerate than the project framerate does not fully play to the end. When you get a bit of time, can you have a look at this, please? Reproducible: Always Steps to Reproduce: 1. load a bunch of clips with different fps. 2. select segments, and put on the timeline. 3. export one segment from a clip that is not at the current project framerate, and add to the project. 4. look at the segments of the clips on the timeline. The time/frame where the segments start and end have moved along in the source clip. Actual Results: Clips in the project bin not the right length Wrong parts of clips selected on timeline, and not the start and end of segment that I specified. Reloading a clip does not fix it. Expected Results: Nice editing experience with only pull up/down to worry about. Previously, I saw this problem when editing 25/50fps footage on 0.9.2-0.9.6, so it's been here a while.
Evert, I would need some more infos to reproduce the issue. Can you reproduce the problem with a very simple project (for example 25fps projet using only one 30 fps clip) ? What do you mean at step 3 : export one segment? Do you mean you render a zone in timeline, then import it in the project ? Then is it a rendering problem ? If you can manage to reproduce the problem with only or or 2 clips and maybe make screenshots, attach the project file or make a screencast that would help me understand.
Hi there. I suspect I am hitting various bugs, and this makes it extra confusing. The problem is in the UI. One bug I can reliably reproduce: Set project to 25 fps. Load a clip that is 30fps. Select a range of say 100 frames of the clip. Export that range, and add it to the project. The exported clip contains about 79 frames, but is still 30fps, so is actually shorter than the segment that was selected from the original clip by 21 frames. I would expect one of either two things: 1. That the original number of frames are exported at 30fps to give the same duration as the selected segment. or 2. That the original duration is preserved at 25fps (which would give less frames) I will describe additional bugs with differing framerates as I am able to reliably reproduce them.
Created attachment 93864 [details] Screenshot that shows the time discrepancy between an exported clip and the range that it was exported from
Right, I managed to reproduce the other, more annoying bug/s too. This time, put the project at 24fps. I loaded a 2.7gb GoPro file, with 12545 frames. This was footage captured at 25fps from a drone flying over a train. I selected two memorable segments, with frame ranges of 7400 - 8000 ( flying over the train from the left) and Frames 8800-9000 ( panning across the town from high up ) And added these two segments to the timeline. Then I loaded a 30fps bit of HD footage that is from my Samsun K-Zoom phone. It's a bit of a helicopter taking off, and is 1916 frames long. At frame 1328 it's just before the rotor wash kicks up some dust. The footage is a little shakey, so I extraced 1328-1916 and added it back to the project. So far, everything is fine. Then I ran the stabilize clip job on the exported range. ( I have attached a screenshot, showing that the exported range is shorter than the range that was selected from the original footage. ) Once the stabilize job completes, and the mlt is added to the project, there is corruption somewhere. The segments on the timeline now show the wrong parts of the footage. The frame numbers are still correct, but it appears that the segment I wanted to display are now at different frames in the original footage. The train segments have moved to 9400-10000 and 11000-11200 and in the helicopter footage the helicopter does not get along as far as it used to, as if the footage was trimmed shorter, even though the clip still has the same number of frames. I manually extended the duration of the helicopter clip in the properties window, and it now appears to have 2394 frames, where it had 1916 frames before. I checked the train footage, and it now has 15679 frames where it had 12545 frames before. So, it would appear that running the stabilize job and adding the .mlt made kdenlive read the footage frames rather than the duration that was time stamped in the footage. (or, put another way, kdenlive now ignores the fps stamped in the footage, and gives me all the frames, rather than dropping the extra frames that come with footage that was shot at a higher framerate. ) Hmm.... I did a little more testing. Here is a quick way to trigger the bug. Load a clip with a framerate that is higher than the current project into the project bin. Take a look at the last frame, and also write down the number of frames reported in the clip properties. Now, load an .mlt file that was created on a framerate that is different from the project framerate. Look at the first clip again. The last frame displayed will now have changed, and if you go into the clip properties you will be able to get more frames by adjusting the last frame in duration under clip properties. If you were to delete the clip out of the project window, and load it again, you will get a new maximum number of frames, almost as if the project's framerate was changed to whatever framerate the .mlt clip was rendered on. Ah, I can reproduce/describe it even more easily. Start kdenlive from fresh, and start a new 24fps project. Load a clip, any clip will do. Take a look at the total number of frames in the clip. Now load a .mlt clip that was rendered on footage that is a different framerate than the projetc is set at. Remove the original clip, and load it again (hitting reload does not work) Take a look at the total number of frames now. It would appear that just loading an .mts file that was rendered on a different framerate sets the framerate of the project. Just noticed, updating the project framerate manually does not update the framerate displayed in the titlebar of the Kdenlive window. Changing the framerate of a project also does not update the number of frames available from each clip, but when the clip is manually removed and added in again, the total number of frames is different. I guess this is not really an area of kdenlive that has seen extensive testing? One other thing.... sometimes I would like to bring in a video clip of a different framerate, but would also like to avoid the pull up/down associated with this, eg on a smooth slow pan of a landscape. What I do normally is use ffmpeg to just use all the frames at the target framerate, speeding up or slowing down the footage by a little. Is there an easy way of achieving the same thing in kdenlive without incurring the losses of re-encoding the footage? Thank you and kind regards, -Evert-
Ok, took some time to look at the problem described in your comment #2, and in fact the problem lies in FFmpeg. The "Extract Zone" feature you are using passes a command to FFmpeg to cut a part of the clip without re-encoding it (by using -vcodec copy option). However, without re-encoding, FFmpeg cannot cut with frame precision, but only at the nearest keyframe in the video file. That's why the cuts are often offset by a few frames / seconds. Not sure how to solve that. We can either tell FFmpeg to re-encode the video, which will give frame accuracy but probably result in a small quality loss. Or we can export an mlt xml that will be frame accurate so can be reused without quality loss in a project. I will now look at the problems described in you last comment. Changing the frame rate of an existing project is generally quite dangerous and very poorly tested. However I can confirm that loading an .mlt file with an fps different from project's fps changes the current project's fps which is a serious problem. working on it...
Git commit 76cf6ed75bf4437e797ae098a980adf562a30810 by Jean-Baptiste Mardelle. Committed on 03/08/2015 at 21:35. Pushed by mardelle into branch 'Applications/15.08'. Use MLT's "consumer" producer instead of "xml" when adding .mlt files to a project so that we don't corrupt project's framerate M +1 -0 src/monitor/monitor.cpp M +1 -1 src/renderer.cpp M +1 -1 src/timeline/track.cpp http://commits.kde.org/kdenlive/76cf6ed75bf4437e797ae098a980adf562a30810
Git commit 70073f5fe8687ff4b28906590ff3591730c1b6f1 by Jean-Baptiste Mardelle. Committed on 03/08/2015 at 21:37. Pushed by mardelle into branch 'master'. Use MLT's "consumer" producer instead of "xml" when adding .mlt files to a project so that we don't corrupt project's framerate M +1 -0 src/monitor/monitor.cpp M +1 -1 src/renderer.cpp M +1 -1 src/timeline/track.cpp http://commits.kde.org/kdenlive/70073f5fe8687ff4b28906590ff3591730c1b6f1
Hi there, thanks for looking into this issue! My use case for the extract zone feature is as follows. It's quite common to let a GoPro record for hours on end, creating quite large files. Then I go through the footage, pick the bits I like, export them, and delete the original file to save on disk space. So, making an mlt would not help much. Also, it's not possible to stabilize an mlt file. I just did a little more testing... I took some footage at 240fps, put it in a 25fps project, and exported a 100frame segment near the end of the clip. The resultant export was of the same length, but slightly moved in time. It seems that there are two ways to proceed here. One would be to pad the exported segment to ensure that all the desired frames are exported. This has the advantages of being fast and no loss of quality, but does not have the exact number of frames as the original selection. I don't suppose it's possible to indicate keyframes on the clip monitor? The other way would be to have ffmpeg re-encode the exact frames. This would be slower, and cause a loss in quality, but have the exact frames. I can confirm that the adding of an .mlt file that was rendered on a different framerate footage does not change the project's framerate anymore.
Did some research, and found out that FFmpeg can give us the keyframes with the following command: ffprobe -select_streams v -show_frames video.mp4 > video.txt This gives a frame by frame detailed view. Then, we can parse the frames to find out which ones have the "pict_type=I" value, which gives us the points where we can cut without re-encoding. Won't be to hard to analyse a clip and get those values in Kdenlive. But now we need to find how to implement this on the UI side to make users understand that they can only export at keyframe points... any hint is welcome. This change won't be in the 15.08 release but we have monthly releases so it can be included in the 15.08.1 if we find a good UI. regards
Hi there. I don't think it's necessary to make changes to the UI for this. I mean, conceptually we could add darker lines on the slider on the clip monitor where the keyframes are, but this seems excessive. Would it not just make sense to cut to the keyframes before and after the selection, and put a tooltip in the UI saying that the exported range of frames will be larger as we can only cut between keyframes? The exported segment can still be trimmed down when it is imported again, and is much better than messing with the UI.
Hi there.... You know, once you have the frame types, just drawing it on top of the clip in the display would not be a bad idea. You know, have either I, P or B running in the upper left corner of the clip. I would definitely go with padding the exported clip to the nearest I-frames. The main advantages of cutting segments like this is the speed and the no loss of quality as there is no re-encoding happening. Having a few extra frames around the selection is not too high a price to pay. As I said earlier, one can always trim down the segment in the clip monitor when it is loaded again, and so no information is lost. Thanks for all the hard work on Kdenlive!
Git commit 8650166a5264d4a41ad7d4e1440bed3d9479c215 by Jean-Baptiste Mardelle. Committed on 05/10/2015 at 23:24. Pushed by mardelle into branch 'master'. * New Clip job: "Analyse keyframes" will add markers for every I-Frame. Requires ffprobe (path must be set in Kdenlive Settings > Environment) Untested with avprobe * Cleanup marker handling * Allow multi-selection in Clip Properties - Makers tab M +17 -1 src/bin/bin.cpp M +1 -0 src/dialogs/kdenlivesettingsdialog.cpp M +7 -0 src/dialogs/wizard.cpp M +6 -1 src/kdenlivesettings.kcfg M +4 -0 src/mainwindow.cpp M +39 -76 src/mltcontroller/clipcontroller.cpp M +6 -6 src/mltcontroller/clippropertiescontroller.cpp M +1 -1 src/monitor/monitor.cpp M +10 -1 src/project/jobs/abstractclipjob.h M +140 -42 src/project/jobs/cutclipjob.cpp M +13 -3 src/project/jobs/cutclipjob.h M +1 -0 src/project/jobs/filterjob.cpp M +4 -5 src/project/jobs/jobmanager.cpp M +53 -43 src/ui/configenv_ui.ui http://commits.kde.org/kdenlive/8650166a5264d4a41ad7d4e1440bed3d9479c215
Hi there. Just tested this feature. I like that I am able to see the I-frames now. Just doing a quick test on cutting a segment... I still lose a few frames before the first I-frame in the segment that I cut, but I do see a few padded frames at the end of the segment. I suppose that I should just manually align the start of the segment with an I-frame. One other thing I thought might be a nice feature would be to have the "clip jobs" submenu that is available in the context menu in the Project Bin also available in the Context menu of the Clip Monitor. In summary, I am happy with the fixes so far. I would like to have had kdenlive automatically pad to the "outside" I-frame at the start of the segment that is being cut, but it's not a really big deal. Somehow this information that cutting a segment will only start at the next I-frame and pad to the I-frame after the segment needs to be made available to the user. Context menu? Also, it might be an idea to add a "Render Zone" to the Submenu, in addition the the "Extract Zone"? Thanks for looking into this, it really is a great help! -Evert-