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

[Måns Rullgård]

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

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

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.

-- 
M?ns Rullg?rd
mans at mansr.com