[Live-devel] Urgent help needed!

[Ross Finlayson]

>A quick fix for some of the worst problems of buffer underrun could be
>to add an average time between PCRs, and if the time between two is
>avgTime*2 you should just flush out alot of data as fast as possible
>up until the next PCR arrives. This could go seriously wrong on borked
>TS streams though, even worse than it would with the current framer I
>guess, but many times it could save the day also.

Please let us know if you have any specific suggestions for 
improvements to the existing "MPEG2TransportStreamFramer" code...

In any case, I would still like to see a specific example of a 
(real-live) Transport Stream file that illustrates this problem.

>The best way is of
>course to buffer data up to the next PCR. This would also give less
>random access on disk and maybe better troughput, as one reads
>linearly more often

I don't buy this, because the streaming itself causes the data to be 
read linearly.

I think that a better (but related) solution would be to use the 
index file.  When we generate an index file, we are already 'reading 
ahead' in the stream, so it would be not be too difficult, I think, 
to augment the index file records to add an accurate 'duration' for 
each Transport Packet, and to use this 'duration' when streaming. 
Perhaps I'll add this at some point in the future...  (Of course, 
this won't help at all with live streams (because they don't have 
index files), but I think that having live Transport Streams that are 
severly VBR is a really bad idea, if you're not counting on clients 
to have sufficient buffering to handle them.)
-- 

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