Fluctuated naive video bit rate in transport stream

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.


About Moto

Engineer who likes coding
This entry was posted in Uncategorized. Bookmark the permalink.

3 Responses to Fluctuated naive video bit rate in transport stream

  1. Peter says:

    All this "uniform packet distribution" mess because of a hardware engineer implementing a cost efficent hardware design ‘x’ years ago.

  2. Motonari says:

    But I don’t see any technical reason hardware would be cheaper or simpler by enforcing uniformed video packets. I actually suspect these STBs might expect shorter T-STD delay than one second…

  3. Eland says:

    Isn’t this the difference between Leak method and VBV_delay method of transferring bytes from MB -> EB ? If the former is used, then I presume the video bitrate would be “unstable” as described, and “stable” if the VBV_delay method is used? In the VBV_delay method, the packets are delivered at a piece wise constant rate per picture, and hence there is more control for the encoder? Not sure, which method should be used though!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s