[Live-devel] Possible bug in liveMedia + info request about H263 / H263plus compatibility
Cristiano Belloni
belloni at imavis.com
Thu Jan 10 06:11:24 PST 2008
>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>
belloni at imavis.com <mailto://belloni@imavis.com>
More information about the live-devel
mailing list