<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:10pt"><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;">Thanks for the replies sent on the subject of RTP-over-TCP<br><br>I've looked into this issue and have managed to get good results. <br><br>The original problem I had was using testOnDemandRTSPServer example to play a stream of of
mpeg4 encodered frames (elementary stream) via TCP (RTP over TCP). The
video is played for short duration (a minute to 20 minutes) and then stops. <br><br>I sniffed the packets used in the above configuration and compared them to a working TCP streaming server source. One of the differences found was a specification of a session timeout included in the working streaming server RTSP responses.<br><br>Example:<br>Session: 457942862;timeout=80<br><br>This timeout appears in the RTSP server response to both SETUP and PLAY RTSP commands.<br><br>As a result of adding the session timeout, the client periodically sends keep-alive messages which VLC refers to as "live 555 debug: reset the timeout timer".<br>This keep-alive client message requires the server to reply to that message, something which was not currently implemented in live. I've added a simple implementation to answer the keep-alive message (two different ones, for VLC and Real-Player).<br><br>As a result of doing the above I now have what appears to
be a working RTP-over-TCP streaming solution for mpeg4 encodered frames.<br><br>I'd appreciate any input on the meaning of the session timeout field, its recommended value (80?). <br><br>Regarding a different matter, I am curious if adding the session timeout will help solve video frame timing glitches (?) that cause clients (such as VLC) to treat video packets as old packets after a long time that video plays. <br>In such cases all packets are referred to as "late picture skipped(65137)" and the following message is displayed: "more than 5 seconds of late video -> dropping frame (computer too slow ?)" In such a situation all packets are assumed as old and no video is displayed.<br><br>I will keep testing to see if such a situation appears with the session-timeout addition.<br><br>Noam Camiel<br><br></div></div><br>__________________________________________________<br>Do You Yahoo!?<br>Tired of spam? Yahoo! Mail has the best spam
protection around <br>http://mail.yahoo.com </body></html>