[MPlayer-G2-dev] slices

[D Richard Felker III]

On Fri, Feb 20, 2004 at 02:44:03PM +0100, Attila Kinali wrote:
> On Thu, 12 Feb 2004 18:13:02 -0500
> D Richard Felker III <dalias at aerifal.cx> wrote:
> 
> > Consider vf_expand with osd rendering. You want to alpha-blend osd
> > onto the image during the slice rendering, so you don't have to read
> > video memory later to add osd! But here you run into a big problem.
> > Slice rendering takes place in decoding order, whereas osd contents
> > will be known in display order. It would look really stupid for the
> > clock to jump backwards for one frame, etc. How do we solve this??
> 
> I wouldn't mind that. There is at least one subtitle format
> around that does not require time sorted entries, thus the osd
> reader/renderer needs to sort and chache them anyways.
> And i'm sure there are more such stupid formats out there. [1]
> 
> Also i think even if we leave those fileformats aside and
> only look at odered subs (ie by preordering those shit formats)
> it's still not hard to provide a few frameduration long backlog
> of subtitles [2].
> 
> But, the more important question here is, how do you plan
> to integrate the subtitle renderer into your vp/vo design ?
> The current "every vo needs draw_alpha" doesn't work quite
> well as we all know. Beside i'd like to have colored subs
> with any shape. One stupid solution would be to do everything
> in a vp_expand, but then we'd lose potential acceleration by
> the graphics card for alpha only subs (or is there also a way
> for fast coloured subs rendering ?)

All subs are done by vf_expand unless the vo supports subtitles. The
difference from G1 is that vo's are not allowed to implement their own
stupid draw_alpha blending. Support in the vo is ONLY for hardware
subpic devices.

> [1] There are a few more issues here as it's not always possible
> to read the whole subfile at once as it might be a stream
> embeded in ogm/mkv/nut/whatever file or come over a network
> stream. 

Yes, well don't just think of subtitles. Also the clock, or OSD menu,
or anything like that...

> [2] This rises of course the question of how many consecutive
> B frames are allowed/possible. So far i haven't seen more
> than 2 consecutive B frames, but that doesn't mean someone
> outthere thinks he could encode a file consisting of
> one I frame at the beginning, a P frame at the end and
> the whole rest constisting of B frames.

ROTFL! :)

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.

(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?

(c) violate READABLE flag and alpha-blend in video memory, like G1
does... :(

Unfortunately (c) is probably the fastest (but also the stupidest in
principle) assuming the OSD area is small...

Rich