No EOS from uridecodebin3

[Justin Bookshar]

I am working on an existing windows application written in Java, which uses the GStreamer Java bindings, and it has a video pipeline that performs several tasks. It uses several uridecodebin instances to download and decode RTSP streams. It then can display these in a single or quad view format and also write them to disk. I am trying to enhance this pipeline to support hardware decoding and a variety of other things. It was functioning using the original uridecodebin, but I had to upgrade to the latest GStreamer (1.22.7) to get hardware decoding working. During this process I had to swap out some older plugins and replace them with the compositor plugin to get the upgrade to work. I also wanted to move to uridecodebin3 as it seems to support decoding a wider variety of streams with more success in my testing. However, it should be noted the EOS in this pipeline has NEVER worked correctly. Previously we were using the uridecodebin drained signal to indicate the stream was done but uridecodebin3 does not have this signal. I have tried numerous things, and I am not able to get the pipeline to emit an EOS at the end of the stream.

1) I have added EOS callbacks to the pipeline and uridecodebin3 bus (which are the same) while setting the message-forward property to true.

2) I have added message callbacks to the pipeline and uridecodebin3 bus (which are the same) while setting the message-forward property to true and tried to search through all the messages for the EOS message and it is not found.

3) I have added a probe on the video source pad of the uridecodebin3 to look for the EOS event on this pad and this seems to work with some streams but not all.

I have searched through this forum and the archived mailing lists and have not really found a solution.

It should also be noted this pipeline does connect the uridecodebin3 plugin directly to an imagefreeze plugin. I have suspected this is a part of the problem and have seen some posts that indicate this could be contributing to the issues, but I am not certain.

1) I am somewhat new to GStreamer, what should I be looking for to debug this? I do see some EOS indicators in the GStreamer logs (listed below) from the uridecodebin3, but they just don't seem to be bubbled up to the pipeline layer and in some instances they don’t even reach the probed source pad.

0:00:46.821485000   576 000000002418F240 FIXME             decodebin3 gstdecodebin3.c:2465:multiqueue_src_probe:<multiqueue0:src_1> EOS on multiqueue source pad. input:0000000036476420
0:00:46.822014000   576 000000002418F1C0 FIXME             decodebin3 gstdecodebin3.c:2465:multiqueue_src_probe:<multiqueue0:src_0> EOS on multiqueue source pad. input:0000000036476520
0:00:46.822051000   576 000000002418F240 FIXME             decodebin3 gstdecodebin3.c:2465:multiqueue_src_probe:<multiqueue0:src_1> EOS on multiqueue source pad. input:0000000036476420


2) I see this text (below) for the EOS message in the GStreamer documentation. Does this mean every single sink in the uridecodebin3 must post the EOS before it would be passed outside of the bin and then at that point every element in our pipeline must also post the EOS before it would be pushed up to the pipeline level message handler callback? If so, I don't think we could ever meet this requirement with 4 independent video streams alive simultaneously.

GST_MESSAGE_EOS: This message is only posted by sinks in the PLAYING state. If all sinks posted the EOS message, this bin will post and EOS message upwards.

3) What is the "best practice" for detecting and handling the end of a stream. The current code is setup to restart on EOS automatically and I need to maintain this behavior. Assuming a true EOS may not always be emitted for a variety of reasons (network issues etc.) Is the best way to handle this to implement some type of watchdog timer on data flowing out of the source pad of the uridecodebin3 and then if this pad is idle for too long, I declare the stream as done / dead and react accordingly?

4) Is there an easy way to get to the “first” source pad inside a uridecodebin3 element. Given that the internal pipeline is built on the fly, I would suspect this is not an easy thing to do. You’d either have to build a list of known source plugins to search for by stream type, or intelligently walk back the graph pad to pad until you hit something without a sink pad. Is there a better / cleaner way? Does the source-setup signal provide this element?

Thanks,
Justin