[MPlayer-dev-eng] New Codec Interface

[Arpi]

Hi,

> 	A'rpi, I checked out your first draft of the new codec interface.
> Good thinking, overall. So, if I understand it right, the demuxer will not
> make any decision regarding the dimensions of the video in a file, and the
> output format will no longer be specified in etc/codecs.conf? Instead, the
> decoder will callback to the MPlayer app and specify a list of formats
> that it knows how to output? And it will also make the decision about the
> image dimensions? Or will the file demuxer get the dimensions from a file 
> (if available), and give the decoder veto power over the dimensions?
yes.
there are few cases when the demuxer doesn't know the image parameters. such
examples are mp3 audio, png/jpg image sequence, many qt/mov files (they have
something in the ehader but sometimes it differs from the real coded
dimensions and it indicates teh wanted display size after resizing - silly
quicktime feature, there the codecs handle scaling and colorspace conv.)
if demuxer can extract something, it will be placed in the header. but if
the codec finds it bad, it can override. anyway only teh codec knows what
buffering modes are supported and with what limiattions.

about codecs.conf: no, i won't change it soon. it will keep default options
for codecs, but for example, at vfw/dshow codecs they can be queried (anyway
the answer is sometimes bad, so codecs.conf still can override it)

> 	Another thing that wasn't quite clear: Will this new architecture
> entail having the decoders dispatch video frames to the video rendering
> subsystem (like in VFW and QT, as I understand them)? Or will it be like
> the current system where MPlayer calls a decoder, the decoder draws the
> frame to a buffer, and returns execution to the main app and lets it worry
> about drawing the frame?

the codec (or dec_video.c core) will callback to libvo.
and it will handle scale/resize etc filters and colorspace conversion.

mplayer calls teh codec
the codec determines image parameters
codec callbacks to libvo and confi it to best matching mode (and enable
colorspace conv and direct rendering automagically)
codec callbacks to get_surface(), which will either malloc(0 or call libvo
for direct rendering buffer. or call nick's pre-decoding buffering code...

> 	Also, is it okay if I monkey with the sh_video_t structure and add
> a proper palette structure?
put the palette pointer into sh_video_t


A'rpi / Astral & ESP-team

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