April 2024 - This site, and Kamaelia are being updated. There is significant work needed, and PRs are welcome.

Project Task Page: Multicast RTP MPEG Remultiplexer

Status: Blocked - Awaiting hardware purchase authorisation
Current Developers: Matt
Current "inflight" dev location: /Sketches/MH/RTP/
Start Date: ??
Major Milestone date: n/a
Expected End Date: 22nd December 2006
End Date: tbd
Date this page last updated: 27th November 2006
Estimated effort so far: ??


A tool to mix MPEG transport streams received over multicast in RTP format; and rebroadcast as a new multicast RTP stream.

Internal work on developing live multicast streaming services needs a way to take data from one stream and mix it into another. The streams are multicast RTP packets containing MPEG Transport Stream data. The tool, when deployed should be able to run 24/7, combining a subset of data from 2 or more streams to generate a new one.



Task Sponsor: BB (BBC internal)
Task Owner: Matt (MH)


Interested Third Parties

Requirements (non exhaustive):

Receive multicast RTP containing MPEG Transport Stream containing H264 @ ~1Mbit/s (MUST)

Simulataneously receive a 2nd multicast RTP containing MPEG Transport Stream containing EIT data and MPEG2 video @ ~5Mbit/s (MUST)

Combine EIT data from 2nd stream with video from the 1st to form a new stream (MUST)

Transmit the new stream as multicast RTP (MUST)

Adjust stream timestamps (MPEG Transport Stream level, and possibly MPEG Program Elementary Stream level) if needed (WOULD LIKE)



Components to parse and create RTP packets

Command line tool, as described

Webpages describing:



RTP handling

Internet components (uprades/modifications)

DVB/MPEG Transport stream processing

Realistic possibilities arising as a result of activity on this task

New/modified components for mainline codebase (RTP, DVB)

Tasks that directly enable this task (dependencies)


Improved throughput of multicast component and Selector in general

Develop code

Task Log


Need to determine, experimentally, if timestamp resynchronisation algorithms will be neededIf resynchronisation algorithms are needed. Technically remultiplexing severely jitters the timestamps on the transport stream packets.

CPU load is higher than anticipated - handling a single 1-2Mbit/s stream takes 50%+ CPU usage on the Mac Mini currently being used for testing. Faster hardware, and possibly further optimisations, are required.

Selector component has been improved (local copy in the working dir) to increase responsiveness. Specifically, instead of requests to select on file handles queueing up at its inbox until the current select() call timeout fires; a separate filehandle is used to wake it immediately if there are pending requests.

The Multicast components have been optimised (local copy in the working dir) to sleep when inactive, using the Selector component to wake them.