I have a lot of transport stream captures. Over a terrabyte of them. Whenever I stay in a hotel, I pull out my USB DVB-T/C tuner and grab what I can. I have a custom-written capture tool I use for this, which first scans to find any streams it can pick up, then automatically captures each stream. Once I run this tool, I just need to wait for the results!

Recently, I did two trips to Reading, UK for work, a couple of months apart. I thought it would be interesting to compare the captures I took on these visits to see what changed in that time. It is worth noting that the first of these captures locked more frequencies than the second. I believe this is due to the slightly different locations of the hotels I stayed in. I’m sure there’s some fun regional edge-case things I could explore here, but that’s not really the purpose of this post.

The first capture was taken on the 18th August 2025, and the second on the 25th November 2025. That’s a period of 3 months, 7 days apart. My goal is to see what has changed and see if we can find any interesting differences.

The Tools

To start with, I’ll use a few tools together to get an idea of the differences between the streams:

• TSDuck will be used to generate a text report for each stream. This is a really cool open-source tool for processing and analysing transport streams. Using it this way is just scratching the surface of what it is capable of!
• Beyond Compare Any text comparison will do, but I will be using the excellent Beyond Compare.
• DVBInspector For deeper analysis, we will use another open-source tool, DVBInspector to pull apart the transport streams if we want to get more details on something we find.

First Pass Comparisons

To start with, let’s just try a text comparison of the TSDuck reports.

578MHz - TSID 0x8029

Looking at this comparison, we can immediately spot a few things. Firstly, there are three new services and some renamed ones. Most of the services are actually HBBTV OTT services. These are essentially just placeholders that launch a web stream. We can immediately recognise this because the services have the same, very low, bitrate. Of note though is that one of the new services is actually a full broadcast service - that is to say, the video and audio are present in the transport stream. This takes the number of total full services on this multiplex from 2 to 3.

Looking a little further down the comparison, we see that there’s now a new PID, not referenced by any services. It’s incredibly low bitrate though. Another change I notice is that the EITsched tables for other multiplexes in the network are being broadcast significantly less frequently. This means that if you’re tuned to this frequency and your guide is empty, it will take much longer to populate than it did before, especially further into the future (though I doubt it will actually be all that noticable). My guess is that this was done to save some bandwidth for the new service.

618MHz - TSID 0x4083

On the surface, there aren’t really many differences here. That’s not to say there are no differences however. Notably, there’s quite a bit less stuffing in this stream, with several services seemingly receiving more bandwidth. This is nice to see, since it probably increases picture quality a bit. Digging deeper, we see that one of the HBBTV applications has changed slightly in terms of which services it is attached to.

Another interesting change was that while ITV1 HD advertised an HE-AAC receiver-mix audio description channel, the PID was not actually present in the first capture, but is in the second.

626MHz - TSID 0x3006

There are a few more services here, and a lot more changes. Firstly, we see that some services found on 578MHz earlier were actually moved from here. Additionally, some others have left, and a few have been renamed. Interestingly, Shop On TV has become an HBBTV service offering a web stream, where it previously was a full broadcast audio/video service. Also interesting is POP which got renamed to POP Max, keeping the same service ID however the LCN changed from 205 to 212 (previously used by POP+1).

There is of course also now a Christmas service, That’s Christmas.

642MHz - TSID 0x200F

There many interesting changes here

650MHz - TSID 0x5040

There’s a couple of renamed services, but no additions or removals. talkSPORT changed from MPEG-1 to MPEG-2 audio, although the only real change here is a bitrate change.

The most interesting change seems to be on “ADULT smileTV3” - where the video and audio PIDs get replaced by “MPEG-2 PES private data” PIDs (with different PID numbers) and an MHEG-5 app. This poses an interesting question: If I were to replace the PMT with one advertising video and audio as before, would it then decode correctly?

This is actually quite simple to test. TSDuck can be used to replace tables within a stream.

1<?xml version="1.0" encoding="UTF-8"?>
2<tsduck>
3	<PMT version="0x01" service_id="22400" PCR_PID="0x0263">
4		<component stream_type="0x02" elementary_PID="0x0263">
5	  	</component>
6	  	<component stream_type="0x03" elementary_PID="0x0264">
7	  	</component>
8	</PMT>
9</tsduck>

This can then be used with TSDuck to replace the table already in the file: tsp -I file 650.ts -P inject --replace --pid 0x2cc pmt.xml -O file 650-fixed.ts

After doing this, I can confirm the video is indeed viewable in VLC. I will not, however, post any screenshots of this due to the nature of the content(!)

666MHz - TSID 0x1043

There really aren’t any differences of note here. There is on interesting thing though as I started digging: In both captures, several BBC services include two private data PIDs, one of which is tagged as containing an Application Information Table. The other is not tagged as containing any particular data, however through inspection with DVBInspector, I can see it does in fact also contain AIT sections. To be sure they are the same however, we can dump the two PIDs with TSDuck.

tsp -I file 666.ts -P tables -p 0x1BBF --xml-output 1bbf.xml -O drop tsp -I file 666.ts -P tables -p 0x1Bc1 --xml-output 1bc1.xml -O drop

After doing this, we discover that the only difference is the component tag used on the version included via DSM-CC (rather than the http-delivered app)

At first glance, this seems like it might be a weird thing to do. I suspect, however, that this is to allow the same data to be used in different places or on different transports, and to switch between the tables they need to just patch the PMT.

674MHz - TSID 0x6040

Not too many changes here, but there are a few. Here we see Ideal World and PBS America switching from being HBBTV-only services to containing video, while we also see ADULT Xpanded TV and ADULT Babestn switching the other way, becoming HBBTV only. POP has also moved here from 626MHz.

Summary of Service Changes

Added

Removed

Renamed

Moved

LCN Change