I need capture video and save it to hard drive every xxx minutes. It will be win-service, which is always capturing and saving. There would be several cameras, so I think use processing thread per camera. So if I decide use Thread instead of timer, I should use Thread.Sleep before saving operation. To my mind it's not good practice.
So the question is my design(thread per camera) appropriate for my situation? What about timers?
Thanks, Andrew
Your code may get occasional lockups due to global mutex'es (for example, in driver).
Also, for example, you have open input in one thread, you're flushing it to some stream, and you want to read it from other thread: mutex lock happens. Same with timers. Considering the event-driven machine too hard to implement here, you still can fallback to multiple instances..
You could have a look at the code for the open-source project Media Portal at http://www.team-mediaportal.com/
Look at their sub-project called TvEngine3.
You could force it to graph your cameras as a "Tuner" device, and set it to record via api.
Point is, they've worked out hundreds of DirectShow issues, and there are many.
I would definitively go for one thread per camera as chances are you'd use less than 20-30 cameras. But it is probably not required as reading a camera (usually) is a non-blocking operation.
There are several questions on webcam and video in C# on SO. Try looking at How do I capture video from a webcam?
Note that you may want to pre-allocate large chunks of data to avoid disk fragmentation. Storing multiple streaming videos to disk could really fragment stuff, and then watching/copying/modifying the videos would be really slow.
Related
Specifically I'm looking to perform a two channel convolution operation on an audio file at playback. i.e. to add a reverb effect to the file using an impulse response, before it is sent to the sound card for playing.
There is a distinct lack of examples or references to performing this operation in real-time in a C# application.
The NAudio (and maybe CScore) libraries look most promising but the absence of built in convoliution engine seems odd, is this likely because there is not enough call for it or is it more likely that a managed application is not suited to such operations?
Therefore it leads me to ask the posted question Can the real-time multi-channel audio convolution be performed in a C# application?
Yes, no problem you can do this. C# applications however aren't great for audio playback because of possible garbage collection delays. You'll need a fairly large buffer on the sound card and that introduces lag into your signal. From a file that's no issue, from a microphone in real-time it's not so great. I have a system that plays back three music streams simultaneously on three separate sound cards and muxes in additional speech files with ducking all written in C#. I do run the playback threads at higher priority also.
As to why there's no existing library to do this (there probably is), it's a fairly trivial piece of code: just multiplying and adding on a 1D stream of values.
I have a Windows Store app with an option to export certain data in a video file format. My app is in C#, but the encoding itself is handled by dropping into a C++ library adapted from this sample by David Catuhe and is working well. The problem is that I have found is that the encoding process can take a long time when run at high quality, and if the screen times out (say, on a Surface RT) or the user switches apps, the process fails. I'm not entirely sure what the source of the failure is and am working to verify it, but even if the process were able to survive suspension without changes, I don't know how to handle being tombstoned.
I can live with the encoding being interrupted in certain situations. What I don't want is to have to start over from scratch if the app goes away for some reason.
As far as I can tell, it isn't feasible to simply close the stream without finalizing the video and resume writing to it later. In light of this, I have considered a few options, but I can't tell which, if any, might actually work. I'd be very grateful for some direction.
1) If possible, it'd be great to be able to simply close the stream and reopen it later, picking up where I left off. At the moment I haven't been able to get this to work, but if it SHOULD work I'd love to know.
2) Push the encode process to a background task, either from the start or only when tombstoned. But is there a way to pass an open stream from my app to a background task? If not, is there a way to get my app's background task to run without CPU/memory limitations at least while my app is in the foreground? Because doing a whole encode within the very tight constraints that normally bind background tasks would take years.
3) Render segments of the video progressively while the app is in the foreground and then stitch the parts together at the end. This way, if the encode is interrupted I can pick up at the most recent segment. From my reading this should be possible in theory (I think it falls under the category of remuxing, which would avoid the need to re-encode the video). But I haven't found any samples that cover this scenario, not even in C++ (which I have almost no experience with). The Transcode API doesn't seem to cover joining multiple samples. I've looked into using SharpDX to do it, but the most likely candidate for what I'd want to use (a Media Session) is only exposed for desktop apps.
4) Push the work off to either a desktop or server app. The problem is I want to have this run on Windows RT (so desktop is out) and I don't currently have a business model that can support servers capable of handling such intensive work on my customers' behalf.
So my question is, what is my best line of attack here? Is there any way to hold onto my stream across suspension? And if, as I suspect, option #3 is my best bet, do you know of any samples or guides on how to do it? Obviously C# options would be very much preferred, so I hope I am overlooking one. C++ might be OK (as it was with Mr. Catuhe's sample that got me this far), but I'm afraid I'd need some pretty specific guidance. The MSDN documentation on this, incidentally, is so high-level that I have only a vague idea of even which pieces I would need to assemble and what each requires, let alone how to write the actual program in C++.
Any help you could offer would be very much appreciated.
Unfortunately I don't have enough reputation points on SO to just comment so I have to give this as an answer.
You could consider a combination of #3 and #4. Render in segments within your app and then upload the segments for stitching together. This would bring you back into the realms of using a commodity solution to create your final output.
I have a wpf app writing to a text logfile fairly infrequently (from 0.25s to 4s between writes).
Each write is one short line of text.
I don't flush after every write.
At the moment, this is called directly on the main UI thread, as I figure the length of time taken isn't even beginning to become close to being a concern.
..Is the right way to do it, though?
Should I have the logging process on it's own thread, and send some asynchronous event to it to log the data?
Have a look at NLog, Spring or any of the multitude of logging platforms. Make your app cool and worry about the best way to do logging later. Logging calls will be made from your gui methods, how they are implemented should be abstracted onto a framework so you can put them on different threads etc. if required.
May I suggest trying Log4Net? It handles all of this for you in a very simple, lightweight and easy to use package.
File writes are buffered by the file system cache. It takes but a handful of microseconds. You'd have to write at a rate of ~10 megabytes per second or have a heavily fragmented hard drive to ever get the cache to fill up so that you have to wait for the disk. You're not close to this by a long shot.
I think at this write rate, you would get more overhead from the thread(context switches, syncronize it, etc.) than not doing it.
It is not a big deal in your case to keep logging process in the UI thread, however I personally would prefer to write the logs in a different thread because doing so separate the work of logging from your main thread and that good for maintainability and it is commonly that logs may be more frequent due to requirement change or bug tracing or maybe you would like to change to windows event log..
I think going with a logging thread is better choice.
You might want to take a lot at MSDN's Managed Threading Best Practices, particularly the note about Parallel Programming in the .NET Framework. Plus I'd personally recommend you to rely on a logging framework such as Apache log4net.
I'm going to split a program into two parts, because I'm running out of process memory. One part is taking a picture and storing it on the file system (GUI) and the other part is analyzing the picture (OCR) and reporting the results back to the main part.
The communication between the two processes will look like this:
Is the OCR process responding?
If not, start OCR process.
Tell the OCR process that there is a new picture.
Wait until the OCR process returns the result (most likely less than 1 KB of characters)
The three most important things, in order of priority for me are:
High performance
High stability
Low complexity - I've only got around three days to finish and test the program.
The GUI is written in .NET/C#, so the solution must be compatible with that. Which method of IPC would you recommend me to use?
I'd probably use point to point queues for this. They perform very well and are stable - the kernel uses them for it's own notification system. The MSDN article already has the managed classes built for using them, so complexity is also low.
You could use WCF for Windows Mobile. Microsoft have released guidelines and sample projects for how to do this. If you set it up to use message queue end points (I'm not sure if named pipes are available), then performance should be very good. Apart from that, WCF is a very easy technology to get started with. Good luck!
Can C# be used for developing a real-time application that involves taking input from web cam continuously and processing the input?
You cannot use any main stream garbage collected language for “hard real-time systems”, as the garbage collect will sometimes stop the system responding in a defined time. Avoiding allocating object can help, however you need a way to prove you are not creating any garbage and that the garbage collector will not kick in.
However most “real time” systems don’t in fact need to always respond within a hard time limit, so it all comes down do what you mean by “real time”.
Even when parts of the system needs to be “hard real time” often other large parts of the system like the UI don’t.
(I think your app needs to be fast rather than “real time”, if 1 frame is lost every 100 years how many people will get killed?)
I've used C# to create multiple realtime, high speed, machine vision applications that run 24/7 and have moving machinery dependent on the application. If something goes wrong in the software, something immediately and visibly goes wrong in the real world.
I've found that C#/.Net provide pretty good functionality for doing so. As others have said, definitely stay on top of garbage collection. Break up to processing into several logical steps, and have separate threads working each. I've found the Producer Consumer programming model to work well for this, perhaps ConcurrentQueue for starters.
You could start with something like:
Thread 1 captures the camera image, converts it to some format, and puts it into an ImageQueue
Thread 2 consumes from the ImageQueue, processing the image and comes up with a data object that is put onto a ProcessedQueue
Thread 3 consumes from the ProcessedQueue and does something interesting with the results.
If Thread 2 takes too long, Threads 1 and 3 are still chugging along. If you have a multicore processor you'll be throwing more hardware at the math. You could also use several threads in place of any thread that I wrote above, although you'd have to take care of ordering the results manually.
Edit
After reading other peoples answers, you could probably argue my definition of "realtime". In my case, the computer produces targets that it sends to motion controllers which do the actual realtime motion. The motion controllers provide their own safety layers for things like timing, max/min ranges, smooth accel/decelerations and safety sensors. These controllers read sensors across an entire factory with a cycle time of less than 1ms.
Absolutely. The key will be to avoid garbage collection and memory management as much as possible. Try to avoid new-ing objects as much as possible, using buffers or object pools when you can.
Of course, someone has even developed a library to do that: AForge.NET
As with any real-time application and not just C#, you'll have to manage the buffers well as #David suggested.
Not only that, there're also the XNA Framework (for things like 3D games) and you can program DirectX using C# as well which are very real-time.
And did you know that, if you want, you can do pointer manipulations in C# too?
It depends on how 'real-time' it needs to be; ie, what your timing constraints are, and how quickly you need to 'do something'.
If you can handle 'doing something' maybe every 300ms or so in .NET, say on a timer event, I've found Windows to work okay. Note that this is something I found true on multiple systems of different ages and different speeds. As always, YMMV.
But that number is awfully long for a lot of applications. Maybe not for yours.
Do some research, make sure your app responds quickly enough for your application.