Re: slices

On Fri, Feb 20, 2004 at 05:08:22PM +0100, Attila Kinali wrote:
> > For files with B frames, we could only do the slice-time OSD blending
> > for B frames or for the first frame in a closed GOP, and then blend
> > onto other frames right before displaying them. But there are some
> > difficulties about how to do it correctly if the frame is in video
> > memory. Do you:
> > 
> > (a) keep the frame buffered in system memory entirely until time to
> > display? This sounds slow.
> 
> Bad idea.

I tend to agree.

> > (b) somehow know in advance the bounding boxes of OSD elements (just
> > not their contents) and save these in system memory during the
> > draw_slice, then use them to alpha-blend OSD at display time?
> 
> Should be possible.
> I thought about a intermediate representation of the OSD
> elements where their size and position is already known.
> Actualy i'm thinking about keeping already rendered
> elements (as RGBA resp YUVA picutres) in memory, so that
> only the last step of blending has to be performed.
> But i dont know how much memory this needs and whether
> it would be faster to render it again for every frame.

AFAIK OSD elements are already prerendered and reused each frame...

> > (c) violate READABLE flag and alpha-blend in video memory, like G1
> > does... :(
> 
> I really dont want that mess again. IMHO it's better to
> sacrifice a few cpu cycles to keep the vo code clean
> otherwise we'll end up again with an vo-hell.

This doesn't "dirty" the vo. I's still done entirely in the expand
filter. It just violates the protocol by reading from a non-READABLE
buffer...

Rich