NTSC picture artifacts, dropped frames, jagged image; any way to clean it up?

[alexeymohr]

Hi all,

I've been working on building this excellent project for some time now. Overall I've got things put together very well. I'm in the US, so I wanted to keep everything in NTSC. I found the tip for commenting out the PAL hack in the usbtv driver and did that, which seemed to work fine.

I'm using a Raspberry Pi rev B, the recommended HDMI-to-composite converter, an EasyCAP with Fushicai chipset, and running Raspbian Wheezy dated 7-26-2013. I'm driving 128 of the recommended LEDs from Adafruit.com. I successfully compiled the usbtv driver and the Ambi-TV program, made a custom .conf file to reflect my exact LED count and placement, and got it all working. Party mode works great, so clearly the main Ambi-TV program and the LEDs are working correctly.

However, in normal use the LED lighting has been rather flickery (even after adjusting the .conf file), and also often seems to have some trouble tracking the on-screen action properly. Sometimes a part of the screen is clearly very bright, but the LEDs just don't seem to track it.

So I decided to investigate just how good the incoming video signal really was using mplayer. I ran this command to do so:

mplayer tv:// -tv device=/dev/video0 -hardframedrop

The resulting video looked pretty messed up; there were all sorts of blocky artifacts, odd interlacing glitches, split frames, and even lots of dropped frames (according to the output report from mplayer). I imagine this bad video signal explains why my LEDs aren't working as smoothly as I'd like!

I tried overclocking to full 1GHz on the Pi using raspi-config, and it didn't make any appreciable difference. So the issue isn't CPU speed.

Does anyone have any thoughts on what I can do to improve the quality of the incoming video signal? Is there a newer version of the usbtv driver that I could use? Or are there any other settings I could adjust, such as frame buffers or something?

Would I be better off trying to get the STK1160 version of the EasyCAP?

Any help is most appreciated!!

[Hackmodford]

Does your hdmi to composite adapter have a PAL/NTSC switch?

Sent from my iPhone

On Nov 25, 2013, at 10:09 PM, alexeymohr notifications@github.com wrote:

Hi all,

I've been working on building this excellent project for some time now. Overall I've got things put together very well. I'm in the US, so I wanted to keep everything in NTSC. I found the tip for commenting out the PAL hack in the usbtv driver and did that, which seemed to work fine.

I'm using a Raspberry Pi rev B, the recommended HDMI-to-composite converter, an EasyCAP with Fushicai chipset, and running Raspbian Wheezy dated 7-26-2013. I'm driving 128 of the recommended LEDs from Adafruit.com. I successfully compiled the usbtv driver and the Ambi-TV program, made a custom .conf file to reflect my exact LED count and placement, and got it all working. Party mode works great, so clearly the main Ambi-TV program and the LEDs are working correctly.

However, in normal use the LED lighting has been rather flickery (even after adjusting the .conf file), and also often seems to have some trouble tracking the on-screen action properly. Sometimes a part of the screen is clearly very bright, but the LEDs just don't seem to track it.

So I decided to investigate just how good the incoming video signal really was using mplayer. I ran this command to do so:

mplayer tv:// -tv device=/dev/video0 -hardframedrop

The resulting video looked pretty messed up; there were all sorts of blocky artifacts, odd interlacing glitches, split frames, and even lots of dropped frames (according to the output report from mplayer). I imagine this bad video signal explains why my LEDs aren't working as smoothly as I'd like!

I tried overclocking to full 1GHz on the Pi using raspi-config, and it didn't make any appreciable difference. So the issue isn't CPU speed.

Does anyone have any thoughts on what I can do to improve the quality of the incoming video signal? Is there a newer version of the usbtv driver that I could use? Or are there any other settings I could adjust, such as frame buffers or something?

Would I be better off trying to get the STK1160 version of the EasyCAP?

Any help is most appreciated!!

— Reply to this email directly or view it on GitHub.

[alexeymohr]

Yes, it's the one recommended by GKaindl. It's currently switched to NTSC mode.

[Angora]

Have you tried to connect the composite adapter to a power source? Try that, if not already done. Am 26.11.2013 04:52 schrieb "alexeymohr" notifications@github.com:

Yes, it's the one recommended by GKaindl. It's currently switched to NTSC mode.

— Reply to this email directly or view it on GitHubhttps://github.com/gkaindl/ambi-tv/issues/40#issuecomment-29265703 .

[alexeymohr]

Would that power source need to share common ground with everything else? I imagine it probably would. Perhaps the easiest thing to do is to splice a mini-USB cable just like the spliced micro-USB cable I'm using to power the Pi, and connect it to the same power supply and ground as everything else?

I'm using a 5-Volt 10-Amp switching power supply that I got from Adafruit.com along with the LEDs.

[Angora]

For me it doesn't. Just use for testing an USB slot of your tv or such.

2013/11/26 alexeymohr notifications@github.com

Would that power source need to share common ground with everything else? I imagine it probably would. Perhaps the easiest thing to do is to splice a mini-USB cable just like the spliced micro-USB cable I'm using to power the Pi, and connect it to the same power supply and ground as everything else?

I'm using a 5-Volt 10-Amp switching power supply that I got from Adafruit.com along with the LEDs.

— Reply to this email directly or view it on GitHubhttps://github.com/gkaindl/ambi-tv/issues/40#issuecomment-29273029 .

[alexeymohr]

So I tried directly powering the HDMI-to-composite adapter with a 5v1a phone charger that I had, and it made no difference. I also tried going back to the PAL driver and switching the adapter to PAL, also no difference.

I also looked more closely at the mplayer information and it's dropping about 70% of the frames. This is consistent under each circumstance that I've tried.

Any other ideas?

[Angora]

How is your USB-Grabber connected to the Raspberry Pi? Directly or with an extension cable? I had issues when connecting over an extension cable, connecting it directly solved my issue. (Even though i don't think that it would help, it would be a guess)

2013/11/26 alexeymohr notifications@github.com

So I tried directly powering the HDMI-to-composite adapter with a 5v1a phone charger that I had, and it made no difference. I also tried going back to the PAL driver and switching the adapter to PAL, also no difference.

I also looked more closely at the mplayer information and it's dropping about 70% of the frames. This is consistent under each circumstance that I've tried.

Any other ideas?

— Reply to this email directly or view it on GitHubhttps://github.com/gkaindl/ambi-tv/issues/40#issuecomment-29275973 .

[alexeymohr]

The USB grabber is connected directly. I had read about the issues with extension USB cables, so I avoided that.

[Hackmodford]

Instead of connecting the hdmi-composite adapter to the pi, try connecting it to your tv to see if it actually works.

Sent from my iPhone

On Nov 26, 2013, at 4:08 AM, alexeymohr notifications@github.com wrote:

The USB grabber is connected directly. I had read about the issues with extension USB cables, so I avoided that.

— Reply to this email directly or view it on GitHub.

[alexeymohr]

So I ran the HDMI-to-Composite adapter directly to a TV and it is working fine. The picture is pretty ugly, but it is standard-def after all ;-)

I also installed the EasyCAP under WIndows 7 (which took some doing!). The video input there looks much better than on the Pi; there are still some interlacing artifacts, some moire, and a faint grey vertical scroll hum bar, but it's seeing the video at full 30FPS and is more-or-less fine. I imagine it would certainly be adequate to drive the Ambi-TV program.

Now, I just need to be able to get that level of video capture performance on the Raspberry Pi......

So it seems all my hardware checks out. Any further thoughts on the software side of things?

[Hackmodford]

Did you over clock the pi?

Brandon Butler

On November 26, 2013 at 3:43:26 PM, alexeymohr (notifications@github.com) wrote:

So I ran the HDMI-to-Composite adapter directly to a TV and it is working fine. The picture is pretty ugly, but it is standard-def after all ;-)

I also installed the EasyCAP under WIndows 7 (which took some doing!). The video input there looks much better than on the Pi; there are still some interlacing artifacts, some moire, and a faint grey vertical scroll hum bar, but it's seeing the video at full 30FPS and is more-or-less fine. I imagine it would certainly be adequate to drive the Ambi-TV program.

Now, I just need to be able to get that level of video capture performance on the Raspberry Pi......

So it seems all my hardware checks out. Any further thoughts on the software side of things?

— Reply to this email directly or view it on GitHub.

[alexeymohr]

I have tried overclocking up to 1Ghz, no change in performance.

Has anyone run mplayer to check the video stream and gotten a nice, smooth image without artifacts?

[alexeymohr]

A picture says a thousand words, so here's an iPhone video of the issue:

http://youtu.be/2toEp2Ag0uQ

Please pardon the bad glare off the TV. You can still get a sense for the issue however. At the end of the clip I pan over to terminal and you can see the dropped frame count from MPlayer.

[iLLiac4]

Why are you using full res? Lover it and you will get better performance. /usr/bin/mplayer -tv driver=v4l2:width=72:height=58:device=/dev/video0 -vo fbdev -fs -fps 15 tv:// </dev/null >/dev/null 2>&1 &

[alexeymohr]

That's great for checking with mplayer, but doesn't Ambi-TV use full NTSC or PAL resolution? (That is to say, either 720x480 for NTSC or 720x576 for PAL).

Is there any way to modify Ambi-TV to scale down the resolution it analyzes off the video capture in order to make it run more smoothly?

[Hackmodford]

Why not scale down to the actual resolution to match the LED resolution you have? So if you have 10 lEDs wide by 5 high make the resolution 10x5. Do you think that would help lower cpu processing in general?

[alexeymohr]

BTW, I'm having no luck getting mplayer to display the video at a lower resolution. No matter what flags I specify, no matter what order, it still shows the same output with all the artifacts and such.

I imagine that lowering the resolution of the video stream to maybe 2x the number of LEDs would be good. Now, how the heck do I do that? ;-)

[r3vO88]

Hi Alex, did you find a solution

[dwojahn]

Alex, I just got mine set up and I'm having the same issue. Did you find a resolution?

[alexeymohr]

Here's the latest on my progress:

Still no luck getting better performance when checking the EasyCAP with MPlayer. I've overclocked the Pi to the max allowed by raspi-config, and that didn't help. I got a second EasyCAP with fushicai chipset, and it was the same. I tested both EasyCAPs under Windows 7 and Ubuntu on a PC, and both worked fine on each OS. Their video capture still looks awful, but it's exactly what one should expect from a cheap SD analog video capture device. The important part is that the video capture on the PC was a full framerate with no artifacts.

So the issue isn't the EasyCAP. Next I wanted to see if the issue was NTSC, since GKaindl set it all up in PAL. I got a high-quality HDMI NTSC-to-PAL converter and set the EasyCAP driver on the Pi back to PAL. I got the same low frame rate and artifacts in MPlayer that I saw under NTSC, so that's not the issue.

Finally I made a few more changes to the .conf file of Ambi-TV and got good results!

I set the crop-left, crop-right, crop-top, and crop-bottom all to 20. When the EasyCAP is working smoothly on the PC, the video capture still has nasty artifacts on the edges. This cropping compensates for that.

Then I set the blended-frames to 8 frames. I've also run it at 6. I get better results and a smoother presentation than the default 3.

For me, those .conf file changes really did it! I still need to get a bit more amperage to my LEDs, and my hardware setup is still rather messy and needs to be organized better, but overall it's working pretty well!

[dwojahn]

Thanks, I got mine working as well.

I was getting horrible flickering, not even anything like the picture on the tv, and when I fired up mplayer I was seeing exactly what you are, so I thought that must be the cause.

Then I saw a few other posts about splicing the ground wires together if you are using separate power supplies for the pi and the lights, so I figured I'd give it a try and it worked! Now the lights work perfect and I didn't have to mess with the config file at all! So I'm thinking that the stream mplayer is showing really doesn't matter when it comes to the lights.

Thanks again!

[ghgoldberg]

Yes, using common grounds can help. Also, make sure to use a big enough power supply. I am using a 12A supply, and all the 5V inputs are fed from a common point. Also, you should power the leds from BOTH ends. That will eliminate the voltage drop at the leds at the end of the chain.

[ghgoldberg]

You can see my hardware setup in thread 48.

[HyperFann]

@alexeymohr Can you point me how to disable Pal Hacks in the usbtv driver so I can use NTSC.

thanks !