[Live-devel] TS file with high VBR

[Ross Finlayson]

>>        - Or: use the index file to store current frame BR (so use 
>>the actual BR of a frame instead of an average based on past frames)
>
>Yes, for Transport Stream files for which we have pre-computed an 
>index file, we do - in principle - have enough 'future' information 
>(using PCR values) from which we could compute a more accurate 
>'duration' for each outgoing Transport Stream packet.  In the past I 
>had considered modifying "MPEG2TransportStreamFramer" to use this 
>information, but didn't (because such a solution would work only for 
>Transport Stream files for which we have index files, whereas the 
>existing code works for any Transport Stream data).
>
>However, because - as you noted - excessively VBR streams are more 
>likely to be a problem with H.264 Transport Streams, I think I'll 
>take another look at this, to see if we can use the index file - 
>when present - to generate more accurate Transport Stream 
>'durations'.

As promised, I looked into whether it would be feasible to do this 
(use the index file to compute more accurate 'durations' for each 
outgoing RTP packet, when streaming an indexed Transport Stream file. 
(When streaming from a non-indexed file, or a live stream, the 
existing code would continue to be used.)  I came up with a solution 
that would work, but decided not to check it in, because I'm not 
convinced that it would be a good idea, for several reasons:
	1/ My solution changes the format of the index file (to add a 
new 'duration per transport packet' field).  Old index files would no 
longer work, which means that everyone would have to reindex all of 
their Transport Stream files.  (Also, index files would become about 
36% bigger.)
	2/ While streaming a Transport Stream file, the server would 
also need to read the whole of its corresponding index file, leading 
to an almost 10% overhead in file system reads.
	3/ Although we would now know more accurate 'durations' for 
each outgoing packet, we would still need to adjust these using some 
'fudge factors' (tuning parameters), because otherwise we'd often end 
up seeing 'buffer underflow' at the receivers (due to network jitter, 
for example).  (So the new scheme would not eliminate the 'fudge 
factors' present in the current scheme.)
	4/ For highly VBR files, this new solution - by computing 
more accurate 'durations' for each outgoing packet - would end up 
generating an output network packet stream that's more bursty than 
the current scheme (which works by computing a weighted average 
duration).  This would potentially lead to more network congestion 
(and possibly more packet loss).

Therefore, my current thinking is that it's probably best to retain 
the existing scheme, even though its tuning parameters ('fudge 
factors') sometimes need to be tweaked in special circumstances.  (I 
could potentially still be convinced otherwise, though.  But right 
now I don't plan to change the existing "MPEG2TransportStreamFramer" 
implementation.)
-- 

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