I'm trying to implement camera security in my application. I got some SDK's from some security companys to implement there system but they all use ActiveX. My view right now is that ActiveX is kinda old?
But what is the newest way to get video from devices and display (stream) them on a screen?
What control to use in .net 4.5 WPF (and Windows 8)
I'm working on video WPF app for two years now and we had a fundamental problem with video and WPF which was never resolved, and that's variable fps-rate. This blog post goes into details.
There's also a nice library called Media Kit (by Jeremiah Morrill), it might be suitable for your problem.
In our solution we had no choice but to expose HWND's for our rendering DirectX engine. We accomplished this by using HwndHost class and extending it to our custom WPF control. Note this is the base class for windows forms host, so you get the same amount of problems as with WinForms-WPF inter op.
Also, ActiveX is the only way to display professional camera video streams in web interfaces, it's still a defacto industry standard, you'll get it from MOXA, Acti, Vivotek and various other camera equipment manufactureres.
One more thing, if you need to perform some advanced analysis of video, I'd suggest OpenCV.
Related
I know it is somehow possible to implement a windows media player in a form with Visual C#.
The info for that is here: How to add the libraries and here How to code it.
But my project is in Visual C++ and I'm having a hard time finding how to do the same. It is a windows store application based on an example from a Hearth Rate Bluetooth monitor.
My goal is to play a video while the data acquisition occurs.
The answer is Windows Store App can't handle ActiveX controls. At least in a straightforward way.
The solution was to implement a MediaElement from the Toolbox into the XAML page. That element is easy to use with mediaElement.Play() and mediaElement.SetSource()
I'm developping a SmartDevice application (Pocket PC 2003 template) in C# for a device with Windows Mobile 6.1. I need to use the camera of this device (photos, video); to do this work i tried using the CameraCaptureDialog class but it does not work for Pocket PC applications.
So, I documented on the internet and found that I probably refer to DirectShow API, but the problem is that I do not know where to start because I can't found a working/correct example.
My questions:
Is this the right way? Are there alternatives?
Where I can find a very good example that shows how to do this work?
You may try directshowbetcf: http://alexmogurenko.com/blog/directshownetcf/ if you really want to go with DirectShow and NetCF.
There's plenty of examples of directshow on the web. There is a site dedicated to converting the API over to C# which makes it a lot easier, maybe this was it http://directshownet.sourceforge.net/about.html. I struggled with DirectShow until I read the book "programming directshow" from microsoft press. About a third of that way through that book it all seemed incredibly easy and I was able to complete what I wanted. In the end it's a lot like referencing any library and using the classes from within that library. The added difficulty is that you need to add wrappers because they are all COM objects but that has been done for you.
This might be useful to you to understand the DirectShow technology. Basically gives a start to DirctShow and explains some of the important points. But its C++ not C#. Hope this help
Basic Video Capture
DirectShow is the video capture API in Windows Mobile 6. There is a Video Capture Filter there and all in all things are designed pretty much the same way they are in Windows.
The problem is that however that this is a native API, and not just in Windows Mobile. To develop in C# you need some bindings and they are missing. On desktop there is DirectShow.NET, which is a missing piece, but it does not seem to fit well for CE. Yet you still need to fill this gap in Windows Mobile.
To work it around you have a few ways, the first would be to go through DirectShow.NET and update it appropriately to start working on your device, strip parts missing in mobile OS etc. This would get you a twin for DS.NET but for mobile operating system.
Another option would be to do some C++ development and implement the minimal sufficient feature set in that domain, exposing the component via COM. Then you will reference this from managed code and things will get connected together. And another obvious option would be to use a third party solution which already does one of the mentioned above.
Lately, I've been trying to setup a media center PC. I've played around with all the common media center applications like XBMC, Plex, Boxee, and WMC. But all of them have one issue or another. So I was thinking about writing my own application from scratch.
My problem is I have no experience with developing software that plays media such as videos or music. I'm also not interested in spending a huge amount of time trying to figure this out, considering all the different file formats and codecs out there. I'm really more interested in developing the database and library interface for my application and reusing someone else's control or code for actually playing the media.
One option I was thinking was to just control an existing media player externally. So for example you may browse for a video to play in my application, and then when you hit play it would fire up VideoLAN or some other popular video player.
However, I was wondering if there was an easy way to play video inside a .NET application. I'm looking for something that is capable of playing a wide variety of formats such as MKV files, and DVD ISOs. I'm more experience with WinForms, but was also thinking about using this project as an opportunity to learn WPF.
i've spent many years looking at playing video under wpf.
The short answer
There is no easy way to guarantee to be able to play a variety of formats under wpf ( mkv,dvd etc etc ) or under windows for that matter.
the long answer
If you are looking just to run this at home and not release it, install all the codecs you need and most of the formats will run via mediaelement in wpf.
Getting all the codecs to cooperate can sometimes be frustrating.
Now moving into slightly harder territory.
if you want to play DVD then you need to replace mediaelement with wpfmediakit
http://wpfmediakit.codeplex.com/
wpfmediakit gives a base library to get access to the low level directshow functionality.
There is already a code base for playing DVDs based on wpfmediakit.
Now moving onto the very hard territory.
if you want to distribute your application and have users be able to "just watch" most/all media formats means you need to be able to completely control their codecs, which generally means distributing the codecs with your package and building the directshow filter graph in code rather than let windows build it.
The easiest way is to use the existing .Net hooks to Microsoft's standard MediaPlayer:
http://msdn.microsoft.com/en-us/library/system.windows.media.mediaplayer.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/dd562851%28v=vs.85%29.aspx
was trying myself a while ago for something to play media in winforms, and found out there is vlc wrappers for .Net, dunno how good they are as i gave up, but you can try
here is one them:
http://vlcdotnet.codeplex.com/
Thanks for all the great answers. But just found out that VLC can actually be controlled through HTTP. So I think I'm just going to use that to point an instance of VLC running with the HTTP interface at whatever file I want to play.
I recently purchased an XBox 360 and was first introduced to the term "Media Extender". I didn't realize that windows had the ability to stream content to an XBox and was very surprised and excited. I also noticed that people wrote their own plugins that allowed streaming of, for example, netflix. I would like to know more about how to do this but find it hard to even Google it because I know so little about the terminology (I'm not sure whether the XBox is the "extender" or the "extender" is a plugin that makes the Xbox stream). Can anybody explain this technology to me and perhaps direct me to good getting started reference for building my own plugins (for instance, to stream Pandora to the Xbox)?
An Xbox 360 is a Windows Media Center Extender device, implemented in software on the Xbox. Dedicated hardware implementations exist, such as this, but I don't think they've ever taken off like they were supposed to.
Windows Media Center can be extended via its APIs for building add-ins. Take a look at this Google search.
In my experience (we use this in our lounge) not all plugins seem to work via the Xbox 360 - some work only on the PC.
Hope this helps some.
I am hoping to receive some general guidance on accomplishing a seemingly simple goal. I have a DSLR camera (Canon EOS 50D) and need to write an application that will tell the camera to take a picture. I also need to transfer the picture to the computer and possibly delete it from the camera's storage. A bonus would be to get a live preview from the camera in my application. My environment will be Windows (either XP Pro or Vista Enterprise) and .Net 3.5 (C#).
I have done some research and found a couple of options. One I know will work, but limits me to using only Canon cameras in the future. I have found and downloaded an SDK from Canon that provides a lot of this functionality. I've looked over the SDK and while it's extensive and written in C it does have C# wrappers that will speed up development a bit.
Another option I've found is called Windows Portable Devices. Apparently, it is an API that will talk to devices that implement PTP and MTP standards. It is COM based and as far as I can tell it has no .Net wrappers. This is not however a show stopper. I could P/Invoke the functionality I need or write a Managed C++ DLL to use in my application to talk to the camera.
I am looking for anyone with experience with WPD to give me pointers. I've perused the documentation and seen references to transferring images and deleting images. I have not, however, seen mention of commands to take a picture, get a preview image, or say focus/auto-focus.
The WPD api provides the command WPD_COMMAND_STILL_IMAGE_CAPTURE_INITIATE
I am not sure whether your camera supports it but it should be simple enough to find out. If you can get the "wpdinfo" tool from the driver development kit and start it with your camera connected then send it a WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_COMMANDS command and see if it supports the still image capture command. IF so then you could give that a try.
The comment from TallGanglyGuy is incorrect. ptp does allow you to trigger new images and change exposure, etc. Some cameras have firmware that only exposes some of the ptp commands.
PTP supports common device controls, such as taking a picture, so that
the user could take advantage of the PC/camera combination in new and
different ways again, without requiring additional software.
quoted from http://msdn.microsoft.com/en-us/windows/hardware/gg463507.aspx#EXC
try my Eos Framework: https://github.com/esskar/Canon.Eos.Framework
IMHO it's a better alternative then the .cs file that comes with the SDK.
PTP and MTP are both protocols for transferring files from a digital still camera (DSC). The protocols provide no functionality for triggering new images, or setting exposure control. You will be stuck using the camera specific SDK. If you want multiple vendor support Nikon has an SDK that provides similar support as the Canon SDK for their cameras.
More info on PTP and MTP can be found here:
http://en.wikipedia.org/wiki/Picture_Transfer_Protocol
and
http://en.wikipedia.org/wiki/Media_Transfer_Protocol
EDIT
I forgot to mention that WIA may be interesting to you, assuming your camera's driver provides a WIA interface.
This is really generic, but it may help.
I had to write an application that used two different bar code scanners from two different vendors with different SDK's. I created an interface that defined the methods and events that I wanted to code for, and then wrote adapter classes that implemented my interface.
This worked well in my case, and switching from one to the other was pretty seamless. If you took the same approach, you wouldn't be totally dependent upon one SDK.