LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What is the quickest way to render video full screen?

 

In my application I am capturing video from a frame grabber at 640x512 resolution. I need to render output to a full screen window with adjustable scaling, and I need this to run at 60Hz.
At the moment I am rendering the video using IMAQ WindDraw, unfortunately it isn’t fast enough when rendering full screen. Drawing to a 640x512 window it manages 60Hz. To get “full screen” output I scale the image by a factor of 2 and draw it to the middle of a 1920x1080 borderless window, matching the screen resolution. In this mode the frame rate drops to roughly 30Hz. (I have verified that it is the rendering not the scaling which is slow.)
I can see three options for increasing the speed:
1. Accelerate the WindDraw function.
(new drivers? faster graphics card? I don’t understand why the drawing process is so slow.)
2. Use a 2D surface in the 3D Picture function.
(I know this uses hardware acceleration I feel it should be quick, but I don’t have evidence and I am having difficulty getting the picture camera setup to avoid distortion.)
3. Use activeX to interface to an external software renderer.
(I know this could work but I have no experience using activeX or interfacing with external programs from Labview, so it is very daunting!)
Does anyone have advice? Any guidance would be greatly appreciated.

 

 

Thanks

 

Luke

Luke_A_P
--
0 Kudos
Message 1 of 8
(3,558 Views)

Hi Luke,

 

Would it be possible for you to upload your existing code, I can then have a look through to see if we can optimise it in any way. Also, which version of the IMAQ driver/Vision Acquisition Software are you currently running? Do you own the Vision Development Module? In terms of your other recommendations for improving performance:

 

1. As with any such graphically intensive process, a faster graphics card will invariably improve performance. Do you have another (higher spec) machine that you could try this out on, to see if this gives the level of performance required?

2. I don't quite understand what you mean by this option. Please elaborate or provide an example so that I can comment.

3. This could give you the performance that you need depending on whether your currently limited by your hardware or the software. Do you have an external software renderer that you could test this out on and does this give you the required performance? The process of interfacing with this in LabVIEW through ActiveX should not be too challenging and there are lots of resources (examples etc.) on the web which would help you out in this process. As a bit of an introduction, see the tutorial I have linked below.

 

ActiveX and LabVIEW

 

I hope this helps.

 

Best Regards,

 

Christian Hartshorne

NI|UK

 

 

0 Kudos
Message 2 of 8
(3,537 Views)

Thanks Christian, I'll put together some simplified examples of my signal chain and post them here.

 

Luke

 

Luke_A_P
--
0 Kudos
Message 3 of 8
(3,530 Views)

Christian,

I have created a demo .vi which includes a simplification of the back-end of my application. I have made this demo so that it can render a dummy video sequence using 3 different methods; IMAQ WindDraw, a 2D picture and a 3D Picture. You can run it and swap in real time between the rendering modes and it reports the framerate. You can turn 2x scaling on and off to see the large effect this has on speed. (I have found drawing the 2x scaled IMAQ to a full screen window is slightly slower still than the 2x mode in this .vi.) After you switch modes bring the appropriate window to the foreground in order to get the proper rendering speed.

 

Using bits from a few examples scattered around the forum, I have put together a 3D picture video renderer. This was not very difficult but unfortunately it is very slow. Playing around a bit, I think it is passing the texture to the object which is slow, not the rendering. I wonder whether anything can be done to improve it. (I also tried it on a laptop with an ATI Radeon graphics accelerator, it was slightly faster, ~10Hz and the frame rate was not affected at all by the window size, which I think slows the rendering is not the bottleneck in that case.)

 

In my full application I have to do about 7ms worth of image processing before the data is ready to display. So whilst this demo .vi gets about 59Hz with a 2x zoom on the image, in the real application I get less than 30 Hz!

 

I hope you can make some sense of this, please let me know if you have any questions.

 

These are the speeds I got on my Lab machine:

 

Core 2 Duo 2.6GHz
3GB RAM
Video Hardware:
Intel(R) 82945G Express Chipset Family

IMAQ
1x - 170Hz
2x - 59Hz

2D Picture
1x - 40Hz
2x - 18Hz

3D Picture
1x - 6Hz
2x - 3Hz

 

Thanks,

Luke

 

Luke_A_P
--
0 Kudos
Message 4 of 8
(3,513 Views)

Hi Luke,

 

Thanks for the comprehensive example, this has been very useful in troubleshooting your problems. Is it absolutely necessary that the video is rendered to a separate window or could we use an Image Display control integrated into the existing window. Some quick testing suggests that this will result in an improvement in performance.

 

I have modified your example and attached it to this post. As you will see, the frame rate seems to be significantly higher for both the scaled and unscaled video. The frame rate does seem to fluctuate quite significantly however.

 

I hope this helps but let me know if you have any further questions.

 

Best Regards,

 

Christian Hartshorne

NI|UK

0 Kudos
Message 5 of 8
(3,474 Views)

Here is the attachment that I mentioned...

 

Christian Hartshorne

NI|UK

0 Kudos
Message 6 of 8
(3,473 Views)

Thanks Christian, I have given your modified vi go. It is faster on my system too, but as you described, the frame rate is less stable. However, I do need an external window so that I can display the image full screen. (I use a borderless IMAQ window sized to fill the screen.) I got a chance to try this test on a 3.8GHz quad core workstation, which did manage about 100Hz in an IMAQ window with 2x zoom (and about 300Hz x1 zoom). At the end of the day I need to make this into a display system that can run on a laptop, so the brute force approach is not really viable. I think the key thing is that the scaling is not taking advantage of the Windows 2D or 3D graphics acceleration. If I can find some way to exploit the directx capabilities I am confident that performance won't be a problem. I have taken a look at the activex tutorial, I'm going to give it a try. Unfortunately, all of my programming experience is in data processing, so I am well out of my depth when it comes to COM and Invoke Methods, it is all new to me! Is the 3D picture rendering path I put together hopelessly under optimised? I wonder if I am missing a trick there. Luke

Luke_A_P
--
0 Kudos
Message 7 of 8
(3,461 Views)

Update:

I have since developed a way to use an imaq front panel display in full screen. It involves resizing the front panel to be larger than the screen and changing it to floating mode to bring it in front of the task bar. The attached example gives an illustration of how it works for a 1920x1080 screen on Windows XP, obviously the code would need to be modified to work with all screen resolutions.

 

This change does produce a significant improvement in performance but it feels like a bit of a hack. I can't help feeling it might be difficult to make it work on all versions of Windows with different display preferences etc. 

 

Luke


Luke_A_P
--
0 Kudos
Message 8 of 8
(3,245 Views)