Page 1 of 1

MJPEG stream capture fails with Axis 211

Posted: Tue Nov 15, 2005 7:32 am
by pressureman
I'm running ZoneMinder 1.21.3, downloaded as a Debian package from www.spic.net. So far, I can only successfully get my Axis 211 camera to work with ZM if I use the JPEG method (source /axis-cgi/jpg/image.cgi) - which at best captures around 7fps, but with up to 20 seconds lag.

If I try to use the MJPEG stream provided by the camera (source /axis-cgi/mjpg/video.cgi), ZM stream no longer works (although strangely, still images do).

My zmdc.log shows the following:
''zmc -m 3' started at 05/11/15 20:21:47
'zmc -m 3' starting at 05/11/15 20:21:47, pid = 5506
'zmc -m 3' stopping at 05/11/15 20:21:57
'zmc -m 3' died at 05/11/15 20:21:57
'zmc -m 3' started at 05/11/15 20:21:57
'zmc -m 3' starting at 05/11/15 20:21:57, pid = 5511
'zmc -m 3' stopping at 05/11/15 20:22:07
'zmc -m 3' died at 05/11/15 20:22:07
'zmc -m 3' started at 05/11/15 20:22:07
'zmc -m 3' starting at 05/11/15 20:22:07, pid = 5518
'zmc -m 3' stopping at 05/11/15 20:22:17
'zmc -m 3' died at 05/11/15 20:22:17
...and so on.

I set ZM_DEBUG_LEVEL_zmc=4 and also echoed 134217728 to shmall and shmmax.

My /var/log/syslog is filling up very fast with messages like the following:
Nov 15 20:14:35 bigbrother zmc_m3[5309]: DB3 [Expecting 2896 bytes]
Nov 15 20:14:35 bigbrother zmc_m3[5309]: DB3 [Read 2896 bytes]
Nov 15 20:14:35 bigbrother zmc_m3[5309]: DB3 [Unable to extract subheader from stream, retrying]
Nov 15 20:14:35 bigbrother zmc_m3[5309]: DB3 [Expecting 1448 bytes]
Nov 15 20:14:35 bigbrother zmc_m3[5309]: DB3 [Read 1448 bytes]
Nov 15 20:14:35 bigbrother zmc_m3[5309]: DB3 [Unable to extract subheader from stream, retrying]
Nov 15 20:14:35 bigbrother zmc_m3[5309]: DB3 [Expecting 2896 bytes]
Nov 15 20:14:35 bigbrother zmc_m3[5309]: DB3 [Read 2896 bytes]

Yet if I connect directly to the camera, and view the MJPEG stream (with Firefox), it works perfectly.

If I try a 'wget -S http://10.10.10.165/axis-cgi/mjpg/video.cgi' from Linux, the headers look correct:
HTTP/1.0 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Connection: close
Content-Type: multipart/x-mixed-replace; boundary=--myboundary

and I confirmed that the returned stream is simply just repeated JPEG's separated by '--myboundary'.

Is this a known problem? I see there are a lot of posts of a similar nature, but it's difficult to make out whether anybody actually has this successfully working. If it is a bug, is it fixed in 1.21.4? It appears that the capture daemon is just having difficulty recognising the MJPEG stream coming from the camera, although I thought this was added as a feature several versions ago...?

The camera firmware is 4.30 (latest as of writing this).

Streaming video of 7fps and 20s lag is not really going to cut it (when I know the camera to stream direct to a browser at 25fps and zero lag).

Posted: Tue Nov 15, 2005 9:22 am
by jameswilson
goto options and network, change to http 1.0 and turn on reg exp

James
Let me know what effect that has

Posted: Tue Nov 15, 2005 9:38 am
by zoneminder
There doesn't look like there is anything wrong from the debug logs. They aren't errors you are listing but just diagnostics. It all looks perfectly normal. Whether streaming versus stills works has no dependencies at all on what capture method you use so I suspect the problem lies elsewhere.

You should get no lag at all really apart from processing time so I suspect you are getting images backed up on the network. Have you set a maximum fps at all? If you have and you haven't told your camera to respect that frame rate you will get a backlog.

Phil

Posted: Tue Nov 15, 2005 9:58 am
by pressureman
jameswilson wrote:goto options and network, change to http 1.0 and turn on reg exp

James
Let me know what effect that has
Ok, the http 1.0 option is sensible, since these cameras do only run an http 1.0 server (although I thought it would have gracefully degraded to 1.0 from 1.1). The regex also helped, and got things working.

After changing back though, things still worked, and it seemed like I couldn't reproduce the problem. Tried a few restarts, got the original problem back, tried your solution, problem fixed. So I'm not really sure which of the two the solution really is (or perhaps both). My money is on the regex.

Posted: Tue Nov 15, 2005 10:01 am
by pressureman
zoneminder wrote:You should get no lag at all really apart from processing time so I suspect you are getting images backed up on the network. Have you set a maximum fps at all? If you have and you haven't told your camera to respect that frame rate you will get a backlog.
Ok, I set a max fps on the cameras of 20, and also in ZM. Which of the two places is it better to limit it? Are we just trying to avoid flooding ZM with frames from the camera?

Posted: Tue Nov 15, 2005 10:17 am
by pressureman
With max fps set to 20 on both my cameras, ZM tells me:
Nov 15 23:07:23 bigbrother zmc_m2[6466]: INF [Workshop: 3000 - Capturing at 5.99 fps]
Nov 15 23:07:42 bigbrother zmc_m1[6437]: INF [Office: 10000 - Capturing at 18.87 fps]

The lights are switched off in the 'workshop', so I suspect the camera itself is dropping the frame rate down.

In the stream from ZM though, it's still very laggy (over 10s), and the media player statistics report only about 2-3 fps.

So it looks like ZM is capturing (at least one) stream at the frame rate it's supposed to, but taking its sweet time to process it. I'm set to use asf stream format in ZM.

Posted: Tue Nov 15, 2005 10:22 am
by jameswilson
ah, you are mpeg streaming?
you using windows media player?

Posted: Tue Nov 15, 2005 12:14 pm
by pressureman
jameswilson wrote:ah, you are mpeg streaming?
you using windows media player?
It looks very much like a WMP embedded in the browser window (Firefox), and the default settings of ZM were 'mpeg' streaming (as opposed to 'jpeg'), and 'asf' for both live and replayed video. Right-clicking in the media player window and looking at properties, it says it's using msmpg4 codec.

Posted: Tue Nov 15, 2005 12:27 pm
by jameswilson
wmp is the cause of you lag, if you change to jpeg streaming you will hardly have any lag, I will be working on an mpeg add in to my windows viewer and am planning on removing the lag issue that wmp player has. Its a bit of work but will solve these probs, in the mean time either use jpeg streaming, accept the lag or find another mpeg player that doesnt suffer from the issues that wmp does

James

Posted: Tue Nov 15, 2005 10:41 pm
by pressureman
jameswilson wrote:wmp is the cause of you lag, if you change to jpeg streaming you will hardly have any lag, I will be working on an mpeg add in to my windows viewer and am planning on removing the lag issue that wmp player has. Its a bit of work but will solve these probs, in the mean time either use jpeg streaming, accept the lag or find another mpeg player that doesnt suffer from the issues that wmp does
A quick update on this - I've reverted ZM to use http 1.1, but kept the tickbox in the 'old regex routines' box - without this option ticked, the mjpeg capture was intermittent/unreliable.

I've removed the frame rate limit on both monitors in ZM, but limited it on the cameras (both Axis 211's) to 25 fps. They can do 30, but since PAL is 25, I don't see much point. The log entries created by ZM in syslog indicate that it is indeed capturing at 25 fps. The 'workshop' camera that was reporting 6 fps last night was simply due to the camera trying to maintain correct exposure in low light, by slowing its shutter speed right down.

I'm about to try changing the video stream option in ZM from mpeg to jpeg (once I am onsite and plugged into that LAN). A couple of questions about this though - does this known issue with WMP only affect live streaming? If ZM is recording (as opposed to monitoring) at 25 fps, surely that can be viewed by WMP at native speed, just as if I was viewing a saved mpeg from disk? Have you thought of using a more open (and hence cross platform) streamable video format like Ogg Theora?

Obviously it would be nice to use a proper mpeg-like stream, to conserve bandwidth.

Posted: Tue Nov 15, 2005 10:51 pm
by jameswilson
i tried a lot of things when i first started with zm to get wmp and zm to play ball in mpeg mode. Gave up after a few weeks, Basically from what i can work out, wmp was designed for reliable post event streams, eg films, trailers demos etc, things where a 10 second or even 1 hour lag are irrelevant, It does this to prevent the stream stalling and to give the user a better experience etc etc (insert more ms bu sorry info here) . Obviously we want live instant unlagged video and dont mind the odd stutter due to a slowdown, outage etc. Of all the commercial recorders that use streaming none (that i currently know of) allow streaming of mpeg through a web interface as this would use the wonderful and very widespread ms wmp. They usually keep their web viewer very basic and only allow full utilistation of features with their 'custom' software. If you give me a few weeks i think zm will have this too. I will also make a very basic single viewer only for testing purposes. Unfortunatly the only reason im not messing with mpeg's now is because i dont have access to a working zm with mpeg streaming. This is because i cant install zm the proper way and need (the wonderful) Ross's RPM's.
I have used a program on my ppc that allows changing to options of stream xache etc etc that gave near instant results but i assume their will always be more of a lag with mpeg than jpeg due to the way mpeg is srtucted. I beleive its conditional refresh based, than a full frame retransmitted evry so many frames (5 i think on sky), but i could be wrong. I want to get mpeg4 working for low bandwidth/high cam number usage but i bet the load on the server is significatly higher

PS i dont like paragraphs lol

Posted: Tue Nov 15, 2005 11:58 pm
by zoneminder
Ogg is supported provided you have (a) compiled ffmpeg with the relevant options (b) set ZM to use it and (c) installed a theora capable viewer/plugin.

However, although I've used mpeg streaming in the past I much prefer mpjpeg streaming as it seems more reliable, consistent in quality and less prone to the foibles of the viewer you are using. I don't really think bandwidth comes into it too much as I doubt there's any benefit to be gained from streaming at anything above pretty basic quality, which you can configure.

Phil

Posted: Wed Nov 16, 2005 1:22 pm
by SyRenity
Hi.
wmp is the cause of you lag, if you change to jpeg streaming you will hardly have any lag, I will be working on an mpeg add in to my windows viewer and am planning on removing the lag issue that wmp player has. Its a bit of work but will solve these probs, in the mean time either use jpeg streaming, accept the lag or find another mpeg player that doesnt suffer from the issues that wmp does
Have you tried to reduce the buffering to 1 second? This might perhaps help.
Ogg is supported provided you have (a) compiled ffmpeg with the relevant options (b) set ZM to use it and (c) installed a theora capable viewer/plugin.
This sounds interesting! Phil, do you have any experience streaming video through this codec? BTW, which format should be set in ZM to use it - OGG?

Posted: Wed Nov 16, 2005 9:36 pm
by pressureman
I eventually got a good frame rate (25 fps) from MPEG streaming by going into the ZM config and increasing the frame rate from 15 to 25 for the "high bandwidth" setting. I'm not completely convinced that ZM storing each of the frames from the camera's MJPEG stream as a separate JPEG is a good way to go for long term storage though.

Anyway, since then I've discovered that the Axis 211 camera has built in MPEG4 streaming, motion detection, event notification, and image upload upon event trigger. Essentially it has all the features of ZM apart from long term archival of images.

So, while I see value in ZM when used with dumb cameras, we've paid top dollar for smart Axis cameras, and they can actually do all we need. I'll keep ZM in mind for future projects, but right now it's just going to add complexity where we don't need it.