On Fri, Feb 25, 2011 at 7:46 AM, jb wrote:
> On Thursday 24 February 2011 01:42:04 Dan Dennedy wrote:
>> What do you think; should speed be a factor of the clip's rate or the
>> project's rate?
>>
>> http://sourceforge.net/tracker/?func=detail&aid=3188942&group_id=96039&atid
>> =613414
>
> Yes, I
On Thursday 24 February 2011 01:42:04 Dan Dennedy wrote:
> What do you think; should speed be a factor of the clip's rate or the
> project's rate?
>
> http://sourceforge.net/tracker/?func=detail&aid=3188942&group_id=96039&atid
> =613414
Yes, I think we need to change that to make the slowmotion r
If I understand correctly that in the first example the replay speed
was 1/4 after setting a speed factor of 1/2, then I'd agree that it
should be relative to the clip rate.
2011/2/24 Gabriel Gazzán :
> I guess relative to clip's rate is what a user would expect...
>
> g
>
>
>
> 2011/2/23 Dan Denn
I guess relative to clip's rate is what a user would expect...
g
2011/2/23 Dan Dennedy
> What do you think; should speed be a factor of the clip's rate or the
> project's rate?
>
>
> http://sourceforge.net/tracker/?func=detail&aid=3188942&group_id=96039&atid=613414
>
> --
> +-DRD-+
>
>
>
What do you think; should speed be a factor of the clip's rate or the
project's rate?
http://sourceforge.net/tracker/?func=detail&aid=3188942&group_id=96039&atid=613414
--
+-DRD-+
--
Free Software Download: Index, Searc
On Thu, Nov 26, 2009 at 02:26:12PM -0800, Dan Dennedy wrote:
> One of the things I claimed to do for this next release in a bug
> ticket or forum post was to add an override for the ffmpeg's detected
> frame rate. I will work on that after I finish up this VDPAU support,
> which should be done in a
On Thu, Nov 26, 2009 at 4:32 AM, Mikko Rapeli wrote:
> On Thu, Nov 26, 2009 at 04:11:14AM -0800, Dan Dennedy wrote:
>> > Could the speed effect be applied to the original file with original fps
>> > and convert to project p30 after playing faster/slower?
>>
>> Sorry, not in the near term. Currentl
On Thu, Nov 26, 2009 at 02:32:50PM +0200, Mikko Rapeli wrote:
> Maybe this would do it:
>
> $ ffmpeg -i orig.mp4 -vcodec copy -acodec copy -r 30 -ar 22050 test.mp4
>
> Or maybe not, since mplayer trust the codec frame rate, though ffmpeg
> and ffplay only complain:
Kdenlive uses the rate in the
Mikko,
Does the camera create an XML file with data in it, along with the MP4? If
it does can you post it for me? i'm just curious :)
Thanks,
-Tim
On Thu, Nov 26, 2009 at 6:11 AM, Dan Dennedy wrote:
> On Wed, Nov 25, 2009 at 2:27 PM, Mikko Rapeli wrote:
> > Hello again,
> >
> > I have a prob
On Thu, Nov 26, 2009 at 04:11:14AM -0800, Dan Dennedy wrote:
> > Could the speed effect be applied to the original file with original fps
> > and convert to project p30 after playing faster/slower?
>
> Sorry, not in the near term. Currently, non-speed-effect frame rate
> handling is done within th
On Wed, Nov 25, 2009 at 2:27 PM, Mikko Rapeli wrote:
> Hello again,
>
> I have a problem with speed effect once again.
>
> My project is 720p30 in kdenlive and my material is 720p60. If I use
> speed effect to play at 50% I get 720p15 instead of expected 720p30.
> It appears kdenlive first renders
On Wed, Nov 25, 2009 at 10:45:03PM +, t...@filmchicago.org wrote:
> Miko, I'm not a kdenlive expert but I know certain formats very well.
>
> What camera/deck was the clip recorded with? EX1?
GoPro HD helmet camera.
-Mikko
Miko, I'm not a kdenlive expert but I know certain formats very well.
What camera/deck was the clip recorded with? EX1?
--Original Message--
From: Mikko Rapeli
To: kdenlive-devel@lists.sourceforge.net
ReplyTo: For kdenlive developers
Subject: Re: [Kdenlive-devel] speed effect
Sent
On Thu, Nov 26, 2009 at 12:27:38AM +0200, Mikko Rapeli wrote:
> Sample p60 clip is here:
> http://mcfrisk.kapsi.fi/linux/video/gopro_hd_hero/GOPR0007_720p60.MP4
Here's a sample output of p60 clip playing at 50% in a p30 project:
http://mcfrisk.kapsi.fi/media/2009/kdenlive_p60_to_p15.mp4
-Mikko
On Thu, Nov 26, 2009 at 12:27:38AM +0200, Mikko Rapeli wrote:
> speed effect to play at 50% I get 720p15 instead of expected 720p30.
With p15 I mean p15 frames doubled, every fram twice, to p30 in the
rendered product.
-Mikko
--
Hello again,
I have a problem with speed effect once again.
My project is 720p30 in kdenlive and my material is 720p60. If I use
speed effect to play at 50% I get 720p15 instead of expected 720p30.
It appears kdenlive first renders input clips to project setting p30 and
then applies speed effect
On Friday 02 October 2009 14.36:24 Mikko Rapeli wrote:
> Just tried reproducing other bugs and noticed that I can't move a clip
> to the end of another clip, both using speed effect.
> kdenlive(4577) Render::mltMoveClip: // LOOKING FOR CLIP TO MOVE,
> INDEX: 2
> kdenlive(4577) Render::mltMove
Hello,
im just wondering, why is the speed effect implemented as a video
processing effect, instead of a movie playing clip parameter?
It seems a lot easier to just increase the current frame pointer by a
lower amount when fetching frames instead of doing some kind of magic
when processing input
Just tried reproducing other bugs and noticed that I can't move a clip
to the end of another clip, both using speed effect.
Project is file attached. This show up in log:
kdenlive(4577) Render::mltMoveClip: // LOOKING FOR CLIP TO MOVE,
INDEX: 2
kdenlive(4577) Render::mltMoveClip: // ERROR M
On Wednesday 23 September 2009 09.02:42 Mikko Rapeli wrote:
> On svn3925, fade to black preview broke on a clip with also speed and old film
> effects active. Also unchecking the speed effect changed the clip
> out position on time line without the possibility to undo that change.
I think these is
On Wed, Sep 23, 2009 at 10:02:42AM +0300, Mikko Rapeli wrote:
> On svn3925, fade to black preview broke on a clip with also speed and old film
> effects active.
The clips also have a dissolve transition on at the same time with fade
to black. Plain fade to black later in same project seems to work
On svn3925, fade to black preview broke on a clip with also speed and old film
effects active. Also unchecking the speed effect changed the clip
out position on time line without the possibility to undo that change.
I think that the time line should be more protected from unintentional
changes but
On Tuesday 22 September 2009 14.32:47 Mikko Rapeli wrote:
> Not speed related yet, but can't see my transitions anymore on timeline with
> svn3915. The preview shows them ok.
Fixed.
jb
--
Come build with us! The BlackB
On Tue, Sep 22, 2009 at 09:19:55AM +0100, jb wrote:
> Should be fixed now in svn, with several other speed related issues.
> Please update & let me know if you find any other issue with the speed effect.
Not speed related yet, but can't see my transitions anymore on timeline with
svn3915. The prev
On Friday 18 September 2009 13.58:32 Mikko Rapeli wrote:
> Just noticed that moving all clips on timeline back and forth --
> actually adding a title clip to the beginning -- messed up
> at least the first clip on time line with speed effect set to
> 1000%. The in and out markers seem to have moved
Just noticed that moving all clips on timeline back and forth --
actually adding a title clip to the beginning -- messed up
at least the first clip on time line with speed effect set to
1000%. The in and out markers seem to have moved, or maybe something
didn't move but should have since a clip
jb wrote:
> We are trying to do so when we release a new Kdenlive version. However we
> have currently no efficient way to test for regressions, so it is far from
> perfect.
What about Unit Testing?
http://doc.qtsoftware.com/4.5/qtestlib-manual.html
Would this be possible?
Simon
--
Ah, here it is. I didn't do a make install, simply compiled it and run gdb
src/cmake_bindir/kdenlive. Puh :)
jb wrote:
> On Wednesday 29 July 2009 23:06:16 Simon Eugster wrote:
>> Where is the speed effect now? I cannot find it (r3778). Wasn't at
>> /dev/null either.
>
> It should be listed wit
On Thu, Jul 30, 2009 at 12:38:45AM +0200, jb wrote:
> We are trying to do so when we release a new Kdenlive version. However we
> have currently no efficient way to test for regressions, so it is far from
> perfect.
Shit happens, regressions are fine. Just the big ones like speed and
titler effe
On Thursday 30 July 2009 00:27:08 Mikko Rapeli wrote:
> Is it possible to make speed, titler etc. changes compatible with
> existing project files?
>
> I'm dreaming of automatic conversion of kdenlive projects, but an on-my-face
> warning after opening the project and a clearly marked clip on time
Is it possible to make speed, titler etc. changes compatible with
existing project files?
I'm dreaming of automatic conversion of kdenlive projects, but an on-my-face
warning after opening the project and a clearly marked clip on time line
would suffice. Finding out by accident that rendering fail
On Wednesday 29 July 2009 23:06:16 Simon Eugster wrote:
> Where is the speed effect now? I cannot find it (r3778). Wasn't at
> /dev/null either.
It should be listed with all other effects, in the "Effect List" widget...
don't you have it?
jb
Where is the speed effect now? I cannot find it (r3778). Wasn't at
/dev/null either.
Simon
jb wrote:
> On Sunday 26 July 2009 23:06:50 Dan Dennedy wrote:
>> Should we remove the Speed effect from the Effects List? correct me if
>> wrong, but it does not work because it requires the special produ
On Sunday 26 July 2009 23:06:50 Dan Dennedy wrote:
> Should we remove the Speed effect from the Effects List? correct me if
> wrong, but it does not work because it requires the special producer,
> but I don't know if you are trying to do some special case handling on
> this filter.
Please leave i
Should we remove the Speed effect from the Effects List? correct me if
wrong, but it does not work because it requires the special producer,
but I don't know if you are trying to do some special case handling on
this filter.
--
+-DRD-+
-
35 matches
Mail list logo
