RidgeRun / gst-shark

GstShark is a front-end for GStreamer traces
GNU Lesser General Public License v2.1
94 stars 45 forks source link

Schedule Time tracer blocking pipeline on rtpjitterbuffer and rtph264depay #114

Closed DougCWhite closed 2 years ago

DougCWhite commented 2 years ago

I am trying to profile a gstreamer pipeline that is taking an H264 encoded UDP stream from a camera and displaying it on an i.MX6 based display. I built a yocto image for the display featuring the yocto-zeus branch of the meta-ridgerun repo.

When running with the scheduletime tracer enabled, I noticed that ~95% of the trace events are coming from the rtpjitterbuffer and rtph264depay elements and my camera feed is never being rendered on the display. I've attached the resulting datastream and metadata in the zip archive: traceData.zip

Disabling the tracer and running the same pipeline has the expected result of showing the camera feed on the display.

My gstreamer pipeline is as follows: gst-launch-1.0 udpsrc port=1234 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtpjitterbuffer ! rtph264depay ! h264parse ! imxvpudec enable-frame-reordering=false ! imxipuvideosink sync=false use-vsync=true

I've been adding GST_DEBUG="GST_TRACER:7" GST_TRACERS="scheduletime" at the start of the pipeline to enable the tracer.

Are there any configurations in either gstreamer or gst-shark that I need to enable/disable to allow the full pipeline to run?

DougCWhite commented 2 years ago

Found this link: https://developer.ridgerun.com/wiki/index.php/IMX8/Multimedia/GStreamer_Support/Hardware-accelerated_plugins

Mentions that performance is better when suppressing log output with &> /dev/null. Gave it a try and got much better results.