[MPlayer-G2-dev] basic g2 vp (video pipeline) code

[D Richard Felker III]

[resent because mphq lost it]

[cut to keep from digging up an old thread with mostly outdated info]
In-Reply-To: <200311021858.hA2IwT9B025362 at mail.mplayerhq.hu>

On Sun, Nov 02, 2003 at 07:58:29PM +0100, Arpi wrote:
> > Maybe stride should be negotiated at config-time? That would help
> 
> nope, its impossiblee imho in many cases, and adds yet another
> limitation...

I decided to negotiate stride at config-time anyway. :)))))
So now it's time to address these issues...

> dont forget that config() happens befor ethe first frame is passed,
> so in case of 3rd party codecs, or anything special, you wont know
> the wanted stride before processing first frame

>From what I can tell, there are two cases:

1. The codec is rendering into its own internal buffer, which we'll
   export. In that case, we can wait to call config until it decodes
   the first frame, and then we're safe! In fact, in this case the
   only stride restrictions will be that the output filter has to
   accept the stride that the codec exports.

2. The codec is using a buffer provided by MPlayer, either automatic
   or direct rendering. So we already had to allocate an image before
   decoding the first frame! And thus we must have already known
   (somehow!) what stride we wanted.

Actually there's a slices case too, but we can handle that just like
with vd_ffmpeg.

If there are any problems with this, we can put stride restrictions in
the codecs.conf data. In fact, one is already there. The old "flip"
flag is dead, replaced by negative stride. This makes it so every
MPlayer-native filter can support flipped images, without having to
write special support for them.

So, I don't see any obstacles to config-time stride decision. Now I
just have to design a system of negotiation to decide where to put the
scale/expand/etc. filters to maximize performance...

Rich