Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#16 A/V sync problems with delayed encoding under full load

open-accepted
nobody
5
2009-05-06
2008-04-12
RA
No

Hello,
thanks for this great program! :-)

There is a small problem when --on-the-fly-encoding is *not* used: Audio/video sync is lost in the case that I capture a large area of the screen and a lot of changes happens (e.g. scrolling up and down a large web page).

I suspect that the sync problem occurs once the machine can no longer keep up compressing all the screen updates to the temporary file. When viewing the encoded .ogv later, the symptom is that at the end of the clip, the audio stream is already done while video is still playing.
(This is strange; I'd expect video frames to get lost, which would mean that the video would be finished before the audio, but the opposite is the case!)

With --on-the-fly-encoding, A/V sync is fine.

Cheers, Richard

Discussion

    • status: open --> open-accepted
     
  • Logged In: YES
    user_id=1585344
    Originator: NO

    Hi,

    >> (This is strange; I'd expect video frames to get lost,
    >> which would mean that the video would be finished before
    >> the audio, but the opposite is the case!)

    This problem has to do with the fact that recordMyDesktop can
    only compensate for lost video frames, while it completely
    ignores sound loss.
    When using the cache mechanism, every lost frame gets compensated
    (by duplicating previous ones), so the video stream has the actual
    duration, while when encoding on the fly some video is lost, too and
    the streams appear to have the same duration.

    While this bug is valid and it indicates obvious deficiencies in
    recordMyDesktop's a/v sync, it is also possible to avoid the problem
    by choosing better settings, that will help you avoid excessive
    sound drops (check the following post for more on this:
    https://sourceforge.net/forum/message.php?msg_id=4582228 )

    I'm leaving this bug-report open, but to be honest, designing
    a more safe cache mechanism and compensating better for the loss,
    would take more time than I currently have, so it might be some
    time before there's any progress.

    Thanks,
    John.-

     
    • assigned_to: iovar --> nobody