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
> 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, 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
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
"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: > > >"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
>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. >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. It would be nice, I'm not sure all hardware can do this. >Now that I think about it, what effect, if any, will this have on >drivers that implement their own multi-buffering? It shouldn't have any impact. We use double buffers on i810. This just allow for two things. #1 You can do TOP_FIELD BOTTOM_FIELD which was not possible before. and #2 There is no longer an unknown time between when you ask for a flip and the actual flip, or rather the unknown time is very much shorter since the data copy has been separated from the display request. Internal to the driver things are a little more difficult to understand. My overlay has a buffer#1 and buffer#2 but those pointers are not necessarily pointing to surface#1 and surface#2. Like in XvMC I may have 6 or 7 surfaces and I just point the unused overlay buffer pointer to the next surface I want to display. This is the same thing with just 2 surfaces. >Another clarification question, what happens in this case: >XV_FRAME_TYPE = *|XV_HOLD >XvShmPutImage() >... >XvShmPutImage() >... >XvShmPutImage() >XV_FRAME_TYPE = *&!XV_HOLD Note: You are a little confused. We are not going with the complicated proposal with the bitfields. It was just too hard and the reputImage() function should get me what I was trying to achieve. XV_FRAME_TYPE can only be 0-3 XV_HOLD,XV_TOP_FIELD,XV_BOTTOM_FIELD,XV_FRAME. SO your question should go like this: 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 ___ 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
"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
>"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: > > 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
On Thu, 25 Oct 2001, Sottek, Matthew J wrote: > > 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. Assuming ReputImage() works. I've never used it, but others have (that doesn't mean it works correctly though). > 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. That sounds OK. I didn't consider using Reput unless I wanted to autohandle exposures, but I guess there's no need for that since the client will get an expose anyhow. Hope ReputImage() works as expected. > > 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) Sounds OK to me. > > 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. > Assuming ReputImage() works properly and you still have the data around. Implementations that supply the data via the DMA buffer (like color expansion data) can't do much about that unless you saved off a spare copy. Mark. ___ 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
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
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: > >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. > > Why not? Use two offscreen buffers to hold the data and blit the > correct one over when the HOLD bit gets unset. Can't you check > the cliplist at the time when the bit is removed? We don't know how to get the cliplist. Drawable specific information is lost by the time you get into the driver. Xv passed you the cliplist explicitly during the put that represented a snapshot at the time the request was made. Once you leave your Put function the cliplist is stale. The very next request may have moved the window. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert] Xv hit list
> 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. Right, that delay isn't going to have much of an impact. >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. Why not? Use two offscreen buffers to hold the data and blit the correct one over when the HOLD bit gets unset. Can't you check the cliplist at the time when the bit is removed? > 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)? 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_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 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
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
[Xpert]Xv hit list
Thanks to the list (specifically Mark and Matt) for all your help lately. These are the current issues we have with Xv. I'm curious as to what coding we can help with, and what is actively being worked on. 1) Performance is horrible. All drivers should be using DMA to transfer images from system memory to video memory. Apparently this is being done for X 4.2. Which drivers are fixed and which still need work? Apparently, some chips can read frames right out of system memory without copying to video memory at all (rumor says this is true for i810). Can we improve Xv performance in these cases? 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. 3) Xv should be used to expose hardware RGB scaling everywhere, also with DMA transfers. What cards still need fixing? 4) There is no distinction between rendering and display, and applications have no access to the buffering of frames in video memory. In order to redraw the screen the entire image must be re-blit. Consider a user moving the video output window when displaying a static image. Also we have no way to copy an image to video memory and then show it later, which could greatly increase display timing accuracy for high-quality output. A separation, like what XvMC has, would allow for better quality, much less memory bandwidth during stills, paused video, and window movement, and multi-buffering controlled by the application. Should we deprecate Xv and move to an XvMC-style API, or would there be an easy way to add this functionality to Xv? It seems to me that Xv maybe should act more like normal XImages. Why can't the video automatically be respositioned when the window is positioned? 5) Outstanding bugs that I'm aware of in Xv drivers: - The savage Xv driver fails in 24bpp mode. Is anyone fixing this? - The i810 driver pukes some bad frames after the size of the input images changes. (like switch from 720x480 to 704x480 for when DVD-menus differ from the content). Is this a bug? 6) Drivers claim to support modes that the hardware can't actually optimize. An example is the Savage which claims to support YV12 although it only supports YUY2. 6) libXv.a is only distributed as a non-PIC .a. This list taken from discussions on #ogle and #gstreamer on irc.openprojects.net. -- Billy Biggs [EMAIL PROTECTED] http://www.billybiggs.com/ [EMAIL PROTECTED] PGP signature
