|Anonymous | Login||2016-07-27 11:50 CEST|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002659||Kdenlive||Rendering||public||2012-06-25 21:11||2014-11-17 08:34|
|Platform||compaq cq40 intel dual core||OS||debian wheezy||OS Version||64bit|
|Target Version||Fixed in Version|
|Summary||0002659: MTS clips don't join smoothly when rendered|
|Description||using profile (correct one) HD 1080p 50fps with my MTS clips|
after rendering the project the video has milli-second pauses where the clips joined, so it doesn't play smoothly.
I rendered projects in Ubuntu last year from same video camera with no such problem.
I understand that in editing the MTS files there can be delayed response in starting a clip, but in rendering surely there shouldn't be delays written to file.
any help would be much appreciated
|Steps To Reproduce||1.make a project with clips of 1080p mts|
2.render to mpeg, vob, or mpeg4
3.play the resulting file
4.notice that certain places (=clip joins) get a very short pause before proceeding
5.disdain to continue with hours of rendering when the results are like this
|Tags||No tags attached.|
|Build/Install Method||Distribution package|
edited on: 2012-08-08 16:12
when I said milli-seconds, technically it must be 100-200 ms 1/10-1/5th sec or so at the end of a clip before the next starts.
which would equal 5 to 10 frames
edited on: 2012-07-12 22:34
OK I'm trying to TRANSCODE mts files before getting to the edit stage -
can confirm that trancoding to DNxHD in Kdenlive and then rendering the .mov files the result is very smooth. [edit: the joins]
Edit: the video quality after using 120Mbps DNxHD however was not pleasing at all.
edited on: 2012-07-16 17:37
Aha, I demux with MKV and the result ...
the joins are smoother. but I noticed after more careful observation, and encoding at a lower bps (to eliminate my cpu as culprit), that the resulting movie is jumpy -that's multiple mts clips demuxed with mkv, then rendered as project to any format..
edited on: 2012-07-17 06:01
I've just built ffmpeg, melt and kdenlive from source
still get pauses at clip joins
going to convert clips to mpeg2 first before rendering the project
@orbspider, when you say 'pauses', I assume you mean 'not gaps' just pause at start of MTS clip.
I am having this problem and the culprit (for me) is that the first two or three frames are all the same (a copy of the first frame). Check your's. Just put the timeline cursor just before the clip, with the mouse in the Project Monitor, centre mouse wheel up one click to get the first frame and then again to get the second, see if the frame changes (moves).
Just want to know if we have the same problem. Cheers.
edited on: 2012-08-09 08:44
Hello, thanks for pointing out your problem with frames.
At first I thought you had a different issue, but on further testing i can confirm that some clips have frozen frames or a group of frames the same at the start.
so these need trimming off (but when I do the render is still bad, it judders at each clip where frames were cut)
most of my clips have same frames at the end too. kdenlive doesn't like my mts files??
I've tried converting the mts files to 100Mb mpeg2 (not a lossless format as that just eats my hard disk)
rendering clips produces seamless joins, but the video (even @18Mb mpeg2) is blocky when close up to it.
edited on: 2012-08-20 12:02
Converting the MTS files to mpeg2 I-frame gave good results -just with files of 20x orig. file size!
I'm trying converting to m2ts now (as my Panasonic bundled software used to do that) and going from there.
So far perfect results. And only 3x file size increase with 40Mb m2ts.
something just did not like working with the MTS files, seeing the end and sometimes start frames frozen [while decompressing?].
btw my ffmpeg script [for m2ts] is
for file in *.MTS; do `ffmpeg -i $file -acodec mp2 -f mpegts -vcodec mpeg2video -s 1440x1080 -vb 85000k -g 12 -trellis 1 $file.m2ts`;done
Although the m2ts files are equal Q with the original mts files, rendering in kdenlive causes unfortunate Q loss (even from hdv 1440i 25fps profile to h264 12M format).
I can confirm this issue as a rather new one.
I have been pulling kdenlive and mlt from git, and this issue popped up in the last month or so.
ffmpeg is at the lastest released version, too.
At scene changes in the rendered output it appears as if the image "freezes" for a few frames. It's a bit jarring, to say the least.
Proxy clips do not show this issue, and it's only when one plays the finally rendered output that it shows up.
Video footage was taken with Panasonic TM-900, full HD, 50fps.
I often have this issue with HDV clips.
Here my sample project:
Sample result video with freeses between clips: https://dl.dropbox.com/u/59794362/kdenlive-hdv-join-bug/freeze-between-clips.ogv [^]
Project archive: https://dl.dropbox.com/u/59794362/kdenlive-hdv-join-bug/hdv-freezes-between-clips.tar.gz [^] (212 Mb)
Kdenlive git a5ed66fd260bcc20061792f3b9df2eda81f682b7 (latest for now)
MLT git 004c3048073809a883369049bfd270b24a8076b1 (latest for now)
Arch linux x86_64
I have had this for a very long time and now just accept my work-around as the normal thing to do.
All my HD clips have at least two tail end frames the same, but when you make a proxy, it is correct, without the matching frames. I can prove this by disabling the proxy and looking at the clip in the timeline. The thumbnail moves up a few frames. Your Project plays great when watching the proxies but of course it renders with the HD clips.
So, for straight clip change (no transition) I ALWAYS overlap the previous clip by about 3 to 4 frames, especially when using proxies because you do not know if the problem exists.
Sometimes you can render through proxy clips as workaround (with high quality proxy profile).
But in my case an interlaced and progressive clips has been in my project. So I need two types of proxy clips. Is there a way to tell kdenlive use differend proxy profiles for each file type or clip properties?
@zuf, you can load all the clips of format A with proxy clip encoding profile X (click on the (i) button in Project Profile to set)
then make a new project and load all the clips of format B with proxy profile Y set
then load all the A clips again and their proxies are auto-loaded as have already been made. should work, though I've not tested it.
@norm, I just realised that to overlap clips you need the "overwrite" mode selected with the button at bottom. I was thinking, how does he overlap clips, on lots of tracks or what?
Well, exciting news, a new camera, a render, and changes between clips are sharp, 99.8% or better. prob a better micro processor in the camera.
only there's a little audio fuzz at joins sometimes but that's another thing..
Well, its over a year on, and with a new desktop and a stable version of kdenlive.
I put some mts clips together, HD 50fps, and I got some very small amount of pausing (same frozen frames) at the joins. And note, these freezes are not always at the *end* of clips because I made cuts and moved the next clip up to close space. So it seems to me that MLT sees the "end" of a clip and there we get a freeze.
Overlapping the end of the clip is the best way to eliminate this issue. By overlapping every clip the resulting film has no pausing at all. But, after that, there is some audio artifact where new clips start :(
I encountered this bug on some clips when switching from libav to ffmpeg, so this seems to be a decoder seeking problem.
For me, problem occurs at clip start, the 1st frame being duplicated (checked by stepping frame by frame with right key around a problematic transition).
|2012-06-25 21:11||orbspider||New Issue|
|2012-06-26 21:17||orbspider||Note Added: 0008140|
|2012-07-05 07:23||orbspider||Note Added: 0008153|
|2012-07-09 10:04||orbspider||Note Added: 0008156|
|2012-07-11 18:46||orbspider||Note Edited: 0008156||View Revisions|
|2012-07-12 22:34||orbspider||Note Edited: 0008153||View Revisions|
|2012-07-16 17:37||orbspider||Note Edited: 0008156||View Revisions|
|2012-07-16 17:40||orbspider||Note Added: 0008163|
|2012-07-16 17:59||orbspider||Note Edited: 0008163||View Revisions|
|2012-07-17 06:01||orbspider||Note Edited: 0008163||View Revisions|
|2012-07-21 12:04||norms2||Note Added: 0008165|
|2012-08-08 09:35||orbspider||Note Added: 0008192|
|2012-08-08 10:40||orbspider||Note Added: 0008193|
|2012-08-08 10:44||orbspider||Note Edited: 0008193||View Revisions|
|2012-08-08 16:07||orbspider||Note Edited: 0008192||View Revisions|
|2012-08-08 16:09||orbspider||Note Edited: 0008193||View Revisions|
|2012-08-08 16:12||orbspider||Note Edited: 0008140||View Revisions|
|2012-08-09 07:58||orbspider||Note Deleted: 0008193|
|2012-08-09 08:30||orbspider||Note Added: 0008194|
|2012-08-09 08:42||orbspider||Note Edited: 0008194||View Revisions|
|2012-08-09 08:44||orbspider||Note Edited: 0008192||View Revisions|
|2012-08-20 11:46||evorster||Note Added: 0008204|
|2012-08-20 12:02||orbspider||Note Edited: 0008194||View Revisions|
|2012-12-16 16:54||Zuf||Note Added: 0008803|
|2012-12-17 15:26||norms2||Note Added: 0008822|
|2012-12-18 08:29||Zuf||Note Added: 0008829|
|2013-01-19 15:17||orbspider||Note Added: 0009109|
|2013-05-19 19:59||orbspider||Note Added: 0009562|
|2014-10-31 13:44||orbspider||Note Added: 0010459|
|2014-11-17 08:34||vpinon||Note Added: 0010470|
|Copyright © 2000 - 2016 MantisBT Team|