[mythtv] high cpu load for xorg with 50fps playback
msc at antzsystem.de
Fri Apr 27 18:05:42 UTC 2007
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.
> 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
> - 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 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).
More information about the mythtv-dev