Windows Media Player

[Melbourne]

Hi All

I have an application where I need to superimpose graphics over the top of a Media Player video (Media Player 4 Active X control). I would like to place an appropriately sized 2D Picture control (with a transparent background) over the media player such that the drawings on the pic control appear to float over the video. Whilst there has been some discussion about sizing & positioning of the media player, my problem is forcing it to remain in the back most plane in order for the picture control to sit front most. While the picture control can be easily placed over the media player and be told to go front most (during VI creation), when the VI/media player runs the media player automatically jumps front most and covers the picture control

Any ideas here pls

[hooovahh]

I believe this is an issue with the ActiveX control it self. You have similar issues when you put ActiveX controls like this into tabs. It works just fine, but changing between tabs you'll see a flicker of the ActiveX control on top of the tab, and then moved back into the tab.

I don't know of a work around. For the tab it's annoying but doesn't change functionality. For your application it sounds like more of a show stopper.

[GregR]

There are 2 types of ActiveX controls: windowed and windowless. Windowed controls create their own OS window and completely handle drawing inside of that window. Windowless controls get messaged by their containing window when it is their turn to draw. Guess which kind the media player is. In order to draw anything on top of it, we would need to create a partially transparent window on top of it.

You could do something with a second VI that is set to be partially transparent and positioned over the media player.

[Melbourne]

Hi Guys

Thanks for your input. I have tried placing a another vi containing a 2D picture control over the top and that works, but I really need the background of that VI to be completely transparent to provide a good view of the movie clip underneath. Adjusting the vi transparency unfortunately adjusts not just the back ground of the vi, but of all controls on that vi too. Is there a way to set the background ONLY to transparent and not that of the controls too perhaps??

The other thing I have noticed in relation to this, it seems that it matters what computer and what video clip is being played. There are combinations of computers/video clips where it is entirely possible to keep control of the front most image and retain the Media Player in the background. Its just really frustrating when you think you have it working and transfer to another PC to find your graphics images remain hidden...

[Darin]

Follow the example here to use the Windows API to set a transparent color in a FP window.

http://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-04-17-2006/m-p/352929#M179807

[Melbourne]

Yes, thanks have tried that, but it also "fades out" the colour of any controls on the front panel too. I really need to set the front panel background to transparent leaving controls as they would normally appear, so that objects being drawn on the 2D picture control in the foreground plane retain their visibility/colour.

[Darin]

Did you use a color for the FP that does not appear elsewhere? Using a white or gray could cause some issues.

[Melbourne]

I used black oddly enuf - that seemed to give the best "quality" of image - I tried many different colours and different levels of transparency. Around 85% and a black picture control back ground gave what seemed to me to be the "best" results

[Melbourne]

In an effort to get a working solution to this application working, I have implemented the partially transparent VI overlay idea. Whilst this sort of works it isnt a good solution. The transparent overlay makes the WPM image underneath very dark or washed out depending upon the choice of overlay VI background colour. Further when attempting to draw graphics on the overlay when WPM is in play mode the image flickers quite badly. Any ideas how to suppress the flicker OR force WMP to stay back most on a VI front panel to enable a 2D pic control to remain front most over it pls?

[Francois Normandin]

I've had the same kinds of flickering problems with this particular ActiveX. I remember I hooked to the Event Callbacks and deferred panel updates until a particular action was completed. It was not an overlay but rather a resizing problem that caused the ActiveX container to resize to the original video size and then back to the "fit to screen" in a fraction of a second. I couldn't get rid of the effect but this was a workaround that worked in my case. I don't know if such an approach could help in your case...

[MikaelH]

I tried to see if it worked using the VLC Media Plyer Active X controller instead. But all my LV version just crashes when I try to insert the VLC media player, anybody else that can do this?

//Mike

[asbo]

I had totally forgotten the VLC even had an ActiveX control. With both v1 and v2, LabVIEW 2011 SP1 crashes without a word.

I think the ActiveX component of VLC is all but a legacy component at this point, based on some of the documentation I read on the VLC site. Still, it would be very cool to embed VLC in a VI.

[Val Brown]

I've had the same kinds of flickering problems with this particular ActiveX. I remember I hooked to the Event Callbacks and deferred panel updates until a particular action was completed. It was not an overlay but rather a resizing problem that caused the ActiveX container to resize to the original video size and then back to the "fit to screen" in a fraction of a second. I couldn't get rid of the effect but this was a workaround that worked in my case. I don't know if such an approach could help in your case...

Yes this is a problem with how LV implemented the ActiveX container for WMP. I've filed SR and even CARs on this for YEARS and NI has simply ignored them.

I do know that it would be VERY EASY fix for them to implement, but there's nothing else to do but something like what you've implemented or very byzantine embedding of WMP in VB constructs.

[MikaelH]

With both v1 and v2, LabVIEW 2011 SP1 crashes without a word.

If you want it to work with VLC, just download the source code and rewrite it to work with LabVIEW ;-)

Download latest VLC source code

If you want, you can download the source code of VLC media player.

[asbo]

If you want it to work with VLC, just download the source code and rewrite it to work with LabVIEW ;-)

It can be tough enough to debug an ActiveX control that's already written ... I wonder how painful it is to debug writing one yourself?

[Val Brown]

It can be tough enough to debug an ActiveX control that's already written ... I wonder how painful it is to debug writing one yourself?

Well...... it CAN be done.... ....but it can be very painful...

[Rolf Kalbermatter]

It can be tough enough to debug an ActiveX control that's already written ... I wonder how painful it is to debug writing one yourself?

Writing ActiveX Controls if there are other solutions is only for real masochists . Go the DLL path, that gives you a lot more control in the debugging process, avoids an entire level of obscure Windows 3.1 imposed limitations, and a few more levels of intermediate bullshit, and last but not least if done with a little planning in mind, you can port it to every single platform that LabVIEW and VLC support without to much effort.

[Val Brown]

Writing ActiveX Controls if there are other solutions is only for real masochists . Go the DLL path, that gives you a lot more control in the debugging process, avoids an entire level of obscure Windows 3.1 imposed limitations, and a few more levels of intermediate bullshit, and last but not least if done with a little planning in mind, you can port it to every single platform that LabVIEW and VLC support without to much effort.

Yes, that's definitely the way to go.

[asbo]

Writing ActiveX Controls if there are other solutions is only for real masochists . Go the DLL path, that gives you a lot more control in the debugging process, avoids an entire level of obscure Windows 3.1 imposed limitations, and a few more levels of intermediate bullshit, and last but not least if done with a little planning in mind, you can port it to every single platform that LabVIEW and VLC support without to much effort.

No doubt On the DLL interface, what is the rendering interface? The nicety of the ActiveX control is that it gives you a bounded space on your front panel for display. I haven't seen this sort of thing with other DLLs.

[Rolf Kalbermatter]

No doubt On the DLL interface, what is the rendering interface? The nicety of the ActiveX control is that it gives you a bounded space on your front panel for display. I haven't seen this sort of thing with other DLLs.

Rendering is obviously an issue, but ActiveX is not the solution here, as it is at best a "briccolage" as the French say. The most simple way would involve some copying of the data into a LabVIEW Indicator like the Picture Control. Not ideal in terms of performance but at least doable in any LabVIEW platform without issues about overlapping and such.

I would love to be able to create my own control like the IMAQ control, but alas that is not an option for us mere mortals as it requires to much NI internal only knowledge about LabVIEW.

The second best would be to use a VI panel as a sub panel and reserve the entire VI as render surface. Extract the platform graphics port (HWND on Windows) and pass it to VLC to let it render its output directly into it. there will be issues with overlap of other elements with that Window but ActiveX has that too, and the only way to get that right is to hook into the internal LabVIEW object messaging which is not an option without serious access to at least some parts of the LabVIEW interna.

[asbo]

I was pondering the latter option and wondered if that VLC would be able to pull enough information via the HWND to know what boundaries to draw to. I need to stop thinking about this before I start trying things...

[Rolf Kalbermatter]

I was pondering the latter option and wondered if that VLC would be able to pull enough information via the HWND to know what boundaries to draw to. I need to stop thinking about this before I start trying things...

No VLC could not be aware of anything besides the HWND boundaries at all, since everything inside a VI front panel is LabVIEW specific and not visible to anything that only knows about Windows details. It would be definitely a case of a VI panel being used for nothing else but a HWND container and there is no sensible way of sharing that with any LabVIEW controls or whatsoever in the same Window. It is even worse than that, as VLC can not know if you overlay that panel by something else in LabVIEW.

On the other hand VLC does not have to worry about blitting only within the Windows bounderies as long as it uses GDI or friends for it. Windows will make sure that any blitting will only occur in the window boundary no matter what. That changes of course if VLC would do direct blitting into graphics frame buffers, but as far as I know this is strongly discouraged by Windows and actually made very hard since it requires hardware specific code which is able to deal with various graphics card drivers.