[FFmpeg-devel] TS muxer issues -- some progress
Fri Jan 30 16:13:46 CET 2009
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 18.104.22.168.
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.
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).
22.214.171.124 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?
More information about the ffmpeg-devel