Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ivtv: devel

PVR 350 flicker & temporal filter patch - Needs testing

 

 

ivtv devel RSS feed   Index | Next | Previous | View Threaded


mail01 at iarmst

Feb 26, 2010, 7:33 PM

Post #1 of 10 (4010 views)
Permalink
PVR 350 flicker & temporal filter patch - Needs testing

I have a patch here that requires additional testing. It's aimed at the PVR350
and appears to fix the annoying flicker that can sometimes occur during
capture. It also fixes the ghosting that occurs with the temporal filter. Both
problems share the same trigger, but the ghosting is the more common symptom.
The main fix is a single additional firmware call in ivtv-streams.c when
closing the last capture stream. The second change is for cx2341x.c, but is
simply to re-enable the temporal filter which is partially disabled in the
current release (and contrary to the comment, ghosting can occur with a full
res capture).

This patch was generated against kernel 2.6.32

--
Ian
Attachments: ivtv-flicker.patch (1.34 KB)


f-myth-users at media

Feb 26, 2010, 8:42 PM

Post #2 of 10 (3881 views)
Permalink
PVR 350 flicker & temporal filter patch - Needs testing [In reply to]

Is this fix likely to matter for 250's as well?

I no longer use my 350 for capture for various reasons (though I do
still use it for display), but some maybe 5%? 1%? of my 250 captures
display ghosting---sometimes slight, sometimes pretty objectionable.
In some captures, it persists for the entire capture; in others, I
can see a visible one-frame flash and -then- the rest of the capture
is ghosted until the stream is closed. Typically there are faint
vertical black/gray bands as well, most-obviously if the source is
letterboxed because they show up against the uniform background;
typically three are 3-5 of them across the width of the screen.

The ghosting typically manifests as the image contents (or perhaps
just edges, e.g., the derivative of the image) shifted sideways about
1/4 of the width of the screen or so. Really does look for all the
world like the typical multipath ghost from RF days.

I'm still running 0.4.1 on those (because of various chicken & egg
issues that would have required me to update absolutely -everything-
on the box to move forward to modern ivtv and modern MythTV---I'm
capturing with MythTV 0.18.1), but sometime soon I expect to have
a clone system set up to do testing using bleeding-edge everything
and could test then. (I also expect at some point to have a second
350 available for testing, and I could try capturing on that.)

Of course, maybe 250 ghosting was fixed in the years since 0.4.1
and it'll go away on its own once I'm able to upgrade. Dunno.

Note that all of this is baseband capture from an STB, since I no
longer have any sources of RF analog available. (Well, I guess I
might have a VCR or DVD player with RF channel 3/4 output.)

P.S. I -do- recall an obnoxious flickering of the upper 1/4 of the
screen that was often provoked by a loss of sync on the input---that
was in the days when I took RF directly from a cable, and one of our
local PBS stations had a tendency to transmit badly-corrupted bursts
of video (also really badly overmodulated, so much so that white areas
caused audio buzzing) a few times a day. I don't know offhand if it
-only- manifested on 350 capture, and I rather suspect not. (I could
possibly research it if it mattered, based on my records.) I haven't
seen it in quite some time, but I don't know if it's because I stopped
capturing on my 350 or because I switched to STB-only sources; the two
happened at pretty much the same time, I think.

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


mail01 at iarmst

Feb 27, 2010, 2:51 AM

Post #3 of 10 (3869 views)
Permalink
Re: PVR 350 flicker & temporal filter patch - Needs testing [In reply to]

On Saturday 27 February 2010, f-myth-users [at] media wrote:
> Is this fix likely to matter for 250's as well?

Possibly. I haven't tested it, but the patch doesn't check the card type.

> I no longer use my 350 for capture for various reasons (though I do
> still use it for display), but some maybe 5%? 1%? of my 250 captures
> display ghosting---sometimes slight, sometimes pretty objectionable.
> In some captures, it persists for the entire capture; in others, I
> can see a visible one-frame flash and -then- the rest of the capture
> is ghosted until the stream is closed. Typically there are faint
> vertical black/gray bands as well, most-obviously if the source is
> letterboxed because they show up against the uniform background;
> typically three are 3-5 of them across the width of the screen.
>
> The ghosting typically manifests as the image contents (or perhaps
> just edges, e.g., the derivative of the image) shifted sideways about
> 1/4 of the width of the screen or so. Really does look for all the
> world like the typical multipath ghost from RF days.

The type of ghosting you describe is what this hopefully stops, but only when
it persists for the entire recording. This ghosting affects all sources, not
just the tuner.

You can easily check for it by setting the temporal filter to 31. For current
drivers this can be done by running 'v4l2-ctl --set-ctrl=temporal_filter=31'
(btw the normal value is 8 - Be sure to reset it to avoid screwed up
recordings)

With a full res capture it should only suffer motion blur. If the glitch has
been triggered it will produce a weird effect with a trail of images across
the screen. (It must be a full res capture, as the temporal filter was
partially disabled a few years ago due to the ghosting issues).

> P.S. I -do- recall an obnoxious flickering of the upper 1/4 of the
> screen that was often provoked by a loss of sync on the input---that
> was in the days when I took RF directly from a cable, and one of our
> local PBS stations had a tendency to transmit badly-corrupted bursts
> of video (also really badly overmodulated, so much so that white areas
> caused audio buzzing) a few times a day. I don't know offhand if it
> -only- manifested on 350 capture, and I rather suspect not. (I could
> possibly research it if it mattered, based on my records.) I haven't
> seen it in quite some time, but I don't know if it's because I stopped
> capturing on my 350 or because I switched to STB-only sources; the two
> happened at pretty much the same time, I think.

This sounds like the flicker this patch should also fix, but like the
ghosting, only where it affects the entire recording. As before, this glitch
isn't restricted to the tuner. My understanding is that with current drivers,
this type of glitch is primarily a PVR350 problem.

The patch does not remove the trigger event for either of these issues. The
capture init sequence itself produces a trigger and if it happens at just the
right time either glitch can occur, with ghosting the most common. With the
patch installed, the firmware will recover itself from both issues before
capture actually starts.

--
Ian

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


martin.dauskardt at gmx

Feb 28, 2010, 2:29 PM

Post #4 of 10 (3815 views)
Permalink
Re: PVR 350 flicker & temporal filter patch - Needs testing [In reply to]

> > P.S. I -do- recall an obnoxious flickering of the upper 1/4 of the
> > screen that was often provoked by a loss of sync on the input---that
> > was in the days when I took RF directly from a cable, and one of our
> > local PBS stations had a tendency to transmit badly-corrupted bursts
> > of video (also really badly overmodulated, so much so that white areas
> > caused audio buzzing) a few times a day. I don't know offhand if it
> > -only- manifested on 350 capture, and I rather suspect not. (I could
> > possibly research it if it mattered, based on my records.) I haven't
> > seen it in quite some time, but I don't know if it's because I stopped
> > capturing on my 350 or because I switched to STB-only sources; the two
> > happened at pretty much the same time, I think.
>
> This sounds like the flicker this patch should also fix, but like the
> ghosting, only where it affects the entire recording. As before, this
> glitch isn't restricted to the tuner. My understanding is that with
> current drivers, this type of glitch is primarily a PVR350 problem.

I described this flickering here:
http://www.gossamer-threads.com/lists/ivtv/devel/32970

PVR250 with cx23416 do not have this problem. But I know that earlier
revisions of the PVR250 with cx23415 (have a heatsink!) also have this
flickering when losing sync.

The funny thing is that I cannot provoke this flickering even with a current
unpatched driver. So there is no difference with the patch. (I can't say much
about ghosting - I always use 720x576. I will see next weekend if I can do
more testings)

@ Ian Armstrong:
Could you check if you can provoke the flickering without your patch, but with
a driver that has these changes:
http://linuxtv.org/hg/v4l-dvb/rev/7753cdcebd28
http://linuxtv.org/hg/v4l-dvb/rev/ec42a97b1a36

Greets,
Martin

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


mail01 at iarmst

Feb 28, 2010, 7:43 PM

Post #5 of 10 (3800 views)
Permalink
Re: PVR 350 flicker & temporal filter patch - Needs testing [In reply to]

On Sunday 28 February 2010, Martin Dauskardt wrote:
> > > P.S. I -do- recall an obnoxious flickering of the upper 1/4 of the
> > > screen that was often provoked by a loss of sync on the input---that
> > > was in the days when I took RF directly from a cable, and one of our
> > > local PBS stations had a tendency to transmit badly-corrupted bursts
> > > of video (also really badly overmodulated, so much so that white areas
> > > caused audio buzzing) a few times a day. I don't know offhand if it
> > > -only- manifested on 350 capture, and I rather suspect not. (I could
> > > possibly research it if it mattered, based on my records.) I haven't
> > > seen it in quite some time, but I don't know if it's because I stopped
> > > capturing on my 350 or because I switched to STB-only sources; the two
> > > happened at pretty much the same time, I think.
> >
> > This sounds like the flicker this patch should also fix, but like the
> > ghosting, only where it affects the entire recording. As before, this
> > glitch isn't restricted to the tuner. My understanding is that with
> > current drivers, this type of glitch is primarily a PVR350 problem.
>
> I described this flickering here:
> http://www.gossamer-threads.com/lists/ivtv/devel/32970
>
> PVR250 with cx23416 do not have this problem. But I know that earlier
> revisions of the PVR250 with cx23415 (have a heatsink!) also have this
> flickering when losing sync.
>
> The funny thing is that I cannot provoke this flickering even with a
> current unpatched driver. So there is no difference with the patch. (I
> can't say much about ghosting - I always use 720x576. I will see next
> weekend if I can do more testings)

With the current driver the flicker seems to be rarer, but unfortunately I
still see it occasionally. Ghosting is the most common problem.

> @ Ian Armstrong:
> Could you check if you can provoke the flickering without your patch, but
> with a driver that has these changes:
> http://linuxtv.org/hg/v4l-dvb/rev/7753cdcebd28
> http://linuxtv.org/hg/v4l-dvb/rev/ec42a97b1a36

I'll give it a try. One thing to note is that my patch can remove the glitch
after it has been triggered. Although the patch is for stopping a capture, it
has an effect on firmware behaviour when starting a capture. Here's an
explanation of what I found.

When the card is first started, it starts digitizing immediately whether a
capture is requested or not. I wrote some code to pull the image direct from
one of the yuv buffers without touching the firmware. This allowed me to view
the video while stepping through the setup for a capture. Using this method I
was able to identify the trigger points that can cause the problems.

Checking further, it appeared that the problem is related to the incoming
video stream. Hit the trigger at just right time and boom, capture broken. I
wrote a simple program that would sync to the incoming video stream and then
try to trigger the glitch at a certain position within the frame. Some
positions virtually guarantee a glitch. Again, I was bypassing the firmware so
no capture was in progress during this test. I did try running the glitch
program with a proper capture, but all it did was confirm the results.

One odd thing I noticed was video was sometimes still being digitized
after a capture had been stopped. (I was only looking at one buffer, so I
don't know what was happening in the others). I started poking around with the
stop capture firmware call, trying various parameters. Then I noticed that a
capture I started cleared the glitch. Normally, once you're glitched, you're
screwed. I then managed to isolate which parameter variation caused this, and
further refined it to the minimum required (the last parameter is a bitmask).

I then ran the following sequence with the stock driver:

1.Load firmware
2.Start buffer monitor (capture OK)
3.Run glitch program (capture BAD)
4.Start capture (capture OK) - Note the glitch is removed.
5.Run glitch program (capture BAD)
6.Stop capture
7.Start capture (capture BAD)

Capture is now broken across repeated stop/starts. (You can move the glitch
program to between 6 & 7, so no capture is occurring when trying to break it,
but it still triggers the glitch.)

I then reran it with the patch in place:

1.Load firmware
2.Start buffer monitor (capture OK)
3.Run glitch program (capture BAD)
4.Start capture (capture OK)
5.Run glitch program (capture BAD)
6.Stop capture - Note this now has the additional firmware call
7.Start capture - (capture OK)

Although the capture can be broken while in progress. Restarting now fixes it.
It seems that the extra stop command makes the firmware reset/reinitialize
something when the capture is started. You don't need it for the first capture
because it's not setup anyway, so the first capture is never bad.

You can see an example of the different problems at
http://www.iarmst.demon.co.uk/test/pvr350.jpg
The flicker you know, but the ghosting is more common but not always obvious
with default settings, and it depends on the type of scene as to how visible
it is. Both examples of ghosting shown were done with the temporal filter at
31, which is no good for normal usage, but good at highlighting the issue. You
can get both the flicker and ghosting at the same time. The captures where all
done at 720x576.

btw my chosen method of trigger was the vbi setup.

--
Ian

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


mail01 at iarmst

Mar 1, 2010, 3:51 AM

Post #6 of 10 (3793 views)
Permalink
Re: PVR 350 flicker & temporal filter patch - Needs testing [In reply to]

On Sunday 28 February 2010, Martin Dauskardt wrote:
>
> @ Ian Armstrong:
> Could you check if you can provoke the flickering without your patch, but
> with a driver that has these changes:
> http://linuxtv.org/hg/v4l-dvb/rev/7753cdcebd28
> http://linuxtv.org/hg/v4l-dvb/rev/ec42a97b1a36
>

I've now installed the latest driver from linuxtv.org, but it's still possible
to trigger the flicker simply by starting and stopping a capture. Doesn't
happen often, but it's still there.

--
Ian

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


awalls at radix

Mar 1, 2010, 5:36 PM

Post #7 of 10 (3757 views)
Permalink
Re: PVR 350 flicker & temporal filter patch - Needs testing [In reply to]

On Mon, 2010-03-01 at 11:51 +0000, Ian Armstrong wrote:
> On Sunday 28 February 2010, Martin Dauskardt wrote:
> >
> > @ Ian Armstrong:
> > Could you check if you can provoke the flickering without your patch, but
> > with a driver that has these changes:
> > http://linuxtv.org/hg/v4l-dvb/rev/7753cdcebd28
> > http://linuxtv.org/hg/v4l-dvb/rev/ec42a97b1a36
> >
>
> I've now installed the latest driver from linuxtv.org, but it's still possible
> to trigger the flicker simply by starting and stopping a capture. Doesn't
> happen often, but it's still there.


Ian,

IIRC, your patch looked OK. I'll try to apply it soon (real life keeps
getting in the way...)

Regards,
Andy


_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


mail01 at iarmst

Mar 5, 2010, 12:04 PM

Post #8 of 10 (3599 views)
Permalink
Re: PVR 350 flicker & temporal filter patch - Needs testing [In reply to]

On Sunday 28 February 2010, Martin Dauskardt wrote:

> The funny thing is that I cannot provoke this flickering even with a
> current unpatched driver. So there is no difference with the patch. (I
> can't say much about ghosting - I always use 720x576. I will see next
> weekend if I can do more testings)
>
> @ Ian Armstrong:
> Could you check if you can provoke the flickering without your patch, but
> with a driver that has these changes:
> http://linuxtv.org/hg/v4l-dvb/rev/7753cdcebd28
> http://linuxtv.org/hg/v4l-dvb/rev/ec42a97b1a36
>

I've just found that the delay changes partially break my patch. Full res
captures are fine with no ghosting or flickering, but the new delays
consistently break scaled captures, with ghosting every time.

My patch only seems to work properly with the current kernel version, which
has a single 300ms delay before CX2341X_ENC_INITIALIZE_INPUT. (260ms also
seems to work, but 250ms does not). There must be no delay between the init &
capture start, as that also breaks things.

I've reverted the delay changes on my test box, and it's now running the
following without problems. This is identical to the ivtv driver in 2.6.32.

/* Avoid unpredictable PCI bus hang - disable video clocks */
v4l2_subdev_call(itv->sd_video, video, s_stream, 0);
ivtv_msleep_timeout(300, 1);
ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0);
v4l2_subdev_call(itv->sd_video, video, s_stream, 1);
}

Depending on what you found with your delay tests, it may be that the delay
required is different depending on the hardware in use.

--
Ian

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


martin.dauskardt at gmx

Mar 5, 2010, 1:35 PM

Post #9 of 10 (3592 views)
Permalink
Re: PVR 350 flicker & temporal filter patch - Needs testing [In reply to]

> I've just found that the delay changes partially break my patch. Full res
> captures are fine with no ghosting or flickering, but the new delays
> consistently break scaled captures, with ghosting every time.
>
> My patch only seems to work properly with the current kernel version, which
> has a single 300ms delay before CX2341X_ENC_INITIALIZE_INPUT. (260ms also
> seems to work, but 250ms does not). There must be no delay between the init
> & capture start, as that also breaks things.
>
> I've reverted the delay changes on my test box, and it's now running the
> following without problems. This is identical to the ivtv driver in 2.6.32.
>
> /* Avoid unpredictable PCI bus hang - disable video clocks */
> v4l2_subdev_call(itv->sd_video, video, s_stream, 0);
> ivtv_msleep_timeout(300, 1);
> ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0);
> v4l2_subdev_call(itv->sd_video, video, s_stream, 1);
> }
>
> Depending on what you found with your delay tests, it may be that the delay
> required is different depending on the hardware in use.

This code should also be fine as long as it concerns the "black screen"
problem.
The summary of my testings (see table in http://ivtvdriver.org/pipermail/ivtv-
devel/2010-January/006381.html) was that it is not important if we do a single
sleep or split them. The only important thing is that we have a total delay of
300ms before starting capture.

I can't say if this code still solves the audio problem (which was the
original intention of Andys changes). I never had any audio problem, and I
don't know if there is any final feedback from the original poster of the
audio problem.

Martin

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


mail01 at iarmst

Mar 6, 2010, 3:20 AM

Post #10 of 10 (3570 views)
Permalink
Re: PVR 350 flicker & temporal filter patch - Needs testing [In reply to]

On Friday 05 March 2010, Martin Dauskardt wrote:

> This code should also be fine as long as it concerns the "black screen"
> problem.
> The summary of my testings (see table in
> http://ivtvdriver.org/pipermail/ivtv- devel/2010-January/006381.html) was
> that it is not important if we do a single sleep or split them. The only
> important thing is that we have a total delay of 300ms before starting
> capture.

I can confirm that the 300ms delay is needed before the capture is started.
The only difference I found was that a split delay can cause problems (with a
feature which is disabled in the current driver).

> I can't say if this code still solves the audio problem (which was the
> original intention of Andys changes). I never had any audio problem, and I
> don't know if there is any final feedback from the original poster of the
> audio problem.

The extra firmware command does affect the audio stream, but I don't know if
it cures any problems. With the PVR350, the only audio problem I've ever
encountered is complete lack of. Attempts to read /dev/video24, which should
be the raw audio stream, result in no data. Video is fine, with mpeg captures
simply being silent. This is rare, so I don't yet know if the extra call also
solves this.

--
Ian

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

ivtv devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.