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

[Markus Schulz]

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 Martin Long:
> > No, i'm using RTC (and also tried opengl-vsync). Booth have the
> > same problem. I've also added some debug code inside
> > RTCVideoSync::WaitForFrame to check how often CalcDelay was called.
> > But on my 50Hz beamer its mostly zero, on my 75Hz CRT 10-15 calls
> > per WaitForFrame.
>
> Markus
>
> What happens with bobdeint when displaying at 50Hz? Does it have the
> same problem?

no, but the current bob deinterlacer is working a different way.

> I've had a quick look at your patch  and have a couple of
> observations (assuming you were intending to submit it at some
> point!)
>
> - I don't think the extra setting is necessary. The videooutput
> method should know that full frame rate is required from the type of
> deinterlacer - and there's nothing to be gained from doubling the
> frame rate if you're not deinterlacing.

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. 

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).

> - you shouldn't really need to buffer the frame for the second pass.
> Ideally the filter should detect the frame numbers are the same and
> act accordingly. Looks like the filter is already doing its own
> buffering. I appreciate you're working with pre-existing filter code.

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).

> Do you know how the filter actually deinterlaces?

Regarding quality? In my opinion one of the best available inside 
xine-lib. Jack Perveiler is working on another deinterlacer filter from 
DSCaler (greedy2frame). The code is similar to greedyh but needs a more 
complex frame history (up to 5 fields instead of 4 fields for greedyh).

-- 
Markus Schulz