Faster DIVX playback, Better quality playback and solves some crashing in pocketmvp

fibrizo · 03-03-03, 06:25 PM

Here's a file I've been using from the beginning. I didn't know it made so much of a difference till I tried running normal PocketMVP without this file... My frame rate was alot worse with the default pocketMVP divx.dll... plus it crashed sometimes.... I hadn't tried it out because I always had this file and assumed that it didn't do that much. So I figured if some of you are having playback issues, try this file.. Also If you want higher framerates/better quality decoding... This version does B-frames...

Just unzip and make sure pocketMVP isn't running and copy the HQ arm divx.dll to your pocketMVP install folder on your PPC

http://personal.telefonica.terra.es/web/pdp/PDD80.zip

geezer · 03-03-03, 06:46 PM

Nice hint. Grabbing the file now. Will report back on any differences noticed.

Thanks.

Therigwin · 03-03-03, 08:15 PM

I notice that the date on that file is older than one that came with PocketMVP, but it is also a larger file too.

I put it in and I really can't tell any difference on the videos that I have (but mine are mostly shorts under 10 minutes)

But thanks for all the other great work you have done and tutorials you have provided.

geezer · 03-04-03, 05:17 AM

I agree with Tom. Not much difference in the drop frames on the trailers I have loaded. Playback seemed smoother. Which version of PMVP are you using?

fibrizo · 03-04-03, 02:20 PM

I'm using .8p of pocketMVP. The file is newer... even if the date is older... PocketMVP uses ver .62 of the dll and this is .80 with real B frame support. Of course you could try the low quality ARM file, which supposedly is even faster, but not as good quality with b frames decoding. But some people say they can't tell.

Aximifuwanna · 03-04-03, 02:45 PM

Would you consider me an idiot if I asked what the hell a "B frame" was? Because if you would, then I won't ask..

geezer · 03-04-03, 05:10 PM

Quote:

what the hell a "B frame" was

These are compiled together to create those famous "B" movies of yester year, popular among the younger folks at the drive-in theaters. Often low budget flicks with poorly scripted stories, over acted by wannabe stars and laughable special effects.

(sorry - couldn't resist);)

Jeff (who fondly remembers many nights at the drive-in...)

fibrizo · 03-04-03, 10:12 PM

A B-frame is a Bidirectionally encoded frame. That is, it uses extra bandwidth from before and after the frame is show to be encoded. At least that's my understanding.

domotang · 03-14-03, 05:30 PM

No doubt, the dll id much better optimized for divx movies. I can say that it more than doubled my framerate compared to PocketMVP's dll

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)