Issues with GStreamer Pipeline on Raspberry Pi 5 – QTDemux Linking Error

Application Development
1

Hi everyone,

I’m having trouble building a GStreamer pipeline on my Raspberry Pi 5. The pipeline is meant to read an MP4 file, demux it, decode the H265 stream, apply a 3D rotation effect, and finally display it. However, I consistently encounter an error related to the qtdemux element.

Here are the details:

  1. Pipeline Using fakesink Works
    When I run:

    gst-launch-1.0 filesrc location=/home/intenscity/Videos/test.mp4 ! qtdemux name=demux demux.video_0 ! fakesink

    the pipeline reaches EOS without error. This shows that qtdemux is able to extract a video pad (named “video_0”) from the file.

  2. Pipeline Fails When Linking to Decoder and Effect
    When I modify the pipeline to decode and process the video:

    gst-launch-1.0 filesrc location=/home/intenscity/Videos/test.mp4 ! qtdemux name=demux \
demux.video_0 ! queue ! h265parse ! avdec_h265 ! videoconvert ! gltransformation rotation-x=30 rotation-y=20 rotation-z=10 ! autovideosink

    I get the following errors:

    • Warning:
      AVERTISSEMENT : de l’élément /GstPipeline:pipeline0/GstQTDemux:demux : Échec du chargement dynamique différé.
      (Translation: “Warning: Element … failed deferred dynamic loading.”)
    • Error:
      ERREUR : de l’élément /GstPipeline:pipeline0/GstQTDemux:demux : Internal data stream error.
    • Debug Information:
      subprojects/gstreamer/gst/parse/grammar.y(950): gst_parse_no_more_pads (): /GstPipeline:pipeline0/GstQTDemux:demux:
failed delayed linking pad video_0 of GstQTDemux named demux to some pad of GstQueue named queue0
../subprojects/gst-plugins-good/gst/isomp4/qtdemux.c(7552): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstQTDemux:demux:
streaming stopped, reason not-linked (-1)

It appears that while qtdemux successfully creates a “video_0” pad, the downstream elements are not being linked to it. The error “failed delayed linking pad video_0 of GstQTDemux named demux to some pad of GstQueue named queue0” indicates that the automatic (delayed) pad linking is failing—resulting in an “Internal data stream error” and the pipeline not moving past the PRE-ROLL phase.

Potential causes/solutions I’ve considered:

  • File Integrity: Although the file plays with a simple fakesink test, it might contain metadata or structure that causes qtdemux to fail when linking further elements.
  • Manual Linking: Removing parsebin (or replacing it with h265parse) might be necessary, as it seems that the delayed linking isn’t completing correctly.
  • Element Availability: I’ve also checked that the decoding elements (like v4l2slh265dec, avdec_h265) are available and properly installed.
  • Alternative Pipeline Construction: I’m considering building the pipeline by manually specifying the demux output to avoid delayed linking issues.

Any help or suggestions on how to resolve the pad linking problem with qtdemux would be greatly appreciated!

Thanks in advance.

2

This is missing a glupload ! glcolorconvert before gltransformation. Also, there is no guarantee that the video sink chosen by autovideosink will accept the output of gltransformation. If you need that, you should use glimagesink directly.

1 Like
3

Thanks @ystreet00 ! It’s good now