Hello!
I am using QGroundControl application that has a fairly big, dynamic pipeline.
Which works only for the first time the application (re)starts but doesn’t when the pipeline is rebuilt (because of RTSP source change, or the pipeline is stopped, then restarted).
I created two graphs of the working and hanging pipeline. They are very similar except the capsfilter inside decodebin3. And saved the log file, that you can check at the github issue, you can also find more details about the hardware (camera, android device): Android GStreamer pipeline only starts once at application startup · Issue #11676 · mavlink/qgroundcontrol · GitHub.
The most suspicious lines in the log file are the ones printed at GstTypeFindElement:
When the pipeline works it says:
[I] at …/plugins/elements/gsttypefindelement.c:181 - " found caps video/x-h265, width=(int)1920, height=(int)1080, framerate=(fraction)0/1, parsed=(boolean)true, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)main, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, colorimetry=(string)1:3:5:1, tier=(string)main, level=(string)4.1, probability=100"
When it doesn’t:
[I] at …/plugins/elements/gsttypefindelement.c:181 - " found caps video/x-h265, width=(int)16, height=(int)16, framerate=(fraction)0/1, parsed=(boolean)true, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)main-10, probability=100"
That’s why I think the pipeline stops because the decoder can’t negotiate. I tried modifying the pipeline by replacing the decodebin with a specific HW decoder and the parsebin with an rtph265depay and h265parse element (so I can get rid of the typefind elements), but sadly the app crashes when I replaced the parsebin.
I would appreciate any suggestions if I am on a wrong track or any experience that you can share.