[MPlayer-dev-eng] Video plugin layer

[Fredrik Kuivinen]

On Mon, Mar 25, 2002 at 07:42:08PM +0100, Arpi wrote:
> Hi,
> 
> > > [snip]
> > > > 
> > > > Comments? Should I commit this?
> > > haven't checked the code, but sounds interesting, feel free to commit
> > > it.
> ehh...
> 
> > I was under the impression that this was supposed to be implemented
> > through postproc, NOT as a fake vo driver. IMO this should at least
> > wait for Arpi's approval before being committed.
> 
> I don't like it but have no time to make it better, so dunno.
> I imagined the video filter layer implemented iside libmpcodecs.
> these filters would get an mp_image_t structure as input and request a
> destination one using get_image() then convert it.
> it would allow simple transforms liek flip, crop, extend as modification of
> few fields of the struct, without doing memcpy. it also should do the
> scaling/colorspace conversion/postprocessing job. 

I agree with you that it would be better. I didn't want to change any mplayer
APIs though and I don't know how to do it without changing them...

If the filter layer is in libmpcodecs where should they be called? in
decode_video? Then we wont be able to filter anything that uses
MP_IMGFLAG_DRAW_CALLBACK. That may not be a big problem as it is only mpeg2 that
uses the ..._CALLBACK thing (AFAIK). Maybe it is possible to change it without
efficiency losses. I haven't looked at it though. Or pass some other function
to libmpeg2 that it should call instead of draw_slice.

We will still have to copy the frame at the end of the filter chain if the
mp_image_t struct ends up with stride != 0 and it is a packed format though
(because of draw_frame). 

Btw: IMO we should deprecate draw_frame and draw_slice and introduce a new
function something like draw(mp_image_t* img, int x0, int y0) instead. We don't
have to change every vo driver at the same time to do this. We could use the
control interface instead.

> someone already working
> on virtualdub plugin support for mplayer/mencoder but needs a good interface.
> 

That would be me I suppose.

> We need it to be in libmpcodecs to be usable with mencoder too.
> But currently, as a big hack, mencoder emulates itself as being libvo driver
> :) so with the current "design" of mencoder it would work...
> 

I don't see whats wrong with the current mencoder design...

> So, the best thing would be building teh filter layer into libmpcodecs, as
> planned. If it's not possible (no volunteers) then commit this libvo hack.

I am a volunteer but I don't want to do everything myself especially not the
design. I prefer to discuss things like this before committing them because it
is always nice with other peoples suggestions, opinions etc.

I just read your video-filters.txt and I am actually working on something like
that now (Began with it when I read your comments in this thread.). I will
hopefully send a patch to dev-eng in a few days.

/ Fredrik