Re: [Mlt-devel] [Kdenlive-devel] Big Kdenlive update

[Zachary D. <zac...@gm...>]

Can you comment on where you were going with the DOUBLE_MLT_POSITION define?
>

I was experimenting with giving MLT slow playback by using the speed
property. For example, at half speed the frame progression would be 0, 0.5,
1, 1.5, 2, 2.5... One of producer_slowmotion's modes literally creates
intermediate frames, such as frame 1.5.

I ended up taking a different approach with producer_slowmotion in the end
and keeping an internal representation of speed.

Zach


>
>
> >
> >
> > On Jan 25, 2008 11:37 PM, Dan Dennedy <da...@de...> wrote:
> >
> > >  2008/1/24 Zachary Drew <zac...@gm...>:
> > >
> > > >
> > > > On Jan 24, 2008 1:59 AM, Dan Dennedy <da...@de...> wrote:
> > > >
> > > > As alluded to in a previous email on the MLT list, while the above
> > > > > changes are critical fixes, if one tries to alter framerate on render, then
> > > > > the edit points get screwed up. To fix that, I will be changing mlt_position
> > > > > to represent time (something like microseconds) instead of frames.
> > > > >
> > > >
> > > > This sounds like progress! However, some of my MLT code relies on
> > > > frame number to determine:
> > > >
> > > > 1. If the playback is paused
> > > > 2. If the playback direction has changed
> > > > 3. If a frame was skipped
> > > > 4. Possibly other things, I need to review my code to be sure
> > > >
> > > > The obvious problem is #3. Do you have any thoughts on this?
> > > >
> > > > Also, you should probably start a discussion MLT about these
> > > > changes.
> > > >
> > >
> > > Moving this to mlt-devel now.
> > >
> > > I have to do a lot of analysis to understand the impact and
> > > implications. I have to spend more time now to finishing up the big change I
> > > have in my working copy before embarking on that. However, my initial
> > > thought is that you can always derive a frame number from a time and fps.
> > > The pending change makes it very easy to access the current profile and its
> > > properties (including fps) from just about anywhere.
> > >
> > > I think the points you raise above are about relative time and
> > > independent of fps. The point of the change is to fix the absolute and
> > > declarative times. As an illustration of the problem, setting in and out
> > > properties today makes an assumption about the fps. However, in the case of
> > > a westley file, there is nothing that even indicates what the current
> > > profile and fps are. Furthermore, adding that would just make it less
> > > flexible.
> > >
> > > For a long time, Kino only dealt with frame numbers. Since Kino was
> > > restricted to NTSC or PAL and people tended to stick to one or the other, it
> > > was not a big deal. I added the time capability for the sake of UI and to
> > > support compliant SMIL time values in the project file. However, the
> > > addition of time to Kino was mainly a surface level thing. Internally, it
> > > still uses frame numbers. The time widgets translate everything into frame
> > > number based on the project's fps. Also, the SMIL time values in the project
> > > file are just translations done during (de)serialization. The drawback is
> > > that rendering is always done at full frame frame even though you may intend
> > > to export to a lower frame rate.
> > >
> > > MLT is different and the time handling can not just be surface level.
> > > First of all, it has an API that deals a lot with time--whether it admits it
> > > or not. It just currently places the burden of converting between time and
> > > frames on the application (or its user) just as I had to do with Kino. MLT
> > > needs to bite the bullet and admit to itself that it really is dealing with
> > > time and not just frames. A true time-based interface makes the framework
> > > easier and more attractive. Moreover, I had considered leaving it as is,
> > > doing all processing at full frame rate, and then just adding frame rate
> > > adjustment at the consumer. However, more often than not, one is reducing
> > > frame rate, and it is wasteful to process frames that will just be
> > > discarded.
> > >
> >
>