TiVo Community Forum Archive 1 (http://archive.tivocommunity.com/tivo-vb/index.php)
- TiVo Underground (http://archive.tivocommunity.com/tivo-vb/forumdisplay.php?forumid=8)
-- cs22 file decoder (http://archive.tivocommunity.com/tivo-vb/showthread.php?threadid=30615)

cs22 file decoder

I tossed this together "real quick". If someone wants to try to mess with the cs22 (screen images) on their TiVo. The below source will decompress the cs22 file into a second file you can then play with. I haven't looked at this raw file any yet, but thought I would post this for others.

Obviously you need to compile this on your PC. It "should" compile on most enviroments (Borland, Watcom, MSVC, DJGPP, gcc, etc).

You will also need to pull some sample cs22 files from your TiVo. You can get them with Zmodem through a terminal program and a bash prompt on your TiVo. You can also mount a TiVo drive with Dylan's boot disk to get them.

The format of the program is 'programname srcfile.cs22 destfile". A possible format to convert these cs22 files to and from is pcx since it uses packbytes format also.

Of the 4 cs22 files in my /tvbin directory there seem to be two packbyte sizes. 346120 and 172840. Not sure what resolution these images are. Be curious to hear what others with more time figure out.

You can get it at the below URL.
http://home.cinci.rr.com/mhill/cs22decode.c


------------------
Belboz
belboz@cinci.rr.com

FWIW, I threw some random (gzip'd) data at /dev/mpeg0a and noticed that the
garbage image seemed to move around to different areas of the screen as time went by. Perhaps part of the image data describes which areas of the screen should be masked off.

quote:

---

Originally posted by Mr. Belboz:
Of the 4 cs22 files in my /tvbin directory there seem to be two packbyte sizes. 346120 and 172840. Not sure what resolution these images are. Be curious to hear what others with more time figure out.
[/B]

---

quote:

---

Originally posted by agt:

FWIW, I threw some random (gzip'd) data at /dev/mpeg0a and noticed that the
garbage image seemed to move around to different areas of the screen as time went by. Perhaps part of the image data describes which areas of the screen should be masked off.

---

I haven't looked at the actual content of these files yet, but didn't someone say they have a header? Looks like "PackBytes%d/n" where %d is the uncompressed size. I just want to note that the C code Belboz posted doesn't take a header into account, which might explain the extra space you found.

Oops. I'm stupid. I missed the fgets line. Never mind.

Hmm.. 172840 = 4321 * 40... Not much use there.
Well, 360 * 240 * 2 = 172800.. 40 bytes off
And 360 * 480 * 2 = 345600.. 520 bytes off

Why did you choose 352?

------------------
Otto, Supreme TiVoWarrior - Moderator - AVS Forum - Tivo Underground
"If once you start down the dark path, forever will it dominate your destiny. Consume you it will!" -- Yoda


[This message has been edited by Otto (edited August 17, 2000).]

if you notice that 1khz mp2 audio file, they use that for testing the sounds are prolly just variations of mpeg2 audio files.. (maybe)

quote:

---

Originally posted by agt:

FWIW, I threw some random (gzip'd) data at /dev/mpeg0a and noticed that the
garbage image seemed to move around to different areas of the screen as time went by. Perhaps part of the image data describes which areas of the screen should be masked off.

---

quote:

---

Originally posted by Otto:
I haven't looked at the actual content of these files yet, but didn't someone say they have a header? Looks like "PackBytes%d/n" where %d is the uncompressed size. I just want to note that the C code Belboz posted doesn't take a header into account, which might explain the extra space you found.

Oops. I'm stupid. I missed the fgets line. Never mind.

Hmm.. 172840 = 4321 * 40... Not much use there.
Well, 360 * 240 * 2 = 172800.. 40 bytes off
And 360 * 480 * 2 = 345600.. 520 bytes off

Why did you choose 352?

---

Well, these are input images, right?

However, I now have support for the 360 theory. I ran your decoder on the InstallingSoftware.cs22 and got a large file out of it. Looking at the hex, I noticed that the first 520 (0x208) bytes are a bunch of junk. Assuming this is a raw file bitmap, type of thing, I'd say that's a palette of some type. When I display that on the screen with osdwriter, there nothing on the top line, as far as I can tell. The rest of the file looks consistent with a straight bitmap image. And the size matches 360x480.

Now if I could only find an image editor that understood this file type...

Addition: sending the resulting raw file to the various /dev/mpeg0* does nothing, except garble the screen a bit on mpeg0o. However, running osdwriter output.raw does display the same screen as running it on the *.cs22 file.

------------------
Otto, Supreme TiVoWarrior - Moderator - AVS Forum - Tivo Underground
"If once you start down the dark path, forever will it dominate your destiny. Consume you it will!" -- Yoda


[This message has been edited by Otto (edited August 17, 2000).]

The image format of the raw file is 720 high by 240 wide, with a 520 byte header. I'm was able to open it in Paint Shop Pro 6.02 as a raw format file. I still haven't worked out that palette yet, however. It's in the header, I just don't know the format yet.

Bit of a weird image aspect ratio though. But that's definitely it. EDIT: No it's not. Paintshop pro assumes 24 bit color. I couldn't get it to work as 16 bit. That's why it was giving me weird aspect ratios.

------------------
Otto, Supreme TiVoWarrior - Moderator - AVS Forum - Tivo Underground
"If once you start down the dark path, forever will it dominate your destiny. Consume you it will!" -- Yoda

[This message has been edited by Otto (edited August 18, 2000).]

I think it's 360 x 480 but with 2 bytes (16 bits) per pixel, though it seems for 65k colors you'd need more than 520 bytes of header to describe the palette... I'm honestly not sure how it works yet, but I also suspect there might be a byte-order issue here (Intel's LSB-MSB vs Motorola's MSB-LSB)... but either way, if we can somehow translate the header (and thus the palette), we should be able to duplicate it.

I tried renaming the uncompressed version to every single image type that Paint Shop and Photoshop recognize, with no success. I tried every conceivable setting for "raw" in both programs, and was able to view them but the colors were way off...

I have some other ideas - neither program seems willing to take an image containing a palette for any raw type - it has to be either grey-scale or RGB or CYM (or whatever)... but nothing with a palette. So I'm thinking about trying to add the image header from an 8 or 16 bpp bitmap, and see if I can get it to recognize it. Then I may be able to somehow merge the palette into the header as well. If we can crack that, we should be able to easily whip up a BMP --> cs22 converter in C

I still don't know why I so badly want to get this to work - once I'm able to display my own images on the screen, I then will need to come up with a practical use... but I'm sure that won't take too long...

Also - I'm wondering if some of those bits are reserved for something like "transparency level". All image formats that I know of (except for .psd) cannot store varying levels of transparency - it's either transparent or opaque, no in-between. But keeping with TV standards, you need to be able to overlay an image over the video.

Consider this:

- TiVo can play only one MPEG type of image at a time, period. There is only one hardware decoder capable of displaying compressed images.

- TiVo can however mix raw video with the MPEG. Remember, you cannot mix compressed data without first decompressing both portions, mixing, then re-compressing them together - which the TiVo does not have enough processing power to do (same with audio).

Thus, all on-screen images that are mixed with video are raw (or RLE encoded, which is relatively simplistic in comparison to MPEG/JPEG). Hint: this is why the TiVo main menu will not overlay TV - it has its own animations in the back drop, probably in the form of an MPEG

What does all of this mean? I'm not sure, but my mind has been stuck on this all day. /dev/mpeg0v is for MPEG video. Go ahead and 'cat' something to it, you'll only see distortions in the video (proving my point above about mixing compressed data). The OSD is a separate rendering device (also why it records only the video, even if you're using the OSD to look at the description, for example).

To summarize, if we can figure out the color palette, the transparancy settings (how many bits are used for each - doesn't have to necessarily be 8:8 btw), the byte-ordering and so on, we should be able to project images, possibly as overlays and over only portions of the screen (perhaps ICQ messages, stock quotes, or whatever you can make a program on another PC send to the TiVo)...

PS - sorry for the long post - I've been up too long, and I tend to do 'brain dumps'

PPS - Thanks for the decoder, btw - it's been extremely helpful with this whole process

- J-Man aka Justin

[This message has been edited by J-Man (edited August 18, 2000).]

I've been thinking about this, and I agree with your conclusions that all the menus, guide, overlays, etc. Must be raw data. It just dumps them on top of the screen. At the same time, the overlays must support transparency and they don't need to support a lot of colors, really.

Then I started thinking about that 520 byte header. It doesn't really have to be a palette. That 520 bytes can be anything. With 16 bits of color, why not say that the image might be RGBA instead? 4 bits each, with the alpha channel providing 16 levels of transparency? This fits with what I've seen of the menus (note that the colors aren't great on some of the pictures in the titlebars of Tivolution Magazine. Also, the menus are partly transparent on the background as is the Live TV Guide on the TV image. The colors may be reversed, BGRA or something, but that's just details...

Just an assumption to work on that might be useful.


------------------
Otto, Supreme TiVoWarrior - Moderator - AVS Forum - Tivo Underground
"If once you start down the dark path, forever will it dominate your destiny. Consume you it will!" -- Yoda

[This message has been edited by Otto (edited August 18, 2000).]

quote:

---

Originally posted by Otto:
The image format of the raw file is 720 high by 240 wide, with a 520 byte header.

---

If you read the rest of the post, you'll see I was mistaken.

The image format is a lot trickier than it looks. Paint Shop Pro sucks. I'm going to have to sit down and write something to decode this thing the right way. It looks like 360x480 interlaced. It's weird and it's making my head hurt. I've got some more theories I'll code up tonight and give it a shot. I may be able to write a raw2bmp (and therefore a cs22->bmp) convertor. I'll give it my best this weekend.

I think it's interlaced, but I'm uncertain. I'll figure that out when I figure out the size. The 520 bytes may or may not be a palette. Frankly, I don't know what the hell they are. Maybe they're commands to the mpeg decoder, maybe they're transparency chunks, I dunno.

Here's the deal with the wack image sizes. The reason I thought it was 240 wide is that that loaded the image properly in paint shop pro. However, it was using 3 bytes per pixel (24 bit) and doesn't understand 16 bit at all. So when it read 720 bytes, it got 240 pixels out of it. However, that was good enough to get a wacky bad color image that resembled the original. The lines at least synched up though, and you didn't get any diagnoal jaggies because 720 bytes is the length of the line. It should be 360 pixels wide though, or maybe 480. If the image is 16 bit (4-bit RGBA?), then it's 360 wide. It also could be 12-bit (4-bit RGB?), in which case it's 480 wide. Either way, the width of a raster line in this image is 720 bytes, period.


------------------
Otto, Supreme TiVoWarrior - Moderator - AVS Forum - Tivo Underground
"If once you start down the dark path, forever will it dominate your destiny. Consume you it will!" -- Yoda

Ok the bigger packbyte files seem to be the following. This is unpacked obviously.

First 8 bytes unknown (header?). Could be offset, etc.

Next 512 bytes are RGB values for the 256 color palette. 2 Bytes per palette entry. Not sure on how the RGB values are mapped.

Image size is 720 X 480 with one byte per pixel so the final 345600 bytes make up the image.

I wrote a program to convert the above file to a Targa (TGA) file since it seems to be simple enough to use. Targa supports uncompressed images so it is a simple matter of tossing on a proper Targa header, toss out the palette, and then the image data.

The resulting TGA file looks great from an aspect ratio and pixel content. Just the palette is all messed up.

The smaller packbyte files have the 8 byte header as above and then 32 bytes which make up the RGB values for 16 colors (2 bytes per palette entry).

Haven't looked at the make up of the smaller packbytes files image. Not sure if it is a smaller size image, or 2 pixels per byte.

p.s. dont hunt me down if all of this is wrong.

------------------
Belboz
belboz@cinci.rr.com

[This message has been edited by Mr. Belboz (edited August 18, 2000).]

For a good time, "export DUMP_OSD=1 ; myworld" and then look in /var/tmp/osdDump.bin. Watch the file as you make menu selections, etc.

I'm heading out of town and can't play w/ this further.
Have fun folks, please post anything you find. Thanks.

quote:

---

Originally posted by Mr. Belboz:
I wrote a program to convert the above file to a Targa (TGA) file since it seems to be simple enough to use. Targa supports uncompressed images so it is a simple matter of tossing on a proper Targa header, toss out the palette, and then the image data.

---

quote:

---

Originally posted by Otto:
Care to toss us that source code?

---

RGBA - that sounds like a winner here. 4 bits per channel (RG and B), then 4 bits for transparency. I think that should yeild decent color results.

If that happens to be the case, I could probably whip up a program to convert a standard 24 bit RGB bitmap into a 12 bit RGB with a set transparency level or something to that affect - eg, take the 4 highest bits from each color channel, dropping the LSBs, and adding a common transparency level, settable from the command line ??

Source for the TGA converter would be most appreciated as well, as I'm sure it would prove helpful

quote:

---

Originally posted by J-Man:

Source for the TGA converter would be most appreciated as well, as I'm sure it would prove helpful

---

Actually, I (rather impatiently) just wrote my own. It's essentially the same as Belboz's though. I found the TGA specs and they are rather simple, really. I had no idea.

I'm still having problems figuring out the color format. I've tried several ways.


------------------
Otto, Supreme TiVoWarrior - Moderator - AVS Forum - Tivo Underground
"If once you start down the dark path, forever will it dominate your destiny. Consume you it will!" -- Yoda

Well, I'm convinced it's not RGB.

I went through every logical thing I could think of, and others that made no sense. I can't make heads or tails of the color format. I'm looking at CMYK and HSL now to see if its in one of these formats, but I am sure as heck that it's not RGB. I went to the trouble of looking at individual pixels, the color of which I knew, tracking them down in the file, seeing what colors they are, looking that up in the color map, converting to binary and visually comparing. They are more or less chaotic, in terms of differences on RGB. However, they have a vague CMYK feel to them, so I'm trying that now.


------------------
Otto, Supreme TiVoWarrior - Moderator - AVS Forum - Tivo Underground
"If once you start down the dark path, forever will it dominate your destiny. Consume you it will!" -- Yoda