[MPlayer-dev-eng] Decoder With Motion Compensation

Arpi arpi at thot.banki.hu
Thu Feb 28 02:40:39 CET 2002


Hi,

> On Wed, 27 Feb 2002, Arpi wrote:
> 
> > imgfmt_static is not good for you.
> > anyway its' teh old filter layer stuff, i've redesigend this long time ago
> .

anyway just commited initial version of libmpcodecs core, and two sample
codecs (cinepak and null). this API supports various buffering modes:

// codec doesn't support any form of direct rendering - it has own buffer
// allocation. so we just export its buffer pointers:
#define MP_IMGTYPE_EXPORT 0
// codec requires a static WO buffer, but it does only partial updates later:
#define MP_IMGTYPE_STATIC 1
// codec just needs some WO memory, where it writes/copies the whole frame to:
#define MP_IMGTYPE_TEMP 2
// I+P type, requires 2+ independent static R/W buffers
#define MP_IMGTYPE_IP 3
// I+P+B type, requires 2+ independent static R/W and 1+ temp WO buffers
#define MP_IMGTYPE_IPB 4

for your case, MP_IMGTYPE_IP seems to be ok, with flags PRESERVE and READABLE.

libmpcodecs doesn't work yet (i mean it should work, but not yet used),
i'll finish it in next few days and start adding more codecs.

anyway, i suggest implementing MC+DCT based codecs into libavcodec, as it
has the whole general framework for this. in short, it's enough to code
vlc/huffman decoding and the others (MC and DCT and buffer handling) is done
by the well-optimized libavcodec core.
i don't see sense of adding and optimizing again a whole MC+DCT core to
mplayer...


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu



More information about the MPlayer-dev-eng mailing list