I am using Live555 libraries to stream H264 video provided by a
frame grabber, via RTP (not RTSP).
I use VLC and VLC activeX as a RTP/H264 client.
Sometimes, I need to change the camera used by the framegrabber, so
I close the RTP sink, the framer, the source, and I open them again
with the new video. Doing that, (even with the same video
parameters), the client often hang (but not every time), and
sometimes go on playing again but with a big delay.
How can I prevent the client from freezing the video or display the
video with delay ? Sending some missing frames ? Special trick to
warn client ?
My main objective is LOW latency, some image skips are not a problem.
I suspect that your problem is caused by the fact that each sending
camera (server) necessarily uses a different RTP timestamp base, and
so when you switch to receiving from a new camera, the received
data's presentation time will briefly be inaccurate, until you
receive a new RTCP "SR" packet from the new source. (I'm assuming
that your servers send RTCP as well as RTP; because you're using our
software, that should be the case.)
One way to reduce this problem is to increase the average RTCP
sending frequency, which you can do by increasing the "totSessionBW"
parameter that you pass to "RTCPInstance::createNew()". (This
parameter is intended to represent the stream's bitrate in kbps. It
is used - by the RTCP code - to figure out how often to send RTCP
packets.)
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
