[Live-devel] TransportStreamFramer latency?

[Ross Finlayson]

>After some checking I am still not able to make out the source of the
>problem. To me it seems like TransportStreamFramer uses the time
>between PCR divided by the number of TS packets (or groups of TS
>packets GOTS) to determine the delay befor the scheduler will return
>and ask for another group of TS packets. Is this correct?

Yes.  More specifically, "MPEG2TransportStreamFramer" uses the time 
between successive PCRs to compute (using a weighted average) the 
average duration ("fDurationInMicroseconds") between successive 
outgoing chunks of Transport Stream data.  This, in turn is used (by 
"MultiFramedRTPSink", or - for the Amino STB - "BasicUDPSink") to 
properly pace the streaming of outgoing network packets.

>  Does this
>not mean that the delay to next GOTS will be sent after the supposed
>delay plus the time it takes to run the TransportStreamFramer code?

No, the delay does not include the "time it takes to run the 
TransportStreamFramer code".  (Note how "BasicUDPSink" uses the 
"durationInMicroseconds" parameter.)

The problem with the Amino STBs (unlike other clients like VLC) is 
that they have a very small input buffer, so buffer overflow (or 
underflow) is not uncommon, despite the fact that the server streams 
to at at the proper rate (on average).

You may be able to ameliorate the effect of this by adjusting the 
constant "NEW_DURATION_WEIGHT" in "MPEG2TransportStreamFramer".

For a custom project (using only the Amino STBs as client), we 
overcame this problem by modifying the "MPEG2TransportStreamFramer" 
by continually adjusting the computed "fTSPacketDurationEstimate" 
value in order to maintain a roughly fixed (and >0) estimated buffer 
size at the client.  Unfortunately, this code isn't very portable 
(because it's peculiar to the ideosyncracies of the Amino STB), so 
it's not clear if/when/how it could be made part of the general, public code.


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>