<div dir="ltr">Ok, Ok I see - for me the consumer is MLT too :-))<br><div><br></div><div style>Thanx for the detailed info. I parsed a little bit in the code. Now it's clear for me.</div><div style><br></div><div style>
I'll try to use the jack consumer with OpenGL. In refactoring we'll be based on OpenGL</div><div style>in any case. The current OpenGL implemention in kdenlive is horrible slow.</div><div style><br></div><div style>
Perhaps I'll port the shotcuts implementation it works like a swiss knife so far. </div><div style><br></div><div style><br></div><div style>regards </div><div style><br></div><div style>eddrog</div><div style><br></div>
<div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/7 Dan Dennedy <span dir="ltr"><<a href="mailto:ddennedy@gmail.com" target="_blank">ddennedy@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Tue, May 7, 2013 at 12:29 PM, Ed Rogalsky <<a href="mailto:ed.rogalsky@gmail.com">ed.rogalsky@gmail.com</a>> wrote:<br>
> Hi Dan,<br>
><br>
> the last days I did a lot of jack transport sync tests and found the<br>
> following behaviour:<br>
><br>
> For frame rates unequal 25 fps the mlt playback is deverging pretty fast. In<br>
> about 3-5s<br>
> I get a difference of a frame and so on. Only for 25 fps the mlt playback<br>
> speed and jack<br>
> is in sync. And this is curious:<br>
><br>
> I know the mlt - jack clocks are not synchronized => (minor) sync issues are<br>
> expected and if "mlt's<br>
> clock" is running faster => for all frame rates mlt would play faster. Fact<br>
> is that only fps != 25<br>
> are faster and this is what I don't understand. I didn't parse the code but<br>
> I think there is something systematic - relative time calculation and<br>
> optimistic rounding ...???<br>
><br>
> Any ideas?<br>
><br>
><br>
> The fact is that the mlt clock is not synced with jack. This would be not so<br>
> critical if the deverging speed would be less or null. For now the running<br>
> transport sync is too bad for use. And this problem is only solveble if the<br>
> two clocks are synced in some way :-((( Or there are some tricks?????<br>
><br>
><br>
> BTW: The audio frequecy is 48kHz and I work close together with Robin<br>
> Gareus. He's implementing the video timeline in ardour3.<br>
><br>
><br>
> PS: Do we have a chance to drop frames or "sync speed" based on an external<br>
> clock like jack<br>
> in mlt? I know adding this is absolutely not trivial :-((<br>
><br>
> regards<br>
><br>
> eddrog<br>
<br>
</div></div>MLT does not have its own clock; the consumer provides the clock. For<br>
most consumers, that is the audio clock, and the consumer is<br>
responsible for supplying the correct number of samples over time. The<br>
consumer uses mlt_sample_calculator() in mlt_frame.c to compute the<br>
number of samples per mlt_frame object received. This function takes<br>
fps as a float instead of a rational with both numerator and<br>
denominator. However, it does not use accumulation; so any rounding<br>
error only ought to amount to one sample and might be compensated in a<br>
subsequent call to mlt_sample_calculator.<br>
<br>
You can use the jack clock by using the jack consumer. That only<br>
provides audio output, however, which is fine if you are kdenlive's<br>
OpenGL display method. If you want to support SDL for video output,<br>
then you probably need to make a new video-only SDL consumer that<br>
encapsulates the audio consumer of choice and handles the<br>
consumer-frame-show mlt_event.<br>
<br>
--<br>
+-DRD-+<br>
</blockquote></div><br></div>