[New Plugin] Atmolight Process Plugin **Update 25.05.2010 V1.9**

After playing around with my new Atmolight i faced that problem that my HTPC is always on and MP is running most of the time - be it idle or in use.
Using Atmolight (V 0.46 work great) the lights would be on all the time.
That's why i created this process plugin.
See the screenshot to check out the options.
It basically grabs about every 2nd frame MP renders to the screen and then sends the pixel to AtmoWin via it's COM interface.

Installation
Just double-click the attached MPEI package

Requires AtmoWin V 0.46 which can be obtained here AtmoWin ? VDR Wiki

The readily built - ready to use Atmolight hardware can be bought here: ca.rstenpresser.de::WebShop
(Since this is the only source for the prebuilt hardware i could find i think this "advertisement" link should be no problem)

Version History:

13.01.2010 New Version V1.1
Because of AtmoWinA being a CPU killer at a decent capture rate of about 25 fps i am grabbing the picture now from inside the plugin via MP's internal DirectX methods and then pass the raw pixel data to atmowin via com.
Probably the next question is:
"If you already get the screen in the plugin then why not processing it yourself without the need of AtmoWin?"

Well, the answer is easy: Calculating the colors for the LED stripes is a quite complex algorithm and why inventing the wheel twice.
This works great (at least for me).


13.01.2010 New Version V1.2
This version makes grabbing the current image very effective. Even much better than in V1.1 BUT it requires a patched Core.dll.
The package will install the patched Core.dll and overwrite your existing, so please make a backup of Core.dll BEFORE installing this package and use it only with the current snapshot which is here http://forum.team-mediaportal.com/u...t-01-08-2010-02-15h-revision-24669-rar-75857/
For those who are interested in what has to be changed you can check the attached patch.
It's just a small patch which doesn't affect any other functions of MP, so hopefully it makes it's way into SVN


15.01.2010 New Version V1.4
- capturing is now done via the backbuffer and some optimized resizing routines
- No need for a patched Core.dll anymore
- grabs with a framerate of about 27 fps on my ION 330 system

15.01.2010 New Version V1.5
Changes:
- should now also be compatible with MP 1.0.2 stable
- Fixed "alwaysOn" switch was not used

20.01.2010 New Version V1.6
Changes:
- backbuffer method from V1.4 and V1.5 didn't work because at least every 2nd frame was corrupted. This is unfortunately due to design of the backbuffer itself
- A patched Core.dll and DXUtil.dll is needed
- Removed the other activate options because we can only analyze a video that is being played so there is nothing to configure here

06.02.2010 New Version V1.7
Changes:
- changed back to the OnNewFrame patch from V1.2 which seems to be more stable and doesn't cause frame drops
ATTENTION: The scan delay has no meaning in this version, since any frame is analyzed always



23.02.2010 New Version V1.8
Changes:
- includes patched Core.dll for MP 1.1 RC1
- restructured config
- added option to set the effect for Music,Radio and video differently
- fixed a bug were the leds won't go off after stopping a movie


25.05.2010 New Version V1.9
Changes:
- includes patched Core.dll for MP 1.1 RC3
- added a time setting were atmolight won't be activated to same energy during daylight
- added a menu to disable/enable Atmolight manually - just press the "STOP" button when not playing anything

17.04.2011 New Version V1.9.5
Changes:
- added plugin version check to be MP1.2 compatible

Although capturing the screen is now much less CPU intensive it still takes it's CPU time.
Just play around with this setting.
If you enable the "debug" log output, everytime the plugin has processed images for about 1 secs it ouputs a line like:
"atmolight: processed 27 bitmaps in 1002 ms. Capture delay is 30 ms"
so you can check how this affects you capture framerate

No need to disable AERO anymore

This version installs a patched Core.dll which is based on latest public svn snapshot from 8th January 2010.
Please only use it with this snapshot atm.

If there are no issues this patch will get probably submitted to SVN so please help us testing

I also just attached a patched core.dll and dxutil for MP 1.0.2 stable. To use it just install the MPEI and then overwrite the 2 dll files


Hope you also find it useful

Well i am running Windows 7 Ultimate (32 Bit) and i don't need to disable AERO when using AtmoWin.
All is working fine.
To make things a bit smoother you can play with the "GDI capture frame rate".

I am currently working on some speed improvements for AtmoWin (thanks to the devs - the sourcode is available)

Just uploaded V1.1 with major modifications. Check first post

gemx, did you consider using a smaller DX surface size? Or maybe you already are using strechrect() to a DX surface, that is maybe 300x400 pixels. Should lower the CPU usage a lot since GPU to main RAM copy over PCI is costy operation.

I tried to play with it:
I just (quick and dirty) hacked DXUtil's VideoSurfaceToRGBSurface(...) where the stretchrect happens and also had to patch Framegrabber.cs OnFrame(...) to create the RGB surface only in the resolution 64x48 which works great.
Much less CPU time.
The only problem with this is that the StretchRect(...) seems to be only able to copy if sourceRect=targetRect.

Well targetRect is the actual size of the target bitmap which fine but sourceRect having the same size would mean NOT stretching but only copying a part of the original surface or am i wrong?

BTW: I tried to use the backbuffer directly in the plugin and use StretchRectangle on that but this always gave D3D_INVALIDCALL whatever i tried.

tourette: Do you have any ideas?

Ok, found something:

I tried on VMR9 and there we use a PlainOffScreenSurface were as with EVR we use a RenderTargetSurface.

StrectchRect can only resize to another RenderTargetSurface or to a TextureSurface

I also played with the backbuffer from inside the plugin but it always seems to be black.

So the only option would be to extend the framebuffer class to not only get a snapshot but also be able to give the resolution of that snapshot. Should also be usefull for other programs that use the framegrabber as it drastically reduces CPU time. At least with HD content

Since this only works with a very small change in the MP sourcecode - attached is the patch.
With this patch, it's working nearly without any noticeable CPU time (at least in taskmanager) for SD TV and and a small impact depending on capture delay for HD TV