[MPlayer-users] dxr3: divx2mpeg or divx2mpeg2

[Arpi]

Hi,

> I think it would increase speed in divx playing on a drx3 or any dvb card.

In theory - yes.
In practice - maybe... but not easy.

Problem: divx and other mpeg4 variants (including h263 and vivo) use
unrestricted motion vectors. it means that image is 64 pixel bigger in
both direction than visible area, and motion comp. operates on the full
image size. mpeg 1/2 decoders can't do that. i thought it should be possible
at least with the DVB card, to program decoder for w+64 * h+64 size image
and display only w * h area. but after reading all specs and some driver
source of SAA decoder chip, it seems it doesn't allow specifying different
area to view than to decode :(
Unfortunatelly lowlevel specs aren't fully public, so i'm not sure yet.

Second problem is that UMC area should be updated after each decoded frame.
I can't do it by hardware, and DVB card doesn't allow access to decoder
buffers from CPU. It allows from its own CPU (ARM) but i don't have any
programming specs (and ARM asm knowledge) how to do it.

So, it is possible to support mpeg4 with no UMC, but 99.5% of files uses UMC
so it has no much sense (compared to the work of implementing it).

It will be problem for XvMC (hardware idct/mc vga cards) too.

I don't know dxr2/3 card details, maybe they allow manipulating video
buffers.

Currently we decode divx and then encode to realtime mpeg1 (I frames only,
or I and P frames, it's very fast but produce bad quality/bitrate ratio, but
it doesn't matter so it isn't problem)
I think, for I+P version we should reuse motion vectors from the divx
decoder. It will save us from slow MV searching, but still forces to decode
I frames and execute MC to get P frames.


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu