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: tivxVpacLdcProcess error

Part Number: TDA4VM


Tool/software:

Hi Ti Experts:

    We have discovered an issue while using the graph to capture camera images on the TDA4VM. After creating the capture and graph normally, when we call vx_GraphParameterDequeueDoneRef to retrieve the image, a message "[tivxVpacLdcProcess:323] Failed to Submit Request" is printed. However, this message no longer appears after we call vxMapImagePatch. Could you explain why this happens? We are using SDK version 8.4 on a Linux platform.

Thanks and best regards.

  • Hi,

    This error typically comes when the parameters passed to the LDC are null. So wondering if you are calling vxVerifyGraph to make sure that all the parameters are allocated properly? Also when you call vxMapImagePatch, are you using object array and calling this API for all indices of this object array?

    Regards,

    Brijesh

  • HI,

    yes, we called the vxVerifyGraph function, and the function returned a normal value. After calling vxGraphParameterDequeueDoneRef, we performed vxMapImagePatch on the array, and for this object, we called vxMapImagePatch for all indices. We are puzzled as to why, after calling vxMapImagePatch, the error is no longer prompted?

  • HI,

    We continued our tests and found that if we perform vxMapImagePatch on the LDC output array before calling vxGraphParameterDequeueDoneRef, the error no longer occurs. However, if we first execute vxGraphParameterDequeueDoneRef and then call vxMapImagePatch, the error still appears. Why is this happening?

    Thanks and best regards.

  • hi,

    I would like to add some additional description. The screenshot below shows our usage method, where the red box highlights the vx_object_array that we created ourselves via vxCreateObjectArray for use with vx_GraphParameterDequeueDoneRef to obtain the output of LDC. In our tests, if we only perform vxMapImagePatch and vxUnmapImagePatch on this array first, then when we execute vx_GraphParameterDequeueDoneRef, it will not prompt that error. Why is this? Is this the correct procedure? Or is this the normal usage process?

    Thanks and best regards.

  • Hi,

    What exactly would you like to do? 

    If you want to get access to LDC output images, then yes, you can create graph parameter of LDC output image and then if LDC is replicated, then it should be object array. So please check how you are using LDC and accordingly use data objects. 

    Regards,

    Brijesh 

  • Hi,

    Yes, we plan to access the output of the LDC and are already able to use our custom-defined object array. Even though we occasionally encounter the error "[tivxVpacLdcProcess:323] Failed to Submit Request," we can still successfully retrieve the image with the configuration shown in the screenshot above. I would like to ask: What is the correct procedure? Do we need to call vxMapImagePatch and vxUnmapImagePatch first before calling vx_GraphParameterDequeueDoneRef?

    Thanks and best regards.

  • Hi,

    No need to do mapping of the images of the object array, as this will allocate the buffer space, but this can also taken care by the framework, if appropriately used. 

    Most likely you are replicating LDC node, because you are passing object array. Are the object array size is same for all object arrays passed to this node? This error "Failed to submit" error comes when one of the parameter, most like input/output buffer is null, so please analyze your node creation parameter and confirm that it is created with the correct set of parameters. 

    Regards,

    Brijesh 

  • Hi,

    Our further testing found that when we set APP_BUFFER_Q_DEPTH to 4, there is no issue. However, if it exceeds 4, an error occurs. Is there any correlation with this?

    Thanks and best regards.

  • Hello, 

    I really dont think there is correlation between buffer queue depth and node replication, if the graph is properly written, so can you please check your graph? 

    Regards,

    Brijesh

  • Hi,

        We have located the error at the position indicated by the screenshot, and we found that calling vxMapImagePatch assigns a value to this addr, and the acquired image is normal. According to our method shown in the screenshot, is it necessary to call vxMapImagePatch once when using this approach?

    Thanks and best regards.

  • Hi,

    Yes, map will allocate the buffers if it is not already allocated. But framework should have allocated this buffer, if it is getting used somewhere. So could you please check this buffer that you are mapping is being used in some part of the OpenVX code? Are you using it as LDC output or something? 

    Regards,

    Brijesh

  • Hi,

        We just create and set this buffer in the way shown in the screenshot above, then call vx_GraphParameterDequeueDoneRef to get the LDC image, and an error is printed afterward. So, if we want to avoid this error, do we need to add any additional processing? Is our way of setting it incorrect? What is the correct way to do this

  • Hi,

    It is difficult to review the settings from the screenshots, can you please share this part of the code? In general, if the image object is not used, it will not be allocated, and since you are mapping it, it is getting allocated. So i want to understand where you are using this image object. 

    Regards,

    Brijesh

  • Hi,

        I apologize for the inconvenience, but since the codebase is large and cannot be exported, we can only share it via screenshots. However, all the parts involving LDC usage have been captured in the screenshots. Our current use case is as follows: app_init_ldc --> vxCreateObjectArray to create the LDC output buffer --> app_create_graph_ldc --> app_verify_graph --> call vxGraphParameterDequeueDoneRef --> save image. The image-saving function in the screenshot is the one provided in the official app_multi_cam, which includes calls to functions like vxMapImagePatch. My question is, are there any issues with using it as shown in the screenshots? Is there a way to resolve this error?

    Thanks and best regards.

  • Hi,

    But when you call app_init_ldc, LDC output is already created by this API. This API internally calls create_ldc_outputs, which created LDC output image and creates an object array out of it. So what's the use of intermediate image that you have created in the application? Can you help understand the use of this image? 

    Please note this intermediate image will not be used in creating the LDC node and that's probably the reason why you are seeing memory allocation for this intermediate image. 

    Regards,

    Brijesh

  • hi,

    Our approach is based on the official demo's app_multi_cam_codec. That demo creates the ldc output in this way. By default, the ldc output is a vx_object_array pointer. I understand that if we want to manually vxGraphParameterDequeueDoneRef, we must create an array of pointers, right? Moreover, when analyzing the source code of vxSetGraphScheduleConfig, if it's a pointer, it might cause errors, right? So, do you mean that we only need to use the default output?

    Thanks and best regards.

  • Hi,

    But do you really require output of the LDC in the application? Why can't you allow framework to handle output of LDC, just like multi-camera application? In multi-camera application, LDC output is directly connected to Mosaic node and there is no intermediate image required. 

    Regards,

    Brijesh

  • Hi,

    Yes, we do need the output from ldc because the images we obtain from the capture node are in UYVY format, but we need NV12 format. Therefore, we need to use ldc for format conversion. Then this problem occurs. I see that in app_multi_cam_codec, they do it in the same way to obtain ldc. Is there any way to solve this error?

    Thanks and best regards.

  • Hi,

    But where the output of LDC is used? Is it used in some other OpenVX based nodes? Then you dont require to get the output from LDC in the application. 

    Regards,

    Brijesh

  • Hi.

    The output of ldc is not utilized by other OpenVX nodes. After vxGraphParameterDequeueDoneRef is executed, we will process the obtained image for other purposes, such as saving it or passing it to other algorithms for processing.

    Thanks and best regards.

  • In that case, can you please avoid using LDC from the modules folder, essentially app_init_ldc and app_create_graph_ldc APIs? and create LDC node in your example application. Then you can control the LDC output. you can create an object array of this output and also replicate this node if required and can also get this output as graph parameter and send it for further processing. 

    Regards,

    Brijesh

  • Hi

    So, is it your meaning that the initialization code of ldc in the current modules folder will have this problem? If it needs to be modified, do you mean that the output should be changed to an object array?

    Thanks and best regards.

  • Yes, since you are using LDC from the modules folder, it uses internally allocated object array and so it will not use intermediate object array from the application. You need to remove calls to module folder, and create LDC node from your application, just like single camera application or you need to update this module folder to make use of your intermediate buffers. 

    Regards,

    Brijesh

  • Hi,

    Thank you very much for your suggestion. We have modified the source code in the ldc module and found that there are still error messages printed. By further locating the source code, we discovered that due to the ldc node calling the vxReplicateNode to replicate the node, when the verify graph requested memory, it would request the space of the parent object. However, the mem_alloc_callback of the parent node was NULL, so the ldc memory was not allocated. I removed vxReplicateNode from the modified program and created 4 ldc nodes. As a result, no more error messages were printed and the image was normal. Could you please help me check if there are any problems with this approach? Thank you very much.

    Thanks and best regards.

  • Thanks a lot, finally this issue got resolved, so closing this thread.