Re: Re: trying mp_image -> get/release_buffer migration...

On Tue, May 27, 2003 at 11:42:15PM +0300, Andriy N. Gritsenko wrote:
>     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.

This was discussed about a month ago. PTS (or rather duration) is a
property of the image now, so it's not an issue.

>     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. :)

That's a slow and nonsensical way to do OSD... Yes, we want
multi-input support, but I don't think multiple opens makes any sense.
If anything, multiple config, once for each source, but open should be
called only once.

Rich