The DisplayStream program is a tool which was intended to aid developers in examining TyStream files extracted from TiVo.

All source code is public domain and was written by Charlie Payne.

TyStream data is displayed in a way that I thought was useful and intuitive, however since the TyStream format is still not completely understood, there may be errors in my understanding of the data and thus the way it is presented by the program. If you find out new information, please feel free to update the program.

Examining the TyStream format in a conventional hex editor is difficult and annoying at best, impossible at worst. DisplayStream is a special Hex Viewer application which uses color syntax highlighting, filters and other useful features to make examining the data easier.

Many values are displayed in HEX, it should be noted however that the following values are in decimal:

 Offset
 Count
 Packet Size
 Records

This can be confusing at times - particularly because "Packet Size" doesn't match "size". Keep this in mind. I actually wrote this program as a tool for myself, so I didn't bother with some frills. Take that as a warning, if you tell it to display ten thousand chunks, you can either kill the task or wait for it to crash on its own - it's not going to protect you from doing something stupid. If you don't like any of these limitations... fix it!

All source code is included. It was compiled for Microsoft Windows using Borland C++ Builder V3.0. The application itself is DisplayStream.exe, but if you need to be told that, you shouldn't be using this program. No technical support will be provided.

Despite its limitations, I have already found it to be extremely useful in trying to understand the TyStream format. Since there is still a lot we don't know about this format, I figured the program was still valuable.

Because I used some old disk functions, this program will not work properly on huge files. I'm not sure what the file limit is, but it's likely either 2 or 4 gigabytes.



Brief overview of TyStream format:

The TyStream format consists of many 128 KByte chunks, one after the other. Each chunk contains packets of data of various types and a table which tells you how to find the packets and gives information about them. The first byte of the chunk tells you the number of records in the table. After that are three other bytes (I don't know what they're for). After that is the table which consists of one 16 byte record after another. Each record corresponds to a packet of data. The records and the packets are in the same order. After the table are the packets and they too are placed end to end until the end of the chunk is reached. Then we continue the same way in the next chunk.



Description of program controls and data:

Stream filename: Path and filename of the TyStream file to be examined.
Chunk Offset:Number of chunks to skip before displaying data. In other words, if you want to view the fifth chunk in the file, enter 4.
Chunk Count:The number of chunks you want to display.
Audio:Check this if you want to view audio records and packets. This is determined by byte 3 (fourth byte) of the record, which should equal 0xC0 for audio. (audio and aud-P)
Video:Check this if you want to view video records and packets. This is determined by byte 3 (fourth byte) of the record, which should equal 0xE0 for video. (video, vid-P and vid-H)
Unknown:Check this if you want to view unknown records. This is determined by byte 3 (fourth byte) of the record, which should not equal 0xC0 or 0xE0.
Packet Size:This filter allows you to view only records and packets where the packet is a particular size. This can be very useful for filtering out specific types of packets. Be warned that some packets are not always the same size even though they may seem to be. For example video headers are usually 0x54 bytes long, but they can sometimes be 0x50 bytes long.

The Packet Size field also supports the following non-numerical entries:

 *Any size
 >20 Any packet longer than 20 bytes (20 is only an example, any number will do)
 <20Any packet shorter than 20 bytes (20 is only an example, any number will do)

LineBreaks:If this box is checked, a blank line will be placed between the data from each chunk. This can be very handy at times, other times the blanks just get in the way.
Display:This loads the data from the file and displays it in the listbox. Actually, it should be noted that it isn't a list box. It's actually a rich text edit box. This is very handy. Editing the data doesn't actually change the file, but it can be used to add notes as you work. Be warned that these notes will be deleted when you close the program or click the Display button again. You can select text to aid your eye while trying to view long lines. Because it is rich text, if you copy the text to WordPad it retains the colors, which can be great for taking notes.
Records:The number of records in the last chunk displayed. This is also the first two bytes of the last chunk displayed. They are stored in low byte-high byte order, which is odd because it's the opposite of the other TiVo data.
First 4 bytes:The first four bytes of the last chunk displayed. Two of these bytes can't be found anywhere else, so I thought they should be displayed somewhere.


If you re-size the program's window, the list box will re-size with it, that way if you have a big enough screen you can view a whole line of data at once without having to scroll around.

The hex view (black text) on the left size of the list box is the table which describes the packets of data. Each horizontal line of sixteen two-digit hexadecimal numbers is one record of the table. The Packet it describes is displayed on the same line to the right of the vertical divider. The packet data is the red and black text. Actually, it's just the black text. The red text shows you the data that comes before and/or after the actual packet data. Usually you ignore the red text, but it can occasionally be handy. Often the red data is just a duplication of the data on the line above or below. If a packet is longer than 16 bytes, it is truncated to 16 bytes. There is no way in this program to display the remainder of the packet (though the last three bytes of it are usually displayed in red on the next line).

the green text "size=" indicates the size of the packet. This is derived from bytes 0 and 1 and the most significant nybble of byte 2 of the record. It is placed here for convenience. The size is only listed for audio and video packets, as far as we know, the "unknown" records don't actually have a packet associated with them, so no size is appropriate.

The column of information in parentheses just to the left of the vertical divider indicates the type of packet. Black hex numbers are "unknown" packets. Audio is green or blue and is determined by a "C0" in byte 3 of the record. Video is purple, maroon or red and is determined by an "E0" in byte 3 of the record.

"audio" in green is data that is part of the audio elementary mpeg stream. "aud-P" in blue is what I believe to be an audio PES header which gives information about the stream, but is not actually part of the stream itself. Though I could be wrong, this is just what appears to be the case. I am making this determination based on the least significant nybble of byte 2 of the record, though I've never noticed anyone else doing this, so again, it may be wrong. I assume "aud-P" whenever that nybble is equal to 3 and the type is audio.

"video" in purple is data that is part of the video elementary mpeg stream. "vid-P" in red is what I believe to be a video PES header which gives information about the stream, but is not actually part of the stream itself. Though I could be wrong, this is just what appears to be the case. I am making this determination based on the least significant nybble of byte 2 of the record, though I've never noticed anyone else doing this, so again, it may be wrong. I assume "vid-P" whenever that nybble is equal to 6 and the type is video.

"vid-H" in maroon seems to be data that is part of the video elementary mpeg stream. I believe it is a video header, so I called it "vid-H". I am making this determination based on the least significant nybble of byte 2 of the record. I assume "vid-H" whenever that nybble is equal to 7 and the type is video. Note that sometimes the packet is only 4 bytes long, when this happens it is continued in the next packet, and it looks like the packet may be padded with one, two or three leading zeros which will need to be removed during extraction. In my experience when it isn't 4 bytes, the whole header is in one packet and it has no leading zeros. My assumption is that all of this has something to do with 32 bit word alignment. You may notice that all packets have a size that is divisible by four.


Download application and source by clicking here.