Kevin Marks busts a move:
> At 3:06 PM -0800 11/30/00, Jim Van Vorst wrote:
> >First, many thanks to Kevin Marks for helping me get my ulaw-and-jpeg
> >streaming server to talk to Quicktime player. I am now successfully streaming
> >synchronized audio and video over RTP.
>
> Glad to hear it - got any example URLs?
Right now I just have one unit limping along in proof of concept stage that
I'm actively developing on, so I don't have anything available for outside
consumption yet (besides - 1 connection swamps our T1!).
> >My next question is about buffering and latency. RFC 1890 specifies a clock
> >rate for ulaw (8000Hz) and jpeg (90000Hz). With each RTP packet, you include
> >a timestamp which is the sampling instant of that data. If my timestamps are
> >incremented according to the RFC, my audio and video are synchronized, but
> >there is about a 5 second latency, like maybe Quicktime is buffering up 5
> >seconds in case of network burpage.
>
>
> >If I "lie" about the jpeg timestamps, and increment the stamp by, say, 4000
> >each second instead of 90000 each second, the video runs without perceptible
> >latency, but the audio is still lagging. If I try to lie about the audio
> >rate, I get no audio at all. I can't seem to lower the latency on the audio.
> >
> >My goal is to get both the audio and video to have low delay. Does Quicktime
> >always buffer the stream for some set number of seconds, or is there something
> >I can do with the stream to tell it not to do that?
>
>
> QT buffers 3 seconds by default. You can set this in the sdp file
> with the a=x-bufferdelay:x.x parameter, with x in seconds.
>
> It may not let you set it below 3 though.
Are these sdp settings documented someplace?
Thanks,
Jim
