[mythtv] [PATCH] high speed smooth video v2

[Bruce Markey]

Mark Spieth wrote:
...
> no. the work is done in NuppelVideoPlay::Avsync which skips the
> videoOutput->Show() call.
> DoneDisplayingFrame is called in the parent function so I believe its safe.
> I am making the assumption that just skipping this step still processes
> frames correctly as I just skip the
> rendering stage which is quite CPU intensive.

At one time, that would have been true. However, in order to
update the frame as quickly as possible after the target time,
most of the heavy lifting is in PrepareFrame() before waiting
for the target time. Show() just calls XSync() to flush the
prepared frame and returns almost instantly. Most of the CPU
time of the video output loop is in PrepareFrame().

> Im surprised no one else is noticing this jerky effect.

Noticed. I tested this when you first submitted it just before
0.17. I didn't see any performance improvement, motion was more
jerky and there were other issues related to frame timing that
needed to be addressed which is why it went on the back burner.
You submitted it again a day before a planned release date so
I didn't even look at it.

> but then again maybe its my config but I cant see why.
> Ill get to the bottom of it eventually.
> IMO This patch is still better than the avsync alternative where the
> presented frames > refresh rate of the monitor. Ill let others decide.
> cheers

However, the refresh rate is normally at least 2X the frame
rate. Full frames are grabbed including both interlaced fields
at 29.97fps NTSC (25fps PAL). A TV set retraces fields 59.94 times
per sec (50 PAL). Computer monitors are usually even faster.

The bob deinterlacer splits the two fields and shows the top line
doubled then the bottom line doubled for each frame at twice the
frame rate. This can be useful if the refresh rate is synchronous
but causes horizontal edges to bob up and down one line when not
synchronous. Therefore this should only be done at 1X which is one
of the things that was in the works before 0.17.

So, for 1.05X30fps through 2.0X30fps there can never be two XSyncs
(Show()) between two retraces. Every frame update would be drawn on
a new retrace. However, the idea of dropping frames might be useful
for 3X fast motion (press U twice). 2X fast motion has always struck
me as unusually clear and smooth as the frame updates are synchronous
and there is an entire new frame for each retrace. Anyway, I don't
think dropping frames (29.97) at less than the refresh rate (59.94)
is a good idea. The problem is that if a frame is dropped, two
retraces show the field from one frame, the next frame is missing
then the next two retraces are from the second frame after. By
drawing all the intermediate frames, the two fields will work kind
of like the pulldown tricks used for televising movies.

--  bjm