Problem with persistent scaling/shifting in RADEONDisplayVideo()

[Thomas Hilber]

On Wed, Jul 30, 2008 at 04:17:10PM +0200, Roland Scheidegger wrote:
> Actually, this is a very interesting patch. I've been thinking about
> this a bit lately. How much jerkyness do you actually get when it's not
> synchronized? I'd assume that if you use an output mode which is as

it depends on various conditions. Most people using players like xine
or mplayer feed everything through an deinterlacer first. They must
do this because their VGA modelines are also progressive. If you loose 
a progressive frame it visibly affects smoothness of replay. Watching 
a ticker is very good for debugging this. The movement is visibly choppy 
at the moment when a frame is lost. Even though this progressive frame lasts 
only for 20ms.

But using a software deinterlacer generally is not a good idea.
Even the best ones available today for linux show visible artifacts.
In particular if watching sport events. Because these mostly are
recorded by special TV cameras producing high quality true-interlaced 
material which is difficult to deinterlace in realtime.
By the way these software deinterlacers consume a considerable amount of 
CPU power.

In our case since we do not deinterlace at all a field loss is
even worse. Because after each field loss successive even/odd fields are 
swapped when they reach the output. There is no way to workaround this. 
It continues until the next field loss. Then the field order is correct 
again until the next loss etc.

> close as possible to the supposed 50i PAL timings, you should only get
> non-smooth motion (that is a frame displayed twice or skipped) very rarely?

no. Even if you are lucky enough to adjust your modeline to 50.01Hz you
still get visible skips (or even/odd field order probs) about every 
100 seconds. 

> And, a problem you'd have with htpc would be that you often have
> different source material - probably 25p, 50i, 23.976p, 24.0p,...

right. But in my case the Radeon serves as an output device for VDR,
the famous linux video disk recorder. In this case the Radeon has to
deal only with PAL streams from DVB providers. For example satellite
broadcasters.
All conversion of different source material to PAL is responsibility of
these providers. So no hassle for us:)

> So, even in a setup where you wouldn't care about (output) interlace and
> are just fine using a scaler (for different source resolutions), you'd
> still need to switch output modes to match (or use an exact multiple) of
> the framerate, which then could be synchronized with your (or similar)
> patch. That's an awful lot of hacks to get most smooth playback without
> any API really to make it work in some sane way...

since we only want to generate a PAL signal with it's well defined timings
it's no problem for us.

-Thomas