1
0
mirror of https://github.com/DigitalDevices/dddvb.git synced 2023-10-10 13:37:43 +02:00
dddvb/docs/bbframes

105 lines
3.0 KiB
Plaintext
Raw Normal View History

2017-12-15 00:25:51 +01:00
To allow the transport of DVB-S2 baseband frames (BBFrame) across existing hard- and software
2017-12-22 19:19:56 +01:00
interfaces, we have added the ability to embed the BBFrame data into
an MPEG2 transport stream.
2017-12-15 00:25:51 +01:00
2018-03-22 19:33:35 +01:00
This feature is available on supported cards as firmware update and
is currently considered experimental.
2017-12-15 00:25:51 +01:00
Supported hardware:
Cine V7A (>=1.7 FW)
OctopusCI S2 Pro Advanced (>=1.7 FW)
Duoflex S2 v4 Advanced (TBA)
2018-03-22 19:33:35 +01:00
MaxSX8 (NOT the MAXS8!)
2017-12-15 00:25:51 +01:00
The following cards are based on the broadcast version of the
DVB-S2 demodulator. The BBFrame output is working but
not documented. We therefore can not guarantee the
feature will work under all conditions.
cineS2 V7 (>=1.7 FW)
OctopusCI S2 Pro (>=1.7 FW)
Duoflex S2 v4 (TBA)
2017-12-22 19:19:56 +01:00
Current FPGA images (including FW 1.7 for the above mentioned cards)
can be found here:
http://download.digital-devices.de/download/firmware/html/firmwareupdate.html
2017-12-15 00:25:51 +01:00
Packet format:
The BBFrames are packetized into MPEG2 private sections (0x80), one section per transport stream
packet. The PID is fixed at 0x010E.
Header packet of frame:
0x47 0x41 0x0E 0x1X 0x00 0x80 0x00 L 0xB8 BBHeader (169 * Data)
L: Section Length, always 180 (0xB4)
BBHeader: 10 Bytes BBFrame header (see DVB-S2, EN-302307)
Data: 169 Bytes of BBFrame payload
Payload packets:
0x47 0x41 0x0E 0x1X 0x00 0x80 0x00 L N (179 * Data)
L: Section Length, always 180 (0xB4)
N: Packet counter, starting with 0x01 after header packet
Data: 179 Bytes of BBFrame payload
Last packet:
0x47 0x41 0x0E 0x1X 0x00 0x80 0x00 L N ((L-1) * Data) ((180 L) * 0xFF)
L: Section Length, remaining Data 1, (0x01 .. 0xB4)
N: Packet counter
Data: L-1 Bytes of BBFrame payload
Automatic detection of input format:
The bridge firmware allows automatic detection of the incoming data.
To receive regular transport streams in this formats it is still required to setup
the DVB-S2 demodulator to output BBFrames instead of regular TS Packets.
When enabled the embedding mode is automatically turned on or off depending on incoming data
from the DVB-S2/S2X frontend. The decision depends currently only on the first byte of a packet.
If it is 0x47 it switches to transport stream mode else it switches to embedding mode.
Note that 0x47 can currently not occur in the first byte of a BBFrame header if all reserved
values of DVB-S2 and -S2X are observed.
API:
Currently DTV_STREAM_ID is misused.
Set it to 0x80000000 to enable frame mode in the demod.
2018-03-22 19:33:35 +01:00
Because there were some questions why we use this data format,
here are some examples for why using this format this makes handling BBFrames easier:
- The start of a frame is easily found because a new set of sections is
started.
- Existing software layers like the Linux kernel DVB demuxer can be used unchanged.
- Existing hardware like the OctopusNet SAT>IP server which can only handle TS packets can
stream BBFrames via SAT>IP with this method.
- There is at least one demodulator (e.g. on the MaxSX8) which supports this format in hardware.