Forums/Bluecherry BC- series driver support/Hardware compression MPEG-4 / H.264 driver
Answered
[Resolved] Jumpy/Glitchy unusable video, missing keyframes, etc
Roman Gaufman
asked this on June 17, 2011 05:57
I have the 16 channel H264 hardware compression card. I'm not sure what is wrong, but I'm getting unusably bad video. I'm doing:
v4l2-ctl -d /dev/video10 -v width=704,height=576,pixelformat=MPEG && mencoder -nosound -ovc copy -frames 500 /dev/video10 -o test.avi
This is the result I'm getting:
http://itstar.co.uk/bluecherry_test.avi
I'm using the latest driver from Github: https://github.com/bluecherrydvr/solo6x10
Attached is the output I get from mencoder.
Please let me know if any further information is required.
Comments
We are working on getting a gstreamer plugin developed. Hopefully that would work as a replacement to mencoder.
Otherwise, I believe this is mencoder not handling the raw frames that the card produces, not a problem with the driver itself.
I dont have to use mencoder. Please suggest something, anything that does handle the raw h264 frames that the card produces. Either a player or anything at all that can take the generated file and play it or put it in a container.
Otherwise I am unable to use this card :(
Also, if I generate raw H264 with x264, mencoder handles that fine. I also asked ffmpeg developers and it's news to them that it doesn't handle raw frames. Please advice what is different about those frames and what I can do or use to make use of them?
I saw you have a tool in solo6x10 - I managed to get it compiled, but it segment faults instantly when I try to use it - I was told on #bluecherry that maybe it's for MPEG4 only cards?
Please advice.
I also tried to use gstreamer that also handles raw h264 frames, I got this:
# gst-launch -v filesrc location=test.264 ! h264parse ! mp4mux ! filesink location=test.mp4
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = video/x-h264, parsed=(boolean)true, stream-format=(string)avc, alignment=(string)au
/GstPipeline:pipeline0/GstMP4Mux:mp4mux0.GstPad:src: caps = video/quicktime, variant=(string)iso
ERROR: from element /GstPipeline:pipeline0/GstH264Parse:h264parse0: GStreamer encountered a general stream error.
Additional debug info:
gstbaseparse.c(2695): gst_base_parse_loop (): /GstPipeline:pipeline0/GstH264Parse:h264parse0:
streaming stopped, reason not-negotiated
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
/GstPipeline:pipeline0/GstFileSink:filesink0.GstPad:sink: caps = video/quicktime, variant=(string)iso
/GstPipeline:pipeline0/GstFileSink:filesink0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstMP4Mux:mp4mux0.GstPad:src: caps = NULL
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = NULL
Freeing pipeline ...
Attaching debug messages from h264parse - it says: "referred SPS invalid
I tried reducing the FPS to 15 and using the patch suggested by azop on #bluecherry - http://support.bluecherrydvr.com/attachments/token/e0lr892wxquoak1/...
Still video where no motion occurs is better but still getting pretty severe ghosting for anything that moves. Examples: http://itstar.co.uk/18-31-18.mkv
I'm also seeing a new process in top "ksoftirqd/0" that is taking up anywhere from 20 to 50% of my CPU.
Please advice
Example of ghosting: http://itstar.co.uk/18-31-43.mkv
Just a note, the latest 2 videos posted were recorded with the Bluecherry 2.0 beta7 software - I'm seeing the same issues with the video when using the Bluecherry software.
I'm seeing this same problem, regardless of what linux utility I use to pull the video off the card. The only way I can get usable video is to use vlc to serve the MJPG stream. Is there a way to pull the h264 video from the card at all?
Had the card for 3 months and still not able to pull h.264 video from the card reliably - there are missing keyframes and ghosting and all kinds of problems with the video, even when using the bluecherry software :/ - anyone?
Hello Roman,
Have you gotten around this problem? I am thinking of buying a 4-port H.264 card that would stream H.264 via VLC or mencoder but the issues you're having are keeping me away.
Thanks.
So far this bug hasn't been fixed, but we are working on it:
http://improve.bluecherrydvr.com/issues/878
Hi Curtis, is there an ETA for delivery of this fix? The product is great and I appreciate everybody's hard work but this issue is rendering my 8 camera's rather ineffective at the moment.
Thanks,
Dan.
And my 16 cameras,
Thanks,
Roman
We haven't resolved it yet. We are reworking the driver to solve several race conditions that will allow us to resolve issues faster. I don't have an ETA,. It can't hurt for you to 'watch' the repo on Github, as once we have a patch it will be immediately posted there:
https://github.com/bluecherrydvr/solo6x10/watchers
Just to provide a update on this, we are still working on this. Our kernel developer assigned to this bug has fallen pretty sick and has been in the hospital for the past week and a half, and will most likely be in for another week. We wish him well, and hope that he returns soon.
Roman,
You can try downloading the latest git driver and seeing if this solves some of the recording problems you have. This is not at all an official release, and is just the beginning of a set of commits we will be doing in the next week or so.
c6d8887This should be resolved now in the latest driver (2.3.7)
http://www.bluecherrydvr.com/2011/11/driver-2-3-7-released/
Lets see, compiled latest drive, plugged in test camera, I had to modify bc-record a little for PAL@25 fps - please confirm if this looks right?
vparm.parm.capture.timeperframe.denominator = 20;
vparm.parm.capture.timeperframe.numerator = 1;
vfmt.fmt.pix.width = 704;
vfmt.fmt.pix.height = 576;
I ran 3 tests: 1 using the same mencoder command as above, next was just cat /dev/video9 > file and finally using bc-record included with the driver. These are the results:
http://itstar.co.uk/20111119_cat.h264
http://itstar.co.uk/20111119_mencoder.avi
http://itstar.co.uk/20111119_bc-record.mkv
Cat and Mencoder look about the same (unusable), the bc-record version is improved but it's still horrendous at the beginning of the video and you can see several glitches and jumps even in a 30 second test recording.
So I wouldn't call this resolved just yet - there are clear improvements though!
I've seen occasional glitches in the recording with the latest driver, but not that frequently. I'll try recording from those sources soon and see if I get the same results. The recording tests for that fix were mostly done through the Bluecherry server, which initializes things a bit differently from bc-record - that could be the problem. It's also possible that they're PAL-related, but we'll hope not.
I'll let you know when I find something out. Thanks for the patience
Thank you, please keep me updated. Can you maybe update bc-record to initialize things the same as the bluecherry server?
I was having a similar issue running fedora 14 with amahi. I compiled and installed zoneminder 1.25.0, and I found somewhere to try the following setting:
in /etc/sysctl.conf add:
kernel.shmall = 33554432
kernel.shmmax = 536870912
reboot.
Afterwards, my video only jumped the first few 25 frames in zoneminder. Im watching one camera at 22-38fps. this setting will also allow you to use mjpeg in zoneminder. All of my memory mapping issues in zoneminder have stopped.
I have the same problem with ghost in my 16 cameras
Installed a bluecherry 16 ports H.264 card , ubuntu server 10.04
any solution?
Is this fixed or not? I've been wanting to buy this card for 3 months but haven't because of this issue.
A recent update has improved things somewhat but no, this is not fixed yet :(
Ian,
We do not have a proper fix for this yet. We have a 'dirty hack' fix, however mileage will vary:
On line 781 of solo6010-v4l2-enc.c:
Change:
long timeout = schedule_timeout_interruptible(HZ);
to:
long timeout = schedule_timeout_interruptible(1);
This could cause timeouts to happen faster then the DMA expects can could give (false) timeouts, which could clog the p2m-dma buffer. However for the customers that have tried this patch it seems to resolve most of their issues.
the last driver's update (2.4.0) not solve the problem for me.
Leo,
Which problem are you referring to?
For most cases this is now resolved. There are some spotty reports that the duplication is occurring, but so far nobody has provided us remote access to their systems to help identify the problem.
I'm marking this as closed for now. If someone can provide remote access, please email the SSH details to beta@bluecherrydvr.com