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

[Marc Mason]

Marc Mason wrote:

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

M?ns and/or other Transport Stream enthusiasts ;-)

Could you comment? Specifically, I'm not sure I agree with the statement 
that it is trivial to convert a VBR TS to a CBR TS.

-- 
Regards.