Full changelog:
4.0.9 - June 15, 2015
Timing is everything and this point release is all about it. So much so that even some core video timing algorithms have been rewritten.
RTSP streams contain timing information, which up until this release, has largely been ignored in favor of a rigid timing mechanism that was better suited for analog devices and AVI files. Now, the software uses this information to more accurately determine the presentation time for each frame. Of course a camera's time clock will not match 100% with your PC, so additional calibration algorithms were required and implemented as well.
Together with RTSP timing and an ideal minimum buffer period, smoother live play should be observed.
The audio stream timing algorithm has also been re-coded with tighter video synchronization in mind.
The BVR audio playback engine used a large buffer with an asynchronous start. Revisions to this algorithm should bring playback delay to less than 50 milliseconds, more inline with what may have been observed through other playback formats.
Delay is often not a good thing, but if you wish to further fine-tune audio/video synchronization, you will find a new Delay setting on the Video tab in camera properties. 50-150 milliseconds may make a big difference if you find audio trails video in web casting etc.
It's no longer optional to use the automatic frame rate adjustment option for network IP cameras, and really should never have been optional. If the FPS setting is lower than the rate at which the camera is sending frames, the decoder does the same amount of work, and frames are dropped. This causes timing problems (there's that word again) especially with recording. If your camera cannot limit its own frame rate and you want to record at another rate, use the "alternate" frame rate setting on the Record tab.