Re: [Xpert]Using Xv to display odd/even fields from a TV camera
- Original Message - From: Vladimir Dergachev [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 8:24 PM Subject: Re: [Xpert]Using Xv to display odd/even fields from a TV camera On Sat, 11 May 2002, Paul Robertson wrote: On Fri, 10 May 2002, Paul Robertson wrote: I have some software which uses Xv to render images acquired from a TV camera in something like realtime. Currently we only capture even fields, and we scale the image vertically by 200%. It looks OK. Now we need to start working with both odd and even fields. If we do that with our current software, the picture wobbles up and down. If I write some code to adjust the position of the odd field, the picture still looks wrong, particularly if nothing is moving in the picture. If I write code to reconstitute a full frame by interlacing the odd and even fields, then I see nasty artefacts when there is horizontal motion in front of the camera. We actually use ATI Rage and the r128 driver at the moment, but a while ago we evaluated the i815 graphics controller. I remember that it supported a number of different hardware scaling methods including Up interpolation and Down interpolation, and I wondered if I could use these modes to get a better quality picture. ATI hardware does support this but the driver does not do this (yet?). What software do you want to use this with ? Is the source available for download ? Vladimir Dergachev Its closed source commercial stuff I'm afraid. Ohh. Well in this case this will stay unsupported.. Vladimir Dergachev Well, I'd still like to get involved if I can. I have a Bt848 capture card somewhere, I'm sure I can write some software to capture odd and even TV fields and display them using Xv... -- Paul ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Using Xv to display odd/even fields from a TV camera
Apologies, My last post wasn't meant for the list. -- Paul ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Using Xv to display odd/even fields from a TV camera
From: Mark Vojkovich [EMAIL PROTECTED] Sent: Saturday, May 11, 2002 10:19 PM Mpeg2 supports interleaved content. Looks like crap if you display it as a weave. We're mostly talking about that on this list. I think we merely need a standard XvPortAttribute hint to tell the Xv adaptor if the next Xv(Shm)PutImage request should be a field instead of the default frame behavior. The Xv adaptor only loads half of the data in that case and displays it with the correct offsets and scaling. OK, I think I'm beginning to understand. (Actually, I just trawled up an excellent article at http://www.hometheaterhifi.com/volume_7_4/dvd-benchmark-part-5-progressive-1 0-2000.html) So taking this and your recent reply to Billy... In my case I would decode two consecutive wavelet images into an odd and even field, weave them into a 704x486 image, copy it to shm, then call XvShmPutImage twice, setting the XvPortAttribute appropriately. If I lose phase, say I get two even fields in a row, then should I weave two frames with anything on the odd scan lines andcall XvShmPutImage once for each frame with the PortAttribute set for an the field each time? -- Paul ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Using Xv to display odd/even fields from a TV camera
On Sat, 11 May 2002, Paul Robertson wrote: On Fri, 10 May 2002, Paul Robertson wrote: I have some software which uses Xv to render images acquired from a TV camera in something like realtime. Currently we only capture even fields, and we scale the image vertically by 200%. It looks OK. Now we need to start working with both odd and even fields. If we do that with our current software, the picture wobbles up and down. If I write some code to adjust the position of the odd field, the picture still looks wrong, particularly if nothing is moving in the picture. If I write code to reconstitute a full frame by interlacing the odd and even fields, then I see nasty artefacts when there is horizontal motion in front of the camera. We actually use ATI Rage and the r128 driver at the moment, but a while ago we evaluated the i815 graphics controller. I remember that it supported a number of different hardware scaling methods including Up interpolation and Down interpolation, and I wondered if I could use these modes to get a better quality picture. ATI hardware does support this but the driver does not do this (yet?). What software do you want to use this with ? Is the source available for download ? Vladimir Dergachev Its closed source commercial stuff I'm afraid. Ohh. Well in this case this will stay unsupported.. Vladimir Dergachev It looks like this topic has been the subject of quite some discussion in the past before momentum was lost. I'll try to stay in the loop this time in case there is anything I can do to help move things along. -- Paul ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Using Xv to display odd/even fields from a TV camera
On Fri, 10 May 2002, Paul Robertson wrote: I have some software which uses Xv to render images acquired from a TV camera in something like realtime. Currently we only capture even fields, and we scale the image vertically by 200%. It looks OK. Now we need to start working with both odd and even fields. If we do that with our current software, the picture wobbles up and down. If I write some code to adjust the position of the odd field, the picture still looks wrong, particularly if nothing is moving in the picture. If I write code to reconstitute a full frame by interlacing the odd and even fields, then I see nasty artefacts when there is horizontal motion in front of the camera. We actually use ATI Rage and the r128 driver at the moment, but a while ago we evaluated the i815 graphics controller. I remember that it supported a number of different hardware scaling methods including Up interpolation and Down interpolation, and I wondered if I could use these modes to get a better quality picture. ATI hardware does support this but the driver does not do this (yet?). What software do you want to use this with ? Is the source available for download ? Vladimir Dergachev Its closed source commercial stuff I'm afraid. It looks like this topic has been the subject of quite some discussion in the past before momentum was lost. I'll try to stay in the loop this time in case there is anything I can do to help move things along. -- Paul ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Using Xv to display odd/even fields from a TV camera
Can I butt in with some basic questions? I'd just like to understand what kinds of applications will benefit from this proposal. We have lots of DVD players, the ubiquitous Brooktree framegrabber, and esoteric stuff like my ADV601. I know for sure it would help me. The Bt chips normally produce 25/30 interlaced frames/sec which might look lousy when displayed if there is horizontal motion. They can be programmed to decimate the frame, so you would only see say 25/30 even fields/sec Can they also be programmed to deliver 50/60 fields/sec? Does v4l support all this? Do v4l apps usually have the Bt chip writing the YUV image directly into video memory? Would Xv, or the graphics driver support odd/even fields in this case? DVD players I know nothing about. What do they do? -- Paul - Original Message - From: Mark Vojkovich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 10, 2002 11:34 PM Subject: Re: [Xpert]Using Xv to display odd/even fields from a TV camera On Fri, 10 May 2002, Billy Biggs wrote: The delay stuff is less important than the field flag. Mark Vojkovich ([EMAIL PROTECTED]): I'd like an XV_FIELD (or better named) attribute that indicates the next PutImage request should upload and display the field rather than the frame which is the default. 0 is top, 1 is bottom, per mpeg conventions. It's a one-shot state that gets reset to frame after the next PutImage happens. How does this work for full 50 or 59.94fps video? Do I upload the same frame twice, or does this attribute just mean: only copy from the source frame the even/odd field, so that the whole frame isn't coped twice, only half of it? It means that only the field is copied and only the field is displayed. I'm also worried about switching from frame-mode to field-mode. In my DVD player for example, I'll switch between 3:2 pulldown correction in software, or, if I lose the phase, go back to 60fps output. Do you think video cards are going to have a problem switching the scaling width/height without artifacts? NVIDIA cards won't have a problem with this. I think some cheaper cards that don't double buffer their registers and have to be programmed during the retrace won't be able to do this very well. 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]Using Xv to display odd/even fields from a TV camera
On Sat, 11 May 2002, Paul Robertson wrote: Can I butt in with some basic questions? I'd just like to understand what kinds of applications will benefit from this proposal. We have lots of DVD players, the ubiquitous Brooktree framegrabber, and esoteric stuff like my ADV601. I know for sure it would help me. The Bt chips normally produce 25/30 interlaced frames/sec which might look lousy when displayed if there is horizontal motion. They can be programmed to decimate the frame, so you would only see say 25/30 even fields/sec Can they also be programmed to deliver 50/60 fields/sec? Does v4l support all this? Do v4l apps usually have the Bt chip writing the YUV image directly into video memory? Would Xv, or the graphics driver support odd/even fields in this case? In that case, no. In the case of a decoder dumping data to the graphics controller via the VIP (CCIR 656) it's possible and I'm currently looking at implementing a generic CCIR656 input device for the NVIDIA driver (for NVIDIA Personal Cinema and the like). I will automatically bob the video in that case. No API changes are required for that. You just tell the Xv adaptor where to put the data and it will put anything coming through the VIP port there. It relies on another piece of software to program the device that sends stuff through the VIP, whether that is a TV decoder, DVD card, or other device. For cases where a Bt chip dumps YUV data to the framebuffer directly, there are some synchronization issues that can't be solved unless the Bt driver and overlay driver are the same driver. Currently, with Xv+V4L based solutions, the Bt control is in the kernel while the overlay is in the X-server. I don't see how to handle the synchronization in that case. DVD players I know nothing about. What do they do? Mpeg2 supports interleaved content. Looks like crap if you display it as a weave. We're mostly talking about that on this list. I think we merely need a standard XvPortAttribute hint to tell the Xv adaptor if the next Xv(Shm)PutImage request should be a field instead of the default frame behavior. The Xv adaptor only loads half of the data in that case and displays it with the correct offsets and scaling. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Using Xv to display odd/even fields from a TV camera
Paul Robertson ([EMAIL PROTECTED]): Now we need to start working with both odd and even fields. If we do that with our current software, the picture wobbles up and down. If I write some code to adjust the position of the odd field, the picture still looks wrong, particularly if nothing is moving in the picture. If I write code to reconstitute a full frame by interlacing the odd and even fields, then I see nasty artefacts when there is horizontal motion in front of the camera. If you want the hardware to do all the scaling, it was sort of decided that we should update the Xv API to tell it if you're giving an odd or even field, and let it handle the scanline offset. Otherwise, you can do the interpolation in software. I wrote an app that does this, but it's not 'done' yet: http://www.dumbterm.net/graphics/tvtime/ Linear interpolation as I do there emulates pretty reasonably what cheap TVs look like. We can discuss options further if you like, but Xpert probably isn't the right place. v4l-list might be better. :) -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Using Xv to display odd/even fields from a TV camera
We talked about some standardized method within the current API for telling the drivers to display fields. This was done through PortAttributes. I'm not sure if anyone actually implemented this in their drivers though. Mark. On Fri, 10 May 2002, Paul Robertson wrote: I have some software which uses Xv to render images acquired from a TV camera in something like realtime. Currently we only capture even fields, and we scale the image vertically by 200%. It looks OK. Now we need to start working with both odd and even fields. If we do that with our current software, the picture wobbles up and down. If I write some code to adjust the position of the odd field, the picture still looks wrong, particularly if nothing is moving in the picture. If I write code to reconstitute a full frame by interlacing the odd and even fields, then I see nasty artefacts when there is horizontal motion in front of the camera. We actually use ATI Rage and the r128 driver at the moment, but a while ago we evaluated the i815 graphics controller. I remember that it supported a number of different hardware scaling methods including Up interpolation and Down interpolation, and I wondered if I could use these modes to get a better quality picture. Has anyone had to deal with these kind of issues? I should say that CPU time is scarce, as the TV fields are compressed in hardware and have to be decompressed in software. -- Paul Robertson ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Using Xv to display odd/even fields from a TV camera
On Fri, 10 May 2002, Mark Vojkovich wrote: We talked about some standardized method within the current API for telling the drivers to display fields. This was done through PortAttributes. I'm not sure if anyone actually implemented this in their drivers though. Mark. On Fri, 10 May 2002, Paul Robertson wrote: I have some software which uses Xv to render images acquired from a TV camera in something like realtime. Currently we only capture even fields, and we scale the image vertically by 200%. It looks OK. Now we need to start working with both odd and even fields. If we do that with our current software, the picture wobbles up and down. If I write some code to adjust the position of the odd field, the picture still looks wrong, particularly if nothing is moving in the picture. If I write code to reconstitute a full frame by interlacing the odd and even fields, then I see nasty artefacts when there is horizontal motion in front of the camera. We actually use ATI Rage and the r128 driver at the moment, but a while ago we evaluated the i815 graphics controller. I remember that it supported a number of different hardware scaling methods including Up interpolation and Down interpolation, and I wondered if I could use these modes to get a better quality picture. ATI hardware does support this but the driver does not do this (yet?). What software do you want to use this with ? Is the source available for download ? Vladimir Dergachev Has anyone had to deal with these kind of issues? I should say that CPU time is scarce, as the TV fields are compressed in hardware and have to be decompressed in software. -- Paul Robertson ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]Using Xv to display odd/even fields from a TV camera
On Fri, 10 May 2002, Sottek, Matthew J wrote: I was going to do this but never finished it. Perhaps someone could go back through the archives and refresh our memory as to exactly what the spec was going to be. And then they could make an updated Xv spec. At lease then it is on paper and drivers could implement it as they get time. -Matt I think it started out simple and then degenerated as people tried to cram alot of features into it. Initially we'd just send a one-shot port attribute that indicated that the next, and only the next request would be a top or bottom field instead of the default which was a frame. Then people wanted to put delays in there. The attribute indicated that the next PutImage request shouldn't actually display the frame, but rather copy it to video ram and hold it there until the next attribute that would display the frame. I think that if there is going to be some delayed display mechanism that should be a separate attribute, because I'm not keen on implementing it, but I will do the field stuff. I'd like an XV_FIELD (or better named) attribute that indicates the next PutImage request should upload and display the field rather than the frame which is the default. 0 is top, 1 is bottom, per mpeg conventions. It's a one-shot state that gets reset to frame after the next PutImage happens. Maybe if somebody wanted to implement the delayed display stuff they could set an XV_ attribute that says not to display the next PutImage request, but rather upload it an hold it until the the same attribute gets set with a different argument that says to display it. I'm not sure if I will implement that one. For mpeg, my focus has been on XvMC which doesn't have these kinds of problems. Mark. -Original Message- From: Mark Vojkovich [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 11:14 AM To: [EMAIL PROTECTED] Subject: Re: [Xpert]Using Xv to display odd/even fields from a TV camera We talked about some standardized method within the current API for telling the drivers to display fields. This was done through PortAttributes. I'm not sure if anyone actually implemented this in their drivers though. Mark. On Fri, 10 May 2002, Paul Robertson wrote: I have some software which uses Xv to render images acquired from a TV camera in something like realtime. Currently we only capture even fields, and we scale the image vertically by 200%. It looks OK. Now we need to start working with both odd and even fields. If we do that with our current software, the picture wobbles up and down. If I write some code to adjust the position of the odd field, the picture still looks wrong, particularly if nothing is moving in the picture. If I write code to reconstitute a full frame by interlacing the odd and even fields, then I see nasty artefacts when there is horizontal motion in front of the camera. We actually use ATI Rage and the r128 driver at the moment, but a while ago we evaluated the i815 graphics controller. I remember that it supported a number of different hardware scaling methods including Up interpolation and Down interpolation, and I wondered if I could use these modes to get a better quality picture. Has anyone had to deal with these kind of issues? I should say that CPU time is scarce, as the TV fields are compressed in hardware and have to be decompressed in software. -- Paul Robertson ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Using Xv to display odd/even fields from a TV camera
The delay stuff is less important than the field flag. Mark Vojkovich ([EMAIL PROTECTED]): I'd like an XV_FIELD (or better named) attribute that indicates the next PutImage request should upload and display the field rather than the frame which is the default. 0 is top, 1 is bottom, per mpeg conventions. It's a one-shot state that gets reset to frame after the next PutImage happens. How does this work for full 50 or 59.94fps video? Do I upload the same frame twice, or does this attribute just mean: only copy from the source frame the even/odd field, so that the whole frame isn't coped twice, only half of it? I'm also worried about switching from frame-mode to field-mode. In my DVD player for example, I'll switch between 3:2 pulldown correction in software, or, if I lose the phase, go back to 60fps output. Do you think video cards are going to have a problem switching the scaling width/height without artifacts? -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Using Xv to display odd/even fields from a TV camera
On Fri, 10 May 2002, Billy Biggs wrote: The delay stuff is less important than the field flag. Mark Vojkovich ([EMAIL PROTECTED]): I'd like an XV_FIELD (or better named) attribute that indicates the next PutImage request should upload and display the field rather than the frame which is the default. 0 is top, 1 is bottom, per mpeg conventions. It's a one-shot state that gets reset to frame after the next PutImage happens. How does this work for full 50 or 59.94fps video? Do I upload the same frame twice, or does this attribute just mean: only copy from the source frame the even/odd field, so that the whole frame isn't coped twice, only half of it? It means that only the field is copied and only the field is displayed. I'm also worried about switching from frame-mode to field-mode. In my DVD player for example, I'll switch between 3:2 pulldown correction in software, or, if I lose the phase, go back to 60fps output. Do you think video cards are going to have a problem switching the scaling width/height without artifacts? NVIDIA cards won't have a problem with this. I think some cheaper cards that don't double buffer their registers and have to be programmed during the retrace won't be able to do this very well. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
