[Live-devel] TS file with high VBR

[Ross Finlayson]

>Maybe I'm wrong, but, by reading the code of the media server, it 
>looks likes it relies on an average BR to determine when to send the 
>packets (based on past packets).

Yes.  (This is done in "MPEG2TransportStreamFramer".)


>  The PCR is used to compute this average, but not to determine when 
>to actually send the packets. (I might be totally wrong here as I 
>must admit that the code is quite complex and I probably have missed 
>something.....).
>Now, if I'm not totally wrong, would there be a way to either:
>        - Rely on PCR to determine when to send packets (something 
>like: get the next PCR, determine BR from first packet till this PCR 
>packet, send packets in a way where the packet containing the PCR is 
>sent on time).

The "MPEG2TransportStreamFramer" code is intended to work when 
streaming arbitrary Transport Stream data - including Transport 
Stream data that might come 'live' from an encoder.  It therefore has 
no knowledge of 'the next PCR' (because it doesn't look ahead in 
time).  However...


>        - 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'.
-- 

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