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
