Different codecs DO behave differently, but in many respects they’re similar in regard to how FF and REW are handled.
Here’s a primer on MPEG decoding I wrote for the TiVo community.
Faster than 1x FF giving “Smooth Video” is extremely processor intensive, and makes it too “Expensive” a proposition.
To do 1X play, the MPG stream is decoded “normally,” at real time, and each and every frame is rendered to completion.
To do 2X play “Smoothly,” EVERY frame still has to be rendered at twice Real Time, and every other frame displayed. That’s because each successive frame is “Built” on the previous one, and THAT one has to be built to completion based on the previous one, and so on, 'til you get to an I-Frame, which is NOT based on the previous one.
Same goes as you move faster. If you want SMOOTHNESS, EVERY frame MUST be rendered COMPLETELY, and then a subset of them thrown out. You have to multiply I/O bandwidth by your FF speed. Not practical, given that HD feeds can be 30-50 Megabits per Second, and a SATA drive isn’t going to give much more than 250 Megabits per second in practical cases, you’ll render the drive or CPU useless much beyond 4X FF. No more recording two streams while you Fast Forward another.
This is MPEG basics. You have I Frames, which are “COMPLETE” frames that are compressed in the same way that JPG is compressed. Each successive frame is built on CHANGES to that reference frame, using sets of P and B frames. You don’t get another COMPLETE frame until some time later.
So, to do fast forward, it’s MUCH more economical to scan the stream by loading a big buffer, find an I-frame, decompress it, display it, and move on, and only build intermediate frames as needed. It’s simply not practical to do “Smooth Motion” fast forward at arbitrary speeds. It’d likely be beyond the bandwidth capability of the storage medium.
Now, as to why different programs behave differently: It’s because they have different ratios of I Frames, P and B frames. You’ll even see this WITHIN a program sometimes, if you FF at 2 Clicks, you may see “Relative” smoothness during the program, and get really jerky FASTER Fast-Forward during commercials.
This also explains why you’ll seldom see smooth REVERSE. That’s even MORE processor intensive, because it has to go BACKWARD until it finds a Reference frame, then build all the NEXT frames (in a forward direction) until the NEXT Reference frame. Each of those frames now has to be buffered (again, in FORWARD order) then displayed in REVERSE order.
To quote Wikipedia: “Typically, every 15th frame or so is made into an I-frame. P-frames and B-frames might follow an I-frame like this, IBBPBBPBBPBB(I), to form a Group Of Pictures (GOP); however, the standard is flexible about this.”