Mailing List Archive

On Thu, Mar 26, 2009 at 8:26 AM, Paul Gardiner <lists@glidos.net> wrote:
> I've just created a patch that provides a deinterlacer for perfect image
> quality and motion smoothness when using an interlaced display mode that
> exactly matches the video source. See Ticket #6391. The deinterlacer comes
> up in the menus as "Interlaced x2". It is also known as field order.
>
>
> Preconditions of use
> ~~~~~~~~~~~~~~~~~~~~
> You need a graphics chip that can output interlaced display modes correctly.
>

Any idea what those might be? Very interested though.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Lichti wrote:
> On Thu, Mar 26, 2009 at 8:26 AM, Paul Gardiner <lists@glidos.net> wrote:
>> I've just created a patch that provides a deinterlacer for perfect image
>> quality and motion smoothness when using an interlaced display mode that
>> exactly matches the video source. See Ticket #6391. The deinterlacer comes
>> up in the menus as "Interlaced x2". It is also known as field order.
>>
>>
>> Preconditions of use
>> ~~~~~~~~~~~~~~~~~~~~
>> You need a graphics chip that can output interlaced display modes correctly.
>>
>
> Any idea what those might be? Very interested though.

I think I've worded that condition in a confusing way. All should be
well if you are using TV out.

I've been using the VGA to Scart trick, which requires interlaced TV
timings from VGA. Finding chip/driver combinations that can handle
that is harder. Many ATI chips now work if you use the radeon driver.
And development of the radeon driver is very active. I've had a Radeon
9000 work. I'm currently using an integrated X1250. I've heard that
an integrated HD3200 will work.

I don't know about 1080i. I don't have HD capability at the moment.

There's been a lot of talk of nVidia's drivers not supporting interlaced
output correctly, but I don't know if that applies to just VGA, or
also TV out. 1080i via HDMI might be fine. Don't really know.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Paul Gardiner wrote:
> Tom Lichti wrote:
>> On Thu, Mar 26, 2009 at 8:26 AM, Paul Gardiner <lists@glidos.net> wrote:
>>> I've just created a patch that provides a deinterlacer for perfect image
>>> quality and motion smoothness when using an interlaced display mode that
>>> exactly matches the video source. See Ticket #6391. The deinterlacer
>>> comes
>>> up in the menus as "Interlaced x2". It is also known as field order.
>>>
>>>
>>> Preconditions of use
>>> ~~~~~~~~~~~~~~~~~~~~
>>> You need a graphics chip that can output interlaced display modes
>>> correctly.
>>>
>>
>> Any idea what those might be? Very interested though.
>
> I think I've worded that condition in a confusing way. All should be
> well if you are using TV out.
>
> I've been using the VGA to Scart trick, which requires interlaced TV
> timings from VGA. Finding chip/driver combinations that can handle
> that is harder. Many ATI chips now work if you use the radeon driver.
> And development of the radeon driver is very active. I've had a Radeon
> 9000 work. I'm currently using an integrated X1250. I've heard that
> an integrated HD3200 will work.
>
I think a problem here is (correct me if I'm wrong) that TV out usually means
S-Video or Composite, neither of which will give you as good a quality of
picture on your TV as a VGA output (or something better like DVI or HDMI, etc)
would.

--

Mike Perkins

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Thu, 2009-03-26 at 14:12 +0000, Paul Gardiner wrote:
> >> Preconditions of use
> >> ~~~~~~~~~~~~~~~~~~~~
> >> You need a graphics chip that can output interlaced display modes
> correctly.
> >>
> >
> > Any idea what those might be? Very interested though.

> There's been a lot of talk of nVidia's drivers not supporting
> interlaced
> output correctly, but I don't know if that applies to just VGA, or
> also TV out. 1080i via HDMI might be fine. Don't really know.

I do 1080i with an nVidia 5200FX card. That's AGP, not PCIe. The only
driver that works with this is version 8776, and it only works when
connecting with DVI (using DVI->HDMI in my case) to a TV that puts out a
valid EDID 1080i mode. If you try to specify a 1080i modeline, it won't
work. I've recently patched it to work with more recent kernels, but it
limits me to Xorg-1.3.

The latest drivers have dropped support for my card, so I haven't been
able to test them to see if they've fixed the problem, but I haven't
heard anything encouraging.

The lack of good video drivers for 1080i is the main thing holding me
back from upgrading my MythTV system. I like my native-1080i TV.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Mike Perkins wrote:
> Paul Gardiner wrote:
>> Tom Lichti wrote:
>>> On Thu, Mar 26, 2009 at 8:26 AM, Paul Gardiner <lists@glidos.net> wrote:
>>>> I've just created a patch that provides a deinterlacer for perfect
>>>> image
>>>> quality and motion smoothness when using an interlaced display mode
>>>> that
>>>> exactly matches the video source. See Ticket #6391. The deinterlacer
>>>> comes
>>>> up in the menus as "Interlaced x2". It is also known as field order.
>>>>
>>>>
>>>> Preconditions of use
>>>> ~~~~~~~~~~~~~~~~~~~~
>>>> You need a graphics chip that can output interlaced display modes
>>>> correctly.
>>>>
>>>
>>> Any idea what those might be? Very interested though.
>>
>> I think I've worded that condition in a confusing way. All should be
>> well if you are using TV out.
>>
>> I've been using the VGA to Scart trick, which requires interlaced TV
>> timings from VGA. Finding chip/driver combinations that can handle
>> that is harder. Many ATI chips now work if you use the radeon driver.
>> And development of the radeon driver is very active. I've had a Radeon
>> 9000 work. I'm currently using an integrated X1250. I've heard that
>> an integrated HD3200 will work.
>>
> I think a problem here is (correct me if I'm wrong) that TV out usually
> means S-Video or Composite, neither of which will give you as good a
> quality of picture on your TV as a VGA output (or something better like
> DVI or HDMI, etc) would.

Yeah, you may be wrong. I think, for an SD source, most of our
deinterlacers degrade the quality more than the use of S-Video - for
SD you lose very little through S-Video.

Also, it may be possible to output 480i or 576i via HDMI (I'm afraid I
know little about that).

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Thu, Mar 26, 2009 at 8:26 AM, Paul Gardiner <lists@glidos.net> wrote:
> I've just created a patch that provides a deinterlacer for perfect image
> quality and motion smoothness when using an interlaced display mode that
> exactly matches the video source. See Ticket #6391. The deinterlacer comes
> up in the menus as "Interlaced x2". It is also known as field order.
>

Very very cool stuff Paul. I was reading about this on your thread on
the dev list.

I've been running 0.21-fixes version 18314 under Gentoo patched with
that 2903 patch to allow Bob x2. I watch all U.S. OTA DTV on a rear
projection CRT (Hitachi 51F500), so my issues have been mainly with
1080i content. In my case the 2903 patch and Bob have worked well,
though never quite as good as with no deinterlacing (when it happened
to be in sync, which certainly wasn't often enough to put up with).

I was able to patch the rev 18314 source with your patch, though hunk
3 of the libs/libmythtv/videodisplayprofile.cpp gave me a problem so I
had to enter it manually:

@@ -1304,6 +1311,8 @@
msg = kYadifMsg;
else if (deint == "yadifdoubleprocessdeint")
msg = kYadifMsg + " " + kDoubleRateMsg;
+ else if (deint == "fieldorderdoubleprocessdeint")
+ msg = kFieldorderMsg + " " + kDoubleRateMsg;
else if (deint == "opengldoublerateyadif")
msg = kYadifMsg + " " + kUsingOpenGLWorkaround;
else

...those three lines after your added lines don't seem to appear that
way in 18314 or even in the current 0.21-fixes SVN...instead it's
followed by the final else clause.

In any case I got it to work and I'm only having one issue (not the
fault of your code...more on that below). I have to say that this is
the first time I've seen my myth system play 1080i content and have it
look just as good as my Samsung HD receiver. From my testing so far,
this appears to be exactly what I've been hoping for since building
the system two years ago, and may be just as good as actually having
nVidia fix their 1080i ouput (which may never happen).

The issue I'm running into is due to the fact that two of my 1080i
stations...NBC and CBS...have the unexplainable practice of mixing
progressive and interlaced frames. This causes the constant
re-enabling of interlacing every 1/2 second or so:

2009-03-26 14:08:04.288 Using deinterlace method fieldorderdoubleprocessdeint
2009-03-26 14:08:07.491 NVP: progressive frame seen after 91 interlaced frames
2009-03-26 14:08:07.558 Enabled deinterlacing
2009-03-26 14:08:07.808 NVP: interlaced frame seen after 9 progressive frames
2009-03-26 14:08:07.808 Enabled deinterlacing
2009-03-26 14:08:08.094 NVP: progressive frame seen after 10 interlaced frames
2009-03-26 14:08:08.163 Enabled deinterlacing
2009-03-26 14:08:09.274 NVP: interlaced frame seen after 29 progressive frames
2009-03-26 14:08:09.274 Enabled deinterlacing
2009-03-26 14:08:09.458 NVP: progressive frame seen after 7 interlaced frames
2009-03-26 14:08:09.524 Enabled deinterlacing
2009-03-26 14:08:10.791 NVP: interlaced frame seen after 33 progressive frames
2009-03-26 14:08:10.791 Enabled deinterlacing
2009-03-26 14:08:11.091 NVP: progressive frame seen after 10 interlaced frames
2009-03-26 14:08:11.158 Enabled deinterlacing

...etc...etc. This issue (especially with NBC) has come up on the
list before. It doesn't seem to cause visible issues with Bob x2 for
some reason.

However, as long as this occurs using fieldorderdoubleprocessdeint I
run into various problems including occasional tearing. However, if
immediately after starting playback, I pause and then go into the
playback menu and change the video scan from "Detect" to "Interlaced
(Normal)" your deinterlacer seems to work flawlessly...at least from
what I've seen so far. Forcing that setting has actually been the
recommended work-around when this issue has been raised here before.

Definitely cool beyond belief though. I'm going to look into seeing
if I can find a way to patch playback so that, as soon as
deinterlacing gets enabled after seeing any progressive frames (which
doesn't seem to ever happen on any of my actual 720p channels), it
simply leaves deinterlacing on. In my case that would take care of
it.

Thanks!!
Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Thu, Mar 26, 2009 at 12:17 PM, Preston Crow
<pc-mythtv08a@crowcastle.net> wrote:
> On Thu, 2009-03-26 at 15:51 +0000, Paul Gardiner wrote:
>> Preston Crow wrote:
>> > I do 1080i with an nVidia 5200FX card.  That's AGP, not PCIe.  The only
>> > driver that works with this is version 8776, and it only works when
>> > connecting with DVI (using DVI->HDMI in my case) to a TV that puts out a
>> > valid EDID 1080i mode.  If you try to specify a 1080i modeline, it won't
>> > work.  I've recently patched it to work with more recent kernels, but it
>> > limits me to Xorg-1.3.
>> >
>> > The latest drivers have dropped support for my card, so I haven't been
>> > able to test them to see if they've fixed the problem, but I haven't
>> > heard anything encouraging.
>> >
>> > The lack of good video drivers for 1080i is the main thing holding me
>> > back from upgrading my MythTV system.  I like my native-1080i TV.
>>
>> That's interesting. What do you do about synchronisation of the
>> interlaces between source and display? Do you use a deinterlacer,
>> or does the 5200FX produce only one vsync per frame?
>
> I don't use a deinterlacer, and it looks fine, so I'm guessing that
> there's only one vsync per frame.  I have an AMD 2500+ Athlon.  I
> normally use XVMC for HD, and that works pretty well.  Without XVMC, I
> can still do HD, but if anything else is running, it starts to hiccup.
>
> The 5200FX is fanless, but apparently shouldn't be; I've had two burn
> out, so I've bought replacements on eBay.
>

I thought you might be interested in this if you didn't see it. Seth
Daniel on the list says that nVidia has apparently acknowledged this
and files bugs:

http://www.gossamer-threads.com/lists/mythtv/users/372990#372990

...though I haven't actually seen what he's referring to on the nVidia forums.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Thu, Mar 26, 2009 at 03:21:50PM -0400, Tom Dexter wrote:
> On Thu, Mar 26, 2009 at 12:17 PM, Preston Crow
> <pc-mythtv08a@crowcastle.net> wrote:
> > On Thu, 2009-03-26 at 15:51 +0000, Paul Gardiner wrote:
> >> Preston Crow wrote:
> >> > I do 1080i with an nVidia 5200FX card.  That's AGP, not PCIe.  The only
> >> > driver that works with this is version 8776, and it only works when
> >> > connecting with DVI (using DVI->HDMI in my case) to a TV that puts out a
> >> > valid EDID 1080i mode.  If you try to specify a 1080i modeline, it won't
> >> > work.  I've recently patched it to work with more recent kernels, but it
> >> > limits me to Xorg-1.3.
> >> >
> >> > The latest drivers have dropped support for my card, so I haven't been
> >> > able to test them to see if they've fixed the problem, but I haven't
> >> > heard anything encouraging.
> >> >
> >> > The lack of good video drivers for 1080i is the main thing holding me
> >> > back from upgrading my MythTV system.  I like my native-1080i TV.
> >>
> >> That's interesting. What do you do about synchronisation of the
> >> interlaces between source and display? Do you use a deinterlacer,
> >> or does the 5200FX produce only one vsync per frame?
> >
> > I don't use a deinterlacer, and it looks fine, so I'm guessing that
> > there's only one vsync per frame.  I have an AMD 2500+ Athlon.  I
> > normally use XVMC for HD, and that works pretty well.  Without XVMC, I
> > can still do HD, but if anything else is running, it starts to hiccup.
> >
> > The 5200FX is fanless, but apparently shouldn't be; I've had two burn
> > out, so I've bought replacements on eBay.
> >
>
> I thought you might be interested in this if you didn't see it. Seth
> Daniel on the list says that nVidia has apparently acknowledged this
> and files bugs:
>
> http://www.gossamer-threads.com/lists/mythtv/users/372990#372990
>
> ...though I haven't actually seen what he's referring to on the nVidia forums.

I haven't been on the forum in a while. I'm content with using vdpau w/
bob 2x + 2903 patch. It looks really good. Much better than using
software bob 2x + 2903 patch. Not to mention that the CPU utilization
is *much* less.

At one point I was more active on the nvnews forum and I actually
received responses from Stephen Warren (the most active of the nvidia
folks on that forum). Although playback of 1080i material to a 1080i
display still tears if you don't use bob 2x + the 2903 patch.

--
seth /\ sethdaniel.org
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> On Thu, Mar 26, 2009 at 8:26 AM, Paul Gardiner <lists@glidos.net> wrote:
>> I've just created a patch that provides a deinterlacer for perfect image
>> quality and motion smoothness when using an interlaced display mode that
>> exactly matches the video source. See Ticket #6391. The deinterlacer comes
>> up in the menus as "Interlaced x2". It is also known as field order.
>>
>
> Very very cool stuff Paul. I was reading about this on your thread on
> the dev list.
>
> I've been running 0.21-fixes version 18314 under Gentoo patched with
> that 2903 patch to allow Bob x2. I watch all U.S. OTA DTV on a rear
> projection CRT (Hitachi 51F500), so my issues have been mainly with
> 1080i content. In my case the 2903 patch and Bob have worked well,
> though never quite as good as with no deinterlacing (when it happened
> to be in sync, which certainly wasn't often enough to put up with).
>
> ...
>
> In any case I got it to work and I'm only having one issue (not the
> fault of your code...more on that below). I have to say that this is
> the first time I've seen my myth system play 1080i content and have it
> look just as good as my Samsung HD receiver. From my testing so far,
> this appears to be exactly what I've been hoping for since building
> the system two years ago, and may be just as good as actually having
> nVidia fix their 1080i ouput (which may never happen).

Great news. I wondered whether it could work with 1080i. Sounds like
you've been in a similar position to me, having other equipment that
could give slightly better image quality, and never quite being able
to give up on making mythtv do as well.

The bit about nVidia confuses me a bit. I've obviously not understood
what the problem they have with 1080i because I was expecting it to
prevent use of the fieldorder patch; I thought it caused line doubling
when using XV rendering. What is that actual problem? Is it just the
problem of getting two vsyncs per frame?

> The issue I'm running into is due to the fact that two of my 1080i
> stations...NBC and CBS...have the unexplainable practice of mixing
> progressive and interlaced frames. This causes the constant
> re-enabling of interlacing every 1/2 second or so:
>
> 2009-03-26 14:08:04.288 Using deinterlace method fieldorderdoubleprocessdeint
> 2009-03-26 14:08:07.491 NVP: progressive frame seen after 91 interlaced frames
> 2009-03-26 14:08:07.558 Enabled deinterlacing
> 2009-03-26 14:08:07.808 NVP: interlaced frame seen after 9 progressive frames
> 2009-03-26 14:08:07.808 Enabled deinterlacing
> 2009-03-26 14:08:08.094 NVP: progressive frame seen after 10 interlaced frames
> 2009-03-26 14:08:08.163 Enabled deinterlacing
> 2009-03-26 14:08:09.274 NVP: interlaced frame seen after 29 progressive frames
> 2009-03-26 14:08:09.274 Enabled deinterlacing
> 2009-03-26 14:08:09.458 NVP: progressive frame seen after 7 interlaced frames
> 2009-03-26 14:08:09.524 Enabled deinterlacing
> 2009-03-26 14:08:10.791 NVP: interlaced frame seen after 33 progressive frames
> 2009-03-26 14:08:10.791 Enabled deinterlacing
> 2009-03-26 14:08:11.091 NVP: progressive frame seen after 10 interlaced frames
> 2009-03-26 14:08:11.158 Enabled deinterlacing
>
> ...etc...etc. This issue (especially with NBC) has come up on the
> list before. It doesn't seem to cause visible issues with Bob x2 for
> some reason.
>
> However, as long as this occurs using fieldorderdoubleprocessdeint I
> run into various problems including occasional tearing. However, if
> immediately after starting playback, I pause and then go into the
> playback menu and change the video scan from "Detect" to "Interlaced
> (Normal)" your deinterlacer seems to work flawlessly...at least from
> what I've seen so far. Forcing that setting has actually been the
> recommended work-around when this issue has been raised here before.
>
> Definitely cool beyond belief though. I'm going to look into seeing
> if I can find a way to patch playback so that, as soon as
> deinterlacing gets enabled after seeing any progressive frames (which
> doesn't seem to ever happen on any of my actual 720p channels), it
> simply leaves deinterlacing on. In my case that would take care of
> it.

That sounds like an ideal patch. Hope you can get that working. Will
also be handy for me when I eventually go HD here.

The other thing I wonder about is whether we can get 2903 committed.
Perhaps it could be made a configuration option with default being off.
I haven't yet figured out how one adds new config options though.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Fri, Mar 27, 2009 at 6:14 AM, Paul Gardiner <lists@glidos.net> wrote:
> Tom Dexter wrote:
>>
>> On Thu, Mar 26, 2009 at 8:26 AM, Paul Gardiner <lists@glidos.net> wrote:
>>>
>>> I've just created a patch that provides a deinterlacer for perfect image
>>> quality and motion smoothness when using an interlaced display mode that
>>> exactly matches the video source. See Ticket #6391. The deinterlacer
>>> comes
>>> up in the menus as "Interlaced x2". It is also known as field order.
>>>
>>
>> Very very cool stuff Paul.  I was reading about this on your thread on
>> the dev list.
>>
>> I've been running 0.21-fixes version 18314 under Gentoo patched with
>> that 2903 patch to allow Bob x2.  I watch all U.S. OTA DTV on a rear
>> projection CRT (Hitachi 51F500), so my issues have been mainly with
>> 1080i content.  In my case the 2903 patch and Bob have worked well,
>> though never quite as good as with no deinterlacing (when it happened
>> to be in sync, which certainly wasn't often enough to put up with).
>>
>> ...
>
>>
>>
>> In any case I got it to work and I'm only having one issue (not the
>> fault of your code...more on that below).  I have to say that this is
>> the first time I've seen my myth system play 1080i content and have it
>> look just as good as my Samsung HD receiver.  From my testing so far,
>> this appears to be exactly what I've been hoping for since building
>> the system two years ago, and may be just as good as actually having
>> nVidia fix their 1080i ouput (which may never happen).
>
> Great news. I wondered whether it could work with 1080i. Sounds like
> you've been in a similar position to me, having other equipment that
> could give slightly better image quality, and never quite being able
> to give up on making mythtv do as well.
>
> The bit about nVidia confuses me a bit. I've obviously not understood
> what the problem they have with 1080i because I was expecting it to
> prevent use of the fieldorder patch; I thought it caused line doubling
> when using XV rendering. What is that actual problem? Is it just the
> problem of getting two vsyncs per frame?
>

To tell you the truth, most of the technical stuff regarding video is
way out of my league. I'm not sure what nVidia is doing wrong. All I
really know is that apparently very old nVidia drivers kept 1080i
video sync perfectly with no deinterlacing at all. Any newer ones
(any that I've been able to run) look great temporarily but
periodically drift out of sync.

>> The issue I'm running into is due to the fact that two of my 1080i
>> stations...NBC and CBS...have the unexplainable practice of mixing
>> progressive and interlaced frames.  This causes the constant
>> re-enabling of interlacing every 1/2 second or so:
>>
>> 2009-03-26 14:08:04.288 Using deinterlace method
>> fieldorderdoubleprocessdeint
>> 2009-03-26 14:08:07.491 NVP: progressive frame seen after 91 interlaced
>>  frames
>> 2009-03-26 14:08:07.558 Enabled deinterlacing
>> 2009-03-26 14:08:07.808 NVP: interlaced frame seen after 9 progressive
>> frames
>> 2009-03-26 14:08:07.808 Enabled deinterlacing
>> 2009-03-26 14:08:08.094 NVP: progressive frame seen after 10 interlaced
>>  frames
>> 2009-03-26 14:08:08.163 Enabled deinterlacing
>> 2009-03-26 14:08:09.274 NVP: interlaced frame seen after 29 progressive
>> frames
>> 2009-03-26 14:08:09.274 Enabled deinterlacing
>> 2009-03-26 14:08:09.458 NVP: progressive frame seen after 7 interlaced
>>  frames
>> 2009-03-26 14:08:09.524 Enabled deinterlacing
>> 2009-03-26 14:08:10.791 NVP: interlaced frame seen after 33 progressive
>> frames
>> 2009-03-26 14:08:10.791 Enabled deinterlacing
>> 2009-03-26 14:08:11.091 NVP: progressive frame seen after 10 interlaced
>>  frames
>> 2009-03-26 14:08:11.158 Enabled deinterlacing
>>
>> ...etc...etc.  This issue (especially with NBC) has come up on the
>> list before.  It doesn't seem to cause visible issues with Bob x2 for
>> some reason.
>>
>> However, as long as this occurs using fieldorderdoubleprocessdeint I
>> run into various problems including occasional tearing.  However, if
>> immediately after starting playback, I pause and then go into the
>> playback menu and change the video scan from "Detect" to "Interlaced
>> (Normal)" your deinterlacer seems to work flawlessly...at least from
>> what I've seen so far.  Forcing that setting has actually been the
>> recommended work-around when this issue has been raised here before.
>>
>> Definitely cool beyond belief though.  I'm going to look into seeing
>> if I can find a way to patch playback so that, as soon as
>> deinterlacing gets enabled after seeing any progressive frames (which
>> doesn't seem to ever happen on any of my actual 720p channels), it
>> simply leaves deinterlacing on.  In my case that would take care of
>> it.
>
> That sounds like an ideal patch. Hope you can get that working. Will
> also be handy for me when I eventually go HD here.
>
> The other thing I wonder about is whether we can get 2903 committed.
> Perhaps it could be made a configuration option with default being off.
> I haven't yet figured out how one adds new config options though.
>
> Cheers,
>        Paul.

I discovered that a patch was discussed on the dev list. I replied here:

http://www.gossamer-threads.com/lists/mythtv/dev/376752#376752

For my own purposes I found a quick hack (not sure if it would affect
other things like DVD playback which I don't use the internal player
for). In libs/libmythtv/NuppelVideoPlayer.cpp, at the very end of
NuppelVideoPlayer::AutoDeint() I changed the line:

m_scan_locked = false;

...to...

m_scan_locked = (m_scan_tracker > min_count);

...that is, if we've detected interlaced frames and switched to
interlaced, lock it that way (just like setting it in the menu). It
appears to work great in my circumstance...and the new deinterlacer is
working just great. It really does look crystal clear like I've never
seen in mythtv...at least not consistently. Really great.

By the way...I noticed that the new deinterlacer uses a bit more CPU
that Bob x2 (though certainly acceptably low). Would you think that's
to be expected?

Thanks again. Great work!
Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Fri, Mar 27, 2009 at 6:14 AM, Paul Gardiner <lists@glidos.net> wrote:
>
> The other thing I wonder about is whether we can get 2903 committed.
> Perhaps it could be made a configuration option with default being off.
> I haven't yet figured out how one adds new config options though.
>
> Cheers,
>        Paul.
>

Yea...I forgot to mention that. When I first installed the new
deinterlacer I did so without the 2903 patch and thought the
deinterlacer wasn't working. Then I noticed that it was enabling it
and then immediately falling back on none because of the refresh rate.
After I recompiled with that patch it worked fine.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Hi

2009/3/28 Tom Dexter <digitalaudiorock@gmail.com>:
> Yea...I forgot to mention that.  When I first installed the new
> deinterlacer I did so without the 2903 patch and thought the
> deinterlacer wasn't working.  Then I noticed that it was enabling it
> and then immediately falling back on none because of the refresh rate.
>  After I recompiled with that patch it worked fine.

Ah is that why it wasn't working for me...

I've included the new "deinterlacer" in my ubuntu packages from version 20275...

2903 was integrated in trunk just a few minutes ago.

Recompiling packages with 2903 now..

Jean-Yves
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> By the way...I noticed that the new deinterlacer uses a bit more CPU
> that Bob x2 (though certainly acceptably low). Would you think that's
> to be expected?

Probably not surprising. But should be faurly low, nowhere near the
requirements of yadif.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Jean-Yves Avenard wrote:
> Hi
>
> 2009/3/28 Tom Dexter <digitalaudiorock@gmail.com>:
>> Yea...I forgot to mention that. When I first installed the new
>> deinterlacer I did so without the 2903 patch and thought the
>> deinterlacer wasn't working. Then I noticed that it was enabling it
>> and then immediately falling back on none because of the refresh rate.
>> After I recompiled with that patch it worked fine.
>
> Ah is that why it wasn't working for me...
>
> I've included the new "deinterlacer" in my ubuntu packages from version 20275...

Magic! That's good to know.

> 2903 was integrated in trunk just a few minutes ago.
>
> Recompiling packages with 2903 now..

Yeah, I just noticed that. Looks like it's all getting
sorted out.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter <digitalaudiorock@gmail.com> says:
> In libs/libmythtv/NuppelVideoPlayer.cpp, at the very end of
> NuppelVideoPlayer::AutoDeint() I changed the line:
>
> m_scan_locked = false;
>
> ...to...
>
> m_scan_locked = (m_scan_tracker > min_count);

Thanks for this; it neatly answered my request for same
(<URL:http://www.gossamer-threads.com/lists/mythtv/dev/375271#375271>.
My display is progressive, not interlaced, but the phantom
progresive-frames issue bedevils all of us. I agree your hack is
probably not ideal for DVD playback (where there really is content
with both interlaced and true progressive frames mixed together,
apparently), but like you I almost never use MythTV for DVDs. Until a
more-comprehensive solution arrives yours will do nicely.

--
Frontend/backend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Sat, Mar 28, 2009 at 6:40 AM, Yeechang Lee <ylee@pobox.com> wrote:
> Tom Dexter <digitalaudiorock@gmail.com> says:
>> In libs/libmythtv/NuppelVideoPlayer.cpp, at the very end of
>> NuppelVideoPlayer::AutoDeint() I changed the line:
>>
>> m_scan_locked  = false;
>>
>> ...to...
>>
>> m_scan_locked = (m_scan_tracker > min_count);
>
> Thanks for this; it neatly answered my request for same
> (<URL:http://www.gossamer-threads.com/lists/mythtv/dev/375271#375271>.
> My display is progressive, not interlaced, but the phantom
> progresive-frames issue bedevils all of us. I agree your hack is
> probably not ideal for DVD playback (where there really is content
> with both interlaced and true progressive frames mixed together,
> apparently), but like you I almost never use MythTV for DVDs. Until a
> more-comprehensive solution arrives yours will do nicely.
>
> --
> Frontend/backend:       P4 3.0GHz, 1.5TB software RAID 5 array
> Backend:                Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
> Video inputs:           Four high-definition over FireWire/OTA
> Accessories:            47" 1080p LCD, 5.1 digital, and MX-600

You're welcome! I used to generally ignore that disabling and
re-enabling of the deinterlacer caused by those as it didn't seem to
affect Bob x2. I generally tried to remember to switch from "Detect"
to "Interlaced (normal)" when watching NBC and CBS shows, but it
really didn't make a difference.

However it really did cause problems with the new deinterlacer, and
this addresses that. Come to think of it, I suppose that hack could
use this:

m_scan_locked = (m_scan_tracker > min_count && !ringBuffer->isDVD());

...thus behaving exactly as it used to for DVD playback.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Thu, Mar 26, 2009 at 8:26 AM, Paul Gardiner <lists@glidos.net> wrote:
> I've just created a patch that provides a deinterlacer for perfect image
> quality and motion smoothness when using an interlaced display mode that
> exactly matches the video source. See Ticket #6391. The deinterlacer comes
> up in the menus as "Interlaced x2". It is also known as field order.
>
>

I noticed something using this deinterlacer that I thought was an
issue with the deinterlacer itself. Others may notice it so I figured
I'd point out what I discovered:

I noticed some flickering of translucent portions of the OSD (the
playback menu for example) while this deinterlacer was in use (unless
video is paused). On 720p stations where it gets disabled this
doesn't occur at all.

However I discovered that this is strictly an artifact caused by the
stations that mix those progressive frames in the interlaced
content...and the more they do it, the more noticeable the OSD
flickering. For example, on NBC shows that do this it's very
noticeable...on the CBS shows that mix them in it's less noticeable,
and on PBS which uses pure 1080i interlaced content it doesn't occur
at all.

Using Bob x2 I get similar results but much less so...the flickering
is there for those same shows but is barely perceptible, so I had
never noticed it. For whatever reason it's much more pronounced with
the frame order deinterlacer.

I really wish these stations would cut the crap...honestly. Just try
and figure out their thought process: With shows that are actually
produced as non-HD 4:3, they were (apparently) afraid that switching
formats on the fly would cause problems with TVs etc, and chose
instead to broadcast them as 1080i with black bars built into the
content (so what should be SD shows take up as much disk on my system
as do HD shows...thank you very much). Yet they have no issue with
tossing progressive frames into interlaced video and using different
frame rates for commercials (thus those 1 hour shows that get reported
as 51 minutes in the OSD). What the hell are they thinking.

All I can say is kudos to the MythTV devs for the fact that it handles
all that horse shit as well as it does.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> On Thu, Mar 26, 2009 at 8:26 AM, Paul Gardiner <lists@glidos.net> wrote:
>> I've just created a patch that provides a deinterlacer for perfect image
>> quality and motion smoothness when using an interlaced display mode that
>> exactly matches the video source. See Ticket #6391. The deinterlacer comes
>> up in the menus as "Interlaced x2". It is also known as field order.
>>
>>
>
> I noticed something using this deinterlacer that I thought was an
> issue with the deinterlacer itself. Others may notice it so I figured
> I'd point out what I discovered:
>
> I noticed some flickering of translucent portions of the OSD (the
> playback menu for example) while this deinterlacer was in use (unless
> video is paused). On 720p stations where it gets disabled this
> doesn't occur at all.

I've noticed that too with SD content here, both with the new
deinterlacer and with no deinterlacer. I think the handling of
the OSD is special cased for Bob so that might be why Bob avoids
it. Bob might be processing the OSD giving a sort of deflicker
effect.

Oh yeah, I had wondered whether there were cases where the OSD
gets painted twice (because of somehow getting stored in the
deinterlacer's buffers). For a translucent OSD that would
momentarily darken it.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> I noticed some flickering of translucent portions of the OSD (the
> playback menu for example) while this deinterlacer was in use (unless
> video is paused). On 720p stations where it gets disabled this
> doesn't occur at all.

I think I've just sussed what is causing this. The deinterlacer gets
given each frame twice. Each time it overwrites the bottom field,
but leaves the top field unchanged. After each call the OSD will
be rendered over the frame. The fact that I don't update the
top field in the second call to the deinterlacer means the OSD gets
rendered over the top of a previous rendering. That doesn't matter
for a solid OSD, but if translucent the top field will be
darker than the bottom.

Should be easy to fix:

Change

if (y & tff)
{
if(parity)
{
/* Second call: put back the second field to its previous
state */
memcpy(dst + dst_offsets[i] + y*dst_stride[i],
&p->ref[nr_c][i][y*refs], w);
}
else
{
/* First call: replace second field by that of the previous
frame */
memcpy(dst + dst_offsets[i] + y*dst_stride[i],
&p->ref[nr_p][i][y*refs], w);
}
}

to
if(parity)
{
/* Second call: put back the whole frame to its previous state.
* Although we have not altered first field, we need to overwrite
* it because the OSD will have been rendered to the copy passed
* in. */
memcpy(dst + dst_offsets[i] + y*dst_stride[i],
&p->ref[nr_c][i][y*refs], w);
}
else
{
/* First call: replace second field by that of the previous frame */
if (y & tff)
{
memcpy(dst + dst_offsets[i] + y*dst_stride[i],
&p->ref[nr_p][i][y*refs], w);
}
}

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Paul Gardiner wrote:
> Tom Dexter wrote:
>> I noticed some flickering of translucent portions of the OSD (the
>> playback menu for example) while this deinterlacer was in use (unless
>> video is paused). On 720p stations where it gets disabled this
>> doesn't occur at all.
>
> I think I've just sussed what is causing this. The deinterlacer gets
> given each frame twice. Each time it overwrites the bottom field,
> but leaves the top field unchanged. After each call the OSD will
> be rendered over the frame. The fact that I don't update the
> top field in the second call to the deinterlacer means the OSD gets
> rendered over the top of a previous rendering. That doesn't matter
> for a solid OSD, but if translucent the top field will be
> darker than the bottom.
>
> Should be easy to fix:

...

Hmmm, so much for that idea! Doesn't seem to make any difference.

P.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Mon, Mar 30, 2009 at 4:39 AM, Paul Gardiner <lists@glidos.net> wrote:
> Paul Gardiner wrote:
>>
>> Tom Dexter wrote:
>>>
>>> I noticed some flickering of translucent portions of the OSD (the
>>> playback menu for example) while this deinterlacer was in use (unless
>>> video is paused).  On 720p stations where it gets disabled this
>>> doesn't occur at all.
>>
>> I think I've just sussed what is causing this. The deinterlacer gets
>> given each frame twice. Each time it overwrites the bottom field,
>> but leaves the top field unchanged. After each call the OSD will
>> be rendered over the frame. The fact that I don't update the
>> top field in the second call to the deinterlacer means the OSD gets
>> rendered over the top of a previous rendering. That doesn't matter
>> for a solid OSD, but if translucent the top field will be
>> darker than the bottom.
>>
>> Should be easy to fix:
>
> ...
>
> Hmmm, so much for that idea! Doesn't seem to make any difference.
>
> P.
>

It's definitely a side affect I can live with for sure...it's not even
all that noticeable.

The deinterlacer really does work great though. Watching the 1080i
content I'm starting to notice more and more just how much better it
looks...that almost 3D-like clarity I just wasn't getting before.
Great stuff.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> On Mon, Mar 30, 2009 at 4:39 AM, Paul Gardiner <lists@glidos.net> wrote:
>> Paul Gardiner wrote:
>>> Tom Dexter wrote:
>>>> I noticed some flickering of translucent portions of the OSD (the
>>>> playback menu for example) while this deinterlacer was in use (unless
>>>> video is paused). On 720p stations where it gets disabled this
>>>> doesn't occur at all.
>>> I think I've just sussed what is causing this. The deinterlacer gets
>>> given each frame twice. Each time it overwrites the bottom field,
>>> but leaves the top field unchanged. After each call the OSD will
>>> be rendered over the frame. The fact that I don't update the
>>> top field in the second call to the deinterlacer means the OSD gets
>>> rendered over the top of a previous rendering. That doesn't matter
>>> for a solid OSD, but if translucent the top field will be
>>> darker than the bottom.
>>>
>>> Should be easy to fix:
>> ...
>>
>> Hmmm, so much for that idea! Doesn't seem to make any difference.
>>
>> P.
>>
>
> It's definitely a side affect I can live with for sure...it's not even
> all that noticeable.

I've just tried yadif and see exactly the same thing, so I guess it's
a general problem with doubleprocess deinterlacers on an interlaced
display. As you say, it's not that noticeable in any case.

> The deinterlacer really does work great though. Watching the 1080i
> content I'm starting to notice more and more just how much better it
> looks...that almost 3D-like clarity I just wasn't getting before.

I'm really pleased. I imagined it would make a significant difference
to 1080i. I've been suspicious for some time that most people running
MythTv aren't getting full quality 1080i. Good to hear you are now.

BTW, what graphics card are you using, and what method of connection?

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Wed, Apr 1, 2009 at 4:07 AM, Paul Gardiner <lists@glidos.net> wrote:
> Tom Dexter wrote:
>>
>> On Mon, Mar 30, 2009 at 4:39 AM, Paul Gardiner <lists@glidos.net> wrote:
>>
>> It's definitely a side affect I can live with for sure...it's not even
>> all that noticeable.
>
> I've just tried yadif and see exactly the same thing, so I guess it's
> a general problem with doubleprocess deinterlacers on an interlaced
> display. As you say, it's not that noticeable in any case.
>
>> The deinterlacer really does work great though.  Watching the 1080i
>> content I'm starting to notice more and more just how much better it
>> looks...that almost 3D-like clarity I just wasn't getting before.
>
> I'm really pleased. I imagined it would make a significant difference
> to 1080i. I've been suspicious for some time that most people running
> MythTv aren't getting full quality 1080i. Good to hear you are now.
>
> BTW, what graphics card are you using, and what method of connection?
>
> Cheers,
>        Paul.
>

I have a PCI Express GeForce 7100GS connected to the TV via DVI.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> On Mon, Mar 30, 2009 at 4:39 AM, Paul Gardiner <lists@glidos.net> wrote:
>> Paul Gardiner wrote:
>>> Tom Dexter wrote:
>>>> I noticed some flickering of translucent portions of the OSD (the
>>>> playback menu for example) while this deinterlacer was in use (unless
>>>> video is paused). On 720p stations where it gets disabled this
>>>> doesn't occur at all.
>>> I think I've just sussed what is causing this. The deinterlacer gets
>>> given each frame twice. Each time it overwrites the bottom field,
>>> but leaves the top field unchanged. After each call the OSD will
>>> be rendered over the frame. The fact that I don't update the
>>> top field in the second call to the deinterlacer means the OSD gets
>>> rendered over the top of a previous rendering. That doesn't matter
>>> for a solid OSD, but if translucent the top field will be
>>> darker than the bottom.
>>>
>>> Should be easy to fix:
>> ...
>>
>> Hmmm, so much for that idea! Doesn't seem to make any difference.
>>
>> P.
>>
>
> It's definitely a side affect I can live with for sure...it's not even
> all that noticeable.

Turns out the changes did work. I was confused because there is still
a small amount of flicker with my OSD.

Mark Kendall has now committed the deinterlaced to trunk, and has
fixed the flashing plus another bug, so grabbing that patch might
be good.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Fri, Apr 3, 2009 at 2:40 PM, Paul Gardiner <lists@glidos.net> wrote:
> Tom Dexter wrote:
>>
>> It's definitely a side affect I can live with for sure...it's not even
>> all that noticeable.
>
> Turns out the changes did work. I was confused because there is still
> a small amount of flicker with my OSD.
>
> Mark Kendall has now committed the deinterlaced to trunk, and has
> fixed the flashing plus another bug, so grabbing that patch might
> be good.
>
> Cheers,
>        Paul.
>

Thanks for the info! As far as the flickering and other fixes, should
I be taking the filter_fieldorder.c file as-is from trunk (even though
I'm running 0.21.fixes)?

Thanks in advance.
Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> On Fri, Apr 3, 2009 at 2:40 PM, Paul Gardiner <lists@glidos.net> wrote:
>> Tom Dexter wrote:
>>> It's definitely a side affect I can live with for sure...it's not even
>>> all that noticeable.
>> Turns out the changes did work. I was confused because there is still
>> a small amount of flicker with my OSD.
>>
>> Mark Kendall has now committed the deinterlaced to trunk, and has
>> fixed the flashing plus another bug, so grabbing that patch might
>> be good.
>>
>> Cheers,
>> Paul.
>>
>
> Thanks for the info! As far as the flickering and other fixes, should
> I be taking the filter_fieldorder.c file as-is from trunk (even though
> I'm running 0.21.fixes)?
>
> Thanks in advance.

I've backported Mark Kendall's improved version of the patch to fixes
and fixes with vdpau plus opengl. I've uploaded the new patches to
the original ticket: http://svn.mythtv.org/trac/attachment/ticket/6391/

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Hi

2009/4/4 Paul Gardiner <lists@glidos.net>:
> I've backported Mark Kendall's improved version of the patch to fixes
> and fixes with vdpau plus opengl. I've uploaded the new patches to
> the original ticket: http://svn.mythtv.org/trac/attachment/ticket/6391/

Hi Paul

I too backported Mark's update to my VDPAU patches ; but I'm pretty
sure the two you have posted won't compiled.

Have you tried them?

Jean-Yves
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Hi

2009/4/4 Paul Gardiner <lists@glidos.net>:

> I've backported Mark Kendall's improved version of the patch to fixes
> and fixes with vdpau plus opengl. I've uploaded the new patches to
> the original ticket: http://svn.mythtv.org/trac/attachment/ticket/6391/

Just a note that I have included your patches in the VDPAU patch set
from version 20300 (I used the trunk version).
Now that it has been merged with trunk, it is easier for me to
maintain my VDPAU backport that way.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Jean-Yves Avenard wrote:
> Hi
>
> 2009/4/4 Paul Gardiner <lists@glidos.net>:
>> I've backported Mark Kendall's improved version of the patch to fixes
>> and fixes with vdpau plus opengl. I've uploaded the new patches to
>> the original ticket: http://svn.mythtv.org/trac/attachment/ticket/6391/
>
> Hi Paul
>
> I too backported Mark's update to my VDPAU patches ; but I'm pretty
> sure the two you have posted won't compiled.
>
> Have you tried them?

Sorry you are right. I've uploaded the one from before I fixed the
compile failures. I'll try again.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Hi

2009/4/4 Paul Gardiner <lists@glidos.net>:
> Sorry you are right. I've uploaded the one from before I fixed the compile
> failures. I'll try again.

I've just uploaded my new set of patches for VDPAU ; it includes your
patch as well as the one allowing to use 2X deinterlacers with
interlaced TV..
So there won't be any need for your patch for the vdpau code anymore.

Need to tell Mark that the deinterlacer description won't fit with
many themes on my 1080p screen ; text is too long ..

JY
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Jean-Yves Avenard wrote:
> Hi
>
> 2009/4/4 Paul Gardiner <lists@glidos.net>:
>> Sorry you are right. I've uploaded the one from before I fixed the compile
>> failures. I'll try again.
>
> I've just uploaded my new set of patches for VDPAU ; it includes your
> patch as well as the one allowing to use 2X deinterlacers with
> interlaced TV..
> So there won't be any need for your patch for the vdpau code anymore

That's great. I've, in any case, corrected both just for consistency.
Hopefully I have them right now.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Sun, Apr 5, 2009 at 10:26 AM, Paul Gardiner <lists@glidos.net> wrote:
> Jean-Yves Avenard wrote:
>>
>> Hi
>>
>> 2009/4/4 Paul Gardiner <lists@glidos.net>:
>>>
>>> Sorry you are right. I've uploaded the one from before I fixed the
>>> compile
>>> failures. I'll try again.
>>
>> I've just uploaded my new set of patches for VDPAU ; it includes your
>> patch as well as the one allowing to use 2X deinterlacers with
>> interlaced TV..
>> So there won't be any need for your patch for the vdpau code anymore
>
> That's great. I've, in any case, corrected both just for consistency.
> Hopefully I have them right now.
>
> Cheers,
>        Paul.
>

I just compiled with the vanilla 0.21-fixes patch and it seems to have
worked fine, and did in fact correct the OSD flickering.

Thanks!
Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Jean-Yves Avenard wrote:
> Hi
>
> 2009/4/4 Paul Gardiner <lists@glidos.net>:
>
>> I've backported Mark Kendall's improved version of the patch to fixes
>> and fixes with vdpau plus opengl. I've uploaded the new patches to
>> the original ticket: http://svn.mythtv.org/trac/attachment/ticket/6391/
>
> Just a note that I have included your patches in the VDPAU patch set
> from version 20300 (I used the trunk version).
> Now that it has been merged with trunk, it is easier for me to
> maintain my VDPAU backport that way.

I think something may have gone wrong with that. The latest VDPAU
patch set is included in minimyth v66b5. I just tied it. 2903
seems to work because I can use yadif x2. Interlaced x2 is present
but doesn't work: I get alternating sync and out of sync as if
with no deinterlacer.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Paul Gardiner wrote:
> Jean-Yves Avenard wrote:
>> Hi
>>
>> 2009/4/4 Paul Gardiner <lists@glidos.net>:
>>
>>> I've backported Mark Kendall's improved version of the patch to fixes
>>> and fixes with vdpau plus opengl. I've uploaded the new patches to
>>> the original ticket: http://svn.mythtv.org/trac/attachment/ticket/6391/
>>
>> Just a note that I have included your patches in the VDPAU patch set
>> from version 20300 (I used the trunk version).
>> Now that it has been merged with trunk, it is easier for me to
>> maintain my VDPAU backport that way.
>
> I think something may have gone wrong with that. The latest VDPAU
> patch set is included in minimyth v66b5. I just tied it. 2903
> seems to work because I can use yadif x2. Interlaced x2 is present
> but doesn't work: I get alternating sync and out of sync as if
> with no deinterlacer.

Thinking about this a bit more, an easy slip that would cause this
would be to hardwire the "field" flag - present on trunk, but not
on fixes - to a fixed value. Instead "dirty" can be used in place
of the field flag.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Sun, Apr 5, 2009 at 3:21 PM, Paul Gardiner <lists@glidos.net> wrote:
> Paul Gardiner wrote:
>>
>> Jean-Yves Avenard wrote:
>>>
>>> Hi
>>>
>>> 2009/4/4 Paul Gardiner <lists@glidos.net>:
>>>
>>>> I've backported Mark Kendall's improved version of the patch to fixes
>>>> and fixes with vdpau plus opengl. I've uploaded the new patches to
>>>> the original ticket: http://svn.mythtv.org/trac/attachment/ticket/6391/
>>>
>>> Just a note that I have included your patches in the VDPAU patch set
>>> from version 20300 (I used the trunk version).
>>> Now that it has been merged with trunk, it is easier for me to
>>> maintain my VDPAU backport that way.
>>
>> I think something may have gone wrong with that. The latest VDPAU
>> patch set is included in minimyth v66b5. I just tied it. 2903
>> seems to work because I can use yadif x2. Interlaced x2 is present
>> but doesn't work: I get alternating sync and out of sync as if
>> with no deinterlacer.
>
> Thinking about this a bit more, an easy slip that would cause this
> would be to hardwire the "field" flag - present on trunk, but not
> on fixes - to a fixed value. Instead "dirty" can be used in place
> of the field flag.
>
> Cheers,
>        Paul.
>

Were you experiencing those problems using the new patch with
0.21-fixes? The reason I asked is that, while I didn't notice it at
first, the new patch version appears to be doing something that is
giving me unusual motion...not so much actual tearing, but motion
really doesn't look right. For tonight I'm using Bob x2. When I get
a chance to recompile I'm going back to the original patch.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Hi

2009/4/6 Paul Gardiner <lists@glidos.net>:
> Thinking about this a bit more, an easy slip that would cause this
> would be to hardwire the "field" flag - present on trunk, but not
> on fixes - to a fixed value. Instead "dirty" can be used in place
> of the field flag.

Does Mark version work for you ?
Or should I revert to your previous patch ?
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> On Sun, Apr 5, 2009 at 3:21 PM, Paul Gardiner <lists@glidos.net> wrote:
>> Paul Gardiner wrote:
>>> Jean-Yves Avenard wrote:
>>>> Hi
>>>>
>>>> 2009/4/4 Paul Gardiner <lists@glidos.net>:
>>>>
>>>>> I've backported Mark Kendall's improved version of the patch to fixes
>>>>> and fixes with vdpau plus opengl. I've uploaded the new patches to
>>>>> the original ticket: http://svn.mythtv.org/trac/attachment/ticket/6391/
>>>> Just a note that I have included your patches in the VDPAU patch set
>>>> from version 20300 (I used the trunk version).
>>>> Now that it has been merged with trunk, it is easier for me to
>>>> maintain my VDPAU backport that way.
>>> I think something may have gone wrong with that. The latest VDPAU
>>> patch set is included in minimyth v66b5. I just tied it. 2903
>>> seems to work because I can use yadif x2. Interlaced x2 is present
>>> but doesn't work: I get alternating sync and out of sync as if
>>> with no deinterlacer.
>> Thinking about this a bit more, an easy slip that would cause this
>> would be to hardwire the "field" flag - present on trunk, but not
>> on fixes - to a fixed value. Instead "dirty" can be used in place
>> of the field flag.
>>
>> Cheers,
>> Paul.
>>
>
> Were you experiencing those problems using the new patch with
> 0.21-fixes? The reason I asked is that, while I didn't notice it at
> first, the new patch version appears to be doing something that is
> giving me unusual motion...not so much actual tearing, but motion
> really doesn't look right. For tonight I'm using Bob x2. When I get
> a chance to recompile I'm going back to the original patch.

I was having problems with the version rolled into the latest VDPAU
patch. I'm now using mythtv-0.21-field-order.5.patch, and that is
working fine. The one that I'd expect to work best for you is
mythtv-0.21-field-order.6.patch, which is almost identical, but
applies directly to 2.1 fixes. Which one were you having trouble
with?

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Jean-Yves Avenard wrote:
> Hi
>
> 2009/4/6 Paul Gardiner <lists@glidos.net>:
>> Thinking about this a bit more, an easy slip that would cause this
>> would be to hardwire the "field" flag - present on trunk, but not
>> on fixes - to a fixed value. Instead "dirty" can be used in place
>> of the field flag.
>
> Does Mark version work for you ?
> Or should I revert to your previous patch ?

It works for me, but only after two build fixes. There's the
ConstFilterInfo => FilterInfo one, but also FieldorderDeint
needs changing to accoung for filters taking only two arguments
on fixes, rather than the three on trunk. Here's the version
I'm using:

+static int FieldorderDeint (VideoFilter * f, VideoFrame * frame)
+{
+ ThisFilter *filter = (ThisFilter *) f;
+ TF_VARS;
+
+ AllocFilter(filter, frame->width, frame->height);
+
+ int dirty = 1;
+ if (filter->last_framenr != frame->frameNumber)
+ {
+ if (filter->last_framenr != (frame->frameNumber - 1))
+ {
+ memset(filter->got_frames, 0, sizeof(filter->got_frames));
+ }
+ store_ref(filter, frame->buf, frame->offsets,
+ frame->pitches, frame->width, frame->height);
+ dirty = 0;
+ }
+
+ filter_func(
+ filter, frame->buf, frame->offsets, frame->pitches,
+ frame->width, frame->height, dirty, frame->top_field_first,
+ dirty);
+
+ filter->last_framenr = frame->frameNumber;
+
+ return 0;
+}

Note "dirty" appearing twice in the arguments to filter_func.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Mon, Apr 6, 2009 at 12:47 AM, Paul Gardiner <lists@glidos.net> wrote:
> Jean-Yves Avenard wrote:
>>
>> Hi
>>
>> 2009/4/6 Paul Gardiner <lists@glidos.net>:
>>>
>>> Thinking about this a bit more, an easy slip that would cause this
>>> would be to hardwire the "field" flag - present on trunk, but not
>>> on fixes - to a fixed value. Instead "dirty" can be used in place
>>> of the field flag.
>>
>> Does Mark version work for you ?
>> Or should I revert to your previous patch ?
>
> It works for me, but only after two build fixes. There's the
> ConstFilterInfo => FilterInfo one, but also FieldorderDeint
> needs changing to accoung for filters taking only two arguments
> on fixes, rather than the three on trunk. Here's the version
> I'm using:
>
> +static int FieldorderDeint (VideoFilter * f, VideoFrame * frame)
> +{
> +    ThisFilter *filter = (ThisFilter *) f;
> +    TF_VARS;
> +
> +    AllocFilter(filter, frame->width, frame->height);
> +
> +    int dirty = 1;
> +    if (filter->last_framenr != frame->frameNumber)
> +    {
> +        if (filter->last_framenr != (frame->frameNumber - 1))
> +        {
> +            memset(filter->got_frames, 0, sizeof(filter->got_frames));
> +        }
> +        store_ref(filter, frame->buf,  frame->offsets,
> +                  frame->pitches, frame->width, frame->height);
> +        dirty = 0;
> +    }
> +
> +    filter_func(
> +        filter, frame->buf, frame->offsets, frame->pitches,
> +        frame->width, frame->height, dirty, frame->top_field_first,
> +        dirty);
> +
> +    filter->last_framenr = frame->frameNumber;
> +
> +    return 0;
> +}
>
> Note "dirty" appearing twice in the arguments to filter_func.
>
> Cheers,
>        Paul.
>


Wow...I'm confused here. Yesterday I was running for a while using
the mythtv-0.21-field-order.6.patch, which seems to have everything
you're referring to, and I swear the motion just didn't look right at
all. I went back to the original patch.

I can't believe I was just seeing things. Maybe I'll try again.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> On Mon, Apr 6, 2009 at 12:47 AM, Paul Gardiner <lists@glidos.net> wrote:
>> Jean-Yves Avenard wrote:
>>> Hi
>>>
>>> 2009/4/6 Paul Gardiner <lists@glidos.net>:
>>>> Thinking about this a bit more, an easy slip that would cause this
>>>> would be to hardwire the "field" flag - present on trunk, but not
>>>> on fixes - to a fixed value. Instead "dirty" can be used in place
>>>> of the field flag.
>>> Does Mark version work for you ?
>>> Or should I revert to your previous patch ?
>> It works for me, but only after two build fixes. There's the
>> ConstFilterInfo => FilterInfo one, but also FieldorderDeint
>> needs changing to accoung for filters taking only two arguments
>> on fixes, rather than the three on trunk. Here's the version
>> I'm using:
>>
>> +static int FieldorderDeint (VideoFilter * f, VideoFrame * frame)
>> +{
>> + ThisFilter *filter = (ThisFilter *) f;
>> + TF_VARS;
>> +
>> + AllocFilter(filter, frame->width, frame->height);
>> +
>> + int dirty = 1;
>> + if (filter->last_framenr != frame->frameNumber)
>> + {
>> + if (filter->last_framenr != (frame->frameNumber - 1))
>> + {
>> + memset(filter->got_frames, 0, sizeof(filter->got_frames));
>> + }
>> + store_ref(filter, frame->buf, frame->offsets,
>> + frame->pitches, frame->width, frame->height);
>> + dirty = 0;
>> + }
>> +
>> + filter_func(
>> + filter, frame->buf, frame->offsets, frame->pitches,
>> + frame->width, frame->height, dirty, frame->top_field_first,
>> + dirty);
>> +
>> + filter->last_framenr = frame->frameNumber;
>> +
>> + return 0;
>> +}
>>
>> Note "dirty" appearing twice in the arguments to filter_func.
>>
>> Cheers,
>> Paul.
>>
>
>
> Wow...I'm confused here. Yesterday I was running for a while using
> the mythtv-0.21-field-order.6.patch, which seems to have everything
> you're referring to, and I swear the motion just didn't look right at
> all. I went back to the original patch.
>
> I can't believe I was just seeing things. Maybe I'll try again.

I'm sure you were seeing a real problem. But be something quite subtle.
Not sure how we can track this down.

P.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> On Mon, Apr 6, 2009 at 12:47 AM, Paul Gardiner <lists@glidos.net> wrote:
> Wow...I'm confused here. Yesterday I was running for a while using
> the mythtv-0.21-field-order.6.patch, which seems to have everything
> you're referring to, and I swear the motion just didn't look right at
> all. I went back to the original patch.
>
> I can't believe I was just seeing things. Maybe I'll try again.

I'm still none the wiser about this. Probably is worth trying the
backport of Mark's patch again. Also you could try the original patch
with the aternative version of filter function below:

static void filter_func(struct ThisFilter *p, uint8_t *dst, int
dst_offsets[3],
int dst_stride[3], int width, int height, int
parity, int tff)
{
int y, i;

uint8_t nr_p, nr_c;

//check if we already got this frames
nr_c = NREFS-1;//always there after store_ref
nr_p = p->got_frames[NREFS-2]?(NREFS-2):nr_c;

for (i=0; i<NCHANS; i++)
{
int is_chroma= !!i;
int w= width >>is_chroma;
int h= height>>is_chroma;
int refs= p->stride[i];

for (y=0; y<h; y++)
{
/* Alter only lines of the second field */
if(parity)
{
/* Second call: put whole frame back to previous state
when first passed in */
memcpy(dst + dst_offsets[i] + y*dst_stride[i],
&p->ref[nr_c][i][y*refs], w);
}
else
{
/* First call: replace second field by that of the
previous frame */
if (((y ^ tff) & 1) == 0)
{
memcpy(dst + dst_offsets[i] + y*dst_stride[i],
&p->ref[nr_p][i][y*refs], w);
}
}
}
}
}


That should fix the flashing OSD and handle bottom field first. But as
far as I can see it then does the same as Mark's version.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Hi

2009/4/7 Paul Gardiner <lists@glidos.net>:
> I'm still none the wiser about this. Probably is worth trying the
> backport of Mark's patch again. Also you could try the original patch
> with the aternative version of filter function below:

Could you publish your changes it as a patch in your existing ticket ?

Thanks
Jean-Yves
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Jean-Yves Avenard wrote:
> Hi
>
> 2009/4/7 Paul Gardiner <lists@glidos.net>:
>> I'm still none the wiser about this. Probably is worth trying the
>> backport of Mark's patch again. Also you could try the original patch
>> with the aternative version of filter function below:
>
> Could you publish your changes it as a patch in your existing ticket ?

Yeah, I'll do that. But before anyone takes it on, it would be good to
see how Tom gets on with it: as far as I can see, my latest version
should do the same job as the backport of Mark's version (with the
fix for the lack of the "field" paramater on fixes, that is).

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Tue, Apr 7, 2009 at 4:29 AM, Paul Gardiner <lists@glidos.net> wrote:
> Jean-Yves Avenard wrote:
>>
>> Hi
>>
>> 2009/4/7 Paul Gardiner <lists@glidos.net>:
>>>
>>> I'm still none the wiser about this. Probably is worth trying the
>>> backport of Mark's patch again. Also you could try the original patch
>>> with the aternative version of filter function below:
>>
>> Could you publish your changes it as a patch in your existing ticket ?
>
> Yeah, I'll do that. But before anyone takes it on, it would be good to
> see how Tom gets on with it: as far as I can see, my latest version
> should do the same job as the backport of Mark's version (with the
> fix for the lack of the "field" paramater on fixes, that is).
>
> Cheers,
>        Paul.
>

OK...I've done some extensive testing of 1080i playback with the
various versions of this patch.

I'm not sure what was going on the other night when I thought I was
having problems with motion using the modified version of Mark's patch
(mythtv-0.21-field-order.6.patch), but today I watched a ton of 1080i
stuff with it and everything looks great.

When I thought I was seeing problems with motion, it was specifically
(and only) with the final episode of ER I recorded last Thursday.
Even then, my wife really didn't see anything wrong, and I really
didn't give it much of a chance before switching to Bob x2 (until I
could find time to recompile). If I was in fact seeing anything odd,
it's possible it was something NBC was doing...possibly mixing more
than their usual amount of progressive frames etc...who knows. The
stuff they do normally causes video to speed up momentarily after
commercials when using Bob x2, so anything's possible. Unfortunately
I neglected to save that show which would have allowed me to verify
that.

In any case, I watched several other NBC shows with their usual
oddball video and everything looks great. I can't tell any difference
today between that and Paul's original patch (or the original patch
with the OSD flicker patch). I watched part of a PBS Nova episode and
it looks simply spectacular.

Sorry for what was apparently a false alarm.

I did have a question about the some differences in filter_func in the
newest (Mark's) version as compared to the original. While the two
appear to be functionally the same, it appears to me that, in the new
one, there may be cases where the filter is doing additional (and
unnecessary) math. That is, there appear to be cases when the
variables src and dst2 get calculated and not used, as well as cases
where src gets calculated twice. The code is arguable cleaner than
the original (less duplicate code), but possibly not as efficient(??).
From what little I know of what's going on, that seems like a place
were efficiency could be pretty important. I think that the newest
version actually is using a bit more CPU than the original, though I'd
have to switch back to be sure.

Thanks again to Paul and Mark for this one. Great stuff.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> On Tue, Apr 7, 2009 at 4:29 AM, Paul Gardiner <lists@glidos.net> wrote:
>> Jean-Yves Avenard wrote:
>>> Hi
>>>
>>> 2009/4/7 Paul Gardiner <lists@glidos.net>:
>>>> I'm still none the wiser about this. Probably is worth trying the
>>>> backport of Mark's patch again. Also you could try the original patch
>>>> with the aternative version of filter function below:
>>> Could you publish your changes it as a patch in your existing ticket ?
>> Yeah, I'll do that. But before anyone takes it on, it would be good to
>> see how Tom gets on with it: as far as I can see, my latest version
>> should do the same job as the backport of Mark's version (with the
>> fix for the lack of the "field" paramater on fixes, that is).
>>
>> Cheers,
>> Paul.
>>
>
> OK...I've done some extensive testing of 1080i playback with the
> various versions of this patch.
>
> I'm not sure what was going on the other night when I thought I was
> having problems with motion using the modified version of Mark's patch
> (mythtv-0.21-field-order.6.patch), but today I watched a ton of 1080i
> stuff with it and everything looks great.
>
> When I thought I was seeing problems with motion, it was specifically
> (and only) with the final episode of ER I recorded last Thursday.
> Even then, my wife really didn't see anything wrong, and I really
> didn't give it much of a chance before switching to Bob x2 (until I
> could find time to recompile).

I find motion in ER to be strange at times. I think the constant
circling of the camera around moving people against a complex
background must be hell for the TV's deinterlacer. Although I
have a CRT TV, it's from the era where they were mixing digital
and analog. I believe it internally deinterlaces, processes the
image and reinterlaces. My TV can get a little confused by ER.
Annoyingly, it gets slightly more confused by the signal from
MythTV than from my DVR. It's subtle, but motion with a signal
from my DVR does look very slightly better. I think it may be
a very slight difference in the mpeg decoding and the deinterlacer
picks up differently on the decoding artifacts. Just a guess.

> If I was in fact seeing anything odd,
> it's possible it was something NBC was doing...possibly mixing more
> than their usual amount of progressive frames etc...who knows. The
> stuff they do normally causes video to speed up momentarily after
> commercials when using Bob x2, so anything's possible. Unfortunately
> I neglected to save that show which would have allowed me to verify
> that.
>
> In any case, I watched several other NBC shows with their usual
> oddball video and everything looks great. I can't tell any difference
> today between that and Paul's original patch (or the original patch
> with the OSD flicker patch). I watched part of a PBS Nova episode and
> it looks simply spectacular.
>
> Sorry for what was apparently a false alarm.

No, thanks for all the testing.

> I did have a question about the some differences in filter_func in the
> newest (Mark's) version as compared to the original. While the two
> appear to be functionally the same, it appears to me that, in the new
> one, there may be cases where the filter is doing additional (and
> unnecessary) math. That is, there appear to be cases when the
> variables src and dst2 get calculated and not used, as well as cases
> where src gets calculated twice. The code is arguable cleaner than
> the original (less duplicate code), but possibly not as efficient(??).
> From what little I know of what's going on, that seems like a place
> were efficiency could be pretty important.

I hadn't thought of that. Yes, it could make a slight difference.

> I think that the newest
> version actually is using a bit more CPU than the original, though I'd
> have to switch back to be sure.

Which one is that: mythtv-0.21-field-order.6.patch or
mythtv-0.21-field-order-no-flicker.patch? Besides CPU usage, I'd expect
you to get identical results from those two.

> Thanks again to Paul and Mark for this one. Great stuff.

As I say, thanks for all the testing and feedback.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Hi

2009/4/8 Paul Gardiner <lists@glidos.net>:
> > Which one is that: mythtv-0.21-field-order.6.patch or
> mythtv-0.21-field-order-no-flicker.patch? Besides CPU usage, I'd expect you
> to get identical results from those two.

Where can I find this field-order no-flicker patch ?
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Hi

2009/4/8 Jean-Yves Avenard <jyavenard@gmail.com>:
>
> Where can I find this field-order no-flicker patch ?
>

Ooops, I see that you submitted it with the 6391 ticket.

Any chance that you will adapt those OSD fixes on your backport of Mark's patch
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Jean-Yves Avenard wrote:
> Hi
>
> 2009/4/8 Jean-Yves Avenard <jyavenard@gmail.com>:
>> Where can I find this field-order no-flicker patch ?
>>
>
> Ooops, I see that you submitted it with the 6391 ticket.
>
> Any chance that you will adapt those OSD fixes on your backport of Mark's patch

I believe You can take the backport of Mark's patch,
mythtv-0.21-field-order.6.patch, as is. The two things I fix in
mythtv-0.21-field-order-no-flicker.patch, Mark already fixed in what he
comitted to trunk. The no-flicker patch was just my playing catch up,
in case Tom continued to have problems with mythtv-0.21-field-order.6.patch.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Wed, Apr 8, 2009 at 5:30 AM, Paul Gardiner <lists@glidos.net> wrote:
> Jean-Yves Avenard wrote:
>>
>> Hi
>>
>> 2009/4/8 Jean-Yves Avenard <jyavenard@gmail.com>:
>>>
>>> Where can I find this field-order no-flicker patch ?
>>>
>>
>> Ooops, I see that you submitted it with the 6391 ticket.
>>
>> Any chance that you will adapt those OSD fixes on your backport of Mark's
>> patch
>
> I believe You can take the backport of Mark's patch,
> mythtv-0.21-field-order.6.patch, as is. The two things I fix in
> mythtv-0.21-field-order-no-flicker.patch, Mark already fixed in what he
> comitted to trunk. The no-flicker patch was just my playing catch up,
> in case Tom continued to have problems with mythtv-0.21-field-order.6.patch.
>
> Cheers,
>        Paul.
>

Believe it or not, I have an episode of Medium (NBC) from Monday night
that's not cooperating well with the deinterlacer (in this case the
mythtv-0.21-field-order.6.patch version). It the same thing I saw on
that ER episode. It's not so much tearing as odd, almost slightly
jerky motion...almost like when a show intensionally uses special
effects to create that sort of choppy/jumpy motion, but not that
pronounced.

This time my wife was able to see it for sure this time. I can almost
guarantee these issues are related to the manner in which NBC mixes
progressive frames into their 1080i stuff. If that's the case, I have
a feeling it will do the same with all versions of the
deinterlacer...unless for some reason, it only occurs only with that
OSD flicker fix. I saved the show and will try it with both other
versions when I get a chance. I'm unclear as to why it on;y seems to
happen with specific programs...perhaps it depends on the amount of
progressive frames.

It's an elusive issue though. You can see the odd motion plainly on
part of a show, but jump back to the same place and have it work
fine...really annoying. I also noticed that the show in general just
doesn't look that good...not as good as my 720p recordings and nowhere
near the 1080i stuff like, for example, PBS, which looks perfect.

Why can't NBC just send real 1080i like PBS instead of being such a
bunch of assholes...seriously. I'd almost rather they just go to
720p.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> On Wed, Apr 8, 2009 at 5:30 AM, Paul Gardiner <lists@glidos.net> wrote:
>> Jean-Yves Avenard wrote:
>>> Hi
>>>
>>> 2009/4/8 Jean-Yves Avenard <jyavenard@gmail.com>:
>>>> Where can I find this field-order no-flicker patch ?
>>>>
>>> Ooops, I see that you submitted it with the 6391 ticket.
>>>
>>> Any chance that you will adapt those OSD fixes on your backport of Mark's
>>> patch
>> I believe You can take the backport of Mark's patch,
>> mythtv-0.21-field-order.6.patch, as is. The two things I fix in
>> mythtv-0.21-field-order-no-flicker.patch, Mark already fixed in what he
>> comitted to trunk. The no-flicker patch was just my playing catch up,
>> in case Tom continued to have problems with mythtv-0.21-field-order.6.patch.
>>
>> Cheers,
>> Paul.
>>
>
> Believe it or not, I have an episode of Medium (NBC) from Monday night
> that's not cooperating well with the deinterlacer (in this case the
> mythtv-0.21-field-order.6.patch version). It the same thing I saw on
> that ER episode. It's not so much tearing as odd, almost slightly
> jerky motion...almost like when a show intensionally uses special
> effects to create that sort of choppy/jumpy motion, but not that
> pronounced.

Why Medium?! If they are going to mess things up, at least pick some
rubbishy program that no one will care about!! I've recently discovered
Medium. Watching the first series and loving it.

> This time my wife was able to see it for sure this time. I can almost
> guarantee these issues are related to the manner in which NBC mixes
> progressive frames into their 1080i stuff. If that's the case, I have
> a feeling it will do the same with all versions of the
> deinterlacer...unless for some reason, it only occurs only with that
> OSD flicker fix. I saved the show and will try it with both other
> versions when I get a chance. I'm unclear as to why it on;y seems to
> happen with specific programs...perhaps it depends on the amount of
> progressive frames.

Could it be that the content is just hard enough to decode that MythTv
is dropping a few frames. Interlaced x2 will look awful if frames are
being dropped. You'll sometimes see motion taking backward steps. I
guess another possibility is that the content truly has bad motion,
and the better resolution you are getting with Interlaced x2 is making
the problem show more than Bob does. Next episode, you could try your
commercial decoder.

> It's an elusive issue though. You can see the odd motion plainly on
> part of a show, but jump back to the same place and have it work
> fine...really annoying. I also noticed that the show in general just
> doesn't look that good...not as good as my 720p recordings and nowhere
> near the 1080i stuff like, for example, PBS, which looks perfect.

That does sound like they've done a bad conversion.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Thu, Apr 9, 2009 at 6:24 AM, Paul Gardiner <lists@glidos.net> wrote:
> Tom Dexter wrote:
>>
>>
>> Believe it or not, I have an episode of Medium (NBC) from Monday night
>> that's not cooperating well with the deinterlacer (in this case the
>> mythtv-0.21-field-order.6.patch version).  It the same thing I saw on
>> that ER episode.  It's not so much tearing as odd, almost slightly
>> jerky motion...almost like when a show intensionally uses special
>> effects to create that sort of choppy/jumpy motion, but not that
>> pronounced.
>
> Why Medium?! If they are going to mess things up, at least pick some
> rubbishy program that no one will care about!! I've recently discovered
> Medium. Watching the first series and loving it.
>
>> This time my wife was able to see it for sure this time.  I can almost
>> guarantee these issues are related to the manner in which NBC mixes
>> progressive frames into their 1080i stuff.  If that's the case, I have
>> a feeling it will do the same with all versions of the
>> deinterlacer...unless for some reason, it only occurs only with that
>> OSD flicker fix.  I saved the show and will try it with both other
>> versions when I get a chance.  I'm unclear as to why it on;y seems to
>> happen with specific programs...perhaps it depends on the amount of
>> progressive frames.
>
> Could it be that the content is just hard enough to decode that MythTv
> is dropping a few frames. Interlaced x2 will look awful if frames are
> being dropped. You'll sometimes see motion taking backward steps. I
> guess another possibility is that the content truly has bad motion,
> and the better resolution you are getting with Interlaced x2 is making
> the problem show more than Bob does. Next episode, you could try your
> commercial decoder.
>
>> It's an elusive issue though.  You can see the odd motion plainly on
>> part of a show, but jump back to the same place and have it work
>> fine...really annoying.  I also noticed that the show in general just
>> doesn't look that good...not as good as my 720p recordings and nowhere
>> near the 1080i stuff like, for example, PBS, which looks perfect.
>
> That does sound like they've done a bad conversion.
>
> Cheers,
>        Paul.
>

An update on my ongoing testing. Since it takes me over an hour to
compile, and the fact that I can't do it during evening TV watching
time :D, I'm a little limited as to when i can do this sort of stuff.

First of all, I noticed the same motion issues with my recording of
Law and Order: SVU from Tuesday...so I have more content to test with.

This morning I compiled with your original patch (the one without the
OSD flicker fix). Believe it or not, both shows look fine with
that...no problems at all. I even watched a good portion of Medium
over again to make sure.

Tomorrow morning I'm going to try again with the version of the
original patch that has to OSD flicker fix just to see if for some
reason that's related. I don't know if this means anything, but I
noticed something interesting. For me the OSD flickering (without the
fix for it) seems to primarily be an issue with content that has those
progressive frames mixed in...the same sort of content that tends to
cause the motion issues. Tonight my wife is watching Survivor, which
is in 1080i on CBS...but those sorts of shows (unlike dramas on NBC
and CBS) never have the progressive frames from what I've seen.
Interestingly, while watching that there's almost no noticeable OSD
flicker, even in the playback menu. That's still using the original
patch.

In any case this all would seem to rule out decoding or dropped frame
issues, as that's all been the same in both tests so far.

I'll post back tomorrow after more testing.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> An update on my ongoing testing. Since it takes me over an hour to
> compile, and the fact that I can't do it during evening TV watching
> time :D, I'm a little limited as to when i can do this sort of stuff.
>
> First of all, I noticed the same motion issues with my recording of
> Law and Order: SVU from Tuesday...so I have more content to test with.
>
> This morning I compiled with your original patch (the one without the
> OSD flicker fix). Believe it or not, both shows look fine with
> that...no problems at all. I even watched a good portion of Medium
> over again to make sure.

That's good news. If nothing else, at least this means you have a
solution. It also has to be very useful information for getting
to understand the problem.

> Tomorrow morning I'm going to try again with the version of the
> original patch that has to OSD flicker fix just to see if for some
> reason that's related.

Yeah, that would be a good test. I'd expect the problem to return
with that patch because, as far as I can tell, it does the same job
as Mark's verion. If the problem does return, one more change worth
trying is to change - in function "filter_func" - the inner condition
from

((y ^ tff) & 1) == 0

to

y & tff


The no-flicker patch actually has two alterations, one to remove the
flicker and the other to deal with bottom-field-first content. The
change I suggest above will retain the flicker fix, but revert the
bottom-field-first fix.

> I don't know if this means anything, but I
> noticed something interesting. For me the OSD flickering (without the
> fix for it) seems to primarily be an issue with content that has those
> progressive frames mixed in...the same sort of content that tends to
> cause the motion issues. Tonight my wife is watching Survivor, which
> is in 1080i on CBS...but those sorts of shows (unlike dramas on NBC
> and CBS) never have the progressive frames from what I've seen.
> Interestingly, while watching that there's almost no noticeable OSD
> flicker, even in the playback menu. That's still using the original
> patch.

That's interesting. That again may tell us a lot.

I find it hard to see the flicker problem sometimes. I wondered
whether it shows only when some movement in the picture causes your eyes
to scan the screen.

> In any case this all would seem to rule out decoding or dropped frame
> issues, as that's all been the same in both tests so far.

I guess it's still possible but unlikely: there's a small possibility
that the difference in efficiency of the two versions might be just
enough to cause frame dropping. Come to think of it, both Mark's and
my flicker fixed versions do 50% more memcpys than the non fixed one.

> I'll post back tomorrow after more testing.

Great. Hopefully we can get this sorted eventually.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Fri, Apr 10, 2009 at 6:50 AM, Paul Gardiner <lists@glidos.net> wrote:
> Tom Dexter wrote:
>>
>> An update on my ongoing testing.  Since it takes me over an hour to
>> compile, and the fact that I can't do it during evening TV watching
>> time :D, I'm a little limited as to when i can do this sort of stuff.
>>
>> First of all, I noticed the same motion issues with my recording of
>> Law and Order: SVU from Tuesday...so I have more content to test with.
>>
>> This morning I compiled with your original patch (the one without the
>> OSD flicker fix).  Believe it or not, both shows look fine with
>> that...no problems at all.  I even watched a good portion of Medium
>> over again to make sure.
>
> That's good news. If nothing else, at least this means you have a
> solution. It also has to be very useful information for getting
> to understand the problem.
>
>> Tomorrow morning I'm going to try again with the version of the
>> original patch that has to OSD flicker fix just to see if for some
>> reason that's related.
>
> Yeah, that would be a good test. I'd expect the problem to return
> with that patch because, as far as I can tell, it does the same job
> as Mark's verion. If the problem does return, one more change worth
> trying is to change - in function "filter_func" - the inner condition
> from
>
> ((y ^ tff) & 1) == 0
>
> to
>
> y & tff
>
>
> The no-flicker patch actually has two alterations, one to remove the
> flicker and the other to deal with bottom-field-first content. The
> change I suggest above will retain the flicker fix, but revert the
> bottom-field-first fix.
>

Yup...it looks as though the bottom-field-first fix is causing it.

My first test today was using the version of the original patch with
both the OSD flicker and bottom-field-first fixes. The problem was
there for sure. One of the clear signs of this issue shows up not
necessarily with significant motion (the kind where you'd notice
tearing), but for example, with people talking...not an audio/video
sync problem, but rather an almost animated look when people are
talking...extremely unnerving and unnatural looking when it happens.

However with the bottom-field-first fix removed as per your above
change, everything's fine.

So it appears that that fix, in conjunction with some 1080i content
that has progressive frames mixed in (NBC stuff specifically) is
causing this.

Interestingly though, I've yet to have any similar problems with CBS
shows, and they tend to do the same...though possibly less. One
difference between NBC dramas and CBS though is that NBC also uses
different frame rates for commercials. That's what causes the issue
where the OSD will show a one hour show was, say, 51 minutes...because
myth is assuming a constant frame rate when calculating the length. I
wonder if that's in any way related.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Sun, Mar 29, 2009 at 2:58 PM, Paul Gardiner <lists@glidos.net> wrote:

> I think I've just sussed what is causing this. The deinterlacer gets
> given each frame twice. Each time it overwrites the bottom field,
> but leaves the top field unchanged. After each call the OSD will
> be rendered over the frame. The fact that I don't update the
> top field in the second call to the deinterlacer means the OSD gets
> rendered over the top of a previous rendering. That doesn't matter
> for a solid OSD, but if translucent the top field will be
> darker than the bottom.
>
> Should be easy to fix:
>
> Change
>
>   if (y & tff)
>   {
>       if(parity)
>       {
>           /* Second call: put back the second field to its previous state */
>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
> &p->ref[nr_c][i][y*refs], w);
>       }
>       else
>       {
>           /* First call: replace second field by that of the previous frame
> */
>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
> &p->ref[nr_p][i][y*refs], w);
>       }
>   }
>
> to
>   if(parity)
>   {
>       /* Second call: put back the whole frame to its previous state.
>        * Although we have not altered first field, we need to overwrite
>        * it because the OSD will have been rendered to the copy passed
>        * in. */
>       memcpy(dst + dst_offsets[i] + y*dst_stride[i],
> &p->ref[nr_c][i][y*refs], w);
>   }
>   else
>   {
>       /* First call: replace second field by that of the previous frame */
>       if (y & tff)
>       {
>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
> &p->ref[nr_p][i][y*refs], w);
>       }
>   }
>

Paul...a quick question about this OSD flicker fix. Can you think of
any reason that this fix could affect overall clarity of 1080i in any
way? I'm probably just getting cross-eyed from all this testing :D,
but I almost thought the version without this fix may have been
slightly clearer. It's too bad I have no way to test one right after
the other...I can only switch after a one hour re-compile.

Just curious. If there is in fact any difference it's extremely
subtle, and may be only with those NBC shows.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Fri, Apr 10, 2009 at 1:52 PM, Tom Dexter <digitalaudiorock@gmail.com> wrote:
> On Sun, Mar 29, 2009 at 2:58 PM, Paul Gardiner <lists@glidos.net> wrote:
>
>> I think I've just sussed what is causing this. The deinterlacer gets
>> given each frame twice. Each time it overwrites the bottom field,
>> but leaves the top field unchanged. After each call the OSD will
>> be rendered over the frame. The fact that I don't update the
>> top field in the second call to the deinterlacer means the OSD gets
>> rendered over the top of a previous rendering. That doesn't matter
>> for a solid OSD, but if translucent the top field will be
>> darker than the bottom.
>>
>> Should be easy to fix:
>>
>> Change
>>
>>   if (y & tff)
>>   {
>>       if(parity)
>>       {
>>           /* Second call: put back the second field to its previous state */
>>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>> &p->ref[nr_c][i][y*refs], w);
>>       }
>>       else
>>       {
>>           /* First call: replace second field by that of the previous frame
>> */
>>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>> &p->ref[nr_p][i][y*refs], w);
>>       }
>>   }
>>
>> to
>>   if(parity)
>>   {
>>       /* Second call: put back the whole frame to its previous state.
>>        * Although we have not altered first field, we need to overwrite
>>        * it because the OSD will have been rendered to the copy passed
>>        * in. */
>>       memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>> &p->ref[nr_c][i][y*refs], w);
>>   }
>>   else
>>   {
>>       /* First call: replace second field by that of the previous frame */
>>       if (y & tff)
>>       {
>>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>> &p->ref[nr_p][i][y*refs], w);
>>       }
>>   }
>>
>
> Paul...a quick question about this OSD flicker fix.  Can you think of
> any reason that this fix could affect overall clarity of 1080i in any
> way?  I'm probably just getting cross-eyed from all this testing :D,
> but I almost thought the version without this fix may have been
> slightly clearer.  It's too bad I have no way to test one right after
> the other...I can only switch after a one hour re-compile.
>
> Just curious.  If there is in fact any difference it's extremely
> subtle, and may be only with those NBC shows.
>
> Tom
>

Never mind on that one. After watching several shows in proper
lighting etc (using the original patch with the OSD flicker fix but
not the bottom-field-first fix), everything looks really
spectacular...even the Law and Order SVU that was one of the problem
recordings.

That bottom-field-first change, for whatever reason, really was
causing problems with those NBC shows.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> On Fri, Apr 10, 2009 at 1:52 PM, Tom Dexter <digitalaudiorock@gmail.com> wrote:
>> On Sun, Mar 29, 2009 at 2:58 PM, Paul Gardiner <lists@glidos.net> wrote:
>>
>>> I think I've just sussed what is causing this. The deinterlacer gets
>>> given each frame twice. Each time it overwrites the bottom field,
>>> but leaves the top field unchanged. After each call the OSD will
>>> be rendered over the frame. The fact that I don't update the
>>> top field in the second call to the deinterlacer means the OSD gets
>>> rendered over the top of a previous rendering. That doesn't matter
>>> for a solid OSD, but if translucent the top field will be
>>> darker than the bottom.
>>>
>>> Should be easy to fix:
>>>
>>> Change
>>>
>>> if (y & tff)
>>> {
>>> if(parity)
>>> {
>>> /* Second call: put back the second field to its previous state */
>>> memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>>> &p->ref[nr_c][i][y*refs], w);
>>> }
>>> else
>>> {
>>> /* First call: replace second field by that of the previous frame
>>> */
>>> memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>>> &p->ref[nr_p][i][y*refs], w);
>>> }
>>> }
>>>
>>> to
>>> if(parity)
>>> {
>>> /* Second call: put back the whole frame to its previous state.
>>> * Although we have not altered first field, we need to overwrite
>>> * it because the OSD will have been rendered to the copy passed
>>> * in. */
>>> memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>>> &p->ref[nr_c][i][y*refs], w);
>>> }
>>> else
>>> {
>>> /* First call: replace second field by that of the previous frame */
>>> if (y & tff)
>>> {
>>> memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>>> &p->ref[nr_p][i][y*refs], w);
>>> }
>>> }
>>>
>> Paul...a quick question about this OSD flicker fix. Can you think of
>> any reason that this fix could affect overall clarity of 1080i in any
>> way? I'm probably just getting cross-eyed from all this testing :D,
>> but I almost thought the version without this fix may have been
>> slightly clearer. It's too bad I have no way to test one right after
>> the other...I can only switch after a one hour re-compile.
>>
>> Just curious. If there is in fact any difference it's extremely
>> subtle, and may be only with those NBC shows.
>>
>> Tom
>>
>
> Never mind on that one. After watching several shows in proper
> lighting etc (using the original patch with the OSD flicker fix but
> not the bottom-field-first fix), everything looks really
> spectacular...even the Law and Order SVU that was one of the problem
> recordings.
>
> That bottom-field-first change, for whatever reason, really was
> causing problems with those NBC shows.

Thanks. That's useful to know. Not sure of the solution. Theoretically
the bottom-field-first change is an improvement, and certain types
of content would not display correctly without it. Funny isn't it?!
I used the test "y & tff" in my version by mistake. I always intended
Mark's logic. Lucky mistake in this instance!

One more version worth trying if you at some stage have the time:

where you replaced

((y ^ tff) & 1) == 0

by

y & tff

could you try

(y & 1) != 0

?


First version is "apply algorithm correctly for all frame types"

Second is "apply algorithm only for top-field-first frames"

Third is "always apply algorithm, but assume top-field-first
even if flag says otherwise"

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Sun, Apr 12, 2009 at 8:33 AM, Paul Gardiner <lists@glidos.net> wrote:
> Tom Dexter wrote:
>>
>> That bottom-field-first change, for whatever reason, really was
>> causing problems with those NBC shows.
>
> Thanks. That's useful to know. Not sure of the solution. Theoretically
> the bottom-field-first change is an improvement, and certain types
> of content would not display correctly without it. Funny isn't it?!
> I used the test "y & tff" in my version by mistake. I always intended
> Mark's logic. Lucky mistake in this instance!
>
> One more version worth trying if you at some stage have the time:
>
> where you replaced
>
>   ((y ^ tff) & 1) == 0
>
> by
>
>   y & tff
>
> could you try
>
>   (y & 1) != 0
>
> ?
>
>
> First version is "apply algorithm correctly for all frame types"
>
> Second is "apply algorithm only for top-field-first frames"
>
> Third is "always apply algorithm, but assume top-field-first
> even if flag says otherwise"
>
> Cheers,
>        Paul.
>

OK...now I think we're getting somewhere. I tried your change above
and everything looked good. That got me thinking this: Perhaps the
top_field_first is just defaulting to 0 for those progressive frames
NBC is mixing into the content. Am I correct that that property
doesn't really even apply to interlaced frames? In any case, it
occurred to me that those may need to be treated like top field first
interlaced frames to look correct.

To test that I took the newest 0.21 modified version of Marks patch
(mythtv-0.21-field-order.6.patch), and simply changed the tff field
being passed to filter_func to this:

filter_func(
filter, frame->buf, frame->offsets, frame->pitches,
frame->width, frame->height, dirty, frame->top_field_first |
!frame->interlaced_frame,
dirty);

...and so far, everything looks flawless. I'm not sure that this is
always the desired behavior or not, as I really don't understand
anything about the ramifications of progressive frames in interlaced
content. However, if your broadcasters never mixes progressive frames
into interlaced content, this change will have no affect at all.

Let me know what you think. I'll leave that version installed and see
how things go, but so far it seems great.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> On Sun, Apr 12, 2009 at 8:33 AM, Paul Gardiner <lists@glidos.net> wrote:
>> Tom Dexter wrote:
>>> That bottom-field-first change, for whatever reason, really was
>>> causing problems with those NBC shows.
>> Thanks. That's useful to know. Not sure of the solution. Theoretically
>> the bottom-field-first change is an improvement, and certain types
>> of content would not display correctly without it. Funny isn't it?!
>> I used the test "y & tff" in my version by mistake. I always intended
>> Mark's logic. Lucky mistake in this instance!
>>
>> One more version worth trying if you at some stage have the time:
>>
>> where you replaced
>>
>> ((y ^ tff) & 1) == 0
>>
>> by
>>
>> y & tff
>>
>> could you try
>>
>> (y & 1) != 0
>>
>> ?
>>
>>
>> First version is "apply algorithm correctly for all frame types"
>>
>> Second is "apply algorithm only for top-field-first frames"
>>
>> Third is "always apply algorithm, but assume top-field-first
>> even if flag says otherwise"
>>
>> Cheers,
>> Paul.
>>
>
> OK...now I think we're getting somewhere. I tried your change above
> and everything looked good. That got me thinking this: Perhaps the
> top_field_first is just defaulting to 0 for those progressive frames
> NBC is mixing into the content. Am I correct that that property
> doesn't really even apply to interlaced frames? In any case, it
> occurred to me that those may need to be treated like top field first
> interlaced frames to look correct.
>
> To test that I took the newest 0.21 modified version of Marks patch
> (mythtv-0.21-field-order.6.patch), and simply changed the tff field
> being passed to filter_func to this:
>
> filter_func(
> filter, frame->buf, frame->offsets, frame->pitches,
> frame->width, frame->height, dirty, frame->top_field_first |
> !frame->interlaced_frame,
> dirty);
>
> ...and so far, everything looks flawless. I'm not sure that this is
> always the desired behavior or not, as I really don't understand
> anything about the ramifications of progressive frames in interlaced
> content. However, if your broadcasters never mixes progressive frames
> into interlaced content, this change will have no affect at all.
>
> Let me know what you think. I'll leave that version installed and see
> how things go, but so far it seems great.

That's brilliant. It gives us a fix that work with Mark's correction.
The one potential problem is it might not work with a mixture of
bottom-field-first, interlaced frames and progressive frames. It might
be worth trying

filter_func(
filter, frame->buf, frame->offsets, frame->pitches,
frame->width, frame->height, dirty |
!frame->interlaced_frame, frame->top_field_first,
dirty);

instead. That will cause progressive frames to be unaltered, the
only process of them being that needed to overwrite the OSD in
the dirty case (assuming I have my reasoning correct).

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Mon, Apr 13, 2009 at 5:16 AM, Paul Gardiner <lists@glidos.net> wrote:
> Tom Dexter wrote:
>>
>> On Sun, Apr 12, 2009 at 8:33 AM, Paul Gardiner <lists@glidos.net> wrote:
>>>
>>> Tom Dexter wrote:
>>>>
>>>> That bottom-field-first change, for whatever reason, really was
>>>> causing problems with those NBC shows.
>>>
>>> Thanks. That's useful to know. Not sure of the solution. Theoretically
>>> the bottom-field-first change is an improvement, and certain types
>>> of content would not display correctly without it. Funny isn't it?!
>>> I used the test "y & tff" in my version by mistake. I always intended
>>> Mark's logic. Lucky mistake in this instance!
>>>
>>> One more version worth trying if you at some stage have the time:
>>>
>>> where you replaced
>>>
>>>  ((y ^ tff) & 1) == 0
>>>
>>> by
>>>
>>>  y & tff
>>>
>>> could you try
>>>
>>>  (y & 1) != 0
>>>
>>> ?
>>>
>>>
>>> First version is "apply algorithm correctly for all frame types"
>>>
>>> Second is "apply algorithm only for top-field-first frames"
>>>
>>> Third is "always apply algorithm, but assume top-field-first
>>> even if flag says otherwise"
>>>
>>> Cheers,
>>>       Paul.
>>>
>>
>> OK...now I think we're getting somewhere.  I tried your change above
>> and everything looked good.  That got me thinking this:  Perhaps the
>> top_field_first is just defaulting to 0 for those progressive frames
>> NBC is mixing into the content.  Am I correct that that property
>> doesn't really even apply to interlaced frames?  In any case, it
>> occurred to me that those may need to be treated like top field first
>> interlaced frames to look correct.
>>
>> To test that I took the newest 0.21 modified version of Marks patch
>> (mythtv-0.21-field-order.6.patch), and simply changed the tff field
>> being passed to filter_func to this:
>>
>>    filter_func(
>>        filter, frame->buf, frame->offsets, frame->pitches,
>>        frame->width, frame->height, dirty, frame->top_field_first |
>> !frame->interlaced_frame,
>>        dirty);
>>
>> ...and so far, everything looks flawless.  I'm not sure that this is
>> always the desired behavior or not, as I really don't understand
>> anything about the ramifications of progressive frames in interlaced
>> content.  However, if your broadcasters never mixes progressive frames
>> into interlaced content, this change will have no affect at all.
>>
>> Let me know what you think.  I'll leave that version installed and see
>> how things go, but so far it seems great.
>
> That's brilliant. It gives us a fix that work with Mark's correction.
> The one potential problem is it might not work with a mixture of
> bottom-field-first, interlaced frames and progressive frames. It might
> be worth trying
>
>    filter_func(
>        filter, frame->buf, frame->offsets, frame->pitches,
>        frame->width, frame->height, dirty |
> !frame->interlaced_frame, frame->top_field_first,
>        dirty);
>
> instead. That will cause progressive frames to be unaltered, the
> only process of them being that needed to overwrite the OSD in
> the dirty case (assuming I have my reasoning correct).
>
> Cheers,
>        Paul.

With the change as I have it now, bottom field first and top field
first interlaced frames would be treated just like they were, and
progressive frames would be treated as top field first. Are you
saying that could cause a problem?

I'll try your change when I get a chance. Just to be clear...you're
change is forcing the parity parameter in filter_func (the parameter
that's fed by the 'field' variable in the trunk version) to one for
non-interlaced frames...correct?

That does sound interesting though...I'd think that leaving
progressive frames unaltered should be the ideal approach.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> With the change as I have it now, bottom field first and top field
> first interlaced frames would be treated just like they were, and
> progressive frames would be treated as top field first. Are you
> saying that could cause a problem?

Yeah, I think it might not work for a transmission that was mostly
bottom-field-first frames, with a few progressive ones thrown in,
because the progessive frames would be treated the opposite way to
the rest, which is what gave you bad motion before your change.

> I'll try your change when I get a chance. Just to be clear...you're
> change is forcing the parity parameter in filter_func (the parameter
> that's fed by the 'field' variable in the trunk version) to one for
> non-interlaced frames...correct?

That's right. Setting the field variable to 1 causes the function
to use the current frame rather than the previous, which is what
I think we want for progressive frames.

> That does sound interesting though...I'd think that leaving
> progressive frames unaltered should be the ideal approach.

Yeah, that's exactly what I'm thinking.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Mon, Apr 13, 2009 at 10:32 AM, Paul Gardiner <lists@glidos.net> wrote:
> Tom Dexter wrote:
>>
>> With the change as I have it now, bottom field first and top field
>> first interlaced frames would be treated just like they were, and
>> progressive frames would be treated as top field first.  Are you
>> saying that could cause a problem?
>
> Yeah, I think it might not work for a transmission that was mostly
> bottom-field-first frames, with a few progressive ones thrown in,
> because the progessive frames would be treated the opposite way to
> the rest, which is what gave you bad motion before your change.
>
>> I'll try your change when I get a chance.  Just to be clear...you're
>> change is forcing the parity parameter in filter_func (the parameter
>> that's fed by the 'field' variable in the trunk version) to one for
>> non-interlaced frames...correct?
>
> That's right. Setting the field variable to 1 causes the function
> to use the current frame rather than the previous, which is what
> I think we want for progressive frames.
>
>> That does sound interesting though...I'd think that leaving
>> progressive frames unaltered should be the ideal approach.
>
> Yeah, that's exactly what I'm thinking.
>
> Cheers,
>        Paul.
>

OK...I've tested that new change with the 'parity' parameter
defaulting to 1 for non-interlaces frames and everything looks great.
That definitely seems to be the way to go.

One small cosmetic thing I've noticed, and I believe it's been the
case with all versions: When I have OSD fade enabled and there's any
situation where more than one thing displays via the OSD at a time,
the fade caused some video stuttering. One place I tend to see it is
if I save my place in the recording...that displays the message saying
the position has been saved in addition to displaying the progress
bar. When those fade it tends to stutter a bit. I also get a CPU
spike when that happens. This never occurs with any single OSD
overlay, and also doesn't happen if I disable fading.

Very minor for sure. I see that it doesn't happen with bob x2.

By the way, I took the time to do some comparisons between this
deinterlacer and bob x2 that I was using before. Wow...the difference
is _not_ subtle at all. This thing has definitely cured the one major
flaw I've lived with since I built the system two years ago. Great
stuff.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Pardon my ignorance on this...

Is this at all useful if I have a 1080p display and am using hdmi?

I am assuming that this will not work with VDPAU, is this correct?

Cheers

Phil
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Phil Wild wrote:
> Pardon my ignorance on this...
>
> Is this at all useful if I have a 1080p display and am using hdmi?
>
> I am assuming that this will not work with VDPAU, is this correct?

It is possibly useful if your 1080p display will accept 1080i and
has it's own high quality deinterlacer. But as you say it wont work
with VDPAU (as far as I know), and hence even if you did get a slight
improvement in image quality, it may not be worth it for the CPU
usage. And you would get an improvement only if the displays
deinterlacer is better than the VDPAU ones.

For people using a 1080i capable display but not using VDPAU, yes
worth a try.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> OK...I've tested that new change with the 'parity' parameter
> defaulting to 1 for non-interlaces frames and everything looks great.
> That definitely seems to be the way to go.

Great news. I think we can go with that version. One of us should
upload a patch. Shall I, or do you want to?

> One small cosmetic thing I've noticed, and I believe it's been the
> case with all versions: When I have OSD fade enabled and there's any
> situation where more than one thing displays via the OSD at a time,
> the fade caused some video stuttering. One place I tend to see it is
> if I save my place in the recording...that displays the message saying
> the position has been saved in addition to displaying the progress
> bar. When those fade it tends to stutter a bit. I also get a CPU
> spike when that happens. This never occurs with any single OSD
> overlay, and also doesn't happen if I disable fading.
>
> Very minor for sure. I see that it doesn't happen with bob x2.

That's probably not surprising. I think with bob the OSD is rendered
to Bob's halfheight buffer. Everything's a lot cheaper with bob.
You might find the same stutter with yadif. There is some room for
speeding up field order using faster memcpy. Perhaps should look at
that sometime.

> By the way, I took the time to do some comparisons between this
> deinterlacer and bob x2 that I was using before. Wow...the difference
> is _not_ subtle at all. This thing has definitely cured the one major
> flaw I've lived with since I built the system two years ago. Great
> stuff.

I'm still sometimes seeing slight strangeness in motion. And sometimes
I think I prefer yadif. Certainly rolling text credits show that field
order is doing exactly what it should, but I wonder whether there are
periods in normal playback where the mpeg decode is complex, which
leads to the sync changing rappidly. yadif may cope with that better.
The other possibility I can think of is that the slight blurring due
to yadif is sometimes beneficial.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Wed, Apr 15, 2009 at 5:24 AM, Paul Gardiner <lists@glidos.net> wrote:
> Tom Dexter wrote:
>>
>> OK...I've tested that new change with the 'parity' parameter
>> defaulting to 1 for non-interlaces frames and everything looks great.
>> That definitely seems to be the way to go.
>
> Great news. I think we can go with that version. One of us should
> upload a patch. Shall I, or do you want to?

I just uploaded new versions of both patches with that change.

>
>> One small cosmetic thing I've noticed, and I believe it's been the
>> case with all versions:  When I have OSD fade enabled and there's any
>> situation where more than one thing displays via the OSD at a time,
>> the fade caused some video stuttering.  One place I tend to see it is
>> if I save my place in the recording...that displays the message saying
>> the position has been saved in addition to displaying the progress
>> bar.  When those fade it tends to stutter a bit.  I also get a CPU
>> spike when that happens.  This never occurs with any single OSD
>> overlay, and also doesn't happen if I disable fading.
>>
>> Very minor for sure.  I see that it doesn't happen with bob x2.
>
> That's probably not surprising. I think with bob the OSD is rendered
> to Bob's halfheight buffer. Everything's a lot cheaper with bob.
> You might find the same stutter with yadif. There is some room for
> speeding up field order using faster memcpy. Perhaps should look at
> that sometime.
>

Yea, from what I'm seeing I think that multiple OSD layers trying to
fade is simply maxing out the CPU momentarily. Not surprising. I'd
never even heard of using a faster memcpy. I'm running under Gentoo
specifically compiled for P4...I'm not sure if there's any such thing
available or not. Is that generally a change to glibc or something?

>> By the way, I took the time to do some comparisons between this
>> deinterlacer and bob x2 that I was using before.  Wow...the difference
>> is _not_ subtle at all.  This thing has definitely cured the one major
>> flaw I've lived with since I built the system two years ago.  Great
>> stuff.
>
> I'm still sometimes seeing slight strangeness in motion. And sometimes
> I think I prefer yadif. Certainly rolling text credits show that field
> order is doing exactly what it should, but I wonder whether there are
> periods in normal playback where the mpeg decode is complex, which
> leads to the sync changing rappidly. yadif may cope with that better.
> The other possibility I can think of is that the slight blurring due
> to yadif is sometimes beneficial.
>
> Cheers,
>        Paul.
>

It's been much better than anything I've used. From what I remember,
I don't think my frontend will run yadif. It's a 3Ghz P4.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> On Wed, Apr 15, 2009 at 5:24 AM, Paul Gardiner <lists@glidos.net> wrote:
>> Tom Dexter wrote:
>>> OK...I've tested that new change with the 'parity' parameter
>>> defaulting to 1 for non-interlaces frames and everything looks great.
>>> That definitely seems to be the way to go.
>> Great news. I think we can go with that version. One of us should
>> upload a patch. Shall I, or do you want to?
>
> I just uploaded new versions of both patches with that change.

Yeah, saw those go up. Looks great.

>>> One small cosmetic thing I've noticed, and I believe it's been the
>>> case with all versions: When I have OSD fade enabled and there's any
>>> situation where more than one thing displays via the OSD at a time,
>>> the fade caused some video stuttering. One place I tend to see it is
>>> if I save my place in the recording...that displays the message saying
>>> the position has been saved in addition to displaying the progress
>>> bar. When those fade it tends to stutter a bit. I also get a CPU
>>> spike when that happens. This never occurs with any single OSD
>>> overlay, and also doesn't happen if I disable fading.
>>>
>>> Very minor for sure. I see that it doesn't happen with bob x2.
>> That's probably not surprising. I think with bob the OSD is rendered
>> to Bob's halfheight buffer. Everything's a lot cheaper with bob.
>> You might find the same stutter with yadif. There is some room for
>> speeding up field order using faster memcpy. Perhaps should look at
>> that sometime.
>>
>
> Yea, from what I'm seeing I think that multiple OSD layers trying to
> fade is simply maxing out the CPU momentarily. Not surprising. I'd
> never even heard of using a faster memcpy. I'm running under Gentoo
> specifically compiled for P4...I'm not sure if there's any such thing
> available or not. Is that generally a change to glibc or something?

If you have a look at yadif, you can see it's use of aclib, although
from what I can see it's disabled by a final assignment to standard
memcpy. Because it looked disabled, I didn't dare try using it in
the field order deinterlacer.

>>> By the way, I took the time to do some comparisons between this
>>> deinterlacer and bob x2 that I was using before. Wow...the difference
>>> is _not_ subtle at all. This thing has definitely cured the one major
>>> flaw I've lived with since I built the system two years ago. Great
>>> stuff.
>> I'm still sometimes seeing slight strangeness in motion. And sometimes
>> I think I prefer yadif. Certainly rolling text credits show that field
>> order is doing exactly what it should, but I wonder whether there are
>> periods in normal playback where the mpeg decode is complex, which
>> leads to the sync changing rappidly. yadif may cope with that better.
>> The other possibility I can think of is that the slight blurring due
>> to yadif is sometimes beneficial.
>>
>> Cheers,
>> Paul.
>>
>
> It's been much better than anything I've used. From what I remember,
> I don't think my frontend will run yadif. It's a 3Ghz P4.

The few oddities I am seeing may be down to the deinterlacer in my TV.
Although it's a CRT TV, it's 100Hz capable, and from what I can tell
deinterlaces and reintlaces even when told to do normal scan. I think
a bit of motion blur can help it out sometimes.

P.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Thu, Mar 26, 2009 at 8:26 AM, Paul Gardiner <lists@glidos.net> wrote:
> I've just created a patch that provides a deinterlacer for perfect image
> quality and motion smoothness when using an interlaced display mode that
> exactly matches the video source. See Ticket #6391. The deinterlacer comes
> up in the menus as "Interlaced x2". It is also known as field order.
>
>
> Preconditions of use
> ~~~~~~~~~~~~~~~~~~~~
> You need a graphics chip that can output interlaced display modes correctly.
>
> The display mode must be interlaced exactly matching the video source.
>
> No scaling can be used: don't use scaling to reduce overscan.
>
> Video playback must be full speed, not sped up or slowed down.
>
> The deinterlacer is a doublerate one, so you may need the patch from
> Ticket #2903 before MythTv will allow you to use it.
>

I discovered today that the 0.21-fixes version of the bug 2903 patch
didn't work correctly, as I've explained in the additional comments.
My refresh rate of 30.0267 was failing that test and thus not getting
doubled when I used this version of the patch.

However here's what really confuses me: When I attempted to watch
recorded 1080i content, it was rejected the fieldorder deinterlacer
(as you'd expect with the above check) and therefor using none.
However...when I watched 1080i LiveTV, for some reason it was allowing
the fieldorder deinterlacer, but was completely whacked out. I think
perhaps it may have been trying to use it without treating it as line
doubling deinterlacer, though there's a lot going on there I'm not
familiar with at all. In any case, that was the cause of the
nightmare I went through trying to upgrade to a newer rev of fixes as
described here:

http://www.gossamer-threads.com/lists/mythtv/users/381923

I didn't realize when I posted that that pre-recorded 1080i was using
no deinterlacing at all, which was why it didn't encounter those
errors. With LiveTV it never thought the video had caught up.

Again, I'm very unclear on exactly what that did...but LiveTV was
allowing the fieldorder deinterlacer even when the 2903 patch wasn't
correctly doubling the rate, and the results were pretty ugly.

Once I got that patch corrected, rev 20500 is working perfectly for me.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Hi

2009/5/12 Tom Dexter <digitalaudiorock@gmail.com>:
> I discovered today that the 0.21-fixes version of the bug 2903 patch
> didn't work correctly, as I've explained in the additional comments.
> My refresh rate of 30.0267 was failing that test and thus not getting
> doubled when I used this version of the patch.

Note that the patches found in my ubuntu packages are using a patch
that do work.
It's similar to yours.

I had posted it on my site a while ago.

The previous patch would only work with exactly 50Hz or 60Hz no 50.02
for example which can happen

> http://www.gossamer-threads.com/lists/mythtv/users/381923

Jean-Yves
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Tom Dexter wrote:
> I discovered today that the 0.21-fixes version of the bug 2903 patch
> didn't work correctly, as I've explained in the additional comments.
> My refresh rate of 30.0267 was failing that test and thus not getting
> doubled when I used this version of the patch.
>
> However here's what really confuses me: When I attempted to watch
> recorded 1080i content, it was rejected the fieldorder deinterlacer
> (as you'd expect with the above check) and therefor using none.
> However...when I watched 1080i LiveTV, for some reason it was allowing
> the fieldorder deinterlacer, but was completely whacked out. I think
> perhaps it may have been trying to use it without treating it as line
> doubling deinterlacer, though there's a lot going on there I'm not
> familiar with at all.

Yes I've seen that too. If a rate-doubling deinterlacer is rejected on
the basis of insufficient display framerate then it is properly rejected for
the playback of recordings. But for playback of live TV, the
deinterlacer still gets used in a way that makes playback unwatchably
jerky; my guess is that, although the deinterlacer is used, the
framerate isn't doubled.

P.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users