Mobility Site - View Single Post - Faster DIVX playback, Better quality playback and solves some crashing in pocketmvp

ARM Hacker · 03-14-03, 05:41 PM

In MPEG# (and I guess divx?) compression there are I frames, which are entire and complete frames, basically like a full screen jpg image. Then there are P frames, these contain some data, but just a block or two. Also they encode some 'motion compensation' data to move the current frame around.

Imagine a blue sky with an airplane moving across it, you wouldn't want to encode the whole frame. So you would encode data that only redrew the data for the airplane image changing. Imagine the camera slowly panning across a static scene, you wouldn't want to send the same data over and over in just a slighly different place, so you encode just the fact that a block of data at location X,Y moved in direction dX dY.

B frames never contain any actual picture data, they just contain motion compensation data, however they are able to specify moving data from the FUTURE as well as the past. For this reason the decoder (PocketMVP) has to be smart and decode the future P frames before acting on a B frame it finds. This is why these frames have different presentation and decode timestamps.

In a typical movie you will have IBBPBBPBBPBBIBBPBBPBBI. An I frame every second or so, then some munging of the picture before the next P frame which adds a few extra blocks, then some more munging, etc. By the time the second is over its time for a whole new frame of data though, otherwise the encoded movie will start to look less and less like the original (i.e. blurry crap).

(so the point is B frames are really desireable because they are low in terms of the space they add but they can get you more FPS or lower overall move size, and they can make the movie look better)

03-14-03, 05:41 PM	#10 (permalink)
ARM Hacker Aximsite Rookie Join Date: Jan 2003 Posts: 69 Thanked 0 Times in 0 Posts	In MPEG# (and I guess divx?) compression there are I frames, which are entire and complete frames, basically like a full screen jpg image. Then there are P frames, these contain some data, but just a block or two. Also they encode some 'motion compensation' data to move the current frame around. Imagine a blue sky with an airplane moving across it, you wouldn't want to encode the whole frame. So you would encode data that only redrew the data for the airplane image changing. Imagine the camera slowly panning across a static scene, you wouldn't want to send the same data over and over in just a slighly different place, so you encode just the fact that a block of data at location X,Y moved in direction dX dY. B frames never contain any actual picture data, they just contain motion compensation data, however they are able to specify moving data from the FUTURE as well as the past. For this reason the decoder (PocketMVP) has to be smart and decode the future P frames before acting on a B frame it finds. This is why these frames have different presentation and decode timestamps. In a typical movie you will have IBBPBBPBBPBBIBBPBBPBBI. An I frame every second or so, then some munging of the picture before the next P frame which adds a few extra blocks, then some more munging, etc. By the time the second is over its time for a whole new frame of data though, otherwise the encoded movie will start to look less and less like the original (i.e. blurry crap). (so the point is B frames are really desireable because they are low in terms of the space they add but they can get you more FPS or lower overall move size, and they can make the movie look better) Last edited by ARM Hacker; 03-14-03 at 05:44 PM.