[mythtv] [exp. patch] xv xvmc merge

[Daniel Kristjansson]

On Wed, 2005-03-30 at 19:51 -0500, Daniel Kristjansson wrote:

> Some possible/probable new bugs:
>   b/ Some sections aren't finished and some changes tested and
>      those are marked with "// TODO"
> Some unfixed bugs
>   i/ Sometimes on "studder" when OSD is on screen.

I think I've found the cause for this studder, when looking at one
of the TODO sections. I was trying to add locking of previous and
future frames, but found that they aren't always around when you
need them. I knew that it happened before, but assumed it was due
to broken MPEG files. But it turns out that it's a problem with
the buffer management.

What happens is that MPEG has a series of frames, say: IBBBPBBBI
The I frames don't depend on any other frames, but the B frames depend
on an I and a P, and the P frame depends on the previous I. But once
MythTV displays a frame, it puts it on the list of frames ready to be
recycled. With Lo-Fi TV this is works most of the time; this is only 
because by the time a frame is displayed all the frames depending
on it have usually already been rendered.

With HDTV or serious skipping all hell breaks loose as soon as the
buffer is one or two frames behind. MythTV places an I or P frame 
that is still needed in the recycling bin, it gets reused, and the
B and P frames still being rendered (depending on the missing I or P
frame) slow to a crawl, wait for the new frame to be rendered, 
produce junk, or SEGFAULT, depending on how lucky you are.

Has anyone looked at this before, and perhaps thought of a quick, 
easy, and elegant solution? :)

My initial thought is to mark I and P frames as needing special
treatment. If it is not possible to recycle them immediately, 
after they are displayed, I would put them in a delete buffer.
Then whenever a new frame was needed I check if it was safe
to delete any frame in the delete buffer. This assumes that
any unfinished frames depending on the I and P frames are
in a frame buffer by the time the I or P frame is displayed,
does anyone think that is a bad assumption? Another solution
might be to add a wait for another I and P frame for recycling
I and P frames, resp. This way we know any future B and P 
frames have a reference, but this may effectively result in
one less buffer being around (unless we [can] peek at an 
incoming frame to determine if it is an I, P or other frame).

In the case of XvMC the "Is it safe to delete" function would
depend on every xvmc render state using the frame having 
finished rendering. (Though possibly not finished displaying.)

-- Daniel