I am writing a bin element that is supposed to be used as an audio sink.
Internally, there is an identity element, whose sink pad is ghosted in
the _init() function. The identity pad is the "front", the entrypoint
for audio data. I did this to make sure that the bin's ghost sinkpad is
always linked to an existing element. During the NULL->READY state
change, I then choose which internal sink element to create and use, and
link that one to the identity element's srcpad.
This means that prior to the NULL->READY state change, the identity
element's srcpad is unlinked. This worked fine in pipelines like
decodebin ! my-sink-bin .
But then I tried to use my sinkbin with gst-play, and it didn't work.
gst-launch-1.0 playbin audiosink="my-sink-bin" didn't either. It turns
out that for some reason, the internal playsink recursively walks into
the sinkbin and decides to create a ghost srcpad that is linked to the
identity srcpad. Then, during the NULL->READY state change, linking the
internal sink to the identity pad doesn't work, because the srcpad is
ghosted.
I did a workaround by creating an initial fakesink and link it to the
identity element. During the NULL->READY state change, I get rid of that
fakesink and link the internal sink instead. This fixes the problem, but
I wonder why playsink is doing this. Is this by design, or is this a bug?
Oh, also, I was using GStreamer 1.10.4 here (the packaged version in
Ubuntu 17.04). I'll try with git master later.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Locked
