[FFmpeg-devel] TS muxer issues -- some progress
Fri Jan 30 16:53:22 CET 2009
Marc Mason <mpeg.blue at free.fr> writes:
> M?ns Rullg?rd wrote:
>> Tomer Barletz wrote:
>>> Marc Mason wrote:
>>>> Last time I looked (march 2008, trunk) ffmpeg PCR generation was a mess.
>>>> The muxer picked PCR values ignoring PSI insertion, which lead to huge
>>>> PCR jitter, which (I suppose) makes some hardware decoders throw a fit.
>>> This was fixed about two weeks ago - check the logs.
>>>> Are there any good open source TS analyzers?
>>>> I used Tektronix TS compliance analyzer to test ffmpeg's and vlc's TS
>>>> muxers, but I was told it was horribly expensive.
>>> I would like to know too...
>> Writing an analyser is almost as hard as writing a muxer.
> 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 184.108.40.206.
> 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. Constant-rate streams are required if a
physical link is inherently fixed-rate, e.g. a satellite broadcast.
> 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).
> 220.127.116.11 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.
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.
mans at mansr.com
More information about the ffmpeg-devel