Hi,
I have a pipeline with a basic pipeline structure like:
filesrc -> stuff -> tee
tee -> queue -> more stuff -> sink1
tee -> queue -> even more stuff -> sink2
...
tee -> queue -> still more stuff -> sinkN
The problem is sometimes one of the branches can ‘go wrong’.
For example if "more stuff" has the wrong kind of audio decoder (in my case mpg123dec instead of something to handle AAC) then sink1 never sinks anything (e.g. if a filesink the file stays empty).
However, all the elements seem to keep running and no problem is reported.
The pipeline never receives a EOS on the bus and my program hangs instead of exiting when the filesrc reaches the end of the file.
I was confused for a long time over this as the last event of interest was as a different queue overrunning though the branch and sink elements of that queue were fine.
Is there a conventional way of detecting such problems?
No bus messages leapt out at me and the element all seem to be running.
Presumably I need to track the buffers or lack thereof getting into the final sink element of each branch?
Also I think I might need another (more robust) way of detecting the end of the input stream.
So if a problem like this does occur I at least know when all the input has been read.
I think what I need to do is add a PAD_PROBE_TYPE_EVENT_FLUSH probe to the source element to catch EOS events there. Is that right?
I haven't quite groked how to add the necessary probe.
The probe has to be added after the element is ready or “pad not activated yet” is emitted.
I tried adding it on receipt of a bus message telling me that the filesrc has gone from ready to paused.
However, I don’t see any events from the source probe, least of all an EVENT_EOS.
If I use PAD_PROBE_TYPE_ALL_BOTH with add_probe I see:
GStreamer-CRITICAL **: gst_pad_probe_info_get_event: assertion 'info->type & (GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM | GST_PAD_PROBE_TYPE_EVENT_UPSTREAM)' failed
Any tips?
Regards,
Bruce.
Locked
