[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