MJPEG vs MPEG for low bandwidth and CPU

Forum for questions and support relating to the 1.25.x releases only.
Locked
TitovLab
Posts: 3
Joined: Mon Jan 10, 2011 4:01 pm

MJPEG vs MPEG for low bandwidth and CPU

Post by TitovLab »

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)?
netwrkr
Posts: 15
Joined: Tue Sep 09, 2008 2:56 pm

Re: MJPEG vs MPEG for low bandwidth and CPU

Post by netwrkr »

MPEG.
Flasheart
Posts: 342
Joined: Thu Jul 06, 2006 2:27 pm

Re: MJPEG vs MPEG for low bandwidth and CPU

Post by Flasheart »

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.
mastertheknife
Posts: 678
Joined: Wed Dec 16, 2009 4:32 pm
Location: Israel

Re: MJPEG vs MPEG for low bandwidth and CPU

Post by mastertheknife »

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.
Not entirely true.
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.
Flasheart
Posts: 342
Joined: Thu Jul 06, 2006 2:27 pm

Re: MJPEG vs MPEG for low bandwidth and CPU

Post by Flasheart »

Ah, I didn't realise that. Have you done any tests to see which is faster?
netwrkr
Posts: 15
Joined: Tue Sep 09, 2008 2:56 pm

Re: MJPEG vs MPEG for low bandwidth and CPU

Post by netwrkr »

concur +mastertheknife.

Switching from MJPG to MPEG/H.264 *significantly* reduces bandwidth and CPU load.
developer123
Posts: 4
Joined: Wed Jun 22, 2011 4:02 pm

Re: MJPEG vs MPEG for low bandwidth and CPU

Post by developer123 »

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?
User avatar
kingofkya
Posts: 1110
Joined: Mon Mar 26, 2007 6:07 am
Location: Las Vegas, Nevada

Re: MJPEG vs MPEG for low bandwidth and CPU

Post by kingofkya »

Mpeg is a container

h.264 is codec


The codec goes inside the container.
gblanco
Posts: 28
Joined: Sun Jul 17, 2011 2:15 pm
Location: Porto Alegre, Brazil

Re: MJPEG vs MPEG for low bandwidth and CPU

Post by gblanco »

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
Posts: 678
Joined: Wed Dec 16, 2009 4:32 pm
Location: Israel

Re: MJPEG vs MPEG for low bandwidth and CPU

Post by mastertheknife »

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.
Don't limit the fps.

mastertheknife
Kfir Itzhak.
gblanco
Posts: 28
Joined: Sun Jul 17, 2011 2:15 pm
Location: Porto Alegre, Brazil

Re: MJPEG vs MPEG for low bandwidth and CPU

Post by gblanco »

mastertheknife wrote:
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.
Don't limit the fps.

mastertheknife
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.

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.
gblanco
Posts: 28
Joined: Sun Jul 17, 2011 2:15 pm
Location: Porto Alegre, Brazil

Re: MJPEG vs MPEG for low bandwidth and CPU

Post by gblanco »

gblanco wrote:
mastertheknife wrote:
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.
Don't limit the fps.

mastertheknife
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.

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.

???
carteriii
Posts: 65
Joined: Sun Oct 28, 2007 3:13 pm

Re: MJPEG vs MPEG for low bandwidth and CPU

Post by carteriii »

mastertheknife wrote:Don't limit the fps.

mastertheknife
mastertheknife, would you please elaborate on this statement?

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.
mastertheknife
Posts: 678
Joined: Wed Dec 16, 2009 4:32 pm
Location: Israel

Re: MJPEG vs MPEG for low bandwidth and CPU

Post by mastertheknife »

carteriii wrote:
mastertheknife wrote:Don't limit the fps.

mastertheknife
mastertheknife, would you please elaborate on this statement?

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.
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.
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.
Locked