lists at glidos
Mar 23, 2009, 8:38 AM
Post #3 of 13
(1987 views)
Permalink
|
|
Re: Ticket #2903 is necessary to achieve perfect playback with an interleaved display mode.
[In reply to]
|
|
Mark Kendall wrote:
> I've been meaning to write a software 'field-order' deinterlacer for
> some time. Unfortunately it keeps on getting bumped down the list,
> mostly because interlaced output isn't a big ticket item for me
> anymore (finally invested in a 1080p display).
Good to hear it's not forgotten. I'm quite happy to write it. I
haven't before because it was ages before I managed to build a
system where the loss of sync was the most pressing problem.
I think the field order deinterlacer should be fairly easy to
write: although yadifx2 is very much more complicated, it's
the same pattern of leaving original lines intact, and generating
the inbetween ones, so I think I can base it on that, and replace
the complex calculations by memcpys.
> If you do take a look
> at this, you should be aware that the fieldorder opengl deinterlacer
> in trunk is no longer actually 'fieldorder' - it is effectively
> bobdeint without the bobbing (i.e. it displays one field at a time
> scaled to frame size). I realised after a large amount of testing that
> this was the only reliable way of getting the sync correct for my
> display. As I've said before though, this will almost certainly depend
> on your make/model of tv.
I was aware of that change, but not that it had made it to trunk.
I still don't understand why that should be. Because of what you
have said on the subject, I have been suspicious that field order
wont work for me, but what I am seeing from yadif supports
that it should work (I still get two modes of operation, as
I did without a deinterlaced, but with yadif I either see all
lines from the original video, or all the lines calculated from
yadif - you can tell from the artifacts, such as filled in letters).
Oh, and a strange thing I didn't mention in my first post: I get
really odd results from Bobx2. I expected to again have two
modes of operation depending on sync. One perfect and the other
with the fields swapped spacially. But what I get is a constantly
bad image. I suspect Bobx2 isn't using the line doubling I assumed it
was.
>> Before I could even start on that work, I ran into another problem:
>> my system wont allow me to use a doublerate deinterlacer. I traced
>> that to the refresh rate calculation ignoring the fact that the
>> screen is interlacing and returning 25, rather than 50. (25 is
>> the true framerate, but we need 50 to acknowledge that there
>> are 50 vsyncs per second, and allow the use of the doublerate
>> deinterlacer).
>>
>> I created a patch, to fix the problem, and now I can use
>> yadifx2 which does give really good results, and only loses a
>> little quality (it depends on the sync, now having the wrong
>> sync, rather than giving combs, gives a little loss of quality
>> because I then get all the lines calculated by yadif rather
>> than all the original lines).
>>
>> I thought, before continuing the work, I'd open a ticket and
>> submit my patch so that others can at least use yadifx2 and
>> get the really very good results I'm getting, but I found that
>> someone had solved the problem 3 years ago, just to have their
>> ticket closed as invalid. The explanation given says to use
>> kernel or linear blend. That's madness. Both are going to
>> blur the image horribly, although kernel not so bad for
>> still images I guess.
>>
>> Please can this decision be reconsidered. I guess it doesn't
>> matter to me so much: I now build my own copies of minimyth,
>> but there must be lots of other users who could benefit.
>
> Again, something on my to do list that keeps on getting prioritised
> down. Yes - I believe the approach taken in that patch is correct and
> it will almost certainly work without issue for most people (or at
> least it won't break playback). The problem, as someone quite rightly
> pointed out to me not so long ago, is that it has the potential to
> wreck playback for drivers that take a different approach to
> interlaced modelines. I 'think' recent intel, ati and nvidia drivers
> are consistent but my only ati card got dumped in the bin several
> weeks ago after another fruitless attempt to get it working, older
> nvidia drivers certainly took a different approach and I'm entirely
> unsure about other, less common chipsets.
Might they generate a vsync per frame, rather than per field, are
you suggesting? If that were the case, then I'd expect mythtv to
give perfect results with no deinterlacer. It would be like my
current system, but no possibly of losing sync. I can see the patch
could cause problems in that case. That's a pain. Has anyone reported
such behaviour? Perhaps a way around it would be to trigger the
altered refresh rate calculation only when a doublerate interlacer
is selected. Or it could be made a configurable option.
Cheers,
Paul.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
|
