udp streaming: reconnect on the fly

[Charles]

I'm live streaming from a usb encoder using a device node filesrc and a
udpsink (the "server"), and then playing the video on my client from the
udpsrc.

If I leave the client video open, but kill the server, the video freezes,
as expected. When I restart the server, the video continues streaming.

If I kill the client, however, I cannot reconnect to the stream without
restarting the server.

Is there any way to stop and start the client, without having to restart
the server?

I'd also like to have multiple clients, each with their own IP address, who
could each connect/disconnect from the stream, without restarting the
server. Is this possible?

[Andrey Utkin]

Post by Charles
I'm live streaming from a usb encoder using a device node filesrc and a
udpsink (the "server"), and then playing the video on my client from the
udpsrc.
If I leave the client video open, but kill the server, the video freezes, as
expected. When I restart the server, the video continues streaming.
If I kill the client, however, I cannot reconnect to the stream without
restarting the server.

Shouldn't be so. You have to figure out what's wrong with the client
(BTW which clients have you tried? Did you try such opensource clients
like gst-launch, vlc, ffplay?). Maybe it doesn't close socket
gracefully and next time it cannot bind to it.

Post by Charles
I'd also like to have multiple clients, each with their own IP address, who
could each connect/disconnect from the stream, without restarting the
server. Is this possible?

Use multicast UDP address for stream.

[Andrey Utkin]

BTW which multimedia container (format) do you use for streaming? MPEG TS?

[hobbesc7]

Post by Andrey Utkin
BTW which multimedia container (format) do you use for streaming? MPEG TS?

x-h264?

On the server:

gst-launch -v filesrc location=/dev/video0 ! queue ! video/x-h264 !
udpsink host=192.168.1.100 port=5011

On the client:

gst-launch -v udpsrc port=5011 ! decodebin2 ! xvimagesink sync=false



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/udp-streaming-reconnect-on-the-fly-tp4664785p4664798.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.

[Andrey Utkin]

Post by hobbesc7

Post by Andrey Utkin
BTW which multimedia container (format) do you use for streaming? MPEG TS?

x-h264?
gst-launch -v filesrc location=/dev/video0 ! queue ! video/x-h264 !
udpsink host=192.168.1.100 port=5011

Haven't check it, so cannot substantiate should it work or shouldn't.
But to be safe, i'd suggest you to try

gst-launch -v filesrc location=/dev/video0 ! queue ! video/x-h264 !
h264parse ! mpegtsmux ! udpsink host=192.168.1.100 port=5011

(h264parse may be not necessary, try without it to check if it still works.)

Maybe the client can stay the same, or, to be sure,

gst-launch -v udpsrc port=5011 ! tsdemux ! decodebin2 ! xvimagesink sync=false

MPEG TS is surely loss tolerant and can start playback mid-stream.

[Sebastian Dröge]

Post by Andrey Utkin

Post by hobbesc7

Post by Andrey Utkin
BTW which multimedia container (format) do you use for streaming? MPEG TS?

x-h264?
gst-launch -v filesrc location=/dev/video0 ! queue ! video/x-h264 !
udpsink host=192.168.1.100 port=5011

Haven't check it, so cannot substantiate should it work or shouldn't.
But to be safe, i'd suggest you to try
gst-launch -v filesrc location=/dev/video0 ! queue ! video/x-h264 !
h264parse ! mpegtsmux ! udpsink host=192.168.1.100 port=5011
(h264parse may be not necessary, try without it to check if it still works.)
Maybe the client can stay the same, or, to be sure,
gst-launch -v udpsrc port=5011 ! tsdemux ! decodebin2 ! xvimagesink sync=false
MPEG TS is surely loss tolerant and can start playback mid-stream.

At least if there are keyframes and PPS/SPS of the video stream every
now and then. You can configure that resending of PPS/SPS with the
config-interval parameter on h264parse, for the keyframe interval you'll
have to check the documentation of your video capture driver.

Also use v4l2src for v4l2 devices, filesrc won't work reliably in
general as it's not just simple file IO that is required.

And UDP is not connection based, so the client will just continue to
play something when it receives something new on the port. There's no
need to "reconnect".