[FFmpeg-devel] TS muxer issues -- some progress
Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL
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 126.96.36.199.
>>> 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:
>>> 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  clause 2.1.7.
>>> Further information on PCR jitter measurements is given in clause 5.3.2.
>>> and annex I (PCR related measurements).
>>> 188.8.131.52 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