Trent Piepho wrote: ... > > The version I was given by the author does P and B frames too but > > doesn't do motion compensation (yet?). Its not a public release tho - > > you should contact the author for source... > > In real time on a reasonable machine? That's pretty impressive. Of course > there is big range in what generating a P/B frame could entail. You could > just take the current frame, difference it from the last one, and call it a P > frame. The marginal cost of folding a difference operation into the DCT would > really be very little. Now if you compare each macroblock to the > corresponding ones from the last N preceding frames and the following N > frames, and choose the one that compresses the best, that's a lot more work. Yes real-time. However, you don't do the computation you describe. It wouldn't be MPEG if you did. P frames are always differences from the preceding I or P frame. B frames are always differences between the preceding I or P and/or the following and/or their average. The really expensive part is motion compensation search (choosing which macroblocks to difference from). Even so, and even with zero motion compensation it is by no means easy to do this in real-time. A naive MMX implementation would still be out by a factor of two or so on a 300-400Mhz machine. How do I know - try using mpeg2enc with zero motion compensation set ;-) Andrew
