The UStream channel goes live with the video test pattern.
What I really want to do is start the pipeline with a fakesink in place of the rtmpsink, and then after a few seconds, swap in an rtmpsink. I do the whole pad-blocking dance to replace the element, and when I'm done, the debug graph shows everything playing, and UStream shows the station is live, but the video is just black with no video test pattern.
The only interesting thing I can see so far is that when returning from the blocking probe callback, I receive the message "TypeError: int() argument must be a string or a number, not 'NoneType'". I had thought it might be a bindings quirk, but it's the only lead I have right now.
The issue I had was at the point the pipeline is created, the application doesn't know the user's UStream rtmp url. Unfortunately, if the rtmpsink tries to start playing with an invalid url, it throws errors.
I guess maybe I could have a valve ahead of the rtmpsink, and leave the rtmpsink in the READY state until it has enough data to configure it's url? The biggest thing that confused me about the swapping-in approach is that it works if the swap is done very quickly (scripted to happen immediately rather than waiting for use input), and when done later, is still seeing something that UStream identifies as valid data, just only has black video.
> Alternatively, you can also think of adding a queue before rtmpsink plugin and connect the queue to the sink based on queue callback("running" signal)
Sorry if I'm missing something important. How does connecting the rtmpsink plugin on the queue callback signal help? When looking at the debug messages, it seems like everything gets to PLAYING successfully, and the anomaly is that the video is just a black image. How does the timeout of the RTMP connection affect the video stream? It seems like the RTMP connection is successful because UStream says the channel is "live."