[MPlayer-G2-dev] VP layer progress

[D Richard Felker III]

On Thu, Jan 01, 2004 at 03:26:25AM +0100, Arpi wrote:
> i've just read API3 doc from the above url.
> some notes:
> 
> PRESERVE/REUSABLE vs locking:
> think again my idea, of using 2 locks (a read lock and a write lock)
> instead of singel lock and these flags.

IMO it's not possible. It doesn't matter for AUTO (allocated) buffers,
but for DIRECT and EXPORT it matters a lot. For example, a vo driver
or filter might _not_ be able to provide a buffer if REUSABLE or
PRESERVE is needed. Buffers in video memory definitely are not
reusable (for very next frame, but might be reusable at some later
time). I don't know how to properly handle this. It's related to
buffer age...

Also think of EXPORT buffers. If PRESERVE isn't set, the dest filter
is allowed to trash the (possibly internal) buffers of the source
while processing.

> anywya, where do you want to put the locks and the flags? they will
> be link-only or be passed together with the image data?
> (i mean each link/context will have its own lock and flags, or the
> structure containing teh buffer pointers will have it, and it will be
> passed to next filters?)

My design has always been that locks should be on mpi's, not buffers.
But perhaps it's worth discussing.

> query_format:
> i very like the idea of reporting 'distance' of fault. clever!!!

Yes, I'm not sure how useful it is, but it could be nice. Actually I
think we need a more advanced query system for negotiating link
parameters, so the vp layer can see _why_ certain combinations fail
and auto-load filters to correct.

> what i miss:
> - stride handshaking/negotiation
>   (including 'classic' stride flags of g1, for MB aligned, byte-aligned,
>   pixel-aligned, and for planar modes the inter-plane restrictions like
>   uvstride*2=ystride etc)

The flags are there, but the code isn't complete. See striderest_t.
The align array specifies byte alignment requirements for each plane,
and the negotiation code will take the requirements and capabilities
of the source and dest filter and work out a common agreed-upon
stride, if possible. Otherwise expand will have to be loaded...

> - aspect ratio handling

SAR is negotiated at config time. Most filters can only output a
single SAR: either the same as their input, or 2x or 1/2 height or
something. Scale is probably the only one that can output any SAR, so
provided the user has selected to use aspect correction, the vo will
force scale to get loaded if it can't hardware-scale and the SAR
doesn't match the monitor's pixel aspect ratio in the selected video
mode.

> about locking implementation:
> PLEASE do it using functions to lock/unlock, do not alow the nodes
> change the lock variable directly. why?

I agree totally. That's why vp_lock_image exists.

Rich