gstshark-plot does not graph along axis

[skyline220]

Hi,

GstSharkPlot seems to be an amazing tool but it does not graph along the axis, for example:

This is my pipeline: GST_DEBUG="GST_TRACER:7" GST_TRACERS="interlatency;cpuusage;proctime;framerate" gst-launch-1.0 udpsrc port=5000 buffer-size=2000000 ! application/x-rtp,encoding-name=JPEG,payload=26 ! rtpjpegdepay ! jpegdec ! videoconvert ! autovideosink

Do you know why this could be? I press ctrl+C in the terminal to close the pipeline could that be the issue?

Thanks

[fischer]

It could be the cntl+C. Try using the num-buffers argument to udpsrc, something like

gst-launch-1.0 udpsrc num-buffers=5000 ...

Please reply and close the issue if this fixes the graphing.

[skyline220]

Hi,

I have tried the suggestion of setting the num-buffers for udpsrc and letting that trigger an EOS signal and close the pipeline.

This is the modified pipeline:

GST_DEBUG="GST_TRACER:7" GST_TRACERS="interlatency;cpuusage;proctime;framerate" gst-launch-1.0 udpsrc port=5000 buffer-size=2000000 num-buffers=200000 ! application/x-rtp,encoding-name=JPEG,payload=26 ! rtpjpegdepay ! jpegdec ! videoconvert ! autovideosink

I am still getting the same result with the plot displaying incorrectly, here's an example:

Do you have any other suggestions?

Thanks

[skyline220]

Hi,

These graphs would be extremely helpful for a project I am working on. Is there any suggestions anyone has on how to fix?

Thanks

[rrcarlosrodriguez]

Hi @skyline220

We released a new version of Gst-Shark some days ago and the interlatency tracer was tested. Could you please give it a try pulling out the master branch and compiling again?

Also, could you please describe your system? What platform? What gstreamer version?

[skyline220]

Hi @rrcarlosrodriguez,

Thanks for your help so far. I am running Ubuntu 16.04.04 LTS and GStreamer 1.8.3. Based on your suggestion I re-compiled GstShark. I have found the results of the plot generation to be similar:

As fisher suggested earlier I let the EOS signal be triggered by using the num-buffers property.

This is the pipeline I am using (the sender is a 1920x1080@60FPS feed):

GST_DEBUG="GST_TRACER:7" GST_TRACERS="interlatency;proctime" gst-launch-1.0 udpsrc port=5000 buffer-size=2000000 num-buffers=360000 ! application/x-rtp,encoding-name=JPEG,payload=26 ! rtpjpegdepay ! vaapijpegdec ! videoconvert ! vaapisink

I am still getting the same result with the plot displaying incorrectly, here's an example:

Do you have any other suggestions?

Thanks

[skyline220]

Any suggestions on how to fix this please? Wanted to check as it has been a couple weeks

Thanks

[lleoncr]

Hi @skyline220.

Based on this client pipeline:

GST_DEBUG="GST_TRACER:7" GST_TRACERS="interlatency;cpuusage;proctime;framerate" gst-launch-1.0 udpsrc port=5000 buffer-size=2000000 num-buffers=200000 ! application/x-rtp,encoding-name=JPEG,payload=26 ! rtpjpegdepay ! jpegdec ! videoconvert ! autovideosink

How do you manage the streaming server? Is it starting around 3000-4000 seconds later than the client?

I replicated the conditions (same gstreamer version and OS) and I found that if I start the streaming server a time after the client, this time gap appears in the plots. For example: if I start the streaming server 10 seconds after the client, the plot starts in x=10 seconds.

You can test it using a sample streaming server with:

gst-launch-1.0 videotestsrc is-live=true ! videoconvert ! jpegenc ! rtpjpegpay ! udpsink host=localhost port=5000

[lleoncr]

Hi @skyline220

There is a fix to solve this issue available in develop 7d182f8 .

Please, if your issue is solved with this, close this issue report.

[skyline220]

Hi @lleon-ridgerun,

Compiling from the develop branch seems to have fixed the x-axis plotting issue, the only issue that remains is the framerate on the plot:

The framerate is very high on the plot, is this unrelated to this fix or something that should be fixed as part of this plotting issue? Please let me know and I will update or close this issue accordingly.

Thanks

[lleoncr]

Hi @skyline220,

Fix 7d182f8 does not change any feature of Y-axis, just X-axis. I have checked both versions master and 7d182f8, and they showed me the same results. Also, I tested with a clean install in both cases, and they are working properly and show a frame rate correctly.

We think that your _capsfilter0src is taking and processing so many small packets and it causes that the frame rate increases drastically in such component. In order to disable tracing it, you can filter it (you can see: Individual Element Tracing (filter)). In your case, you can set the filter up in GST_TRACERS like this:

framerate(filter=rtpjpegdepay0|updsrc0|vaapidecode_jpeg0)

In that case, the filter will select rtpjpegdepay0, updsrc0, and _vaapidecodejpeg0, excluding capsfilter0.

An example:

GST_DEBUG="GST_TRACER:7" GST_TRACERS="interlatency;cpuusage;proctime;framerate(filter=videoconvert0|udpsrc0)" gst-launch-1.0 udpsrc port=5000 buffer-size=2000000 num-buffers=200000 ! application/x-rtp,encoding-name=JPEG,payload=26 ! rtpjpegdepay ! jpegdec ! videoconvert ! autovideosink

Let us know if you have any further question or problem. If this Y-axis issue persists, we kindly ask you to open a new issue to solve it.