The bit rate of MPEG-2 transport stream is defined in ISO/IEC 13818-1 Eq. 2-5. It’s actually quite simple: take two successive transport stream packets with PCR. Count the number of bits between these two packets. Divide it by the PCR difference. Thank you, you are done.
However, there are some different definition about bit rate. Be aware they are not following the international standard. I’m going to explain one of these informal bit rate definitions: video bit rate in transport stream.
Let me call this video bit rate as “naive video bit rate”. It is naive because it’s calculated by an intuitive but wrong way: counting the number of video TS packet in a certain time window over time. In other words;
naive_video_bit_rate = number_of_video_ts_packets x 188 x 8 / window_size_in_second
This definition is ambiguous. There is no agreement on the value of window_size_in_second and it’s unknown whether it’s sliding window or not.
Why is this informal, ambiguous naive video bit rate important? Some STBs (=Set Top Box, basically a MPEG-2 TS decoder) requires this naive video bit rate to be “reasonably stable”. No body really knows what this “reasonably stable” means, but they are talking like “This multiplexer is better because the output video bit rate is more stable than others” or “That multiplexer is sucks and the STB doesn’t play due to the lack of video bit rate stability” etc.
Here is the plot of naive video bit rate from “instable” multiplexer (red) and “stable” multiplexer (green). It uses 1 second sliding window moving every 0.1 second. Note that these multiplexers are both generating valid transport stream per ISO/IEC 13818-1. A standard conforming STB shouldn’t have any problem to play back these streams.
So, why the “instable” multiplexer has such fluctuation in naive video bit rate? Actually, the “instable” multiplexer uses flexibility of the ISO/IEC 13818-1 to use the bandwidth more efficiently. To understand this, you need to be familiar with T-STD model. T-STD is imaginary MPEG-2 transport stream decoder specified in ISO/IEC 13818-1. A transport stream must be constructed so that T-STD can decode without causing errors.
Here is the T-STD model for MP@ML stream which is used for Cable Lab SD stream.
Cable Lab SD stream uses transport rate 3750kbps and typical video bit rate (The value coded in the sequence header) is 3180kbps. As you can see here, the transfer speed in T-STD is much faster than this. For example, the maximum transfer rate between MB to EB is 15Mbps. It means the multiplexer is allowed to deliver video data faster than the actual video bit rate under the conditions:
- No buffer overflow happens.
- T-STD delay limitation is kept – no data can stay in T-STD more than one second.
- MB has to be emptied every one second.
As a result, video packets are inserted at high bit rate, and then stopped to wait for the conditions. Therefore the naive video bit rate has fluctuation as observed in the graph above.
This technique is especially important when the EB occupancy is low. In transport stream, there are several conditions that the multiplexer has to insert a packet with higher priority than a video packet. In such a case, low EB would cause underflow error. By inserting video packet as early as possible, we could avoid underflow errors.
A “stable” multiplexer controls the rate between MB to EB to the same value of video sequence header bit rate (3180kbps). It’s less efficient in a sense that it may require higher transport rate for given elementary streams, but the value of naive bit rate is stable.
Some multiplexers have an option to select inefficient but stable mode or efficient but instable mode. User has to select one of them based on the target STBs.