>he good news is that because you set "reuseFirstSource" to True, >this 'close+reopen' will happen only once, regardless of the number >of ciients that you have. However, it's unavoidable (and not a bug), >so you're going to have to find a way to live with it.
Ok. > I suggest that you first get your server to stream from a file > (containing pre-encoded H.263 video data). Only once you have that > working properly, should you move to the more difficult step of > streaming from a live encoder. Did it right now: server sends the prerecorded H263 raw file, and openRTSP receives it. It's still running, because the server sends a single frame (rtp packets + last marked packet) exactly every 8 seconds: [...] packet packet packet + marked [8 seconds of nothing] packet packet + marked [8 seconds of nothing] packet packet packet + marked [8 seconds of nothing] [...] What can the problem be? Also the timestamps of RTP packet seemp to reflect this gap. It's like the server is trying to send 0.125 (1/8) frames per second. Did you ever try to send H263 instead H263plus data with liveMedia? If not, can anyone try with a prerecorded file, preferibly encoded with ffmpeg's 'h263' (NOT 'h263p') video codec to confirm this behaviour? > No, not necessarily. Note that H.263 *can* (and, in fact, now > *should*) be sent using the H.263+ RTP payload format (which is what > we implement in our code). This relieves me :) I was starting to fear I would have to write H263VideoFileServerMediaSubsession. Thanks. -- Belloni Cristiano Imavis Srl. www.imavis.com <http://www.imavis.com> [EMAIL PROTECTED] <mailto://[EMAIL PROTECTED]> _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
