H.263 is a video format the is pretty similar to what you find in MPEG. Like a lot of digital video formats, the first place size reduction happens is at the color level. As it turns out, having an equal representation of R, G, and B values like you are probably used to can be pretty wasteful. For example, your eye can recognize far more shades of green than red or blue. Knowing this, YUV formats are used instead of RGB (some times called Y'CrCb). Y, or luma, stores mostly the green info, while the other two components store the r and b components. Taking into account that your eyes don't need as much distinction between all the colors in the spectrum, YUV formats will generally include less information about the R and B component. In the case of H.263, a format known as 4:2:0 is used. 4:2:0 takes the Y component and stores an array of 8-bit values (width*height) for the image. Following this come the V & U components, which are both stored in individual arrays. However, the V and U values are sampled for each 2x2 block on the screen and only contain 1/4 the amount of information. The loss of detail sucks if you need really crisp edges and you aren't working in a high res environment, but for most types of video (like the average DVD for instance), your eye won't pick up on anything...after all, did you even know they were doing this to you until I told you? :-).
In any case, H.263 stores each frame and then compares the previous frame to the current one so that it can only save the changed portions. However, H.263 handles more than just bit by bit comparisons. H.263 looks for similar areas in the video to determine if something has moved, and then encodes some motion vector information to tell the decoder where to move the existing information.
Macromedia's implementation is pretty much standard H.263; however, they have removed some advanced features and changed up the H.263 headers. The docs don't really provide much info here, but it is relatively easy to convert between the two (hey, I got it right on my first try, so it can't be that bad). As long as you encode your H.263 data with type “0”, the only chunk you have to worry about is converting the H.263 packet headers. The docs say that the H.263 “Macroblock” (basically a 16x16 chunk of your image) headers are different, but my experiences is that, they are exactly the same when working with type “0“.
So, those of you eagerly awaiting the SWFSource.NET release.... we have a working version of H.263 support in addition to ScreenVideo (it's coded in managed C++, not C#, but it does the trick). Unfortunately, I'm still not sure of the patent liabilities involved and if Macromedia's implementation manages to get around them by nixing some of the more advanced features... if you happen to know anything about this, I'd love to hear from you.