[MPlayer-G2-dev] trying mp_image -> get/release_buffer migration...

[Arpi]

Hi,

After some problems raised (including still images and/or osd rendering
into non-temp buffers), codecs using new buffering schemes (like vp3's
gold frames, or h264's more-than-two P frames) i've decided to try to
change video filter layer (yes, i said video filter layer, and yes,
i remember what i did say before :))
to use the get_buffer/release_buffer concept insteda of current
MP_IMAGE_TYPE thingie (buffering schemes like static, temp, export, ip, ipb)

ok, it will be a hard and serious change, meaning that porting codecs &
filters from g1 will be not as easy... but i feel it does worth it.
and anyway as our primary codec is libavcodec, it will be even easier,
as it already uses get/release buffer scheme.

anyway my plans for this implementation inherits some key elements from g1's
mp_image stuff:

there will be a type field for get_buffer() requests:
- EXPORT (it means that memory allocation is done by codec)
- TEMP   
- STATIC (temp and static are actually the same, this type is only a hint
  for underlaying layers that we will keep this buffer after rendering for
  the next frames, or we'll drop it. maybe i'll leave this thing out?)

also there will be restriction flags, just like in g1's mpi, to define what
kind of stride and buffer alignment is accepted and do we need to preserve
buffer content or allocate it in fast (readable and/or random writeable)
memory.

main differences from g1/mpi style:
- no more specialized schemes like IP and IPB, and more than 3 buffers
  supported... (mpi is limited to 3)
- no 'one frame decoding == one get_image call' restirction. it's possible
  to allocate 3 buffers at init (or at first farme decoding) and then use
  them all them and then release them at uninit. or a filter (likeinv.
  telecine) may delay video by many frames, by allocating for example 5 of
  them. and so on, there is no limit. it will solve some problems we
  currently have. and it also make sit easier to implement filter
  merging/branching (multiple vo drivers, mixing 2 videos etc) _later_.
  also a buffer (image) may be returned multiple times by process_image().
- buffer structs aren't cloned/copied while transfering from one filter to
  another, like mpi. although i'm not sure it's required / is a good idea.

comments?


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu