Please add a test case of ML-Inference-Single::NNTrainer

[myungjoo]

https://github.com/nnstreamer/api/blob/95faa11b553861a42cedb4cae441f87a9ec353ce/c/src/ml-api-inference-single.c#L833-L853

  if (nnfw == ML_NNFW_TYPE_NNTR_INF) {
    if (!in_tensors_info || !out_tensors_info) {
      if (!in_tensors_info) {
        ml_tensors_info_h in_info;
        status = ml_tensors_info_create (&in_info); ////////// 1.
        if (status != ML_ERROR_NONE) {
          goto error;
        }


        /* ml_single_set_input_info() can't be done as it checks num_tensors */
        status = ml_single_set_gst_info (single_h, in_info);  /////////// 2.
        ml_tensors_info_destroy (in_info);
        if (status != ML_ERROR_NONE) {
          goto error;
        }
      } else {
        status = ml_single_set_input_info (single_h, in_tensors_info);
        if (status != ML_ERROR_NONE) {
          goto error;
        }
      }

This C-API code appears very strange. Please test it with a unit test.

The smelly part is:

1. create an "empty" in_info
2. configure single_h with the in_info from 1, which is supposed to return -EINVAL.

[taos-ci]

:octocat: cibot: Thank you for posting issue #1771. The person in charge will reply soon.

[zhoonit]

Background

This was added to mitigate slight semantic difference between nnstreamer in gstreamer behavior and ml_api_singleshot behavior.

Long story short, nntrainer inference filter wants to use default dimension if not given from user, if user gives one, we want to set output dimension according to it.

To make it done, we need for nnstreamer to resolve dimensions in different order. As this will make undesirable semantic changes in nnstreamer side, the reported workaround was adopted(sending invalid info and and consume inside nntrainer filter) as per suggestion from @jaeyun-jung.

tests

• gst: https://github.com/nnstreamer/nntrainer/blob/main/test/nnstreamer/runTest.sh#L75-L93
• ml_singleshot: https://github.com/nnstreamer/nntrainer/blob/main/test/nnstreamer/test_nnstreamer_single.cpp#L150-L160

I believe all the branches from the reported code bits has been covered in above tests.

Please circle back if more tests should be added or if I am getting something wrong :)