Inconsitency with new Streammux `frame-duration` property. Docs vs. implementation

Accelerated Computing Intelligent Video Analytics DeepStream SDK
1

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU) both
• DeepStream Version
6.3
• JetPack Version (valid for Jetson only)
• TensorRT Version
• NVIDIA GPU Driver Version (valid for GPU only)
• Issue Type( questions, new requirements, bugs)
Questions re: new Streammux plugin - frame-duration property.

The Deepstream docs for new Streammux define the frame-duration property as

Duration of input frames in milliseconds for use in NTP timestamp correction based on frame rate. If set to 0 (default), frame duration is inferred automatically from PTS values seen at RTP jitter buffer. When there is change in frame duration between the RTP jitter buffer and the nvstreammux, this property can be used to indicate the correct frame rate to the nvstreammux, for e.g. when there is an audiobuffersplit GstElement before nvstreammux in the pipeline. If set to -1, disables frame rate based NTP timestamp correction.

Signed integer, -1 to - 147483647

gst-inspect-1.0 shows

  frame-duration      : Duration of input frames in milliseconds for use in NTP timestamp correction based on frame rate.
                        If set to 0, frame duration is inferred automatically from PTS values.
                        If set to -1, disables frame rate based NTP timestamp correction (default).
                        flags: readable, writable
                        Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 18446744073709

I’m assuming both are wrong and that it should be a Signed Integer64 ?
And when I read the default plugin value I definitely get 18446744073709 not 0

3

The default value of is frame-duration property is GST_CLOCK_TIME_NONE which type is GstClockTime. Yes, it should be signed integer.

5

Just to follow up, it doesn’t matter what you set the value to… 18446744073709 is always returned on get.