Re: [Xpert] Xv hit list
Sottek, Matthew J wrote: Here is the proposal again, if there are on complaints I'll implement it this way. #define XV_HOLD 0x0 #define XV_TOP_FIELD0x1 #define XV_BOTTOM_FIELD 0x2 #define XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD) Just to clarify, the default atom value will be XV_FRAME right? --greg. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert] Xv hit list
Sottek, Matthew J wrote: Here is the proposal again, if there are on complaints I'll implement it this way. #define XV_HOLD 0x0 #define XV_TOP_FIELD0x1 #define XV_BOTTOM_FIELD 0x2 #define XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD) Just to clarify, the default atom value will be XV_FRAME right? Yes, existing Xv clients do not need to change anything. It will works just like it always has. Clients can query for the XV_FRAME_TYPE atom to see if the driver supports this new functionality. I plan on resetting it whenever the Overlay is turned off. --greg. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] Xv hit list
Sottek, Matthew J wrote: Sottek, Matthew J wrote: Here is the proposal again, if there are on complaints I'll implement it this way. #define XV_HOLD 0x0 #define XV_TOP_FIELD0x1 #define XV_BOTTOM_FIELD 0x2 #define XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD) Just to clarify, the default atom value will be XV_FRAME right? Yes, existing Xv clients do not need to change anything. It will works just like it always has. Clients can query for the XV_FRAME_TYPE atom to see if the driver supports this new functionality. I plan on resetting it whenever the Overlay is turned off. Another question real fast. If I blt a frame with the XV_FRAME_TYPE atom set to XV_FRAME|XV_HOLD, and then, sometime later, I set the atom to XV_FRAME, what kind of latency would I be looking at before that held buffer would show up? Is setting atoms a synchronous call? Would I be certain the frame is on the screen when it returns? I don't really care which way as long as Can it be required that all XV_HOLD -- !XV_HOLD transitions happen in the vblank somewhere? That way I can just worry about setting the atom as close to frame display time as I can and not worry about the tearing. I guess I am just looking for another way to work around not getting vsyncs at my level. Now that I think about it, what effect, if any, will this have on drivers that implement their own multi-buffering? Another clarification question, what happens in this case: XV_FRAME_TYPE = *|XV_HOLD XvShmPutImage() ... XvShmPutImage() ... XvShmPutImage() XV_FRAME_TYPE = *!XV_HOLD I take it that only the last frame put will show up? --greg. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] Xv hit list
On Fri, 26 Oct 2001, Greg Wright wrote: Sottek, Matthew J wrote: Sottek, Matthew J wrote: Here is the proposal again, if there are on complaints I'll implement it this way. #define XV_HOLD 0x0 #define XV_TOP_FIELD0x1 #define XV_BOTTOM_FIELD 0x2 #define XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD) Just to clarify, the default atom value will be XV_FRAME right? Yes, existing Xv clients do not need to change anything. It will works just like it always has. Clients can query for the XV_FRAME_TYPE atom to see if the driver supports this new functionality. I plan on resetting it whenever the Overlay is turned off. Another question real fast. If I blt a frame with the XV_FRAME_TYPE atom set to XV_FRAME|XV_HOLD, They're not bitfields. XV_HOLD = 0. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert] Xv hit list
On Fri, 26 Oct 2001, Sottek, Matthew J wrote: Sottek, Matthew J wrote: Here is the proposal again, if there are on complaints I'll implement it this way. #define XV_HOLD 0x0 #define XV_TOP_FIELD0x1 #define XV_BOTTOM_FIELD 0x2 #define XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD) Just to clarify, the default atom value will be XV_FRAME right? Yes, existing Xv clients do not need to change anything. It will works just like it always has. Clients can query for the XV_FRAME_TYPE atom to see if the driver supports this new functionality. I plan on resetting it whenever the Overlay is turned off. I think the idea was this is a write-only attribute and only applied to the next Put. That is a self-canceling option. Autoreseting on off only cleans up if the client quits after it sets the attribute but before it calls Put. As a side note to the ReputImage stuff in the server, I think the appropriate usage might be to ignore all Stop requests that don't have the exit flag set. It looks like Stop still gets called during clip changes. Is XV_FRAME_TYPE the best name for this? In the MPEG stream this would be called the picture_structure. I have no objection to XV_FRAME_TYPE, but I'm wondering if there is a more descriptive name. mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] Xv hit list
Sottek, Matthew J wrote: XV_FRAME_TYPE = XV_HOLD XvShmPutImage() ... XvShmPutImage() ... XvShmPutImage() XV_FRAME_TYPE = XV_FRAME The target of the XvShmPutImage will only change when XV_HOLD is set. (Or if XvShmPutImage is called without XV_HOLD) So however many XvShmPutImage()'s get called while in XV_HOLD get put in the same place overwriting each other. Once I get an implementation done I'll write up some clear documentation. -Matt You and Mark were right, I was still thinking they were bit fields. But, I still have a question on the above example. In a follow up post Mark points out that the XV_FRAME_TYPE (or whatever it ends up being called) is a write only atom that takes effect on the next put. Is that the case? If so, The above won't work right? Just setting XV_FRAME_TYPE to XV_FRAME will not display the last held frame, instead, it won't do anything until the next put which will have new data. or am I confused again? --greg. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert] Xv hit list
On Fri, 26 Oct 2001, Sottek, Matthew J wrote: If I blt a frame with the XV_FRAME_TYPE atom set to XV_FRAME|XV_HOLD, and then, sometime later, I set the atom to XV_FRAME, what kind of latency would I be looking at before that held buffer would show up? Is setting atoms a synchronous call? Would I be certain the frame is on the screen when it returns? I don't really care which way as long as I will flip the buffer on the the next vertical retrace. The XvSetAtom call will return quickly as long as you don't call it more than once per vertical retrace, then is has to block. XvSetPortAttribute and Xv(Shm)PutImage (and most other Xlib functions) do not return. They send a message to the X-server. The X-server will process it when it gets it. As usual, if you need this request to go to the server immediately you need to call XFlush. If you need an acknowledgement that the server processed the event you need to call XSync. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] Xv hit list
On Fri, 26 Oct 2001, Greg Wright wrote: Sottek, Matthew J wrote: XV_FRAME_TYPE = XV_HOLD XvShmPutImage() ... XvShmPutImage() ... XvShmPutImage() XV_FRAME_TYPE = XV_FRAME The target of the XvShmPutImage will only change when XV_HOLD is set. (Or if XvShmPutImage is called without XV_HOLD) So however many XvShmPutImage()'s get called while in XV_HOLD get put in the same place overwriting each other. Once I get an implementation done I'll write up some clear documentation. -Matt You and Mark were right, I was still thinking they were bit fields. But, I still have a question on the above example. In a follow up post Mark points out that the XV_FRAME_TYPE (or whatever it ends up being called) is a write only atom that takes effect on the next put. Is that the case? If so, The above won't work right? Just setting XV_FRAME_TYPE to XV_FRAME will not display the last held frame, instead, it won't do anything until the next put which will have new data. I wasn't expecting clients to call XV_HOLD then Put and not display it afterwards. There seem to be two feasible implemenations: 1) XV_HOLD stays into effect until it is displayed. If a second Put comes along before the display the new Put overrides the first. 2) XV_HOLD gets canceled after a second put. I expect 1) is easier to implement. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert] Xv hit list
I wasn't expecting clients to call XV_HOLD then Put and not display it afterwards. There seem to be two feasible implemenations: 1) XV_HOLD stays into effect until it is displayed. If a second Put comes along before the display the new Put overrides the first. 2) XV_HOLD gets canceled after a second put. I expect 1) is easier to implement. The cleanest concept is to have the client set the XV_FRAME_TYPE and not let the driver alter it. The client is then in total control of the display. The only way the overlay will change after having been set to XV_HOLD is for the client to set it to something else. So this isn't really what you describe in #1. The XV_HOLD stays in effect until the client changes it. XV_FRAME_TYPE modifies the behavior of XvShmPutImage() but XvShmPutImage() does not have an effect on XV_FRAME_TYPE. Let's describe it this way. When XV_FRAME_TYPE is XV_HOLD all changes to the overlay are held in a buffer until the XV_HOLD state is removed. This includes all atoms, data, position and scaling parameters. Only the latest values will be used when the XV_HOLD state is exited. Further, the overlay will only display the requested fields when displaying. When XV_FRAME_TYPE is not XV_HOLD all changes to data, position, scaling, and atoms are applied as soon as possible. The overlay will only display the requested fields when displaying. This is actually really useful. Then you can change a bunch of attributes and the data during a XV_HOLD. The changes will all show up at the same time when you remove the XV_HOLD. As it is now changing an attribute requires an overlay update which may make your next flip have to wait. That is undesirable. -Matt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert] Xv hit list
On Fri, 26 Oct 2001, Sottek, Matthew J wrote: I wasn't expecting clients to call XV_HOLD then Put and not display it afterwards. There seem to be two feasible implemenations: 1) XV_HOLD stays into effect until it is displayed. If a second Put comes along before the display the new Put overrides the first. 2) XV_HOLD gets canceled after a second put. I expect 1) is easier to implement. The cleanest concept is to have the client set the XV_FRAME_TYPE and not let the driver alter it. The client is then in total control of the display. The only way the overlay will change after having been set to XV_HOLD is for the client to set it to something else. So this isn't really what you describe in #1. The only way to display it after XV_HOLD has been called is to call XV_FRAME_TYPE. That clears the XV_HOLD so I think this is #1. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] Xv hit list
On Wed, 24 Oct 2001, Billy Biggs wrote: 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)? It's up to the driver. The driver can have Xv track window positions. That's what the RePut functions in the Xv-driver interface are for. But using this means that you always have to copy all the data to offscreen and not just the part that is displayed because different parts may be visible when you move the window around. That makes display in Xinerama prohibitory which is why I never use that interface in any of my drivers. In Xinerama, each card only copies the part it is displaying rather than copying the whole image. That, of course, means you can't continue to display when the window moves because you usually need data you haven't copied. To ensure that clients work with all implementations they should Put after window configure events. 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. :) The driver doesn't see port releases. This would have to be a write-only attribute that applies to the next Put in the case of HOLD, or to whatever valid data the driver still has in offscreen memory (if it exists) for the display. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert] Xv hit list
On Thu, 25 Oct 2001, Sottek, Matthew J wrote: Ok, I slightly modified the idea to take care of this too. I must say, I really really like this one. #define XV_TOP_FIELD 0x01 #define XV_BOTTOM_FIELD 0x02 #define XV_FRAME (XV_TOP_FIELD | XV_BOTTOM_FIELD) #define XV_HOLD 0x04 Mostly the same behavior as before, but now we really use these as bitfields. When the XV_HOLD bit is ON, the data is not updated onscreen at the end of an XvShmPutImage. It has to wait until the HOLD bit is removed. Here is the change, Bits 0 and 1 indicate the fields that will be updated with the next XvShmPutImage. The image position and scaling information are always updated. Here are some example uses. Default Case: (Works just like it does now) XV_FRAME_TYPE = XV_TOP_FIELD | XV_BOTTOM_FIELD (Default) XvShmPutImage: Both fields are updated from the XvImage, the data is updated asap onscreen since the HOLD bit is not on. Interlaced Video: XV_FRAME_TYPE = XV_HOLD | XV_TOP_FIELD | XV_BOTTOM_FIELD XvShmPutImage: The top field and bottom field are updated from the XvImage. The position, size and scaling information are updated from the call, but the overlay is not updated onscreen. XV_TOP_FIELD | XV_BOTTOM_FIELD is redundant. You can't not copy both fields. XV_FRAME_TYPE = XV_TOP_FIELD The overlay is updated with the latest information and set to show only the top field. The onscreen update happens asap. XV_FRAME_TYPE = XV_BOTTOM_FIELD The overlay is set to show the bottom field and the onscreen update happens asap. Paused Video: Loop: XV_FRAME_TYPE = XV_HOLD XvShmPutImage: NO Fields are updated from the XvImage, but the position and scaling information are taken from the call. The overlay is not updated onscreen. XV_FRAME_TYPE = XV_TOP_FIELD On Screen changed happen asap. goto Loop This is confusing. I don't understand what you are trying to do here. Mark. Paused Video (Better way): Loop: XV_FRAME_TYPE = 0x0 XvShmPutImage: NO Fields are updated from the XvImage, the position and scaling information are updated. The HOLD bit is not set so overlay is updated asap. This means that for a pause you just set The frame type to 0 and continue with puts as normal. No data copying takes place. goto Loop Field at a Time Interlaced: XV_FRAME_TYPE = XV_HOLD | XV_TOP_FIELD XvShmPutImage: Only the top field is read from the XvImage. This is done by taking the first line and then skipping every other line. The position, size and scaling are updated from the call. XV_FRAME_TYPE = XV_TOP_FIELD Update on screen happens asap. XV_FRAME_TYPE = XV_HOLD | XV_BOTTOM_FIELD XvShmPutImage: Only the bottom field is read from the XvImage. Position, size and scaling are updated but not onscreen. XV_FRAME_TYPE = XV_BOTTOM_FIELD Onscreen update happens asap. Repeat. -Matt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert] Xv hit list
In light of ReputImage(), which I was unaware of. I think the first proposal was best. I can make ReputImage() work without copying all the data all the time. Rather than copy the visible part of the XvImage to the offscreen memory starting as the top left of the offscreen buffer, I'll copy the visible region to the same x,y coordinates in the offscreen memory. When the window moves triggering a Reput() either I can show the newly exposed region as zero'd or clip the overlay to the area that I actually have data for. Either way it is better than leaving the overlay in the wrong screen location. Here is the proposal again, if there are on complaints I'll implement it this way. #define XV_HOLD 0x0 #define XV_TOP_FIELD0x1 #define XV_BOTTOM_FIELD 0x2 #define XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD) The atom XV_FRAME_TYPE can be set to one of the above values. XvShmPutImage takes either an interlaced or progressive image and copies both fields to the offscreen area. If XV_FRAME_TYPE is not XV_HOLD the overlay is updated with the new data right away. When it is XV_HOLD the overlay is not updated. At any time the atom can be set to XV_TOP_FIELD or XV_BOTTOM_FIELD or XV_FRAME to display the result of the last XvShmPutImage. Mark, if we make use of Reput() couldn't you then make Blitted video work? Reput() would just update the position during XV_HOLD but not make a copy. Then when XV_TOP_FIELD was set the coordinates would always be correct. Reput() could either do nothing or just update the valid area when XV_FRAME_TYPE != XV_HOLD. -Matt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] Xv hit list
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
