Mark Vojkovich ([EMAIL PROTECTED]): > > Hrm, I hope it doesn't just double each chroma scanline. I'm in > > fear now. Wish that was documented somewhere, I would have written > > a better chroma upsampler sooner. > > It just doubles each chroma line. That's all the nv driver does. I'm > not sure there's any preprocessing that would make the result more > accurate.
I was thinking you could interpolate the samples, but then I realized that you can't be gamma correct without doing an expensive conversion: Y'CbCr->R'G'B'->RGB->R'G'B'->Y'CbCr And then I realized the obvious, that MPEG's 4:2:0 sampling (in between on the left) makes doubling each chroma line the correct thing to do anyway. > > I still think that using DMA is essential for all drivers if the > > images doesn't require some conversion. I guess I'd be worried > > about drivers which require scanlines to be 32bit aligned. Too bad > > the Xv API doesn't allow for that. (or am I on crack again) > > I'm not sure what you mean. Pretty much everything always needs to be > 32 bit aligned. mpeg scanlines are always multiples of 16 pixels > anyhow. Well for planar formats, 720 luma samples is 720 bytes, and that just doens't align nicely. But yes, if you're using 4:2:2, 720*2 is nice and round. I find it interesting that all these overlays only use 4:2:2. Do you think I should move the conversion into my app and save them the trouble (and also improve my OSD compositing)? Sounds like a win to me. -- Billy Biggs [EMAIL PROTECTED] _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
