[mythtv] [mythtv-commits] Ticket #6391: New deinterlacer for perfect image quality when using an interlaced display mode that matches the source

[Paul Gardiner]

Mark Kendall wrote:
>>  1) You mention aligning the opengl and software versions. Which would
>>  change? I ask because the OpenGL one in its current form does a completely
>>  different job. It would be no good for my set up. Its purpose doesn't seem
>>  to be to sychronise interlaces, but to truly deinterlace.
> 
> They are both trying to achieve the same thing - currently they just
> use different approaches. I previously found that the OpenGL approach
> (one field at a time) was consistently more successful on my old
> display but this may have changed with more recent drivers or may just
> be an artifact of how OpenGL interacts with the framebuffer. I'd be
> very surprised if it doesn't do just as good a job as the software
> version on your display.

Hmmm, I guess test results beat theory, but I'd be really surprised if
the OpenGL worked as well. With the software version, all fields are
original unprocessed fields, whereas with the OpenGL version half
the fields are blends. I'd expect results a little like using yadif
on an interlaced display: i.e., image quality depends on which field
you are synched on; half the time it's perfect because all the fields
you are seeing are original fields; half the time quality is lessened
because all the fields you are seeing are calculated fields. In the
case of the OpenGL version of Interlaced x2, I'd expect the image
quality to alternate between perfect and slightly blurred depending
on the sync.

The reason you couldn't get consisitent results from the fieldorder
deinterlacer before might be that so many things have to be exactly
right for it to work - frame rate, resolution, and lack of scaling.
And it doesn't deteriorate gracefully. Anything slightly wrong,
the results will look awful, and the new OpenGL version of Interlace x2
would look better.

>>  2) You mention testing 576i and 480i via HDMI. Is that with 576i and 480i
>>  display modes? Matched source and display mode is the only case this
>>  deinterlacer works correctly. I ask because someone commented in myth-
>>  users that few TVs will accept SD modes via HDMI. It would be very
>>  interesting if that's not the case.
> 
> Yes - this is with 576i and 480i display modes over DVI/HDMI. My new
> tv takes just about everything I would want to throw at it (which was
> the main reason I chose it!). As mentioned on the list, Samsungs seem
> not to accept SD interlaced modes (I've got 2, neither of which will
> do 576/480i).

Nice. What is it? Maybe that's what I should go for eventually.

>>  3) I thought I'd accounted for bottom field first. Any idea what I did
>>  wrong?
> 
> Well - if you look at your code, it doesn't do anything if tff is 0.

Aaagh! I wish I'd taken another look before I'd asked! :-)

>>  4) I made a similar change to avoid flickering OSD, but it didn't work
>>  (for the second occurence of the frame newframe == lastframe, I copied
>>  both field rather than just the second field). I also noticed that yadif
>>  suffers from flickering OSD. My changes were on fixes rather than trunk.
>>  Is that significant?
> 
> I have made some changes in trunk in recent weeks, so they may account
> for the different behaviour. I don't think I've seen a flickering osd
> with yadif (though I'll check just to be sure).

It's only when using yadif with an interlaced display mode. I don't know
maybe I imagined it. I'll check again.

I suppose I may have messed up my attempt at a cure too, like I did with
tff.

Cheers,
	Paul.