From: Dan Dennedy <dan@de...> - 2007-10-29 02:43:16
Hey, as a result of this bug:
I have determined that MLT and therefore kdenlive is currently broken for any
profile not using 25 fps. By broken, I mean various things related to
editing, particularly in and out points are not working as expected. This
occurred with the introduction of mlt_profile. I have in my MLT working copy
a bugfix that I am testing.
From: Dan Dennedy <dan@de...> - 2007-10-30 06:14:55
On Sunday 28 October 2007, Dan Dennedy wrote:
> Hey, as a result of this bug:
> I have determined that MLT and therefore kdenlive is currently broken for
> any profile not using 25 fps. By broken, I mean various things related to
> editing, particularly in and out points are not working as expected. This
> occurred with the introduction of mlt_profile. I have in my MLT working
> copy a bugfix that I am testing.
I want to document my findings during the analysis.
The framework maintains a "fps" property on all producers including tractor,
multitrack, and playlist, which are derived from producer. This makes "fps"
rather stateful with multiple instances of that state. A feature of
mlt_profile is to eliminate requirement of an environment variable
(MLT_NORMALISATION) as a means of passing parameters. It was a kludge for an
API defficiency. The profile property of mlt_consumer is intended to replace
it as a convenience over having to continually specifying all the profile's
Due to order of initialization, some objects are initialized with default
values, obviously, with the default equivalent to profile dv_pal. Typically,
the consumer is constructed last and connected to the last producer.
Therefore, with fps being stateful and the consumer profile property applied
in a late manner, some timings were based on the initial, default PAL fps
value of 25. Therefore, even with a NTSC-based consumer profile, the edit
points were interpreted with the wrong fps.
The framework does not really use the producer fps property much outside
setting it and propogating it (onto the frame and other producers). The
modules do not use it much either. Moreover, they _never_ set it. In fact,
there is an unofficial policy that a module's producer must conform to the
fps or fail initialization because there is no core module filter to
reconcile frame rate differences (between producers or between producer and
consumer). It just so happens producer_avformat is adaptive to any frame
To fix the bug, I made everything accessing the fps producer property use the
existing mlt_producer_get_fps() instead. Then, I changed
mlt_producer_get_fps() to simply return mlt_profile_fps(). However, really it
should reference the final consumer's fps property as, again, the profile is
merely a convenience to set the consumer property and can be overridden. As a
resolution to the redundant fps property, I totally removed it from the
producer side of the framework and all related modules. Left in its place is
a bunch of calls to mlt_producer_get_fps().
Perhaps some day we should require every producer to set its fps and then
allow a filter to reconcile differences. Similar to how fezzik "normalises"
resolution and audio sample rate, it could automatically add a framerate
normalisation filter. The core module could have a duplicate/drop algorithm
and motion_est could provide one as well. In some cases,
mlt_producer_get_fps() calls should be replaced with a mlt_consumer_get_fps(
However, this bug also brings to light an issue if I change the consumer's fps
after editing. For example, I may want a low bitrate encoding with a lower
frame rate. Since all edit decisions are expressed in frames, they are no
longer valid at the lower frame rate.
All of this was not a major issue for the original requirements (ITU 601 NTSC
or PAL for SD broadcast) since each installation tended to pick one of the
two options and stick with it for all inputs and outputs.