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

[Marc Mason]

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

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

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.

-- 
Regards.