[Live-devel] Urgent help needed!

[Ross Finlayson]

>As to the "correct" way of doing packet duration calculations, it
>would be to buffer the incoming data until you have  the next PCR, and
>calculate time per packet based on the PCRs actually related to the
>data between.

Perhaps, although this would add a little latency, and require 
buffering (and add a lot of complexity) at the server. 
Architecturally, with memory being so cheap these days, it seems much 
better to require that *clients* have sufficient buffer memory to 
handle not just variable-bitrate streams, but also network jitter 
(which buffering at the server could never eliminate).

>If Victors live input is variable bitrate, and especially if there are
>big variations, he could experience too low bitrate at some points.

He seemed to be complaining, however, about the *average* output 
bitrate from "MPEG2TransportStreamFramer" being too low.  If that's 
the case, then I don't understand how that could be occurring.  If 
the PCR values in the Transport Stream are correct, then the average 
output bitrate from "MPEG2TransportStreamFramer" should also be 
correct.

If, however, the average output bitrate from 
"MPEG2TransportStreamFramer" is correct (as it should be), but the 
output bitrate has too much variability for your client(s), then you 
may be able to overcome this by tweaking the constants 
"NEW_DURATION_WEIGHT", "TIME_ADJUSTMENT_FACTOR", and 
"MAX_PLAYOUT_BUFFER_DURATION".  (If you do this, though, you're 
definitely on your own...)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/