Mailing List Archive

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