[FFmpeg-devel] TS muxer issues -- some progress

Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL alexandre.ferrieux
Fri Jan 30 17:46:17 CET 2009

Marc Mason wrote:
> M?ns Rullg?rd wrote:
>> Marc Mason wrote:
>>> I've been reading H.222.0 (MPEG-2 Systems) and ETSI TR 101 290 
>>> (Measurement guidelines for DVB systems). Again.
>>> "Systems" explicitly allows variable-bitrate transport streams:
>>> """
>>> Transport Streams may be either fixed or variable rate. In either case 
>>> the constituent elementary streams may either be fixed or variable rate. 
>>> The syntax and semantic constraints on the stream are identical in each 
>>> of these cases. The Transport Stream rate is defined by the values and 
>>> locations of Program Clock Reference (PCR) fields, which in general are 
>>> separate PCR fields for each program.
>>> There are some difficulties with constructing and delivering a Transport 
>>> Stream containing multiple programs with independent time bases such 
>>> that the overall bit rate is variable. Refer to
>>> """
>>> I realize now that I had always implicitly assumed that a given 
>>> transport stream must be constant bit-rate. And this assumption turns 
>>> out to have been wrong.
>> A variable-rate TS can be trivially converted to constant rate by
>> inserting null packets.
> I don't think so.
> If the muxer is real-time, it would need an oracle to predict the future 
> bitrate of the underlying elementary streams.
> If the bitrate of each elementary stream is bounded, then the muxer 
> could pad to the sum of all bitrates + overhead, but this would be 
> highly inefficient.
> Even if the muxer is offline, and thus has perfect knowledge of the 
> "future", it may not be possible to "spread" the excess bits.
> For an unrealistic scenario, consider a stream with the following 
> properties: 50 Mbit/s for one second, then 500 kbit/s for the next 3599 
> seconds. The excess data at the start may have timing imperatives that 
> prevent the muxer from spreading it over 1 hour.
>> Constant-rate streams are required if a
>> physical link is inherently fixed-rate, e.g. a satellite broadcast.
> Variable-bitrate TS over RTP/UDP/IP should be OK then?
> I've worked with several ASI cards, and these required the bitrate to 
> remain constant.
>>> Given a variable bitrate transport stream, it seems to make no sense 
>>> trying to compute PCR accuracy offline, as it is typically computed by 
>>> assuming CBR, dividing the byte count by the CBR, and comparing that 
>>> value to the PCR.
>>> TR 101 290 seems to agree with the above statement:
>>> """
>>> PCR_accuracy_error
>>> The accuracy of +/- 500 ns is intended to be sufficient for the colour 
>>> subcarrier to be synthesized from system clock.
>>> This test should only be performed on a constant bitrate TS as defined 
>>> in ISO/IEC 13818-1 [1] clause 2.1.7.
>>> Further information on PCR jitter measurements is given in clause 5.3.2. 
>>> and annex I (PCR related measurements).
>>> """
>>> """
>>> Program Clock Reference - Accuracy PCR_AC
>>> The accuracy of the PCR values PCR_AC is defined as the difference 
>>> between the actual PCR value and the value it should have in the TS 
>>> represented by the byte index for its actual position. This can be 
>>> calculated for constant bitrate TS, the measurement may NOT produce 
>>> meaningful results in variable bitrate TS.
>>> """
>>> "may NOT" ?? "WILL NOT" seems more appropriate.
>>> Do most demuxers handle variable-bitrate transport streams with no 
>>> problem, or is it generally assumed that a TS is CBR?
>> Most demuxers, including small, cheap hardware decoders, handle
>> variable-rate streams without issue as long as they are delivered at
>> the correct rate.
> So streaming over a LAN should be OK, but streaming over the Internet 
> might not work, because of the network jitter?
>> Some retarded implementations require constant rate for reasons beyond
>> my imagination.  One such implementation I have encountered would give
>> a "bitrate too low" error if the TS rate, as computed from bytes
>> between PCR values, varied even the slightest.
> Thanks for sharing your experience.

I second that 'thanks'.

BTW guys, could one of you have a look at the equivalent code in VLC ? 
It's open source after all... Since vlc gets it right, maybe wild 
research is not entirely necessary ?


More information about the ffmpeg-devel mailing list