[Live-devel] H.264 in MPEG-2 TS streams roughly at the start

[Ross Finlayson]

> We've been using live555MediaServer with MPEG-2 A/V in TS files successfully for quite some time now, but we are now experimenting with H.264 in TS.  We've been unable to create files that stream as smoothly as our old MPEG-2 files.

Our code has trouble streaming MPEG Transport Stream files that are extremely VBR (variable bit rate), which is what I suspect your file is.  The problem is the "MPEG2TransportStreamFramer" class.  This class uses the stream's PCR timestamps to compute (estimate) the duration of each of the (188-byte) Transport Stream 'packet' that pass through it, before they get packed into larger RTP packets and transmitted.  These packet durations determine the rate at which the RTP packets get sent.  Unfortunately, it's difficult to compute accurate duration estimates for VBR streams; consequently, the estimated duration sometimes gets too large, which means that some packets get delivered too slowly for the receiver (i.e., underflow).  Alternatively, the estimated duration sometimes gets too small, which means that some packets will get delivered too quickly for the receiver (overflow, or even packet loss).  The basic problem is that the "MPEG2TransportStreamFramer" class doesn't 'read ahead' through the incoming Transport Stream data, so it doesn't have any 'future' PCR timestamps to work from as it computes estimated durations; instead, it can work only from PCR timestamps that it has already seen.

One way to overcome problems streaming VBR files is to reencode them so that they're 'less VBR'.  Unfortunately, this will likely increase the file's size, and thus the stream's bitrate.

Another possibility is to tweak (e.g., using compile-line definitions) some of the four constants
	NEW_DURATION_WEIGHT
	TIME_ADJUSTMENT_FACTOR
	MAX_PLAYOUT_BUFFER_DURATION
	PCR_PERIOD_VARIATION_RATIO
to try to get better performance.  Unfortunately, this is somewhat of a 'black art', and there's no guarantee that this will improve things.

Down the road, a better solution might be to provide an alternative implementation of the "MPEG2TransportStreamFramer" class that 'reads ahead' (i.e., buffers some input transport data), so that it can look one PCR timestamp ahead, thereby producing more accurate duration estimates.  The disadvantage of this, however, is that it would be less efficient than the current "MPEG2TransportStreamFramer" implementation (which doesn't buffer any input data at all).

Another possibility would be store packet durations in the 'index file' (that gets used when performing 'trick play' operations on Transport Stream files.  The disadvantage of this, however, is that it would work only for prerecorded files, not 'live' input streams (e.g., from an encoder).  It would also require an incompatible change to the index file format.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120907/bcdea4b2/attachment-0001.html>