Hi Phil
I have completed a PASM version of my NTSC changes of your capture program, and have started on the VGA version.
Even with PASM rendering it is difficult to get below one second per frame captures, and the VGA version requires more multiplies.
I added an extra cog to do rendering in SPIN and then tried to convert it to PASM. You can choose which one to use by commenting out the opposite version. During the translation to PASM one can also see options to optimize the SPIN version.
Spin seems to promote variables read to signed arithmetic. Hope to have these new versions in publishable form in a few days
Still having problems with understanding when/how spin promotes to signed values.
my PASM code works for my TV driver( with minor )artifacts but the VGA code is still not useable.
OK I finally got it working! searched throughout the code added debug routines and what was my problem?
Diddly SPLAT!!!! Yes I had forgotten to put a splat in front of an immediate constant.....
In side the attached ZIP file there is a mp4 that gives a taste of the code working.
it shows the propeller being turned on and doing real time display, followed by the playing of two recorded files.
the test pattern is VIDEO_58.VXR
and VIDEO_37.VXR, a funny commercial from China TV.
The last enhancement I added was an interleaved display strategy. which greatly enhanced speed.
As long as there is little motion the display is marginally OK.
I have been measuring performance in lines rendered / second. The 80MHz VGA does about 177 per second.t
It should be able to work on the backpack in "Show" mode simply by putting a few commented lines back in force.
This is actually a video/audio recorder so complete implementation would ad an SD card and audio input/output circuits.
Project still need some fine tuning ( the spin capture cog code probably does not work now I think this shows a model for how to translate SPIN to PASM
The PST terminal shares the last cog with FSRW so only one can be active at a time.
Very interesting, PhiPi
How do you think, could it be implemented to Simple Pal Decoding. I'm working on the similar task with PSoC5, trying to put all activity inside the crystal.
Wow. This thread might be the grail for that elusive Ambi-light-on-one-board so many people have been looking for. "Ambilight" is a Philips trademark.
Right now most everybody uses a PC running BobLight to average color contents in say 2, 4, 8 regions, but some folks go for more!
(talk about overkill!). They send the data from BobLight over a serial/USB link to an Arduino (or other MC) that controls sets of RGB LEDS mounted behind the TV. But that's a lot of extraneous gear, and precludes using non-PC video sources. In practice a 4 region (left, right, top, bottom) Ambilight clone using a 4 x 4 RGB frame capture with a 1 hz sampling rate seems like it would be pretty satisfying. A Prop should be able to do this standalone on any source material.
Time to dig into this possibility? I've never used the Prop for video or even soldered in the Delta/Sigma A/D components. If anyone could summarize the rigging of a QuickStart board to start exploring this, I'd be very grateful. The objective is to derive that 4x4 RGB array to drive the Ambi-light LEDs from.
Since composite is the Lowest Common Denominator of video, available even on HD set-top boxes, it stands to reason to use it. For openers a 4 x 4 would be a more than great start, initially using (plain averaging?) the 4 left edge ones to drive a left color and another 4 to drive a right, later adding top and bottom, maybe separating into 6 regions. Depending. The original Philips ones are rather subtle, nice.
The number of A/Ds aside, would component video be easier or harder to convert? How about adding some simple discrete hardware?
Comments
Here is a version that uses the 8bc_TV driver. I have also tamed my modifications to Eric Ball's NTSC_8bpp driver.
The strategy for decoding the I/Q signals is to build a hue table of expected values and then squeeze to input values to be in side the table.
I chose 32 vectors because 360/32 = 11.25 so I could rotate the table to get the 30 degree rotation to match NTSC coding.
This worked out well as the 8bc_TV driver needed much larger rotation to get the colors correct
I think it would be nice if someone could replace the VGA daughter boad with other boards , eg. SD card + TV video driver.
I am going to post my latest Pixelator code on the "stupid video capture" thread even though it only produces an image every 3 seconds.
Hi Phil
I have completed a PASM version of my NTSC changes of your capture program, and have started on the VGA version.
Even with PASM rendering it is difficult to get below one second per frame captures, and the VGA version requires more multiplies.
I added an extra cog to do rendering in SPIN and then tried to convert it to PASM. You can choose which one to use by commenting out the opposite version. During the translation to PASM one can also see options to optimize the SPIN version.
Spin seems to promote variables read to signed arithmetic. Hope to have these new versions in publishable form in a few days
Perry.
my PASM code works for my TV driver( with minor )artifacts but the VGA code is still not useable.
But I found this app note http://www.digitalcreationlabs.com/docs/AN10_digital_video_overview.pdf
that shows a better RGB conversion algorithm.
where ii is Cb
and qq is Cr
and remembering something from my old "2920 Signal Processor handbook" .. you do multiplies by constants with shifts and additions so I tried this.
' red := yy + (constant(trunc(0.956 * 4096.0)) * ii + constant(trunc(0.620 * 4096.0)) * qq) ~> 12 #> 0 <# 255 ' grn := yy - (constant(trunc(0.272 * 4096.0)) * ii + constant(trunc(0.647 * 4096.0)) * qq) ~> 12 #> 0 <# 255 ' blu := yy - (constant(trunc(1.108 * 4096.0)) * ii - constant(trunc(1.705 * 4096.0)) * qq) ~> 12 #> 0 <# 255 ' yy := 1.164 * (yy-16) yy := (yy - 16) yy := yy + yy~>3 + yy~>5 #> 0 <# 239 ' r := yy + (constant(round(1.596)) * ii) ~> 12 #> 0 <# 255 red := (yy + ii + (ii~>1)) #> 0 <# 255 ' g := yy - (constant(round(0.392)) * qq - constant(round(0.813 * 4096.0)) * ii) ~> 12 #> 0 <# 255 grn := (yy - (qq~>2) - (qq~>3) - (ii~>1) + (ii~>2)) #> 0 <# 255 ' b := yy + (constant(round(2.017)) * qq ) ~> 12 #> 0 <# 255 blu := (yy + qq + qq) #> 0 <# 255and got better colors and skin tones on VGA
Perry
Diddly SPLAT!!!! Yes I had forgotten to put a splat in front of an immediate constant.....
In side the attached ZIP file there is a mp4 that gives a taste of the code working.
it shows the propeller being turned on and doing real time display, followed by the playing of two recorded files.
the test pattern is VIDEO_58.VXR
and VIDEO_37.VXR, a funny commercial from China TV.
The last enhancement I added was an interleaved display strategy. which greatly enhanced speed.
As long as there is little motion the display is marginally OK.
I have been measuring performance in lines rendered / second. The 80MHz VGA does about 177 per second.t
It should be able to work on the backpack in "Show" mode simply by putting a few commented lines back in force.
This is actually a video/audio recorder so complete implementation would ad an SD card and audio input/output circuits.
Project still need some fine tuning ( the spin capture cog code probably does not work now I think this shows a model for how to translate SPIN to PASM
The PST terminal shares the last cog with FSRW so only one can be active at a time.
Perry
How do you think, could it be implemented to Simple Pal Decoding. I'm working on the similar task with PSoC5, trying to put all activity inside the crystal.
Right now most everybody uses a PC running BobLight to average color contents in say 2, 4, 8 regions, but some folks go for more!
(talk about overkill!). They send the data from BobLight over a serial/USB link to an Arduino (or other MC) that controls sets of RGB LEDS mounted behind the TV. But that's a lot of extraneous gear, and precludes using non-PC video sources. In practice a 4 region (left, right, top, bottom) Ambilight clone using a 4 x 4 RGB frame capture with a 1 hz sampling rate seems like it would be pretty satisfying. A Prop should be able to do this standalone on any source material.
Time to dig into this possibility? I've never used the Prop for video or even soldered in the Delta/Sigma A/D components. If anyone could summarize the rigging of a QuickStart board to start exploring this, I'd be very grateful. The objective is to derive that 4x4 RGB array to drive the Ambi-light LEDs from.
Since composite is the Lowest Common Denominator of video, available even on HD set-top boxes, it stands to reason to use it. For openers a 4 x 4 would be a more than great start, initially using (plain averaging?) the 4 left edge ones to drive a left color and another 4 to drive a right, later adding top and bottom, maybe separating into 6 regions. Depending. The original Philips ones are rather subtle, nice.
The number of A/Ds aside, would component video be easier or harder to convert? How about adding some simple discrete hardware?