longldt / javacv

Automatically exported from code.google.com/p/javacv
GNU General Public License v2.0
0 stars 0 forks source link

IP Camera FrameGrabber #384

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Here is "satisfactory" foscam framegrabber.  It should be generalized enough to 
work with any mjpeg ip camera.  Tested with a Foscam camera.

If you can use it you're welcome to it.
Enjoy.
Regards,
Greg.

Original issue reported on code.google.com by supert...@gmail.com on 18 Nov 2013 at 2:49

Attachments:

GoogleCodeExporter commented 8 years ago
Looks great, thanks! Do you mind if I paste the GPLv2 with Classpatch exception 
license at the top with your copyright?

And if feel any of your other FrameGrabber would also be useful to other users, 
let's add them too, thanks!

Original comment by samuel.a...@gmail.com on 24 Nov 2013 at 12:54

GoogleCodeExporter commented 8 years ago
Sure, go ahead.

Original comment by supert...@gmail.com on 24 Nov 2013 at 3:08

GoogleCodeExporter commented 8 years ago
Ok, done!
http://code.google.com/p/javacv/source/detail?r=0e399872bfeb3824e975b3c575ad3a0a
41027dee
Let me know if you'd like to add or change anythings, thanks.

Original comment by samuel.a...@gmail.com on 15 Dec 2013 at 7:08

GoogleCodeExporter commented 8 years ago
Hello Samuel,
I have a performance update to give you.  The previous IPCameraFrameGrabber 
converted the byte stream to a BufferedImage then converted that to a IplImage. 
 The new version only converts the first frame and uses the decode dimensions 
to create a IplImage directly on subsequent frames.  Although, this change is 
not very noticeable on a fast computer - the difference on a Raspberry Pi is 
from ~12 seconds (yowch!) down to 6 ms.

Fixing this issue is a segue to a question regarding how to efficiently convert 
the resulting IplImage back into a displayable image.  I think my preferred 
format would be a stream of mjpeg out.  I already have code for this but it 
depends on converting to a BufferedImage again and I want to avoid this 
performance hit.  Do you have any suggestions? (its my understanding the ffmpeg 
codecs typically depend high cpu utilization in exchange for time - but a raspi 
@ 700Mhz does not have much cpu to utilize :)  I saw 
http://docs.opencv.org/modules/highgui/doc/reading_and_writing_images_and_video.
html#imencode which looks like a new opencv method to encode a IplImage into 
jpg - its currently not available through JavaCV - do you think this might be 
promising?
Regards,
Greg

Original comment by supert...@gmail.com on 28 Dec 2013 at 1:29

Attachments:

GoogleCodeExporter commented 8 years ago
IplImage.create() does not copy data into the new image, so I don't think that 
should even be working.. ?

As you posted on the mailing list, we can use cvEncodeImage() to encode image 
data into JPEG format. It does the same thing as imencode(). But I don't think 
it's particularly efficient. FFmpeg comes with a variety of codecs, and things 
like MPEG-4 are more efficient IIRC, but then that's not MJPEG anymore...

Original comment by samuel.a...@gmail.com on 30 Dec 2013 at 2:37

GoogleCodeExporter commented 8 years ago
Does the updated IPCameraFrameGrabber.java actually works correctly? I'd like 
to make a release soon, but it still doesn't seem to me that the new code 
works. From what I understand, the bottleneck is in IplImage.createFrom(), so 
using cvDecodeImage() in the case of grab() seems like a good approach. 
Something like this should work fast enough:

    byte[] b = readImage();
    CvMat mat = cvMat(1, b.capacity(), CV_8UC1, new 
BytePointer(b));
    return cvDecodeImage(mat);

But we're going to need to make sure to release the image returned by 
cvDecodeImage()...

Original comment by samuel.a...@gmail.com on 3 Jan 2014 at 9:42

GoogleCodeExporter commented 8 years ago
Yes, sorry.. I'll test with what you suggested.

Original comment by supert...@gmail.com on 3 Jan 2014 at 5:01

GoogleCodeExporter commented 8 years ago
I tried following - 

             byte[] b = readImage();
             CvMat mat = cvMat(1, b.length, CV_8UC1, new 
                     BytePointer(b));

             if (decoded != null){
                 decoded.release();
             }

             decoded = cvDecodeImage(mat); 

            Logging.logTime("pre - IplImage.cvDecodeImage");
            return decoded;

The images are returning,
but I'm not sure on how to properly release - currently it returns

java.lang.NullPointerException
    at com.googlecode.javacpp.Pointer.deallocate(Pointer.java:375)
    at com.googlecode.javacv.cpp.opencv_core$IplImage.release(opencv_core.java:539)
    at org.myrobotlab.opencv.IPCameraFrameGrabber.grab(IPCameraFrameGrabber.java:132)
    at org.myrobotlab.opencv.VideoProcessor.run(VideoProcessor.java:238)
    at java.lang.Thread.run(Thread.java:722)
------

Original comment by supert...@gmail.com on 3 Jan 2014 at 5:37

GoogleCodeExporter commented 8 years ago
We have to do it manually with cvReleaseImage().

Original comment by samuel.a...@gmail.com on 4 Jan 2014 at 12:55

GoogleCodeExporter commented 8 years ago
I've patched something together and released it in JavaCV 0.7:
http://code.google.com/p/javacv/source/detail?r=f3bb7aa577c0b427a88f927a2cea8ec5
05c31e22
Please let me know if that doesn't work for some reason, thanks!

Original comment by samuel.a...@gmail.com on 7 Jan 2014 at 12:58