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

[Marc Mason]

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 2.4.2.2.
"""

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:

"""
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).
"""

"""
5.3.2.6 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?

-- 
Regards.