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

[Andriy N. Gritsenko]

    Hi, Arpi!

Sometime (on Tuesday, May 27 at 23:06) I've received something...
>- 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?

    One question is how we have to calculate presentation time at end of
filter chain if some filter will get more that one frame at once? That
value is needed for any sync algorithm so we have to check it. Current
scheme has it as sh_video->ds->pts but if we pull 5 frames (for example)
then pts there will be advanced either. The same if some filter will
scale pts (slowing or fasting video). So I think we have to have per-vf
pts value now.

    Another question is if we will allow mixing video. It will be very
big advantage to have more that one input stream for filter. So I think
while you already will change vf_instance_t then you can add some new
function vf_reopen_filter(). I'll try to describe it. If filter can have
_only_ one input stream then all is as it is now and vf->prev contains
previous vf and vf_reopen_filter() will work exactly as vf_open_filter().
If filter can support more than one input stream then it on open() will
remove vf->prev into internal structure and set vf->prev to NULL. Then
next call of function vf_reopen_filter() will check it and return error
if that pointer is no-NULL. So for filter with only one input stream that
vf_reopen_filter() will call vf->open() only once and for filter with
more streams it may be called as much as filter allows. I hope that
solution is good and fully compatible with all current implementation.
That have also another advantage - it allows as to build concurrent OSD
just as filter module not another layer that will mix video and OSD
inputs. :)

    With the best wishes.
    Andriy.