Failure to Crop Capabilities

[chickenparm1223]

I am unable to determine the settings that I need for my cameras in zoneminder. I can see the camera in Cheese by the way, so I know that it is working. Details below:


System Info
Ubuntu 12.04 LTS Desktop 64-bit
Zoneminder 1.25.0 (from Ubuntu repository)
Bluecherry BC-H16480A 16 port H.264 video and audio encoder / decoder
//video1 is input 1, video0 is the output on the card (assuming I did my research correctly)



Console
$ zmu -d /dev/video1 -q -v
Error, failed to query crop capabilities /dev/video1: Success

Log entry:
2012-08-10 18:47:56.442262 zmu 5506 ERR Failed to query crop capabilities: Inappropriate ioctl for device zm_local_camera.cpp 934

Thank you in advance!

[rk4n3]

I am unable to determine the settings that I need for my cameras in zoneminder. I can see the camera in Cheese by the way, so I know that it is working. Details below:


System Info
Ubuntu 12.04 LTS Desktop 64-bit
Zoneminder 1.25.0 (from Ubuntu repository)
Bluecherry BC-H16480A 16 port H.264 video and audio encoder / decoder
//video1 is input 1, video0 is the output on the card (assuming I did my research correctly)



Console
$ zmu -d /dev/video1 -q -v
Error, failed to query crop capabilities /dev/video1: Success

Log entry:
2012-08-10 18:47:56.442262 zmu 5506 ERR Failed to query crop capabilities: Inappropriate ioctl for device zm_local_camera.cpp 934

Thank you in advance!

I have a similar problem, but I'm running this:

• ZoneMinder 1.24.2
• Slackware64 13.37
• Bluecherry BC-H16480A 16 port H.264 video and audio encoder / decoder
• /dev/video1 is camera input 1 (as shows in qv4l2)

... and I instead get this:

Code: Select all

~# zmu -d /dev/video1 -q -v
Error, failed to query crop capabilities /dev/video1: Invalid argument

... I've tried every kind of setting in the ZoneMinder console's monitor setup, and can't get it working there, either.

I've run qv4l2, and it sees the card and video input, and appears to capture from it (I don't have a camera connected yet, so I can't tell if that's actually getting video successfully, yet - cameras are ordered and on the way in the mail).

I do have a cheap web camera working in this setup, using UVC supported tools (mjpg_streamer, etc...), so at least I know my ZoneMinder install/config is functional.

I've also tried this kind of thing:

Code: Select all

ffmpeg -an -f mjpeg -pix_fmt uyvy422 -s 704x480 -r 30 -i /dev/video1 -qscale 4 capture.mjpeg

This actually behaves as if its capturing, but of course without a camera connected, I'm not sure what I'm supposed to see (if anything) ... the capture.mjpeg file remains at size 0.

I'll post back any significant progress I see after connecting my camera, or post back with further diagnostic info and questions, if that's how things go ...

[rip]

Hi guys. The short answer is, that the BC-16480a card is not suitable for ZM at all. I spent a couple weeks with it and sent it back, and I do video encoders for a living.

It can be made to work with v4l2 tweaks (pixelformat=1 I think, I'd have to look at my notes) to pull from the card in mjpeg format, but the mjpeg encoder on that chipset is utterly horrible, meaning it was bad enough I found it unsuitable for even basic use. Lots of dithering and artifacts, even the MPEG-4 encoder was no prize in my book. I have sub-$100 ethernet cams that do twice as good at 640x480.

They were working on driver changes to up the MJPEG performance, but it's so bad, I doubt it'll fix much. I sent my card back the day Curtis offered me the beta, so never looked at it.

The WIKI should really reflect that this card is not suitable for ZM, which is unfortunate since apparently Bluecherry put the entry in the wiki themselves. While BC does sell Zm compatible cards, the HW encoders are not among them so shouldn't be referenced as a possible solution in the Zm wiki.

The root reason is that MPEG/H.264 does not give motion a full field every frame. Unless you went to all I frames (and right now, the GOP is not tunable) or buffered it through something like ffmpeg to make it more digestible to ZM, but that instantly defeats the benefit of offloading the CPU.

I sent it back, got a PV-183-8 and am going to add an HD-SDI quad card or two (for the important ones) and bump my box up from a 2 core to a 4 core to offset. The CPU upgrade is cheap compare to the time spent on trying to get that card to behave especially given the complete lack of documentation and very limited support (The first thing out of their mouth is ZM isn't supported, which is curious when they add it to the Zm wiki [or in plainer terms, it's a come on to sell their DVR solution IMHO.])

[rk4n3]

Hi guys. The short answer is, that the BC-16480a card is not suitable for ZM at all. I spent a couple weeks with it and sent it back, and I do video encoders for a living.
(... rest snipped for brevity ...)

Thanks for the heads-up. I finally got my cameras in, and I experienced results exactly as you described.

I did get the camera to work with ZoneMinder 1.25.0 right out of the box, with these settings:

Code: Select all

General Tab:
Name						SecurityCam02
Source Type					Ffmpeg
Function						Monitor	
Enabled						checked
Linked Monitors				
Maximum FPS					
Alarm Maximum FPS			
Reference Image Blend %ge		7
Triggers						None available

Source Tab:
Source Path					/dev/video2
Source Colours				24 bit color
Capture Width (pixels)			704
Capture Height (pixels)			480
Preserve Aspect Ratio			unchecked
Orientation					Normal

Options -> Images tab:
Addl input opts 2 ffmpeg:		-an -f video4linux2 -pix_fmt uyvy422
Addl output opts 2 ffmpeg:		

The results I get with these settings are exactly as you (rip) describe: bad performance (slow, jerky), lots of artifacting and "funny color smearing" issues, and even just plain inaccurate video (frames seem to be out of order sometimes, i.e. what's showing seems to go in reverse or jump "back in time" sometimes).

The primary reason I'm still interested in possibly getting things to work with this card are:
- Channel density: I have the 16-channel version, and want to use it for that many wired cameras
- Potential quality: using qv4l2 the quality is fantastic

The big question to me is: why does the card work so well using qv4l2, but not work with ZM ? Isn't ZM supposed to be fairly rock-solid with anything supported by v4l2 ?

I guess I'm still hoping that there's some "magic combination" of configuration elements that will line up to get great video from this card in ZM ... maybe its a pipe dream, but I'd like to persist a bit more to explore the possibilities before I go through the hassle of returning it.

I have sub-$100 ethernet cams that do twice as good at 640x480.

Can you add some info on suggestions you might have for capture options (such as these sub-$100 ethernet cams) that, in your experience, will work well with ZoneMinder ? I'm a bit more interested in multi-channel capture cards than wireless and/or IP cameras...

Sincere thanks

[rk4n3]

OK, I seem to have made some progress with this. I have ffmpeg capturing an mjpeg stream from the encoder interface(s), and it seems to at least perform fairly well (no "glitching", smooth at a wide range of FPS, etc...), though the quality is a bit low (pixelation mostly).

I have a cheapo web cam at video0, so my Bluecherry card starts at video1 for the video channels, and video2 for the encoders. FYI - all the video channels are under the first video device (in my case, video1), and the channel has to be selected. The rest of the video devices are 2-channel encoders (one channel for each of the two "formats"). You can see how this maps out by looking at the choices offered in qv4l2.

Here's the ffmpeg command that I've gotten to work from the command line:

Code: Select all

ffmpeg -an -f video4linux2 -pix_fmt uyvy422 -vcodec copy -s 704x480 -r 22 -i /dev/video2 -vcodec copy capture.mjpeg

The resulting capture.mjpeg file is exactly what I'd expect, though a bit lower-quality than I'd like (as mentioned).

When I set all these options in the ZoneMinder -> Options -> Images section, under ffmpeg input and output options respectively, and then set up a monitor with ffmpeg as the source, and /dev/video2 as the source path, I actually get video in ZoneMinder now.

The video I get is not satisfactory, though - its still quite "jerky", with some kind of issue around playing the frames smoothly, even in order (it appears to "skip" back in time intermittently). I'm guessing that I'm getting as close as possibly a transcode step away from the kind of video that would be minimally satisfactory, meaning that if I could understand exactly what ZoneMinder expects for ffmpeg's output, I could provide the right output options to get the video transcoded to the "right stuff".

Can anyone help me with this bit ? Or, maybe I'm still off on a wild goose chase ? Any further help would be appreciated ....

Sincere thanks

[rk4n3]

I got it to work ! WOOHOO ! \o/

I had to actually make code changes to get there, though. Man, what a journey ...

I was really hesitant to start digging into code, because I don't know that much about video internals, and my concern was that it would involve a learning curve from hell and way too much time. But, the more I putzed and danced around the non-working configurations, and did alot of reading and thinking around possible causes, I started to get the notion that it had to be something related to an unsupported capture palette. What really zero'd me in on this was how ffmpeg ended up being able to capture very nicely with just a couple of parameters, and in particular the pixel format (uyvy422), which didn't show up in ZoneMinder's local monitor list.

So, I dug into the code looking for where pixel formats were defined and set, and found the areas of code fairly easily. There were some pieces of commented-out code referring to the pixel format I needed as "not having a V4L2 equivalent". I tracked it down in the libavutil headers and found that there certainly is a V4L2 equivalent - perhaps this was a recent "improvement". Anyway, I went back to the respective ZoneMinder code areas, uncommented the commented code and filled in some missing portions, and made sure the correct value from the libavutil headers was populated in all the spots that needed it, including adding it to the GUI's PHP code for the drop-down selection(s). A recompile and replacement of the 6 main executables, plus the edits to one PHP file, and a restart of ZoneMinder brought me to success - it worked right out of the gate, to my very satisfied surprise.

I'll probably create a patch for my changes - if I do, I'll try to get back here and post it.

[rk4n3]

Here's the patch - its for ZoneMinder 1.25.0, tested on slackware64 13.34

[CyberTiVo]

Great work rk4n3! What are the chances of getting ZM to take advantage of the hardware compression on the card to reduce CPU overhead? I would be willing to start work on this if someone would point me in the right direction.

[michael smith]

will this patch work for Pal?

Cheers
michael Smith

[michael smith]

After some prozac and a beer...What I should have said is... is this patch implemented in ZM 1.26.4 ? and would this patch work on 1.26.4? to get my Bluecherry BC-H16480A working properly?
Cheers
Mad Mick!

[mastertheknife]

Hi,

Thank you for the patch. I have pushed it to our git repository and it will be included in v1.26.5
If you don't want to wait, you can download the current git version from here:
https://github.com/ZoneMinder/ZoneMinder/tarball/master

[michael smith]

Thanks Masterknife and rk4n3, this will help me too with my BC H16480A. I will rebuild my ZM install.

Cheers
Michael Smith