mpeg streaming delay

[eddyhkim]

Boy, I'm just clogging up the forum today. Couldn't find any mention of this in my search, so probably it's a problem on my end.

Having installed and compiled ffmpeg, I can get streaming mpeg, but it seems to take up to 15 seconds for a real event (my hand waving in front of the camera) to show up on the mpeg streaming view. This is on a lan, and the standard jpeg view is instantaneous. Is this common/expected? Any way to fix it?

And to clarify my understanding of how the system works, the capture daemon is saving the event images as jpeg. The mpeg is only used to generate a stream for viewing/downloading, not for converting existing images to an mpeg file. would converting the existing jpegs to a single video file save disk space? Would it still be possible to use the functions such as the timeline if this was done?

Thanks!
Ed

[jameswilson]

there is a slight delay on mpeg and over time this delay grows, you will read many posts regarding mpeg and montage sync. We established this was a client problem and as yet have no solution.
As all of zm is jpeg based (and i for hope it stays that way) it requires the jpegs and the db for ll functions. You can convert to mpeg and there is a script somewhere for this but you wouldnt be able to browse events from asy current i/f as yet.

Two things i have considered but never acted upon is
a: convert events older than x days to mpeg and delete jpegs
would be a bugger to find an event older than x days but at least i could if i had to

b: (which im thinking of trying but needs some changes to zm(
Convert all events to mpeg. Delete all frames without any motion. (as i use mocord) keep all frames with motion. That way the criticxal bits i need would be in jpeg format but the bulk of stuff could be mpeg to save space

James