0% found this document useful (0 votes)
64 views

Mpegts Introduction

MPEG transport streams contain packets that carry video, audio, and data. Packets are identified by PID and combined to form elementary streams, which are multiplexed into a transport stream. Transport streams use tables and sections to describe service content and structure. Sections are split into packets and multiplexed with other streams. Tables can use short sections for each table or long sections split across multiple packets.

Uploaded by

mizonyx
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
64 views

Mpegts Introduction

MPEG transport streams contain packets that carry video, audio, and data. Packets are identified by PID and combined to form elementary streams, which are multiplexed into a transport stream. Transport streams use tables and sections to describe service content and structure. Sections are split into packets and multiplexed with other streams. Tables can use short sections for each table or long sections split across multiple packets.

Uploaded by

mizonyx
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 42

An introduction to

MPEG-TS
all you should know before using TSDuck

Version 9
Topics 2

• MPEG transport streams


• packets, sections, tables, PES, demux
• DVB SimulCrypt
• architecture, synchronization, ECM, EMM, scrambling
• Standards
• MPEG, DVB, others
Transport streams
packets and packetization
Standard key terms 4

• Service / Program
• DVB term : service
• MPEG term : program
• TV channel (video and / or audio)
• data service (software download, application data)
• Transport stream
• aka. « TS », « multiplex », « transponder »
• continuous bitstream
• modulated and transmitted using one given frequency
• aggregate several services
• Signalization
• set of data structures in a transport stream
• describes the structure of transport streams and services
MPEG-2 transport stream 5

• Structure of MPEG-2 TS defined in ISO/IEC 13818-1


• One operator uses several TS
• TS = synchronous stream of 188-byte TS packets
• 4-byte header
• optional « adaptation field », a kind of extended header
• payload, up to 184 bytes
• Multiplex of up to 8192 independent elementary streams (ES)
• each ES is identified by a Packet Identifier (PID)
• each TS packet belongs to a PID, 13-bit PID in packet header
• smooth muxing is complex, demuxing is trivial
• Two types of ES content
• PES, Packetized Elementary Stream : audio, video, subtitles, teletext
• sections : data structures
Multiplex of elementary streams 6

• A transport stream is a multiplex of elementary streams


• elementary stream = sequence of TS packets with same PID value in header
• one set of elementary streams for global signalization
describe the TS, the network, the operator, the services, the events, EMM’s, etc.
• one set of elementary streams per service
a service is typically a TV channel
global signalization streams

PMT
service 1 streams video
audio 1
audio 2
transport stream subtitles 1
subtitles 2
service 2 streams ECM 1
ECM 2
TS packet 7

4-byte header includes : Adaptation field may include :


• Sync byte = 0x47 • Program Clock Reference (PCR / OPCR)
• PID : 13 bits • Private data
• Continuity counter : 4 bits • Stuffing (for PES stream padding)
• Payload Unit Start Indicator (PUSI) : 1 bit • More…
• Transport scrambling control : 2 bits
• Adaptation field presence : 1 bit
• Payload presence : 1 bit
• More…

TS packet without adaptation field


AF = 0

47

header : 4 bytes payload = 184 bytes

TS packet with adaptation field


AF = 1 adaptation field size

47

header : 4 bytes adaptation field payload < 184 bytes


Multiplexing and demultiplexing 8

• Elementary stream = concatenation of all payloads of all TS packets with same PID
• Elementary stream transport
• packetization = cutting ES into packets payloads with same PID
setting Payload Unit Start Indicator (PUSI) in TS header on « unit » boundary
• multiplexing = mixing with packets from other PID’s to build a complete TS
• demultiplexing = extracting all packets with same PID from TS
• depacketization = rebuilding ES from packets payloads with same PID
using PUSI to resynchronize on « unit » boundary

Elementary stream :
packetization

TS packets :
depacketization
Elementary stream :
Packetized Elementary Stream (PES) 9

• A stream of PES packets


• up to 65536 bytes per PES packet
• start of PES packet identified by PUSI bit in TS header
• PES packets can contain
• video : MPEG-2 (H.262), AVC (H.264), HEVC (H.265), etc.
• audio : MPEG-2 Layer 2, AAC, HE-AAC, AC-3, DTS, DTS-HD, etc.
• DVB subtitles (text or bitmap)
• teletext (deprecated but still used)
• One elementary stream contains one single type of content
• video
• audio for one language (with or without « audio description »)
multi-channel audio (stereo, 5+1, etc.) within same PID
• subtitles for one language (with or without « for hard of hearing »)
• exception : one teletext stream is a multiplex of several text streams (« pages »)
Typical PES packetization 10

First TS packet for PES packet


PUSI = 1 PID = nn PES packet start code prefix

47 PCR 00 00 01 …

header adaptation field payload < 184 bytes


(optional but typical)

As many intermediate TS packets as required for current PES packet


(multiplexed with TS packets from others PID’s)
PUSI = 0 PID = nn

47

header payload = 184 bytes

Last TS packet for PES packet


PUSI = 0 PID = nn fill adaptation field with enough stuffing so that
end of PES packet matches end of TS packet

47 stuffing

header adaptation field payload < 184 bytes


PES streams robustness 11

• TS packet loss is tolerated in audio and video streams


• video « macro-block » effect
• audio « glitch » effect
• quality of recovery based on decoder implementation
• TS packet loss detection based on continuity_counter
• 4-bit field in TS packet header
• cannot detect loss of an exact multiple of 16 TS packets
• resynchronization on next TS packet with PUSI
• But video / audio decoders can resynchronize within PES packet
• video / audio bitstream formats usually contain synchronization patterns
• example : NAL unit boundary in AVC encoding
Sections streams 12

• Contain data structures named « tables »


• A table is split into one or more « sections »
• section = smallest data unit, up to 4096 bytes
• standard header and type-specific payload
• table type identified by table_id in header
• two types of section syntax : « short » and « long »
based on 1 bit in header

• Each type of table defines its own syntax


• use long or short sections
• payload bitstream syntax
• Descriptor
• standard substructure with standard header and type-specific payload
• most tables use generic « lists of descriptors »
Typical section packetization 13

TS packet containing the start of section n+1


PUSI = 1 PID = nn pointer field (to first start of section) table id section size

47 end of section n start of section n+1

header : 4 bytes payload = 184 bytes

As many intermediate TS packets as required for section n+1


(multiplexed with TS packets from others PID’s)
PUSI = 0 PID = nn

47 continuation of section n+1

header : 4 bytes payload = 184 bytes

Last TS packet for section n+1, start of next section


PUSI = 1 pointer field table id section size table id section size
PID = nn

47 end of section n+1 section n+2 start of section n+3

header : 4 bytes payload = 184 bytes


Tables with short section 14

• One section per table


• section and table are equivalent
• Each table brings new information
• CAS EMM / ECM
• date and time information (TDT / TOT)
• No standard integrity check
• except section length in section header
• some table-specific mechanisms
cryptographic integrity in EMM / ECM
CRC32 in TOT
Tables with long sections 15

• Up to 256 sections per table


• need to receive all sections to rebuild the complete table
• Same table repeatedly cycled
• Content change notification
• version number in long section header
• each table is repeatedly broadcast with same version number
• version number changes when table content changes
• STB software sets demux filters to be notified of new tables only
• Integrity check
• CRC32 in each section
• section rejected in case of corruption, can be detected at demux level
• resynchronization on next TS packet with PUSI
Signalization: PSI / SI 16

• PSI : Program Specific


Info. DVB
(mandatory)
DVB
(optional)
• MPEG-defined MPEG-2
PID 16 PID 16

• ISO / IEC 13818-1 PID 0


NIT
Actual
NIT
Other
Network
Information
• TS structure: PAT, PMT PAT
Network Network

• CA : CAT PID 17
Bouquet
BAT
• SI : Service Information Association
PID 1

PID 17 PID 17
CAT
• DVB-defined SDT SDT Service
• ETSI EN 300 468 Actual TS Other TS Description

• private sections in MPEG PMT


PID 18 PID 18 PID 18

terms EIT
Actual TS
EIT
Actual TS
EIT
Other TS Event
present / follow schedule present / follow
Information
schedule
PID 2 PID 20 PID 20

Extracted from TSDT TDT TOT Time & date

DVB standard PID 19

ETSI EN 300 468 RST Running


Status
MPEG-defined PSI 17

• PAT : Program Association Table


• repeated in PID 0
• list of « services » in the TS, ie. TV channels or data channels
• service id and PMT PID
• PMT : Program Map Table
• technical description of one service
• list of elementary streams in the service
• PID, type (audio, video, etc.), additional info using a list of descriptors
• list of ECM streams for this service
• CAT : Conditional Access Table
• repeated in PID 1
• list of EMM streams on this TS
• CAT not present when no EMM on TS
DVB-defined SI (1/2) 18

• SDT : Service Description Table


• editorial description of the services in a TS
• either in « actual » TS or « other » TS
• service names and ancillary services

• BAT : Bouquet Association Table


• commercial operator description and services
• several commercial operators may sell the same services
• NIT : Network Information Table
• technical description of a network
• either « actual » network or « other » network
• list of TS in this network
usually with frequency and tuning parameters
used for fast network scanning
• list of services in each TS
service ids and « logical channel number »
DVB-defined SI (2/2) 19

• EIT : Event Information Table


• editorial description of events
• either in « actual » TS or « other » TS
• EIT « present / following »
short description of current and next event on each service
used to display information banner on screen
• EIT « schedule »
long description of all events in the forthcoming days
used to display the EPG
optional, depends on operator’s good will and bandwidth availability
complete 7-day EPG for a large operator uses several Mb/s
sparse EIT schedule sections, rarely complete tables

• TDT / TOT : Time and Date Table / Time Offset Table


• current date and time, UTC (TDT) and local offset by region (TOT)
• used to synchronize STB system time
• typically one table every 10 to 30 seconds only
DVB SimulCrypt
one network, several conditional access systems
Standard key terms 21

• CAS : Conditional Access System


• CW : Control Word
• content encryption key for video & audio
• EMM : Entitlement Management Message
• CAS-specific message to manage rights, smartcards, subscribers
• sent to some identified set of subscribers, possibly only one
• ECM : Entitlement Control Message
• CAS-specific message to control a scrambled service
• sent to everyone willing to watch the service
DVB SimulCrypt 22

• Enforce coexistence of multiple CAS to protect the same content


• DVB-defined standard
• Use-cases
• one broadcast operator, multiple commercial operators
• transition between CAS generations
• Broadcast
• very simple architecture
• common scrambling
• multiple EMM and ECM streams with standard signalization
• Head-end
• complex architecture
• multiple CAS equipment
• common synchronization
DVB SimulCrypt head-end diagram 23

Extracted from
DVB standard
ETSI TS 103 197
DVB SimulCrypt head-end 24

• Interface between two worlds


• one « MUX system » vendor
yellow components
• multiple CAS vendors
blue components

• DVB SimulCrypt protocols


• specified between components of distinct worlds
• protocols within the same world are not specified
proprietary, vendor specific
• consistent nested tag-length-value (TLV) structures
using logical « channels » and « streams »
except ACG ó EIS protocol (XML protocol)
• EIS ó SCS protocol is specified
so that EIS and SCS may in fact come from distinct vendors

• TSDuck plugins
• scrambler interacts with any standard ECMG
• datainject interacts with any standard EMMG or PDG
EMM signalization 25

• Using CA_descriptor in the CAT of the TS


• standard part of CA_descriptor: CA system id, EMM PID
CA_system_id are allocated by DVB
http://www.dvbservices.com/identifiers/ca_system_id
• private part of CA_descriptor: CAS-specific
used by the CA software in the STB

• Number of EMM streams is CAS-specific


• for instance, one EMM stream may contain all EMM’s for
one operator
one EMM type (e.g. individual, group, global)
or any other configuration
when they exist, operator id and EMM types are CAS-specific concepts
they are usually identified in the private part of the CA_descriptor
ECM broadcast 26

• An ECM usually transports a CW pair and access criteria


• specific to one or more audio or video streams
• specific to one CAS
• Each service (i.e. channel) has dedicated ECM streams
• per scrambling group
• per CAS
base mechanism for DVB SimulCrypt
• Scrambling group
• a set of audio or video elementary streams scrambled with the same CW
• subtitles are usually not scrambled in practice (but could be in theory)
• usually, all audio/video streams of a service are in the same scrambling group
• in rare cases, audio and video streams are scrambled with distinct CW
ECM signalization 27

• Using CA_descriptor in the PMT of the service


• standard part of CA_descriptor : CA system id, ECM PID
same as EMM signalization
• private part of CA_descriptor: CAS-specific
used by the CA software in the STB
CA_descriptor private part is usually different in CAT (EMM) and PMT (ECM)
sample content : operator id, public subset of access criteria
• Two possible positions for CA_descriptors in PMT
• at program level
only if one single scrambling group
• at stream level
mandatory if different ES use different CW
take precedence over program level if both are used for same CA_system_id
Scrambling synchronization : principles 28

• During one crypto-period (CP) number N


• typically 10 seconds
• scrambling using same CWN
• ECMN carries CWN and CWN+1
• initial ECM broadcast delayed from start of CP (CAS specific)
• ECMN is repeated several times during CPN (typically 10 ECM/s)
• if first ECMN+1 is missed, the descrambler already knows CWN+1 anyway
• The CA software configures the descrambler with both CWN and CWN+1
• either N or N+1 is « even », the other one is « odd »
• TS packet header contains 2-bit transport_scrambling_control
• used by the descrambler to select the appropriate CW
00 : clear, do not descramble (MPEG-defined: ISO 13818-1)
10 : use even CW (DVB-defined: ETR 289)
11 : use odd CW (DVB-defined: ETR 289)

• Implemented in TSDuck plugin scrambler


Scrambling synchronization : head-end view 29

• Based on crypto-period (CP) number


• CP numbers are sequentially allocated by SCS
• the full CP number stays on head-end
• its parity is used in TS packets and ECM’s

CWG TS packet
message MUX /
random stream parity = odd 11 è transport_scrambling_control
Scrambler
AA .. .. AA CW = AA..AA
BB .. .. BB scrambled with « odd » CW

SCS CP number is odd


ECM
About to start message
CP number 165 ECMG CW : BB..BB AA..AA
CP num = 165
CW = AA..AA even odd

CP num = 166 CP number is even


CW = BB..BB
Scrambling synchronization : head-end timeline 30

• Crypto-periods timeline

≈ 10 seconds

Current CP number 165 166 167

SCS → MUX odd – AA..AA even – BB..BB odd – CC..CC

165 – AA..AA 166 – BB..BB 167 – CC..CC


SCS → ECMG
166 – BB..BB 167 – CC..CC 168 – DD..DD

TS packet (t.s.c.) 11 10 11

Scrambling CW AA..AA BB..BB CC..CC

BB..BB AA..AA BB..BB CC..CC DD..DD CC..CC


ECM (CW pair)
even odd even odd even odd

time
Scrambling synchronization : receiver timeline 31

• Loose synchronization
• ECM’s may be missed
• CW transition is blurry (video & audio PID’s)
• No explicit synchronization between ECM’s and video/audio crypto-periods

Current CP number 165 (odd) 166 (even)

ECM content BB..BB AA..AA BB..BB CC..CC


even odd even odd

Video PID CW AA..AA BB..BB


Audio PID CW AA..AA BB..BB ECM
received
ECM 0x80 ECM 0x81
ignored
ECM reception (redundant)
time
delay start (head-end)
missed
t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 t15 t16 t17 t18 t19 t20
ECM processing (smartcard)
descrambler setup (chipset) BB..BB AA..AA BB..BB CC..CC
even odd even odd
TS vs. PES scrambling 32

• ISO 13818-1 defines two possible levels of scrambling


• TS level
each TS packet is scrambled individually
clear TS header and adaptation field, scrambled TS payload
• PES level
each demuxed PES packet is scrambled individually
TS packet header marked as clear
PES packet header contains similar 2-bit PES_scrambling_control
clear PES header, scrambled PES payload

• In practice, only TS-level scrambling is used


• PES-level scrambling is technically much more difficult
scrambling is performed on multiplexed TS
ETR 289 specifies sub-scrambling of 184-byte super-blocks
PES packet boundaries not aligned on crypto-period boundaries
• PES-level scrambling is never used in practice
EMM & ECM tables 33

• CA-private in DVB-defined range


• ETSI ETR 289 defines the range of private CA table ids
0x80 – 0x81 : ECM
0x82 – 0x8F : « CA private »
• defined as « short sections »
no versioning
each section is an independent new table

• Typical usage
• 0x80 and 0x81 alternating with crypto periods
ECM table id change used as trigger by CA software to submit ECM to smartcard or TEE
ECM table id and CP number do not necessarily have the same parity
• 0x82 – 0x8F used for EMM’s
CAS-specific
typically one table id for each EMM type, easier to filter in STB
Access criteria transition 34

• Use case : restricted event or pay-per-view event transition


• Scenario :
• the ECMG of each CAS had sent its own timing requirements to SCS
• SCS synchronizes the generation of the ECM from each CAS

Extracted from
DVB standard
ETSI TS 103 197
Clear-to-scramble transition 35

• Use case : Pay-TV channel with public periods in the clear


• Scenario :
• the ECMG of each CAS had sent its own timing requirements to SCS
• SCS synchronizes the generation of the ECM from each CAS

Extracted from
DVB standard
ETSI TS 103 197
DVB CSA-2 36

• DVB Common Scrambling Algorithm


• DVB proprietary algorithm
• supposed to be « secret »
• fully described in Wikipedia
• open-source implementations online (libdvbcsa)
• Algorithm
• 64-bit key (also known as « Control Words » or CW)
• first pass : block cipher in reverse-CBC mode
use CW as key
block size : 64 bits
residue ignored
• second pass : stream cipher
use CW as key and first block as seed (last processed block from reverse-CBC)
residue included
• short payloads (1 to 7 bytes) are not encrypted
even if transport_scrambling_control is non-zero
DVB CSA-2 entropy reduction 37

• Entering the twilight zone….


• 64-bit key
• some national regulations from the 90’s prohibited 64-bit entropy
• entropy was artificially reduced to 48 bits
cw[3] = (cw[0] + cw[1] + cw[2]) mod 256
cw[7] = (cw[4] + cw[5] + cw[6]) mod 256
• entropy reduction is no longer required but still often applied

• Operational issues
• hardware scramblers and descramblers use plain 64-bit keys
• CWG internally generates 64 random bits
• where is the entropy reduction applied ?
common chain : CWG? SCS?
scrambling chain : MUX? scrambler?
descrambling chain : ECMG? smartcard? CA software in STB? descrambler?
who knows if entropy reduction must be applied anyway?
Standards
our essential references
Essential standards 39

• MPEG
• ISO 13818-1, MPEG-2 system layer (TS, packetization, PSI)
transport stream è broadcast, blu-ray discs
program stream è DVD

• DVB / ETSI (Europe and more)


• EN 300 468, DVB service information specifications (signalization)
• TS 103 197, DVB simulcrypt head-end (CAS head-end)
• ATSC (USA), ISDB (Japan, Brazil)
• equivalent features as defined in DVB
Obtaining standards documents 40

• ISO
https://www.iso.org/standards.html
must be purchased
• DVB
http://www.etsi.org/standards
direct search : http://www.etsi.org/standards-search
allocated identifiers : http://www.dvbservices.com/identifiers/
• ITU
http://www.itu.int/ITU-T/recommendations/
H.xxx series : http://www.itu.int/rec/T-REC-H/
• IETF
https://tools.ietf.org/
• NIST
http://csrc.nist.gov/publications/
Audio and video standards and nicknames 41

Origin Type ISO / IEC ITU-T Nicknames


MPEG-1 Video 11172-2 H.261 MPEG-1 video
MPEG-1 Audio 11172-3 MPEG audio layer 1
MPEG-2 Video 13818-2 H.262 MPEG-2 video
MPEG-2 Audio 13818-3 Layer 2: MPEG audio layer 2
Layer 3: MP3
MPEG-2 Audio 13818-7 AAC (Advanced Audio Coding)
Dolby Digital Audio AC-3 (Audio Coding 3)
MPEG-4 Video 14496-2 H.263 DivX, Xvid (codecs)
MPEG-4 Audio 14496-3 HE-AAC, EAAC (High Efficiency, Enhanced AAC)
MPEG-4 Video 14496-10 H.264 AVC (Advanced Video Coding)
MPEG-H Video 23008-2 H.265 HEVC (High Efficiency Video Coding)
Dolby Digital Audio AC-4
MPEG-I Video 23090-3 H.266 VVC (Versatile Video Coding)
Thank you
Any question?

You might also like