One-Click WebCam Recording!

**moreause** · 04-20-2009, 12:04 AM

would it be hard to do an overlay but not with gps data
from text file or a variable
i would like ton input other car data like speed, tps,map
i already have a small vb application to send to data to a dataloging software and sync those data with my obd value

so maybe if i could send those data to the overlay it would work ??

maybe instead of gps data they could be spelled variable 1 to 4 and place it where you want (x and y) wise

**Curiosity** · 04-20-2009, 06:59 AM

Not too hard. I have an API example with the new version. Just download it. It's in C and a lot like the XPort API, and I think it can easily be converted to VB and other languages.

You get 8 text strings to place anywhere you like, but try to keep them close to the top and bottom of the video. It's optimized to copy only from the active rows to the top/bottom edge for speed. The API also allows modifying the font and GPS info so just be careful.

**Cameleon** · 04-20-2009, 07:16 AM

Nice work Curiosity

Just to keep you guys up to date. I have been working on getting the overlay to work with recording and compression. As we thought, RenderStream sucks at adding stuff in the right place, so had to manually force it to put the compression after the GPS overlay filter as it was tring to put it before *doh*.

Think I have most of it sorted so should be able to post the code soon. I think there is some work to be done around optimising it as its quite scrappy atm. I have also added the option to disable audio in the preview. And also the property page for the GPS Overlay

**TheSovereign** · 04-20-2009, 09:22 AM

Great work guys, it's awesome to see how much progress you're making with the overlays =)

I read in one of the posts about integrating RR components -- which very is cool, but I wanted to ask/request at the same time, if possible, to also maintain Capture!'s stand-alone ability for non-RR users (such as myself).

Thanks again for all your hard work and consideration...

**silvi4000** · 04-20-2009, 09:22 AM

how are we going to get the GPS data?
I think there are 2 options
- from RR via the SDK
- directly from the COM port (xPort)

If from RR (or any other front-end), that would limit the program to work only with the front end to get GPS but the front end will do all the work like calculating city, zip, speed, etc...

If from the COM port (xPort), that would make the program more independent but will mean it will have to do all the work of calculating the GPS info

What other options do we have?

**Cameleon** · 04-20-2009, 09:32 AM

Currently it uses Curiosity's GPS Filter which is self contained and can run beside Xport to get the data from the COM port. This keeps the app completely stand alone and useable by CF, RR, and users who dont use either.

I would only go down the RR/CF route if they were being ported into a plugin for the front end. I dont think I will go that route now as it seems like a lot of work to get it into CF and it already embeds nicely now. So dont worry TheSovereign, we will keep it working as a stand alone app, just have profiles for setting up dimensions and button/menu visibility for CF/RR

I guess there is room for others to port them into a plugin in future, but I would like to see core functionality sorted first.

**TheSovereign** · 04-20-2009, 12:07 PM

Originally Posted by Cameleon

Currently it uses Curiosity's GPS Filter which is self contained and can run beside Xport to get the data from the COM port. This keeps the app completely stand alone and useable by CF, RR, and users who dont use either.

I would only go down the RR/CF route if they were being ported into a plugin for the front end. I dont think I will go that route now as it seems like a lot of work to get it into CF and it already embeds nicely now. So dont worry TheSovereign, we will keep it working as a stand alone app, just have profiles for setting up dimensions and button/menu visibility for CF/RR

I guess there is room for others to port them into a plugin in future, but I would like to see core functionality sorted first.

Okay, happy to hear that. =)

Thank you for the quick reply and confirmation. =)

**Curiosity** · 04-21-2009, 08:37 AM

The latest version of the filter actually requires XPort. It eliminates any lag from reading a COM port and parsing all that data, makes it simpler, and doesn't take up another virtual port.

It was also crashing from doing math on invalid data. It won't display anything unless it's seeing valid data now, which makes it a little harder to know it's working. Sorry.

**Nomader** · 04-21-2009, 01:50 PM

hey where can i download the new version of capture! (with the overlay) ? 1st post version is the original right?

**Prefect** · 04-21-2009, 03:38 PM

Hey all!

You made great progress! Nice!

However it would be bad if Capture! would only work with XPort. I don't use XPort, I have GPSGate.

Also I don't use RoadRunner, I use CES (www.ecarpc.de). Capture! should not depend on any external software.

The new layout looks nice for a one-camera-setup. But I personaly use DualCapture with two windows side by side for two cams. It should be possible to activate the old layout (maybe with the new button-icons?)

Just try to not limit the usability of Capture! for those with other CarPC setups.

And keep posting the new versions! :-)

Thanks!
Chris