Correct way to reconnect to a network stream

strider4102 strider4102 at gmail.com
Thu Dec 15 12:39:07 PST 2011


Figured out the solution to both of my problems. I'll go ahead and post what
I did to solve it so others can learn from my fail.

>The MJPEG stream's only problem is it seems to take a while for it to
realize the connection has been lost (about 2 minutes), but once it does
detect the disconnect, it reconnects almost immediately, so I'm sure the fix
for this is probably as simple as changing a timeout property somewhere. 
It was just a simple property (called "timeout" no less), but that property
needs to be set BEFORE it connects to the stream (during the "source-setup"
event is a good time to do it) or it has no effect

>The RTSP/MPEG4 stream however is being a little more problematic. It takes
anywhere from 5 to 10 minutes to reconnect, during which it gets alternating
"Could not read from resource." and "Could not write to resource." errors.
Also, it takes a long time (duration varies, the first attempt is usually 15
seconds, but subsequent attempts take about 110 seconds) to go from the
playing state to the ready state. 
This one was a bit more tricky. I had to move the state change to a new
thread so the main loop can still dispatch and process messages while the
state change was occurring.

Now in both cases the streams come back up in a reasonable amount of time
(sometimes even a little before the orange light on the Axis goes green
indicating it's done booting up)



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Correct-way-to-reconnect-to-a-network-stream-tp4197164p4201879.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.


More information about the gstreamer-devel mailing list