I've got a problem with TSReader. Is debug trace information available to help diagnose the problem?

Yes, TSReader has a lot of debug output! You can catch this by running a third-party debug trace program such as DBGVNT:

• Download this tool
• Run the executable inside
• Click on Capture/Capture Kernel and Capture/Passthrough to disable these features
• When you run TSReader, you'll see a bunch of debug info. We will find this information very useful for bug reports!

What's the difference between the "Mux. Bitrate" and "Last Second" counters?

The mux bitrate is calculated by finding a PCR (Program Clock Reference) in the stream and then counting the bits that come between two of these PCRs and then averaging this over the time that TSReader runs. This results in accurate values for constant bit-rate streams but will vary on variable bit-rate streams.

The last second counter is the number of bits that flow through TSReader during the prior second. This will vary widely because Windows is not a real-time operating system. For example another process on Windows can prevent TSReader from running or a network delivered stream such as TCP or HTTP may temporary slow down packet delivery because of network congestion or packet loss. The buffering inside TSReader prevents packets from being lost so you may see this value drop and then jump up to a high value. TSReader also toggles this value between the bits received in the last second and the maximum it has seen during a run. If you see this value as zero, it indicates the stream has stopped. TSReader running from a file and the end-of-file being reached is one reason the stream may stop.

What are the two bars at the bottom of the TSReader window labeled in and out buffer?

These both show buffer fullness. If these indicators reach full a buffer overrun has occurred. You should shutdown TSReader and find out which process is taking CPU time up since typically that's what causes these buffers to overrun.

The top indicator shows the fullness of the buffer that's used to keep data coming in from the source (the satellite, cable, terrestrial tuner or a file). If this indicator overflows it's because the main processing thread that TSReader runs to parse the stream can't keep up with the data coming from the source.

The bottom indicator shows the fullness of the buffer that's used to stream a program out of TSReader when you use the Stradis or VLC interfaces. If this indicator overflows it's because the destination you're streaming to can't keep up with the stream.

Some satellite modules will tune DSS (DIRECTV) multiplexes. Does TSReader support this standard?

No. DSS is a pre-MPEG-2 system that uses 131 byte packets versus the 188 byte standard in MPEG-2. The standard is proprietary and not published, so TSReader decodes no tables from this standard, but it does align to the SCIDs (the DSS version of PIDs) and allows these to be recorded as individual files. Some people find this useful hence TSReader's support. DIRECTV's newer Ka-band transmissions are MPEG-2 standard.

Why do some PIDs on the PID chart have "~" between the percentage and data rate and others have "-"?

The PIDs that have the "-" between the mutliplex percentage and bit-rate have an accurate bit-rate because the PID is carrying PCR packets. As a result, TSReader is able to calculate the exact data rate for this PID. Those that have the "~" character have the bit-rate calculated by taking the multiplex rate divided the percentage of the multiplex being used by that PID, therefore the results aren't as accurate.

I selected the wrong source module. How can I change it?

For TSReader Lite and Standard, launch TSReader with the Ctrl key held down - you'll then be asked to choose a source again. For TSReader Professional, right click the profile in the profile browser and choose Profile Configuration.

What do the Thread Priority options do?

TSReader has a number of threads that move bytes through the various processes that are needed to receive and decode MPEG-2 transport streams. You can control the priority of each of these - for example if the CPU load is tight (you can check this with the Windows Task Manager - type Ctrl+Shift+Esc and look at the Performance tab) you might want to make TSReader run at a higher priority to ensure that TSReader doesn't drop packets.

There are three main threads and the actual Windows program priority:

Name Function
Data Input Thread This thread reads data from the input source module, if required aligns to the MPEG-2 packets and places them into a circular buffer which the Stream Processing thread then reads from. Part of this thread's code will be in the input source module and part of it inside TSReader depending on whether the source module uses TSReader to synchronize to the MPEG-2 packets.
Main Process Priority This is the priority of the Windows application part of TSReader. This part of TSReader does things like draw charts, display thumbnails and so on.
Stream Processing Thread This is the main processing thread in TSReader and listens to each packet sent by the Data Input thread. Here MPEG-2, ATSC, DVB, DCII and other types of network information are also decoded.
Thumbnail Thread This is the priority given to each of the thumbnail decoders. These threads take the ES data for each stream and then attempt to decode the bitstream. In the case of video streams, a thumbnail with a picture will be shown and for audio streams a simple chart showing volume level is created.


I recorded an entire transport stream because there were two programs I wanted to capture on at the same time. I now want to split out each of these two programs into individual files. How can I do this with TSReader?

This is called demultiplexing and that's what TSReader's Record Program function is for. It generates a single program transport stream by removing packets that aren't part of the current program and builds new tables to tell the decoder what PIDs the single program is using. Follow these steps to demultiplex the file:

  • Make a very short recording of the multiplex - this should only be long enough to get the PAT/PMT tables decoded.
  • Open this file with TSReader and after TSReader has decoded it, you'll get a message saying "Reached the end of the transport stream file".
  • Now select the program you want to demultiplex and click the Record Program button. Fill in the appropriate fields in the dialog.
  • After hitting OK, the status bar at the bottom of the TSReader window will saying "Recording to" and your filename.
  • Now locate the file you want to demultiplex using the Windows Explorer and drop that file onto TSReader's window.
  • When the files have been demultiplexed and you're ready to do the second program simply click on it's PMT entry and drop the file onto TSReader again.

What's are the "Defacto" and "ETSI" radio buttons on the record dialog for?

As usual, this MPEG-2 oddity can be blamed on General Instrument which is now part of Motorola. When the MPEG-2 specification was written there was only support for MPEG-1 or MPEG-2 audio. General Instrument wanted to use Dolby AC3 for their audio coding but had no way to tell the receiver that a PID contained AC3 audio because MPEG-2 didn't allocate a PMT type field for AC3 - just for MPEG audio. So General Instrument used one of the user defined PMT types of 0x81 for AC3 and this has now become the standard in North America - it's used on ATSC terrestrial transmissions, Dish Network's Direct-To-Home satellite service in addition to the Digicipher II system from Motorola.

When Australia was deciding which digital terrestrial standard to use (either DVB-T or ATSC), they decided they wanted DVB-T but with the ability to send either MPEG or AC3 audio. The DVB Group wanted to accommodate the Australians so they did a revision to the specs (which are published by ETSI) and now AC3 is officially supported in DVB. The problem though is that DVB used a different way to tell the receiver that an AC3 stream was present - they used PMT type 0x06 which had previously been used pretty much only for Teletext in Europe. To let receivers know that there's an AC3 stream there (and not Teletext), a special descriptor is included with the PMT - if the receiver sees this registration descriptor and it's the right value, then the receiver can conclude the stream is AC3.

On the input side, when TSReader looks at a stream it can handle either "Defacto" or "ETSI" ways of doing non-MPEG audio. The following table lists the additional audio formats supported by TSReader:

PMT Type Descriptors Resulting Audio
0x06 AC-3 descriptor AC3
0x06 BSSD descriptor LPCM
0x06 DTS1/DTS2/DTS3 descriptor DTS
0x81 None AC3
0x83 None LPCM
0x85 None DTS

The "Defacto" and "ETSI" options are only used for recording or streaming from TSReader. TSReader always adds descriptors to the stream regardless of whether the PMT type is Defacto or ETSI.

Audio Stream Defacto/ETSI Resulting PMT Type
AC3 Defacto 0x81
AC3 ETSI 0x06
DTS Defacto 0x85
DTS ETSI 0x06
LPCM Defacto 0x83
LPCM ETSI 0x06

Please explain what continuity errors mean?

An MPEG-2 transport stream contains data in 188-byte packets. The first four byes of each packet are header and flags and then there's 184 bytes of payload data — video, audio, tables, IP data -- you name it.

In the header, there's a 13-bit field (range 0-8191 decimal) which is the Packet ID (PID) of the packet currently being sent. There is also a four bit field (range 0-15) called the continuity counter. This field increments for each packet sent on that PID. For example, one might see a sequence like:

  PID 100 - continuity 0
  PID 101 - continuity 0
  PID 100 - continuity 1
  PID 100 - continuity 2
  ...
  PID 100 - continuity 15
  PID 100 - continuity 0
  PID 101 - continuity 1
  PID 100 - continuity 1

This field is used by receivers (and programs like TSReader) to make sure that the transport stream data is continuous, i.e. it hasn't lost packets. If a receiver tracks the continuity it can determine if packets on a particular PID were lost -- for example if the satellite signal is interrupted. Unfortunately, continuity errors give no indication of the number of packets really lost. Due to the random number of signal loss, the number of continuity errors is completely dependent on the structure of the stream.

So, given that they indicate packet loss, there are a few reasons why you might see continuity errors displayed in TSReader:

  • Data was lost from the cable, satellite or terrestrial channel -- for example you have too low a signal to receive data from the multiplex reliably.
  • The interface card has a problem with it's DMA engine or the transport stream file is corrupt.
  • The packet's continuity field is being filled in incorrectly. Many multiplexers are incorrectly configured and generate a few continuity errors from time-to-time.
  • The general rule is that if you see only one or two continuity errors per second you're probably OK but if the continuity counter increments quickly, there's something wrong.

What about TEI errors?

Most MPEG-2 networks use some form of forward error correction on the stream as it is transmitted so that errors in stream as seen by the receiver can be corrected. Some MPEG networks use multiple error correction schemes because they "do better" handling different types of interference to the transmitted signal. Generally speaking most MPEG networks use at least the Reed-Solomon error correction algorithm. On MPEG networks this error correction code can fix up to eight error bytes in each transport stream packet with only a 16 byte overhead.

However, if the Reed-Solomon decoder isn't able to correct the errors (too many of them), demodulators change a bit in the transport stream header to tell the demultiplexer that the packet has an uncorrectable error. This is flag is called the Transport Error Indicator or TEI.

What causes "ES has been blacklisted" when I click on an elementary stream?

TSReader tries to figure out encoder parameters for video and audio streams it encounters in the multiplex. To do this, it demultiplexes the transport stream packets associated with the stream down to PES packets which is what's really carried on the PID. Once TSReader has built a PES packet, it scans the packet to find the encoder parameters - resolution and frame rate for video, bit-rate and sampling frequency for audio for example.

There are a number of things that can prevent TSReader from doing this right. For example, if the transport stream packets being looked at have the scrambled bits set (indicating a scrambled stream), TSReader ignores that stream. This situation doesn't cause blacklisting because the stream might later be unscrambled, but say that an encoder is setup to generate a video stream and two audio streams and both are described in the PAT/PMT in the multiplex. Imagine the encoder has a problem and is actually only outputting one audio stream - TSReader has been told via the PAT/PMT that a stream is there but no packets are received on that PID and as a result, the code that's trying to parse the elementary streams hangs waiting for that data on the PID.

So, ES blacklisting occurs when TSReader encounters a stream that:

  • Times out at the PID level - if no packets from the PID are received within 3 seconds
  • The PID doesn't contain PES data (TSReader was unable to locate PES headers in the stream)
  • The PES packets are scrambled (there is an option for either/both the transport and PES packets to be scrambled in MPEG-2)

Why do I get thumbnails with big green pixels?

thumbnail-issue

One of the ways MPEG-2 compresses video is by sending only the differences between pictures. Video is sent using one of three picture types - I (Intra) which contains a complete picture, P (Predictive) and B (Backward Predictive) which both only contain difference information between these pictures and the I picture. So in other words, to get a complete picture with none of the green pixels one must ideally wait until an I picture comes along. However, many encoders are setup to generate an I picture once a second or more and waiting for this picture could slow down thumbnail generation.

That said, it's possible to get a full picture without waiting for an I-picture. The combination of usually three pictures (a BPB sequence) is normally enough to get a full picture without any of the green noise because of the way the MPEG-2 encoders are configured. If you do see green pixels, you can change the maximum number of pictures that TSReader decodes. This option is in the Settings/Thumbnail/Refresh rate/maximum pictures dialog . By default, four pictures are processed on MPEG-2 compliant systems, but for cases like this changing the value to five or six might be required to get a full picture. It's worth pointing out that if an I picture does come along, that will be used and the maximum count will be ignored.

There are actually two values for the maximum pictures - one for MPEG-2 video streams and the other for DCII systems. The DCII (Digicipher II) system uses MPEG-2 video but without I pictures. As a result, it can take 40 or more pictures to get a complete frame on a DCII video stream. When you watch a DCII picture (on a PC or a regular STB), you'll see green noise while the picture is built.

Because H.264 and H.265 transmit slices of the picture (the changed part of the picture) and not a complete frame, these decoders don't return a picture until a complete frame is formed and the default value of one in TSReader for both these stream types is usually fine.