On Wed, 24 Oct 2001, Sottek, Matthew J wrote:
> Mark, Billy,
>
> I was just about to implement this but after giving it some thought
> I'm not sure what it is that you want.
>
> > 2) For interlacing, I like the idea of an XV_FRAME_TYPE attribute:
> > 0 == frame, 1 == top field, 2 == bottom field. I'm worried about
> > the DRI API possibly not supporting stride on texture blits (is
> > this true?) and I'm not sure how to handle this for DMA
> > transfers.
>
> How is this going to work. Are you expecting to make two
> XvShmPutSurface() calls, one for the top field and one for the
> bottom? Each time providing just one field of data? or providing
> an XImage with both fields but only using one?
>
> I don't see how that is different that just doing two
> XvShmPutImage's now and doubling the pitch and vertical scaling.
Slight difference in that the client can't bias the top down
a quarter pixel and bottom upward by a quarter pixels so they
line up. And XvImages don't have a pitch to double. It's implied
from the width just as XImages are.
> The benefit of the TOP_FIELD BOTTOM_FIELD is that you can provide
> a whole image and display only one field at a time. I.e. the data
> is interlaced in the XImage but shouldn't be displayed progressive
> since it will look like crap.
>
> I have a different idea that might work out better. Define these
> four things:
>
> XV_TOP_FIELD 0x1
> XV_BOTTOM_FIELD 0x2
> XV_FRAME (XV_TOP_FIELD | XV_BOTTOM_FIELD)
> XV_HOLD 0x4
Hmmm. That would probably work OK. I kindof like HOLD as 0x0
though (ie, no fields displaying and it makes the min-max 0-3
instead of 1-4).
This probably also helps with 3:2 pulldown and the field
repeat.
Note that this introduces some slight uncertainty in the
display since the overlay might not correspond to the window
location when it comes time to actually display. But that's
not going to be a big deal since the times are short and
you get a delay now anyhow due to the overlay not going into
effect until the retrace on most hardware. It introduces
a larger lag between overlay and image when moving windows
which isn't going to be a big deal. You can't do this for
blitted video though. The cliplist is stale by the time
you display. Not a problem though since blitted video are
merely fallbacks.
Mark.
>
> The it works like this. You do an XvShmPutImage() with the
> XV_FRAME_TYPE set to XV_HOLD. The image (progressive or
> interlaced) is copied to the server but not displayed.
> The you can at any time set XV_FRAME_TYPE to be XV_FRAME
> (show the image now, both fields) XV_TOP or XV_BOTTOM.
>
> This has the benefit of getting rid of the unknown delay
> between the XvShmPutImage and the overlay flip since they
> are now separated (as they are in XvMC) plus you can display
> just top or just bottom.
>
> The XV_FRAME_TYPE will default to 0x3 (XV_FRAME) which means
> that apps using Xv without knowledge of this will just get
> a flip when they do an XvShmPutImage.
>
> Here is the process:
> get port, etc...
> set XV_FRAME_TYPE to XV_HOLD
> LOOP:
> XvShmPutImage()
> set XV_FRAME_TYPE to XV_TOP_FIELD
> (Top field shown asap)
> set XV_FRAME_TYPE to XV_BOTTOM_FIELD
> (Bottom field shown asap)
> set XV_FRAME_TYPE to XV_HOLD
> (Nothing happens on screen but the next put() won't flip)
> goto LOOP
>
> Let me know,
>
> -Matt
>
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
