• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 867 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: TDA4 OpenGL Mosaic Node

Joe Shidle
Intellectual 440 points
Part Number: TDA4VM


Hello,

We are currently attempting to transform our camera streams to OpenGL textures on the TDA4 with the 8.02 PSDK.

We are using a YUV sensor, so we have applied the patches described in the following link to enable support in the app_multi_cam demo for our YUV sensor. This allowed us to stream multiple cameras successfully.

e2e.ti.com/.../faq-how-to-run-multi-cam-usecase-for-yuv-sensors

In order take the next step of transforming our camera streams to OpenGL textures, we have modified the app_multi_cam demo by removing the ImgMosaicNode and replacing it with the tivxOpenglMosaicNode, as described in the app_linux_arm_opengl_mosaic demo. After these changes, we see the program seg fault when attempting to dequeue the fourth frame with the following line:

status = vxGraphParameterDequeueDoneRef(obj->graph, captureObj->graph_parameter_index, (vx_reference*)&capture_input_arr, 1, &num_refs);

First of all, is our current method the best/most efficient route to convert our camera streams to OpenGL textures? If so, what can be done to resolve the seg fault and achieve a continuous stream of OpenGL textures?

Thank you in advance for your time and attention.

This is the end of the demo log:

------------------------------------------

92.845018 s: ISS: Starting sensor [GW_AR0233_UYVY] ... !!!
appStartImageSensor returned with status: 0
app_run_graph_for_one_pipeline: frame 0 beginning
app_run_graph_for_one_pipeline: frame 1 beginning
app_run_graph_for_one_pipeline: frame 2 beginning


 =========================
 Demo : Camera Demo
 =========================

 s: Save CSIx, VISS and LDC outputs

 p: Print performance statistics

 x: Exit

 Enter Choice: Execute 1st frame



 =========================
 Demo : Camera Demo
 =========================

 s: Save CSIx, VISS and LDC outputs

 p: Print performance statistics

 x: Exit

 Enter Choice: 

 Dequeue input: frame 2
[MCU2_0]     92.845477 s:  VX_ZONE_WARNING:[tivxCaptureSetTimeout:774]  CAPTURE: WARNING: Error frame not provided using tivxCaptureRegisterErrorFrame, defaulting to waiting forever !!!
Enqueue input - start execution: frame 2
app_run_graph_for_one_pipeline: frame 3 beginning
Dequeue input: frame 3
./run_app_multi_cam.sh: line 1:  1262 Segmentation fault      (core dumped) /opt/vision_apps/vx_app_multi_cam.out --cfg /opt/vision_apps/app_multi_cam.cfg
  • 0
    TI__Guru 52533 points

    Hi Joe,

    Can you take a look at the surround view examples in <PSDK RTOS root>/vision_apps/apps/srv_demos. The surround view demos use multiple cameras, use OpenGL, and are closer to your use case.

    Regards,

    Takuma

  • 0 in reply to Takuma Fujiwara
    Intellectual 440 points

    Hi Takuma,

    Thank you for the response.

    We have looked at the Surround View examples, but we believe that the OpenGL mosaic node fits our needs more closely in providing individual textures for each camera stream.

    Thanks to our internal efforts we are now able to successfully stream 4-6 cameras with the OpenGL mosaic node - for example 4 cameras running through a 2x2 OpenGL mosaic - to our display utilizing the GPU, but we still see problems with seg faults when trying to run just 1 camera through a 1x1 OpenGL mosaic. If we have 4 cameras plugged in, we can successfully run a 1x1 OpenGL mosaic, but if we have just one camera plugged in we see a seg fault running a 1x1 OpenGL mosaic.

    We were able to previously run the multi_cam_app with just one camera, so we do not think that it is related to an incorrect amount of camera data in the app pipeline. Do you have any insight into what else could be causing this issue?

    Let us know if there are any additional pieces of information you would need from us.

    Thanks in advance,

    Joe Shidle

  • 0 in reply to Joe Shidle
    Intellectual 440 points

    Hi Takuma,

    We have resolved the issue with seg faulting 1 camera with the 1x1 OpenGL mosaic.  So at this time we have no further questions regarding the OpenGL mosaic node.

    Thank you for your time and attention.

    Regards,
    Joe Shidle

  • 0 in reply to Joe Shidle
    TI__Guru 52533 points

    Hi Joe,

    I'm glad you were able to resolve the segmentation fault! If you don't mind, could you share what the fix was for future reference?

    Regards,

    Takuma

  • 0 in reply to Takuma Fujiwara
    Intellectual 440 points

    Hi Takuma,

    For the multi_cam app we had to change the hard-coded #define MAX_TILES  from  (4)  to (1) in the file vx_opengl_mosaic_target.c.  This #define would have to be changed for any number of cameras that were not already 4 (i.e. more than 4, less than 4).

    We had been modifying a number of other parameters, under the assumption that MAX_TILES was the maximum supported number of tiles for that node. Once we realized it was mis-named and was really being used as a "total number of current cameras" for a variety of buffers for total number of existing cameras (and if there were a different number of cameras these buffers would starve or overflow causing seg faults), changing that fixed our issue.

    Regards,
    Joe Shidle