Duuudes... :) I think Matt's idea is AWESOME.. Absolutely gorgeous. Makes me almost cry.
> > 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. Yes that's the problem (although the pitch thing is avoided by setting up the image as a (width*2 x height/2) map and using the src offsets). > > 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). Yeah I think this idea is awesome. > This probably also helps with 3:2 pulldown and the field repeat. No, I don't think it helps here. You never, ever want to perform 3:2 pulldown on a progressive display. If your monitor refresh is 59.94hz and you're providing 24fps content you still are better off showing the first full frame for 3 refreshes and then the next full frame for 2. If you're using Xv as an API for TV output, you've got worse problems, since you need accurate timing information (and TV norm and stuff) from the output card to know what's going on anyways. Something like the v4l2 TV output API may be better suited for this. If you're doubling output to both a TV and an Xv window (ugh!) then you should build progressive frames and display them on the monitor and let the TV output grab fields as necessary. We can't do better then that. :( What XV_HOLD would really help with though is still images, such as when a video player is paused or when it's sitting in a menu or FBI warning (which is encoded on the DVD as a single I-frame). However: > 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. So, this breaks when we're paused or showing a still and you move the image around. Ugh. Are you sure this can't be handled in the hardware without the client having to do another put? Or do you expect the client to re-put whenever it moves (which it has to now anyways)? > > 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. Matt you're awesome. > > 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. Matt you rock my world. Just reset this back to 0x3 when any client releases the port. :) -- Billy Biggs [EMAIL PROTECTED] _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
