MJPEG vs MPEG for low bandwidth and CPU
MJPEG vs MPEG for low bandwidth and CPU
Hello!
What is better MJPEG or MPEG for very slow and expensive IP cameras internet connection (56 kbit/s for each camera, traffic is limited) and for low CPU usage on ZoneMinder server (about 200 cameras on one server)?
What is better MJPEG or MPEG for very slow and expensive IP cameras internet connection (56 kbit/s for each camera, traffic is limited) and for low CPU usage on ZoneMinder server (about 200 cameras on one server)?
Re: MJPEG vs MPEG for low bandwidth and CPU
200 cameras on one server, seriously?
MPEG whilst it does use less bandwidth, uses more cpu as it needs to call ffmpeg to convert to jpg before zm touches it. Mjpeg is just a straight frame grab from a stream.
MPEG whilst it does use less bandwidth, uses more cpu as it needs to call ffmpeg to convert to jpg before zm touches it. Mjpeg is just a straight frame grab from a stream.
-
- Posts: 678
- Joined: Wed Dec 16, 2009 4:32 pm
- Location: Israel
Re: MJPEG vs MPEG for low bandwidth and CPU
Not entirely true.Flasheart wrote:200 cameras on one server, seriously?
MPEG whilst it does use less bandwidth, uses more cpu as it needs to call ffmpeg to convert to jpg before zm touches it. Mjpeg is just a straight frame grab from a stream.
For MJPEG, ZoneMinder uses libjpeg (or libjpeg-turbo) to decompress (convert into one of ZM's native formats, e.g. RGB24) the JPEG image. For a MPEG, ZoneMinder uses ffmpeg to extract frames out of the stream, and also for converting these frames into one of ZM's native formats, e.g. RGB24.
mastertheknife
Kfir Itzhak.
Re: MJPEG vs MPEG for low bandwidth and CPU
Ah, I didn't realise that. Have you done any tests to see which is faster?
Re: MJPEG vs MPEG for low bandwidth and CPU
concur +mastertheknife.
Switching from MJPG to MPEG/H.264 *significantly* reduces bandwidth and CPU load.
Switching from MJPG to MPEG/H.264 *significantly* reduces bandwidth and CPU load.
-
- Posts: 4
- Joined: Wed Jun 22, 2011 4:02 pm
Re: MJPEG vs MPEG for low bandwidth and CPU
So what abot H.264 (in comparison to mpeg4) would that be more expensive for the CPU? Or does that not really make a difference?
Re: MJPEG vs MPEG for low bandwidth and CPU
Mpeg is a container
h.264 is codec
The codec goes inside the container.
h.264 is codec
The codec goes inside the container.
Re: MJPEG vs MPEG for low bandwidth and CPU
How to eliminate the delay of the data stream using MPEG? Over time the data stream is getting late. Sometimes reaches more than 1 minute late. MJPEG is practically in real time.
-
- Posts: 678
- Joined: Wed Dec 16, 2009 4:32 pm
- Location: Israel
Re: MJPEG vs MPEG for low bandwidth and CPU
Don't limit the fps.gblanco wrote:How to eliminate the delay of the data stream using MPEG? Over time the data stream is getting late. Sometimes reaches more than 1 minute late. MJPEG is practically in real time.
mastertheknife
Kfir Itzhak.
Re: MJPEG vs MPEG for low bandwidth and CPU
I use NORMAL CAMERAS (NOT IP)... The data stream is not in real time after a while. It seems to me that there is a buffer.mastertheknife wrote:Don't limit the fps.gblanco wrote:How to eliminate the delay of the data stream using MPEG? Over time the data stream is getting late. Sometimes reaches more than 1 minute late. MJPEG is practically in real time.
mastertheknife
Using JPEG (firefox streaming or camboloza streaming in Internet Explorer) streaming works great(sometime discard one or two seconds) but using mpeg streaming after while get totally late.
Re: MJPEG vs MPEG for low bandwidth and CPU
gblanco wrote:I use NORMAL CAMERAS (NOT IP)... The data stream is not in real time after a while. It seems to me that there is a buffer.mastertheknife wrote:Don't limit the fps.gblanco wrote:How to eliminate the delay of the data stream using MPEG? Over time the data stream is getting late. Sometimes reaches more than 1 minute late. MJPEG is practically in real time.
mastertheknife
Using JPEG (firefox streaming or camboloza streaming in Internet Explorer) streaming works great(sometime discard one or two seconds) but using mpeg streaming after while get totally late.
???
Re: MJPEG vs MPEG for low bandwidth and CPU
mastertheknife, would you please elaborate on this statement?mastertheknife wrote:Don't limit the fps.
mastertheknife
I've always assumed that lowering the fps would help ZoneMinder and reduce the changes of big gaps in my recordings. I think this still makes sense for use with a capture card or with simple jpeg images or even mjpeg, but now I'm wondering if my assumption has been just wrong with mpeg streams. Am I actually creating more work, and risking more lag, by setting Max FPS to just 2-3fps with ZoneMinder? Does a low fps require extra work to "catch up"?
Thank you.
-
- Posts: 678
- Joined: Wed Dec 16, 2009 4:32 pm
- Location: Israel
Re: MJPEG vs MPEG for low bandwidth and CPU
When i advised not to limit the fps, i thought the user was using an IP camera. The problem with a MJPEG stream from an IP camera is that the receiver has no way to control the frame rate, so the only option to reduce the frame rate is to skip certain frames, but at the moment, ZM doesn't do this and by limiting your frame rate, you will actually get a constantly increasing delay.carteriii wrote:mastertheknife, would you please elaborate on this statement?mastertheknife wrote:Don't limit the fps.
mastertheknife
I've always assumed that lowering the fps would help ZoneMinder and reduce the changes of big gaps in my recordings. I think this still makes sense for use with a capture card or with simple jpeg images or even mjpeg, but now I'm wondering if my assumption has been just wrong with mpeg streams. Am I actually creating more work, and risking more lag, by setting Max FPS to just 2-3fps with ZoneMinder? Does a low fps require extra work to "catch up"?
Thank you.
Some cameras have an option to specify the maximum frame rate, e.g. maxfps=5 in the URL. If your camera supports that, thats what you should use.
mastertheknife
Kfir Itzhak.