Metamux showed odd outputs

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU): GeForce RXT 3090
• DeepStream Version: 6.1.1
• TensorRT Version: 8.4.1.5
• NVIDIA GPU Driver Version (valid for GPU only): 515.65.01
• Issue Type( questions, new requirements, bugs): question

My pipeline has 2 sources and its high-level view is as follow:

sources -> muxer -> pgie -> dexmuxer |-> muxer -> sgie-1 |                  
                                     |->      ....       | -> metamuxer -> sink
                                     |-> muxer -> sgie-n |

  • There are 2 sources
  • There are n sgies running in parallel
  • Each branch uses both sources
  • The pipeline doesn’t have a tracker

I have these 2 probes:

GstPadProbeReturn pgie_src_probe(
    GstPad *pad, 
    GstPadProbeInfo *info,
    gpointer u_data)
{
    GstBuffer *buf = (GstBuffer *)info->data;
    NvDsMetaList *l_frame = NULL;
    NvDsFrameMeta *frame_meta = NULL;

    NvDsBatchMeta *batch_meta = gst_buffer_get_nvds_batch_meta(buf);

    static guint batch_id = 0;
    g_message("==============BATCH[%d]==============", batch_id);
    
    for (l_frame = batch_meta->frame_meta_list; l_frame != NULL; l_frame = l_frame->next)
    {
        frame_meta = (NvDsFrameMeta *)(l_frame->data);
        g_message("%s: num frames = %d, frame_meta->batch_id=%d, frame_meta->buf_pts=%ld", __func__, g_list_length(batch_meta->frame_meta_list), frame_meta->batch_id, frame_meta->buf_pts);
        
    }

    batch_id++;

    return GST_PAD_PROBE_OK;
}

GstPadProbeReturn metamux_src_probe(
    GstPad *pad, 
    GstPadProbeInfo *info,
    gpointer u_data)
{
    GstBuffer *buf = (GstBuffer *)info->data;
    NvDsMetaList *l_frame = NULL;
    NvDsFrameMeta *frame_meta = NULL;

    NvDsBatchMeta *batch_meta = gst_buffer_get_nvds_batch_meta(buf);

    static guint batch_id = 0;
    
    for (l_frame = batch_meta->frame_meta_list; l_frame != NULL; l_frame = l_frame->next)
    {
        frame_meta = (NvDsFrameMeta *)(l_frame->data);
        if(frame_meta->batch_id >= g_list_length(batch_meta->frame_meta_list))
        {
            g_message("==============BATCH[%d]==============", batch_id);
            g_message("%s: num frames = %d but frame_meta->batch_id=%d, frame_meta->buf_pts=%ld", __func__, g_list_length(batch_meta->frame_meta_list), frame_meta->batch_id, frame_meta->buf_pts);
        }
    }

    batch_id++;

    return GST_PAD_PROBE_OK;
}
  • pgie_src_probe is attached to the pgie’s src pad
  • metamux_src_probe is attached to the metamux’s src pad

Both of these probes just iterate the batch meta’s frame_meta_list and print the number of frames in the batch, each frame’s batch_id and buf_pts. metamux_src_probe only prints when it detects that a frame whose batch_id is invalid based on the batch size.

I observe odd behaviour:

Please pay attention to batch 76, after pgie, the batch size is 1 and frame batch_id is 0 which is expected, however, after metamux, the batch size is the same but the batch_id is changed to 1, which is wrong because frame_meta->batch_id “Holds the location of the frame in the batch”, if the batch size 1, there can be no position at index 1 since we’re using 0-indexed. The frame_meta->buf_pts is identical at both probe for batch 76 so I don’t think the cause is pts-tolerance is too low (I set it to 360ms or 360000 micoseconds).

Is this expected behaviour?

could you share your configuration? could you use memamux sample to reproduce this issue? GitHub - NVIDIA-AI-IOT/deepstream_parallel_inference_app: A project demonstrating how to use nvmetamux to run multiple models in parallel.

I tried to adapt the samples in GitHub - NVIDIA-AI-IOT/deepstream_parallel_inference_app: A project demonstrating how to use nvmetamux to run multiple models in parallel. to run on a local machine instead of on a server.

Modified app:

tritonclient/sample/apps/deepstream-parallel-infer/deepstream_parallel_infer_app.cpp (49.9 KB)

diff (4.4 KB)

Modified build script: On my local machine, I need sudo make instead of make in the build script tritonclient/sample/build.sh

build.sh (437 Bytes)

First issue, live sources are not supported, I tried to modify tritonclient/sample/configs/apps/bodypose_yolo_win1/sources_4.csv to use a webcam:

sources_4.csv (108 Bytes)

But I got:

Running...
** ERROR: <cb_newpad:234>: Failed to link decodebin to pipeline
** ERROR: <cb_newpad:234>: Failed to link decodebin to pipeline
ERROR from element source: Internal data stream error.
Error details: gstbasesrc.c(3072): gst_base_src_loop (): /GstPipeline:deepstream-tensorrt-openpose-pipeline/GstBin:multi_src_bin/GstBin:src_sub_bin0/GstURIDecodeBin:src_elem/GstV4l2Src:source:
streaming stopped, reason not-linked (-1)
Quitting
Returned, stopping playback
Deleting pipeline
App run successful

Second issue, I tried to add multiple sgies to the pipeline using these configs:

tritonclient/sample/configs/apps/bodypose_yolo_win1/source4_1080p_dec_parallel_infer.yml (7.5 KB)
tritonclient/sample/configs/apps/bodypose_yolo_win1/secondary-gie00.yml (2.1 KB)
tritonclient/sample/configs/apps/bodypose_yolo_win1/secondary-gie01.yml (1.9 KB)
tritonclient/sample/configs/vehicle/dstest2_pgie_config.yml (3.5 KB)
tritonclient/sample/configs/vehicle/dstest2_sgie1_config.yml (3.7 KB)
tritonclient/sample/configs/vehicle/dstest2_sgie2_config.yml (3.7 KB)
tritonclient/sample/configs/vehicle/dstest2_sgie3_config.yml (3.7 KB)

Get the models to build engines:

cp -r /opt/nvidia/deepstream/deepstream-6.1/samples/models/Primary_Detector/* $HOME/deepstream_parallel_inference_app/tritonserver/models/test/Primary_Detector
cp -r /opt/nvidia/deepstream/deepstream-6.1/samples/models/Secondary_CarColor/* $HOME/deepstream_parallel_inference_app/tritonserver/models/test/Secondary_CarColor
cp -r /opt/nvidia/deepstream/deepstream-6.1/samples/models/Secondary_CarMake/* $HOME/deepstream_parallel_inference_app/tritonserver/models/test/Secondary_CarMake
cp -r /opt/nvidia/deepstream/deepstream-6.1/samples/models/Secondary_VehicleTypes/* $HOME/deepstream_parallel_inference_app/tritonserver/models/test/Secondary_VehicleTypes

What I expect is (simplified view):

sources -> mux -> demux -> |mux -> pgie1 -> sgie11 -> sgie12 -> sgie13| -> metamux -> sink
                           |mux -> pgie2 -> sgie21 -> sgie22 -> sgie23| 

However, when I generate the pipeline graph from this dot file:

pipeline.dot (122.4 KB)

The pipeline looks very odd:

All added sgies goes to a fake sink instead of going to the metamux. There is also a random queue that go directly to the metamux.

May be I made some mistakes modifying the configs?

can you run ./apps/deepstream-parallel-infer/deepstream-parallel-infer -c configs/apps/bodypose_yolo/source4_1080p_dec_parallel_infer.yml without any modification? there is pipeline graph in readme, it is similar to your expected pipeline.

Without any modification, after I ran ./apps/deepstream-parallel-infer/deepstream-parallel-infer -c configs/apps/bodypose_yolo/source4_1080p_dec_parallel_infer.yml, I got:

src_ids:0;1;2
src_ids:1;2;3
src_ids:1;2;3
NVDSMETAMUX_CFG_PARSER: Group 'user-configs' ignored
** ERROR: <create_primary_gie_bin:120>: Failed to create 'primary_gie'
** ERROR: <create_primary_gie_bin:185>: create_primary_gie_bin failed
** ERROR: <create_parallel_infer_bin:1199>: create_parallel_infer_bin failed
creating parallel infer bin failed
Quitting
App run successful

I noticed that:

I used the bodypose_yolo_win1 instead. Since bodypose2d engine is not built, I replace it with yolo4 and use nvinfer instead of nvinferserver. The modified config file is:

source4_1080p_dec_parallel_infer.yml (7.5 KB)

The file coco.names needs to be renamed to labels.txt.

The command I use: GST_DEBUG_DUMP_DOT_DIR=. ./apps/deepstream-parallel-infer/deepstream-parallel-infer -c configs/apps/bodypose_yolo_win1/source4_1080p_dec_parallel_infer.yml

The pipeline run normally, but when I inspect the generated dot file, source bins looks odd:

The URI decode bin is created but not linked to anything.

Upon further inspection, the issue occurred before the metamux plugin, the issue actually occurred some where between the streamdexmuxer and the streammuxer of each branch. I’m marking this as the answer and will follow up in a new thread since the issue is not related to the metamux plugin.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.