Re: [Xpert]Re: XVideo and interlaced input
On Fri, 19 Oct 2001, Mark Vojkovich wrote: > On Fri, 19 Oct 2001, Billy Biggs wrote: > > > Mark Vojkovich ([EMAIL PROTECTED]): > > > > >It doesn't work that way. There's no such thing as subpixel > > > destinations so you have to stop thinking about it that way. You have > > > integer rectangles on the screen but you can align how the source > > > scales to that. You can essentially assign the corners of that screen > > > aligned rectangle to subpixel points within the source. I can have > > > the top line of the destination display not the top line of the source > > > but adjust the filter kernel so that it starts displaying, for > > > example, 5/16 of the way between the first and second lines of the > > > source, effectively shifting the whole image up by 5/16 of a pixel. I > > > have subpixel alignment of the source within the destination > > > rectangle. > > > > > >I have not seen any hardware which cannot do this. > > > > Ok, awesome! Makes sense. So, should I start by adding this to the > > i810 or something? I bet I could figure that out. So should we maybe > >There's probably already code that does that in the i810's > XvMC driver. You could add it or Matthew Sottek could if he > had time. > > > standardize on XV_DISPLAY_FIELD and implement that everywhere? I'd like > > I like that name. Maybe somebody else has a better suggestion. > > > to see this implemented ASAP as I know both my code and at least > > mjpegtools code (if not all video players) could benefit from this. > > > > Seems slightly inconsistent with XvMC's signalling though. Or we can > > use the same type: > > > > #define XVMC_TOP_FIELD 0x0001 > > #define XVMC_BOTTOM_FIELD 0x0002 > > #define XVMC_FRAME_PICTURE (XVMC_TOP_FIELD | XVMC_BOTTOM_FIELD) > >That's mpeg's picture structure flags. We could use that > but I think the gaps are a little awkward. There is some other > 0=top, 1=bottom precedence with things like mpeg's > motion_vertical_field_select. > >If it's allowing stuff like frame display, the name XV_DISPLAY_FIELD > probably isn't appropriate. And I don't know what a value of zero > is supposed to do. > > > > > > > > With write-only port attributes you can essentially extend the > > > > > Xv(Shm)PutImage function by specifying additional attributes > > > > > before the request. An attribute such as XV_DISPLAY_FIELD could > > > > > be set to indicate that the next Put request is to be a field. > > > > > The value would be 0=top, 1=bottom in MPEG fashion. It's a > > > > > one-shot thing and only applies to the next put. All drivers > > > > > could add this without API or protocol changes. > > > > > > > > Yes, this would be ideal. Well, besides all this ATI cards have their own deinterlacer. So, in principle, the software could provide interlaced frames and tell that card how to deinterlace them.. Something else to ponder ;) Vladimir Dergachev > > > Mark. > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XVideo and interlaced input
On Fri, 19 Oct 2001, Billy Biggs wrote: > Mark Vojkovich ([EMAIL PROTECTED]): > > >It doesn't work that way. There's no such thing as subpixel > > destinations so you have to stop thinking about it that way. You have > > integer rectangles on the screen but you can align how the source > > scales to that. You can essentially assign the corners of that screen > > aligned rectangle to subpixel points within the source. I can have > > the top line of the destination display not the top line of the source > > but adjust the filter kernel so that it starts displaying, for > > example, 5/16 of the way between the first and second lines of the > > source, effectively shifting the whole image up by 5/16 of a pixel. I > > have subpixel alignment of the source within the destination > > rectangle. > > > >I have not seen any hardware which cannot do this. > > Ok, awesome! Makes sense. So, should I start by adding this to the > i810 or something? I bet I could figure that out. So should we maybe There's probably already code that does that in the i810's XvMC driver. You could add it or Matthew Sottek could if he had time. > standardize on XV_DISPLAY_FIELD and implement that everywhere? I'd like I like that name. Maybe somebody else has a better suggestion. > to see this implemented ASAP as I know both my code and at least > mjpegtools code (if not all video players) could benefit from this. > > Seems slightly inconsistent with XvMC's signalling though. Or we can > use the same type: > > #define XVMC_TOP_FIELD 0x0001 > #define XVMC_BOTTOM_FIELD 0x0002 > #define XVMC_FRAME_PICTURE (XVMC_TOP_FIELD | XVMC_BOTTOM_FIELD) That's mpeg's picture structure flags. We could use that but I think the gaps are a little awkward. There is some other 0=top, 1=bottom precedence with things like mpeg's motion_vertical_field_select. If it's allowing stuff like frame display, the name XV_DISPLAY_FIELD probably isn't appropriate. And I don't know what a value of zero is supposed to do. > > > > > With write-only port attributes you can essentially extend the > > > > Xv(Shm)PutImage function by specifying additional attributes > > > > before the request. An attribute such as XV_DISPLAY_FIELD could > > > > be set to indicate that the next Put request is to be a field. > > > > The value would be 0=top, 1=bottom in MPEG fashion. It's a > > > > one-shot thing and only applies to the next put. All drivers > > > > could add this without API or protocol changes. > > > > > > Yes, this would be ideal. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XVideo and interlaced input
Mark Vojkovich ([EMAIL PROTECTED]): >It doesn't work that way. There's no such thing as subpixel > destinations so you have to stop thinking about it that way. You have > integer rectangles on the screen but you can align how the source > scales to that. You can essentially assign the corners of that screen > aligned rectangle to subpixel points within the source. I can have > the top line of the destination display not the top line of the source > but adjust the filter kernel so that it starts displaying, for > example, 5/16 of the way between the first and second lines of the > source, effectively shifting the whole image up by 5/16 of a pixel. I > have subpixel alignment of the source within the destination > rectangle. > >I have not seen any hardware which cannot do this. Ok, awesome! Makes sense. So, should I start by adding this to the i810 or something? I bet I could figure that out. So should we maybe standardize on XV_DISPLAY_FIELD and implement that everywhere? I'd like to see this implemented ASAP as I know both my code and at least mjpegtools code (if not all video players) could benefit from this. Seems slightly inconsistent with XvMC's signalling though. Or we can use the same type: #define XVMC_TOP_FIELD 0x0001 #define XVMC_BOTTOM_FIELD 0x0002 #define XVMC_FRAME_PICTURE (XVMC_TOP_FIELD | XVMC_BOTTOM_FIELD) > > > With write-only port attributes you can essentially extend the > > > Xv(Shm)PutImage function by specifying additional attributes > > > before the request. An attribute such as XV_DISPLAY_FIELD could > > > be set to indicate that the next Put request is to be a field. > > > The value would be 0=top, 1=bottom in MPEG fashion. It's a > > > one-shot thing and only applies to the next put. All drivers > > > could add this without API or protocol changes. > > > > Yes, this would be ideal. -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XVideo and interlaced input
On Fri, 19 Oct 2001, Billy Biggs wrote: > Mark Vojkovich ([EMAIL PROTECTED]): > > > > It's just something silly, I guess, but important for preserving the > > > spacial position of the fields. Say you're scaling from 720x480 to > > > 1024x768. 768/480 = 1.6, so, you want to scale up each field from > > > 240 lines up to 766.4 lines. This gives a scaling of: > > > > > > [top field] y=0 to y=766.4 > > > [bot field] y=1.6 to y=768 > > > > The *sources* are subpixel. All hardware is that way. You couldn't > > bob video otherwise. You double the pitch and half the surface size > > and you have a single field as a source (and bottom starts a scanline > > later). You just adjust the offset into the texture appropriately to > > get spatial alignment correct. It's much easier for the driver to do > > than for you to do it. > > I've read this paragraph like 3 times and I still don't understand > what you mean, sorry. I understand how doubling the pitch and halving > the surface size gives a single field as a source, no problem, but when > you scale it up you need to subpixel resize it. > > To clarify, say I'm blitting a top field from 720x480 to 1024x768: > >Top Field Bot Field > source scale tosource scale to > x = 0 x = 0 x = 0 x = 0 > y = 0 y = 0 y = 1 y = 1.6 > width = 720width = 720width = 720width = 720 > height = 240height = 766.4 height = 240height = 766.4 > pitch = 1440 pitch = 1440 > > So, the source offsets for these fields are integers, but what I need > them scaled to is not. Can hardware do this easily? I'd assume you'd > have to round down from 1024x768 to something where all of these numbers > are integers, or run at 1280x960. It doesn't work that way. There's no such thing as subpixel destinations so you have to stop thinking about it that way. You have integer rectangles on the screen but you can align how the source scales to that. You can essentially assign the corners of that screen aligned rectangle to subpixel points within the source. I can have the top line of the destination display not the top line of the source but adjust the filter kernel so that it starts displaying, for example, 5/16 of the way between the first and second lines of the source, effectively shifting the whole image up by 5/16 of a pixel. I have subpixel alignment of the source within the destination rectangle. I have not seen any hardware which cannot do this. > > > With write-only port attributes you can essentially extend the > > Xv(Shm)PutImage function by specifying additional attributes before > > the request. An attribute such as XV_DISPLAY_FIELD could be set to > > indicate that the next Put request is to be a field. The value would > > be 0=top, 1=bottom in MPEG fashion. It's a one-shot thing and only > > applies to the next put. All drivers could add this without API or > > protocol changes. > > Yes, this would be ideal. > Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XVideo and interlaced input
Mark Vojkovich ([EMAIL PROTECTED]): > > It's just something silly, I guess, but important for preserving the > > spacial position of the fields. Say you're scaling from 720x480 to > > 1024x768. 768/480 = 1.6, so, you want to scale up each field from > > 240 lines up to 766.4 lines. This gives a scaling of: > > > > [top field] y=0 to y=766.4 > > [bot field] y=1.6 to y=768 > > The *sources* are subpixel. All hardware is that way. You couldn't > bob video otherwise. You double the pitch and half the surface size > and you have a single field as a source (and bottom starts a scanline > later). You just adjust the offset into the texture appropriately to > get spatial alignment correct. It's much easier for the driver to do > than for you to do it. I've read this paragraph like 3 times and I still don't understand what you mean, sorry. I understand how doubling the pitch and halving the surface size gives a single field as a source, no problem, but when you scale it up you need to subpixel resize it. To clarify, say I'm blitting a top field from 720x480 to 1024x768: Top Field Bot Field source scale tosource scale to x = 0 x = 0 x = 0 x = 0 y = 0 y = 0 y = 1 y = 1.6 width = 720width = 720width = 720width = 720 height = 240height = 766.4 height = 240height = 766.4 pitch = 1440 pitch = 1440 So, the source offsets for these fields are integers, but what I need them scaled to is not. Can hardware do this easily? I'd assume you'd have to round down from 1024x768 to something where all of these numbers are integers, or run at 1280x960. > With write-only port attributes you can essentially extend the > Xv(Shm)PutImage function by specifying additional attributes before > the request. An attribute such as XV_DISPLAY_FIELD could be set to > indicate that the next Put request is to be a field. The value would > be 0=top, 1=bottom in MPEG fashion. It's a one-shot thing and only > applies to the next put. All drivers could add this without API or > protocol changes. Yes, this would be ideal. -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XVideo and interlaced input
On Fri, 19 Oct 2001, Billy Biggs wrote: > Mark Vojkovich ([EMAIL PROTECTED]): > > > > I'd be worried about scaling. The Xv driver can't ensure the > > > spacial position makes sense. I guess it could be up to the > > > application to align it nicely. > > > > I don't understand what you're worried about. If you say top or > > bottom that seems pretty clear to me. I don't see what there is to > > mess up. This is pretty much the only way you're going to get > > field-only display in Xv. > > It's just something silly, I guess, but important for preserving the > spacial position of the fields. Say you're scaling from 720x480 to > 1024x768. 768/480 = 1.6, so, you want to scale up each field from 240 > lines up to 766.4 lines. This gives a scaling of: > > [top field] y=0 to y=766.4 > [bot field] y=1.6 to y=768 > > So, if the card can scale to non-integer scanlines, cool, but I doubt > most cards can do this. So, someone has to choose a scale factor such > that the start scanline of the bottom field, and the bottom scanline of > the top field, are integer values so that the spacial position of the > data in the field will make sense. The *sources* are subpixel. All hardware is that way. You couldn't bob video otherwise. You double the pitch and half the surface size and you have a single field as a source (and bottom starts a scanline later). You just adjust the offset into the texture appropriately to get spatial alignment correct. It's much easier for the driver to do than for you to do it. With write-only port attributes you can essentially extend the Xv(Shm)PutImage function by specifying additional attributes before the request. An attribute such as XV_DISPLAY_FIELD could be set to indicate that the next Put request is to be a field. The value would be 0=top, 1=bottom in MPEG fashion. It's a one-shot thing and only applies to the next put. All drivers could add this without API or protocol changes. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XVideo and interlaced input
Mark Vojkovich ([EMAIL PROTECTED]): > > I'd be worried about scaling. The Xv driver can't ensure the > > spacial position makes sense. I guess it could be up to the > > application to align it nicely. > > I don't understand what you're worried about. If you say top or > bottom that seems pretty clear to me. I don't see what there is to > mess up. This is pretty much the only way you're going to get > field-only display in Xv. It's just something silly, I guess, but important for preserving the spacial position of the fields. Say you're scaling from 720x480 to 1024x768. 768/480 = 1.6, so, you want to scale up each field from 240 lines up to 766.4 lines. This gives a scaling of: [top field] y=0 to y=766.4 [bot field] y=1.6 to y=768 So, if the card can scale to non-integer scanlines, cool, but I doubt most cards can do this. So, someone has to choose a scale factor such that the start scanline of the bottom field, and the bottom scanline of the top field, are integer values so that the spacial position of the data in the field will make sense. Alternatively, you put a black scanline at top and bottom of the input, i.e., scale from 482 instead of 480, and then the Xv driver has to do that logic when copying into video memory. That's going to suck for cards which DMA it over though. Haven't thought that option through. Thoughts? -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XVideo and interlaced input
On Fri, 19 Oct 2001, Billy Biggs wrote: > Mark Vojkovich ([EMAIL PROTECTED]): > > > > It seems to me that the Xv API could have benefited from a pixel > > > stride parameter for blits. Is this fixable? > > > > It's possible for the driver to offer a port attribute with > > top/bottom. Maybe it's best that it's write only and applies only to > > the next command. It could work like a hint for the next PutImage. > > I'd be worried about scaling. The Xv driver can't ensure the spacial > position makes sense. I guess it could be up to the application to > align it nicely. I don't understand what you're worried about. If you say top or bottom that seems pretty clear to me. I don't see what there is to mess up. This is pretty much the only way you're going to get field-only display in Xv. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XVideo and interlaced input
Mark Vojkovich ([EMAIL PROTECTED]): > > It seems to me that the Xv API could have benefited from a pixel > > stride parameter for blits. Is this fixable? > > It's possible for the driver to offer a port attribute with > top/bottom. Maybe it's best that it's write only and applies only to > the next command. It could work like a hint for the next PutImage. I'd be worried about scaling. The Xv driver can't ensure the spacial position makes sense. I guess it could be up to the application to align it nicely. > XvMC has explicit top/bottom/frame instructions in the Put command. So, maybe if there was a way to use XImages with the XvMC rendering API, this could solve the problem? I mean, I really don't want to just use the MC API, since I'll be also doing software deinterlacing and postprocessing on the images. -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
