Rewinding issues


I just bought a WD TV Live,

I am running the latest firmware,

I noticed that for a media player the system has a pretty choppy rewinding issues, while fast forwarding is much better than that.

Will there be a fix for that in the future or not?

Probably not.   That’s actually a fairly normal behavior for any device that’s playing back compressed content.

Rewinding with the same smoothness as Fast Forwarding requires a TREMENDOUS amount of CPU and I/O bandwidth.

So is this issue present on Apple TV and XBMC too?

I thought DVD’s were compressed , but they fast forward and rewind in a perfect manner

DVDs use different codecs and thus behave differently (it’s also one of the reasons they can’t compress as well).

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.”

thanx for the technical explaination,

but still WD TV rewind/forward method is not a peasant one…

the time moves faster than the picture, and I am not sure which to pick

move back or forward to the time I want, or look at the video and hit play when I reach the desired scene?

plus any one thinks the first click on WD TV, 1x or 2x I am not sure, is extremely slow?