Hi Mark (and list), apologies for keeping traffic so high, but I have
another question about XVideo and it's just too useful. :)
Say I'm attemping to play 525/59.94 video (identical problem exists
for 625/50 systems). Ideally, I want to do software deinterlacing and
output full 720x486 images at 59.94fps. However, PCs are still slow, so
my application has three choices:
a) full resolution 59.94 deinterlaced,
b) half-resolution 59.94 (using Xv for scaling up each field),
c) full-resolution 29.97 deinterlaced.
Dealing with (a) and (c) is easy, but (b) is ambiguous. I see two
basic methods:
Method 1: Create Xv images of size 720x240. Make sure the scaling of
the window is such that input scanlines are aligned to output scanlines.
o Blit top fields to x,y of 0,0, w,h of 720,485 (scaled)
o Blit bottom fields to x,y of 0,1, w,h of 720,486 (scaled)
Problems:
1) Since I usually get input as frames, I need to do an extra copy to
split the input into the two field buffers. This is really, really
awkward since at least for DVDs we often switch between progressive
and interlaced input. With the i810 at least, any time I start
blitting images of a new size, the card resets and I get a few bad
frames blit before it wakes up! :( (is this a bug?)
It seems to me that the Xv API could have benefited from a pixel
stride parameter for blits. Is this fixable?
2) Having to set my scale size to ensure scanline alignment for the
top and bottom scanlines is awkward. Do video cards usually
provide some method of subpixel positioning? It would sure help
this problem out alot. I'm not optimistic though.
Method 2: Create Xv images of size 1440x240 and blit in full frames.
Then, use the src_x/y and src_w/h values to specify which field to blit
(left or right == top or bottom). Use the same hacks as above to ensure
top/bottom field spacial positioning is correct.
Problems:
1) We now switch between buffers of size 1440x240 and 720x480. Do you
think this might be easier on cards? Since now the memory map is
the same, I can use two XvImage structures pointing at the same
piece of memory, yes? That way I can decide which one to blit from
depending on if the image is progressive or interlaced.
2) Will all cards support these sizes? The i810 says 720x576 as its
maximum image size, but I _think_ it doesn't mind. I'm just worried
that driver writers may not have considered this option.
Ideally I would have liked to just have one array of full frame-sized
buffers which I fill in my app. At some point I'll decide if its
progressive or interlaced, and so I only want to tell Xv how to display
it at render time. This is difficult with no 'stride' setting.
I hope that the i810 resize effect is a bug. Can anyone confirm or
deny this?
Thanks a ton,
-Billy
--
Billy Biggs [EMAIL PROTECTED]
http://www.billybiggs.com/ [EMAIL PROTECTED]
PGP signature
