<div dir="ltr">Hi Dan,<div><br></div><div style>the last days I did a lot of jack transport sync tests and found the following behaviour:</div><div style><br></div><div style>For frame rates unequal 25 fps the mlt playback is deverging pretty fast. In about 3-5s</div>
<div style>I get a difference of a frame and so on. Only for 25 fps the mlt playback speed and jack</div><div style>is in sync. And this is curious:</div><div style><br></div><div style>I know the mlt - jack clocks are not synchronized => (minor) sync issues are expected and if "mlt's</div>
<div style>clock" is running faster => for all frame rates mlt would play faster. Fact is that only fps != 25</div><div style>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 ...???</div>
<div style><br></div><div style>Any ideas?<br></div><div style><br></div><div style><br></div><div style>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?????</div>
<div style><br></div><div style><br></div><div style>BTW: The audio frequecy is 48kHz and I work close together with Robin Gareus. He's implementing the video timeline in ardour3.</div><div style><br></div><div style>
<br></div><div style>PS: Do we have a chance to drop frames or "sync speed" based on an external clock like jack </div><div style>in mlt? I know adding this is absolutely not trivial :-((</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 style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div></div>