[MPlayer-dev-eng] libmpcodecs vs. filter layer

[Arpi]

Hi,

Problems given:
- we should move codecs to libmpcodecs, something similar to libao/vo
modular api
- we should implement filter layer - common buffer and postproc/color
conversion handling/scaling code
- we have to solve the problem, when demuxer can't decide audio/video
parameters from file headers (examples: mp3 stream, many quicktime files,
multifile demuxer)
- some codec's supported outfmt list depends on file (example: huffyuv, raw)
- we should implement direct rendering (supporting static, temp and mixed
(2*static+1*temp) buffer types)
- we shouldn't lost the ability of using slices

current way of video decoding:
- open demuxer, it MUST provide image dimenstions
- init libvo
- init video codec, allocate decoder buffer
{ for each frame:
- read frame from demuxer
- call video decoder
- call libvo draw_ function (sometimes made inside the codec)
}

it's simple, old, but bad, as it doesn't support solution of the above problems.
my today ideas about new way, including some talk with Ponstcho:

- open demuxer. it MAY provide image dimensions (and they MAY be wrong)
- init video codec, it should provide supported outfmt list
{ for each frame:
- call video decoder, it will use callbacks for:
   - read frame from demuxer (should solve B frames problem)
   - call buffer allocation code -> this is the main point!
     this function will get requested buffer parameters (dimensions, type,
     stride restrictions) and should be handled by some common code.
     (we planned this into libvo2 core earlier).
     - if image parameters changed, then (re)init libvo (it's really
       config() now, as init is started erlier to get outfmt list)
     - allocate buffer. it may be handled by libvo (using control() if
       supported -> direct rendering) or by dec_video core (memalign()).
       it should return a surface struct, containing buffer addresses,
       selected stride, optional slice updating callback func, and so on.
}

with this (not so big to be never implemented) change we will be able to
solve many problems, and also implement direct rendering and partial updates
(like draw_slice calls from libmpeg2)

changes to libvo are in range zero .. minimal.
changes to dec_video are big, but we can't avoid that, we should move codecs
to libmpcodecs anyway, things get ugly and messy there already.

accepting the above structural change, we should design libmpcodecs API.

yes, it's a big work, but can be done step-by-step, while keeping the whole
stuff still working.

what do you think?
comments welcomed, but i want to note, i'm thinking about the above change
for long time already, but the version described above is the first (and
maybe the only) easy but working solution for all of the problems.

we should handle very different behaviour of various libvo drivers, demuxers
and codecs, and find the best connection betweehn them while reducing
redundancy and increasing modularity.


A'rpi / Astral & ESP-team

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