Log in or register to post comments

Capturing camera frame......

February 4, 2011 - 12:18am #1

Hi

As per the discussion in the below mentioned link:-
https://ar.qualcomm.com/arforums/showthread.php?t=218

Kim suggested me to capture the frames in the native code and then pass them to the java code for further processing.Well I have decided to do that way only.Thanks Kim :)

For generating frames we need QCAR::State object given by Renderer class.I read in the documentation of Renderer class that all its methods should be called from a render thread.My requirement is that on the click of some button in android code my native method say captureFrame should be called which will capture the frame and will return it to the java code.

I need to capture the frame on the click of button and not while rendering of GLSurfaceView.

Is it possible??Please let me know......

And please let me know if I have misunderstood the documantation.

Re: Capturing camera frame......

February 7, 2011 - 7:24pm #5

Hi Kim

Thanks a lot for your help....Now Iam pretty close to what I want:)

Re: Capturing camera frame......

February 7, 2011 - 6:34am #4
Quote:

Does that mean that all the methods of renderer class are called in a seperate thread automatically....

No, but this is a really easy mistake to make :)

Some methods in the renderer class are automatically called on the GLThread. These include onSurfaceCreated, onSurfaceChanged, and onDrawFrame. You can add your own methods to this class, but they will be run on whichever thread they are called from. So if you create a method named getFrame and call it from the UIThread, it will be run on the UIThread. If, however, you call getFrame from the onDrawFrame method, it will be run on the GLThread (since Android calls onDrawFrame from the GLThread).

So there are two simple choices here:

1) Set a flag when you are ready to call getFrame, and call it from the onDrawFrame method.

2) Use a Handler, or the GLSurfaceView queueEvent method, to do some work on the GLThread.

Note that neither of these solutions are synchronous, in both cases your getFrame method will only be called once the GLThread resumes.

- Kim

Re: Capturing camera frame......

February 7, 2011 - 1:21am #3

Hi

Iam implementing GLSURfaceView so probably will go with the first method...But after reading all this I got a bit confused in my basic concepts of android also :(. As told by you Handler is used for inter thread communication.I also read in android documantation that renderer runs in a seperate thread.

Does that mean that all the methods of renderer class are called in a seperate thread automatically....
So that if from the main UI thread I call any method of my Renderer class extending GLSurfaceView.Renderer will that run in a renderer thread which is different from main UI thread?

Please tell me if Iam wrong somewhere....

My requirement is that if a button is clicked in the main UI thread i should start up the method to retreive frames from qualcomm APIs as mentioned by you earlier.So if my understanding for the renderer thread and invocation of methods in the renderer class as mentioned above is correct i dont think so i need handlers as directly from the main UI thread on the click of button i will invoke one method say getFrame present in my renderer class which will then call the native method given by you to retreive frames hence running in a seperate render thread and not in main thread.

Please tell me if im wrong in my concepts.......

Re: Capturing camera frame......

February 4, 2011 - 5:46am #2

Yes this should be possible, there are a couple ways to go about the problem, depending on whether or not you need OpenGL rendering.

If you do want to create an OpenGL surface (like the samples do), then you can simply use a Handler to pass messages from the UIThread to the GLThread. Handlers are Android constructs for passing messages between threads, look at the Android documentation for more info. In the Dominoes sample we use a Handler for the other direction, passing a message from the GLThread to the UIThread to change the visibility of a button.

GLSurfaceView also has a queueEvent method that accomplishes much the same thing, and may be a little more straightforward.

If you want to use this approach, but don't want QCAR to render the camera image in the background, you can set the QCAR::VideoBackgroundConfig mEnabled setting to false.

If you don't want an OpenGL surface, then this might be a good time to use the QCAR UpdateCallback. Implement the UpdateCallback interface and register an object with QCAR::registerCallback (see VirtualButtons.cpp for an example). Your QCAR_onUpdate method will be called on the Tracker Thread when a frame is available, and it is also passed the state object. For your situation, I might have the button press set a flag in native that you are interested in the next frame, and have this method send the data back up. You'll still need some mechanism to pass the data to the correct thread, however.

- Kim

Log in or register to post comments