[MPlayer-dev-eng] New Codec Interface

[Arpi]

Hi,

> I just looked at the document about libmpcodec structure, and it looks 
> good.
> 
> The only thing I miss is a generic pointer in sh_video to let a demuxer 
> pass some special info to a decoder. Some formats store values in movie 
> header (as an example, QT mjpa uses fiel, mjht and mjqt to keep field 
> ordering info and some optional tables), and it would provide a 
> standard way to pass them to the decoder. Now we have a void *context 
> pointer, but it's used by the decoders to store malloc'ed internal data 
> (examples are fli or cinepack).

good idea. anyway, implementation is a bit harder.
we should collect these infors and add new fields to sh_video_t.
for example, field_no, to store field numbering. palette for palette infos
and so on.
we should imagine if more than one demuxer and more than one decoder use
this info. anyway, codec-dependednt stuff is usually stored appended to the 
BITMAPINFO structure, so windows media formats (avi, asf) can store it and
resture at play time. qt uses chunks for these, so it's not easy.

> I have a question about direct rendering (see A'rpi mail in DECODING 
> AHEAD thread): if a decoder uses method 2 (copy to video mem after each 
> macroblock/stride) it has to take care of color conversion: will 
> mplayer provide a library to do it, at least for most commonly used 
> block sizes (4x4, 8x8, 16x16)? We have rgb2rgb, but it works on a 
> linear buffer, not on blocks.
I hope so. Michael? :)

anyway, as they are very small areas (at least MB level). it will be
probably a few mmx instructions. So calling it from a library may be too
slow, i prefer included inline functions from sone .h file.
having emms outside, handled by teh caller, a smost codec doens't use floats
at all, so doing emms after each MB could slow down things.

> Also why do you suggest method 1 for write only partial update decoders 
> (fli, ...). It seems to me that method 2 is best suited. Or am I 
> missing the point completely? Obviously buffer type would be static w/o.

if you have a single, static buffer, and you don't need colorspace
conversion or other filtering, then method 1 is faster, as the codec can
directly update image in video ram. as these codecs doens't read back
previous frames (no MC) they will never read video ram just partially update
it.

> By the way,are you going to implement direct rendering at the same time 
> as libmpcodec or it will be a future step?
yes. i'm working on this.

> Are we going to include some generic code to perform colorspace 
> selection using codecs.conf values if a decoder doesn't have a reason 
> to force it?
in the next step.


A'rpi / Astral & ESP-team

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