> 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/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
