I have the appsink -> appsrc wrapped in a Bin with the pads Ghosted. I have
the entire thing wrapped in a Pipeline. (as a Note I ALSO tried this by
gating the appsrc.pushBuffer using the AppSrc.NEED_DATA/ENOUGH_DATA and
I registered a listener on the Pipeline so I could track state changes to
help me debug. What I'm seeing is, occasionally the Pipeline will not come
out of the PAUSE state. It seems to come out of the PAUSE state most of the
time but it occasionally hangs.
It ALWAYS hangs if I replace the final xvimagesink with: theoraenc ! oggmux
Also, if I chain more than one of these appsink -> appsrc "breakouts" I get
extra frames in the final sink. I'm guessing this is due to not managing the
PREROLL correctly but if I drop the PREROLL from either breakout the pipe
Can someone tell me what I'm missing? Clearly I'm not understanding
I should also note for the sake of completion that for the breakout (appsink
-> appsrc), the first frame that arrives on the appsink through
NEW_SAMPLE/NEW_PREROLL causes a read of the current negotiated caps on the
appsink's sink pad. Those caps are then transferred to the appsrc using
setCaps (on the java side. This is gst_app_src_set_caps on the c side).
It looks like the PREROLL is called on the AppSink when the AppSink is in
the READY state. When it doesn't work, even if the PREROLL callback returns
a FlowReturn of OK, it doesn't seem to move into the PAUSED state.
If I add a log message from the PREROLL callback, even the tcpserversink
will work sometimes. So it seems like a race condition somewhere but I have
no idea what to wait for or block on or where.