when playing with DVB-T2, I see there are example ts files of different
size, somehow optimized for the transmission mode, 4k or 8k, 64QAM or

Now when I have a look at them with my recoding software, they all look
identical, same bitrate and stuff, just different size. So I wonder,
are the differences, what qualifies a transport stream for a certain
transmission mode? I would like to prepare some on my own :slight_smile:

And another question, how do I set the ID stuff, name, PID?

With best regards


Hi Ralph,

I don’t think there is something specific inside the TS for a
transmission mode, unless there are some packets or packet complement,
just like in ISDB-T (I do not know too much about DVB-T2), where you
place information of which PID goes to which hierarchical layer.

All you have to do is configure your MPEG2-TS muxer to place all the
information you want inside the TS.

I recommend the Open Broadcast Encoder:

Best regards,
Rafael D.

The primary requirement is to the set the Transport Stream bitrate
properly. Otherwise, you’ll get audio or video stuttering. For DVB-T,
the bitrate calculation is straight forward, and there are only so many
combinations. I have a command line utility here.

For DVB-T2, the bitrate calculation is much more complex, and there are
a huge number of combinations. I have a command line utility, but I’ve
been reluctant to publish it on Github since it’s so difficult to use.
What it really needs is a GUI, but I haven’t got around to that.
However, it does work and I’ve put a copy on my website.

You have to enter eleven parameters like so:

usage: dvbt2rate

For example, the BBC 32K mode (vv003-cr23.grc flow graph) would be:

./dvbt2rate 8 32 4 59 202 3 4 0 1 7 3

The results are:

$ ./dvbt2rate 8 32 4 59 202 3 4 0 1 7 3
FFT size = 32768
guard interval = 1/128
number of data symbols = 59
number of FEC blocks = 202
code rate = 2/3
constellation = 256QAM
frame size = normal
carrier mode = extended
pilot pattern = PP7
L1 constellation = 64QAM

clock rate = 9142857.142857, TF = 216.944000 ms
bitrate = 40214645.204775
max symbols = 68, max blocks = 229
symbols = 60, max blocks = 202
cells = 1639268, stream = 1636200, L1 = 2090, dummy = 978, unmodulated =

The bitrate for that mode is 40.214645 Mbps.

For the other test flow graph (vv009-4kfft.grc) it would be:

$ ./dvbt2rate 8 4 0 100 31 3 3 0 0 7 2
FFT size = 4096
guard interval = 1/32
number of data symbols = 100
number of FEC blocks = 31
code rate = 2/3
constellation = 64QAM
frame size = normal
carrier mode = normal
pilot pattern = PP7
L1 constellation = 16QAM

clock rate = 9142857.142857, TF = 48.272000 ms
bitrate = 27588664.235996
max symbols = 541, max blocks = 166
symbols = 104, max blocks = 31
cells = 341682, stream = 334800, L1 = 2216, dummy = 4192, unmodulated =

The bitrate for that mode is 27.588664 Mbps.

There are two rules that must be followed. First, the DVB-T2 frame
length (TF) can’t be longer than 250 milliseconds. Second, the number of
“dummy” cells must be positive or 0. Dummy cells are just filler to
match the number of cells in FEC blocks to the number of cells in OFDM
symbols. To get the maximum bitrate, you want to select the number of
symbols and number of FEC blocks combination that minimizes the number
of dummy cells.

In the first example, the line “max symbols = 68, max blocks = 229” is
showing the maximum number of symbols and FEC blocks that will fit in
250 milliseconds. The line “symbols = 60, max blocks = 202” is showing
the total number of symbols you’ve chosen (in this case, 59 data symbols

  • 1 P2 symbol = 60) and the maximum number of FEC blocks that will fit
    into that number of symbols.

Here’s the guideline for choosing DVB-T2 parameters. See chapter 5.

If you do some Googling, there are probably some DVB-T2 bitrate
calculators available that are much easier to use.

As for PID selection, the range 1 to 0x1f is reserved for specific DVB
functions, so stay away from those. For my test streams, I’ve been

PAT = 0 (the PAT is always at PID 0);
PMT = 0x30
Video and PCR = 0x31
Audio = 0x34
Stuffing = 0x1fff (stuffing packets are always PID 0x1fff)

Most receivers will decode a simple Transport Stream without any
additional PIDs or service information beyond PAT, PMT, PCR, video,
audio and stuffing. If you want to get more complex, the DVB
specification for service information is here:


Thanks a lot for the detailed explanation. This will help me!!



For the video stuff I prefer some kind of Windows software; it is just
storage capacity and horsepower, Linux runs in a VM. The problem is that
know almost nothing about all this stuff, so I am collecting bits and
of information…

Thanks a lot, I will have a look at obe.


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs