ofx version incompatibilities: IPVideoGrabber::makeShared and other methods

[grrrr]

Hi, the static makeShared method is supposed to return an instance of IPVideoGrabber. However, with the openframeworks versions i tried, the base class ofBaseVideoDraws contains pure virtual functions that are not overridden in the IPVideoGrabber class, inhibiting the possibility of constructing an instance of it in makeShared. Apart from that, the function signatures in IPVideoGrabber seem to be incompatible to the ones in ofBaseVideoDraws. It would be helpful to know the exact versions (commit id) of openframeworks to compile ofxIPVideoGrabber with.

[bakercp]

Yeah, it's completely out of date with the new base class API in the openFrameworks 0.9.0+. I'm working on a fix now.

[bakercp]

@grrrr I spent some time on this and got everything compiling, but I'm getting a strange null pointer exception that wasn't there before 0.9.0 -- I have to pause for a bit, so if it's urgent, perhaps take a look at the develop branch and see what you can make of it? Let me know if works or not for you.

[grrrr]

Many thanks, i pulled your changes but it seems that you must also have changed IPCAM2SYPHON, since the make_shared static function has been renamed. Could you push changes to other projects that might have changed alongside? Thanks!

[antimodular]

i am also trying to run it in OF0.9.0. The development branch seems to save the frames successfully. Just need to figure out how to make it display them and use the image. Thanks.

[antimodular]

why did you change image_a from ofImage to ofPixels? seems like there is no way to get ofBuffer in to ofPixels other than as you do, saving and loading it.

[antimodular]

oh i see. just had to change it to ofLoadImage(pix, buffer) and not to load the file from disk

[bakercp]

@antimodular hey, yeah, the version in the develop branch was the in-progress / debugging version where I left off during the last test. It's really close but on my machine I was getting some image allocation errors, which may have just been a bad FreeImage library or something. If you're able to covert those pixels back to jpeg to send out the stream, then I think it's probably good to go ... let me know where you're at and I can probably take another look later this afternoon.

[antimodular]

it seems that i only get the FreeImage error when compiling for Debug mode but not for Release mode.

[bakercp]

So, I'm still getting the same error I was trying to isolate here

                    else if(cBuf[c-1] == JFF)
                    {
                        if(cBuf[c] == SOI)
                        {
                            mode = MODE_JPEG;
                        }
                        else if(cBuf[c] == EOI)
                        {
                            buffer = ofBuffer(cBuf, c+1);

                            if( c >= MIN_JPEG_SIZE)
                            { // some cameras send 2+ EOIs in a row, with no valid bytes in between

                                ///////////////////////////////
                                mutex.lock();     // LOCKING //
                                ///////////////////////////////

                                ofPixels pix;

                                bool result = ofLoadImage(pix, buffer);

                                // get the back image (ci^1)
                                if(result)
                                {
                                    image_a[ci^1] = pix;
                                    isBackBufferReady_a = true;
                                    nFrames_a++; // incrase frame cout
                                }
                                else
                                {
                                    ofLogError("IPVideoGrabber") << "ofImage could not load the curent buffer, continuing.";
                                }

                                ///////////////////////////////
                                mutex.unlock(); // UNLOCKING //
                                ///////////////////////////////

                            }
                            else
                            {
                                cout << "?????????????????? buffersize=" << buffer.size() << " >> " << buffer.getText() << endl;
                            }
                            mode = MODE_HEADER;
                            resetBuffer = true;
                        }
                        else
                        {
                        }
                    }

The line bool result = ofLoadImage(pix, buffer); is throwing EXC_BAD_ACCESS error. I'm a bit confused because the buffer must be valid because we can write it directly to disk and it appears to be a valid JPEG. But when we try to load the buffer straight into a buffer I get errors, which leads me to believe that there is a freeimage problem interpreting the jpg buffer.

[bakercp]

Oh ... ? Interesting ...

[bakercp]

The even stranger part is that if I save one of the jpgs buffers to disk, then open it up in the main thread, then it works.

[bakercp]

OK. So release also works for me. Really odd. It may have something to do with the fact that this is happening in another thread, but, I investigated that in a separate example and it didn't appear that FreeImage was producing problems in that situation. Anyway ... I don't have a ton of time to spend on this today, so if you come up with a solution (could be a bad freeimage build / bug I suppose, esp if it's only happening w/ debug) do PR :)

[bakercp]

So, just a quick update ... I turned on address sanitizer and have been running it over and over again ... and for some unknown reason it isn't crashing w/ debug anymore. This makes me think there is a bug somewhere deeper inside ofBuffer, ofPixels or in our version of FreeImage (not trying to blame it on someone, because it's very likely in this code ... but it has been working for quite a while and a whole lot has changed with ofPixels and ofBuffer internally since 0.8.4). Anyway ... still not sure exactly what it is yet, but let me know if you find a solution.

[bakercp]

OK -- not sure but this may be an issue -- but can you try making the buffer larger ... I'm just realizing it is hard coded to be pretty small ...

static int BUF_LEN = 4512000; // 8 \ 65536 = 512 kB

[bakercp]

This should be working now.