Problem with persistent scaling/shifting in RADEONDisplayVideo()

[Roland Scheidegger]

On 30.07.2008 21:17, Thomas Hilber wrote:
> 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.
That's what fast cpus are for :-). Though I agree in particular the
tvtime deinterlacers at least for me produce artifacts which I consider
unbearable (the greedy ones for instance). linear-blend though doesn't,
though it's considered not very good quality (since it reduces
sharpness), it looks much better to me due to this. I'm not sure native
deinterlacing is much better, after all you still deinterlace - in your
brain :-).


> 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.
Hmm ok that's only about 5000 fields, I'd have expected a bit better.
Though for progressive doesn't sound too bad - depending on the scene
you will never notice this happening every 2 minutes.

> 
>> 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:)
Well, vdr serves as a media (and dvd player) too, so unless you restrict
it to use it only with dvb cards you'd still have that problem.

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

Yes, I was just thinking if it would be possible to make this a bit more
general, but it doesn't look easy...

Roland