Re: [Kdenlive-devel] jack mlt transport sync issues

[Ed R. <ed....@gm...>]

Ok, Ok I see - for me the consumer is MLT too :-))

Thanx for the detailed info. I parsed a little bit in the code. Now it's
clear for me.

I'll try to use the jack consumer with OpenGL. In refactoring we'll be
based on OpenGL
in any case. The current OpenGL implemention in kdenlive is horrible slow.

Perhaps I'll port the shotcuts implementation it works like a swiss knife
so far.


regards

eddrog




2013/5/7 Dan Dennedy <dde...@gm...>

> On Tue, May 7, 2013 at 12:29 PM, Ed Rogalsky <ed....@gm...>
> wrote:
> > Hi Dan,
> >
> > the last days I did a lot of jack transport sync tests and found the
> > following behaviour:
> >
> > For frame rates unequal 25 fps the mlt playback is deverging pretty
> fast. In
> > about 3-5s
> > I get a difference of a frame and so on. Only for 25 fps the mlt playback
> > speed and jack
> > is in sync. And this is curious:
> >
> > I know the mlt - jack clocks are not synchronized => (minor) sync issues
> are
> > expected and if "mlt's
> > clock" is running faster => for all frame rates mlt would play faster.
> Fact
> > is that only fps != 25
> > are faster and this is what I don't understand. I didn't parse the code
> but
> > I think there is something systematic - relative time calculation and
> > optimistic rounding ...???
> >
> > Any ideas?
> >
> >
> > The fact is that the mlt clock is not synced with jack. This would be
> not so
> > critical if the deverging speed would be less or null. For now the
> running
> > transport sync is too bad for use. And this problem is only solveble if
> the
> > two clocks are synced in some way :-((( Or there are some tricks?????
> >
> >
> > BTW: The audio frequecy is 48kHz and I work close together with Robin
> > Gareus. He's implementing the video timeline in ardour3.
> >
> >
> > PS: Do we have a chance to drop frames or "sync speed" based on an
> external
> > clock like jack
> > in mlt? I know adding this is absolutely not trivial :-((
> >
> > regards
> >
> > eddrog
>
> MLT does not have its own clock; the consumer provides the clock. For
> most consumers, that is the audio clock, and the consumer is
> responsible for supplying the correct number of samples over time. The
> consumer uses mlt_sample_calculator() in mlt_frame.c to compute the
> number of samples per mlt_frame object received. This function takes
> fps as a float instead of a rational with both numerator and
> denominator. However, it does not use accumulation; so any rounding
> error only ought to amount to one sample and might be compensated in a
> subsequent call to mlt_sample_calculator.
>
> You can use the jack clock by using the jack consumer. That only
> provides audio output, however, which is fine if you are kdenlive's
> OpenGL display method. If you want to support SDL for video output,
> then you probably need to make a new video-only SDL consumer that
> encapsulates the audio consumer of choice and handles the
> consumer-frame-show mlt_event.
>
> --
> +-DRD-+
>