[mythtv] high cpu load for xorg with 50fps playback

[Markus Schulz]

at first, the problem if reported in my first post also exists with 
bobdeint. Looks like a general problem. 

Am Freitag, 27. April 2007 schrieb Mark Kendall:
> On 4/27/07, Markus Schulz <msc at antzsystem.de> wrote:
> > Am Freitag, 27. April 2007 schrieb Mark Kendall:
> >
> > in my opinion the videoout should have nothing todo with
> > deinterlacing or similar (only if deinterlacers and postprocessing
> > was written as opengl fragment shader, but then it should be also
> > only an extension for videoout).
> > For my full-framerate no modify on videoout code was needed.
> > Videoout should only displays a frame at a given rate and the
> > player calls at the wanted rate and hands over the frame data. I
> > don't like the current bobdeint implementation, two many special
> > cases inside videoplayer _and_ videout module. I know that bobdeint
> > was a little special compared to other deinterlacers, but should be
> > possible to implement without this many special cases.
>
> Yes - I agree, but don't forget that the bob implementation is
> fast/efficient - ie. we only apply the filter once for both fields.

yes, but i think for other full-framerate deinterlacers we need a more 
general way. A second call can be returned from bobdeint himself 
without new result. Then you can call him twice like all other 
deinterlacers without much overhead.
I think need one of the to ways:
 1. call each deint twice and let the deint calculate the intermediate 
frame on first call (needs to save last frame himself)
 2. calculate intermediate frame inside player loop (or better decoder 
stage) and call deint twice, but with different data on each call.

> > And no, doubling framerate or not is nothing what can be detected
> > from deinterlacer. You can use kernel-deint (and all other except
> > bob) with 25fps and 50fps. For 50fps you need only build the
> > intermediate (bottom field from last and top from current) frame
> > for some of them (greedyh and greedy2frame dont need an
> > intermediate frame cause he need the complete previous frame as
> > history).
>
> But none of these filters (as written) will give you a different
> output at 50fps. You need frame doubling versions - at which point
> the deinterlacing options become kernel or kernel 2* etc. (It's been
> a long and painful week - I could well be wrong, if kerneldeint etc
> are 'field' aware...)

but if you calculate the intermediate frame you will get smooth output 
from each of them. Currently watching interlaced material is a pain 
(except bob).

> > i need a clean frame in second call, the osd makes them dirty. It's
> > different than current bobdeint, cause we need to call the
> > deinterlacer filter at 50fps not only at 25fps and drawing twice.
> > GreedyH uses the previous (really previous not the same on second
> > call) for his adaptive algorithmus. Hence i must buffer it inside
> > the filter code. The complete runloop of the player must run at
> > 50fps for greedyh (and other adaptive deinterlacers).
>
> I appreciate that the filter is running at 50fps but it isn't getting
> any new data on the second call. What I'm suggesting is that the
> filter should be handling all of its buffering internally and
> detecting that it just got sent the same frame (same number)

but it produces different output (progressive) frame on second call. But 
you are right, i'm saving the frame inside the filter, hence the filter 
dont need a fresh frame on second call cause he already have a copy of 
it. i will fix this.

> > > Do you know how the filter actually deinterlaces?

> Sorry - should have been clearer. I was trying to understand the
> algorithm used to detect and remove the interlacing artefacts.

only slightly, it calculates a motion value between the frame(field) 
history and lines and if the motion value is above a constant value he 
does average-bobbing, if lower then he weaves the pixels.

-- 
Markus Schulz