Workaround for superfast event replay speed

[glenm]

A disclaimer at the start: I'm brand new to zoneminder, so the problems I encounter could be because I'm a noob. Second disclaimer: to work around shared memory issue, I'm running against Nov 21 2015 HEAD. So my problems may not be your problems. Though I don't see evidence in Git that this code has changed for a bit.

Those points said, I have been having a problem with event replay speed. A 3 minute event could replay in 18 seconds. Wonderful on those days I'm time crunched. Not so good for comprehension.

I had a look at the code for zms, and in particular, EventStream::runStream() in zm_event.cpp, I think the way time_to_event is being calculated may not be right. I'm not use I understand everything this piece of code is trying to achieve. But previously it seemed to calculate the time from the start of the event to the next display frame, and I think what it wanted was time from the previous display frame to the next. It seems to use this time to determine how long to wait before sending the next frame. Apologies to the authors if I've completely misunderstood the point.

In any event, the change below helps in my case. Event replay forward and backward is working at a more accurate speed. There is still a problem with the display rate being inconsistent, some frames are fast and others slow giving a jumpiness to the video, but at least the duration on playback approximates the duration of the real event.

I hope no-one else is having the same problem as me, but if you are and this helps, awesome.

glen

Code: Select all

--- zm_event.cpp.orig   2015-11-24 20:58:46.000000000 -0800
+++ zm_event.cpp        2015-11-25 10:15:40.000000000 -0800
@@ -1389,13 +1389,13 @@
             double time_to_event = 0;
             if ( replay_rate > 0 )
             {
-                time_to_event = event_data->frames[0].timestamp - curr_stream_time;
+                time_to_event = event_data->frames[curr_frame_id-1].timestamp - curr_stream_time;
                 if ( time_to_event > 0 )
                     in_event = false;
             }
             else if ( replay_rate < 0 )
             {
-                time_to_event = curr_stream_time - event_data->frames[event_data->frame_count-1].timestamp;
+                time_to_event = curr_stream_time - event_data->frames[curr_frame_id-1].timestamp;
                 if ( time_to_event > 0 )
                     in_event = false;
             }

[timcraig]

Yes, the fast forward and rewind code in Zoneminder has some erroneous calculations in it. I've found the WEB_H_VIDEO_MAXFPS, WEB_M_VIDEO_MAXFPS or WEB_L_VIDEO_MAXFPS setting (depending on which performance profile your using) effects the replay speed. If the *_MAXFPS is close to the same of our vidoe's FPS the problem goes away, setting is not close to your video's fps (in the case if you have different camers that records at different FPS), then you see the problem. The problem started around 1.24, before the fastforward/rewind feature worked pretty well, afterwards, the speeds were out of wack and the video skipped frames instead of actually speeding up the framerate.

I created this patch on the older system
viewtopic.php?f=9&t=13447&p=51436&hilit=fast#p51436

Others have complained about the issue and said my patch helped fix the problem.

Which fixed the behavior, but a overall refactoring on the zm_monitor code is needed because a lot of the FPS calculations don't make sense (I made notes on what the different variables on the code seem to mean).


Long story short, IMO you are correct that is a issue with the replay speeds. The problem seems to only occur when your have a MAX_FRAMERATE setting that doesn't match your camera's FPS. So not everyone sees the issue.