From what I understand programs like xSplit use DirectShow Filters (VHScrCap) to capture the desktop or running applications (such as games)
Fraps I believe uses driver hooking in order to record the game footage.
My question is what are the benefits of each method?
In addition to that are there any game recording software that use directshow filters or broadcasting software that use driver hooking? If not why?
With DirectShow you can capture video on external device such as camera, or substitute your presenter in order to make something stream into your code rather than to actual display device. None of these cover capturing the desktop and DirectShow has nothing to do with this.
Desktop capture takes place either by polling desktop (easy but inefficient) or providing mirror display driver, or by flavors of hooks. In any event the goal is to receive screen updates as early as possible, with best possible detail about the data being presented.
Related
I am wondering (out of curiosity) how to encrypt a chunk of pixels (e.g. a captcha) in a server application, such that a client cannot use any kind of pattern recognition (neural networks etc.) to decrypt the pixels but will see the correct pixels on his / her screen. I have heard of techniques such as HDCP and I am wondering if there are any libraries to implement this. So my questions are:
Is HDCP the droid I am looking for / are there other solutions?
Are there any libraries that help me to implement this (in C++, Python, Go, Java, whatever)?
Is it possible to use this technique for various (small) patches of the screen (not fullscreen)?
Maybe it is even possible to encrypt/decrypt pixel patches with transparency?
Thank you for your help.
From your description I'm assuming you're talking about a server-client relationship across the internet here. In that case: No. Way.
In order to display anything on screen, something has to decrypt/decode the data on the client and then send it to the screen. That decryption/decoding would be happening in the browser, on the CPU/GPU, and the decoded image would then be stored in memory. From there it's available to any other process, including neural networks and whatnot.
What you would need for this is some way to send encrypted data over the internet directly to the monitor, where it needs to be decrypted and immediately displayed. You would also somehow need to keep the implementation detail a secret, so nobody could be building a "fake monitor" to do the decryption elsewhere and get at the data this way. That's fundamentally infeasible, and even more so given the open standards based protocols and file formats on the internet.
i am working on a project that uses qr code to check in guest at an event. i intended to implement it as a mobile app on android but my professor require a hardware element to the project. so my question s are
can i do decoding of a qr-code image on a microcontroller with a CMOS camera and which one is recommended?
if not, is it possible to use a cmos camera with a microcontroller to take the picture and send it to a pc to do the decoding and which microcontroller is recommended?
any other suggestion will be appreciated
I wouldn't try to decode QR Code with something less powerful than ARM.
Ad 1.
Of course you can, but, as I said, I wouldn't try on something less powerful than ARM (unless you're a C ninja and you can fit into, say, AVR for this task).
Decoding QR code itself isn't that hard and I you'll be able to write it by yourself (or use existing library).
Ad 2.
You'll need some connectivity to do that. There are many Bluetooth, Ethernet and WLAN boards around (in my experience, best choice may be Bluetooth, you may get away without implementing network stack).
Useful link.
Decoding QR codes is relatively easy as barcodes go. You can use source code from the ZXing library, running on the server side (it's primarily Java) to do the decoding. Decoding is "fast"; on the original Android (ARM7) devices it would still decode in about 100ms.
But I think your question is about image quality. I am not familiar with the output of CMOS sensors, but for QR codes, you don't need color data and you don't need much resolution (240x240 works for most QR codes). If anything the issue is focus.
I'm currently dealing with Windows Media Foundation. However, due to some problems with the Microsoft H.264 decoder and some missing decoders for custom format, I'd like to know if it would be possible to instantiate a DirectShow Decoder directly using CLSID, and build a proxy around it that exposes IMFTransform to get a decoder for Media Foundation. So here is my question:
Can i instantiate a Directshow filter (preferrably decoders) directly and use them for decoding (i.e. put some compressed frames and get uncompressed ones) to create a MFT?
I know how to instantiate the filter itself using its CLSID. However, I have no clue how to use the actual decoding functionality.
Any ideas, hints, links whatever will be appreciated. Thanks,
J.
(disclaimer: I have never actually done this, but I see no technical reason it cannot be done. So YMMV)
If the decoder is a DMO filter, then it'll be a lot easier--you can talk to it through IMediaObject. This isn't really much different from how DirectShow uses DMOs; it simply wraps the DMO with another transform filter that handles the media type negotiation and sample passing, but there's nothing really stopping you from doing this in your own application.
There's one catch: for IMediaObject::ProcessInput and IMediaObject::ProcessOutput, you'll need your own buffer class that implements IMediaBuffer. But it's a pretty basic interface, so I don't think you'll have too much trouble implementing it. Here's a basic implementation.
For regular directshow filters, it's actually going to be a lot more difficult, because most DirectShow filters really depend on there being an external graph available (case in point: all of the directshow eventing sort of presumes the existence of this graph). If you really want to use a single DShow filter standalone, you'd probably have to wrap the entire filter graph, and then have a custom source filter to feed samples in. You could use the sample grabber (or a custom render filter) to yank samples out of the graph and expose to the rest of the application. (one sort of crazy idea would even be to wrap this graph in a DMO filter implementation, and then use IMediaObject to talk to it--this might be tricky, however)
Luckily most decoders tend to be implemented as DMO filters, so I think there's a strong likelihood that you can just use IMediaObject.
I'm unsure as to why you would want to do this. You don't really want a filter living outside of a graph.
If you don't want to use the traditional file / network source filters, or the traditional renderers, you can write buffer renderers, and buffer source filters, that you pass pointers to, and get pointers from. Then you can drop the whole mess into a graph and run it, and get the use of the decoder pretty much directly without anything else. This wouldn't be difficult to do. The decoder is probably expecting a PES packet stream though.
We have a device that has an analog camera. We have a card that samples it and digitizes it. This is all done in directx. At this point in time, replacing hardware is not an option, but we need to code such that we can see this video feed real-time regardless of any hardware or underlying operating system changes occur in the future.
Along this line, we've chosen Qt to implement a GUI to view this camera feed. However, if we move to a linux or other embedded platform in the future and change other hardware (including the physical device where the camera/video sampler lives), we will need to change the camera display software as well, and that's going to be a pain because we need to integrate it into our GUI.
What i proposed was migrating to a more abstract model where data is sent over a socket to the GUI and the video is displayed live after being parsed from the socket stream.
First, is this a good idea or a bad idea?
Secondly, how would you implement such a thing? How do the video samplers usually give usable output? How can I push this output over a socket? Once I am on the receiving end parsing the output, how do I know what to do with the output (as in how to get the output to render)? The only thing I can think of would be to write each sample to a file and then to display the contents of the file every time a new sample arrives. This seems like an inefficient solution to me, if it would work at all.
How do you recommend I handle this? Are there any cross-platform libraries available for such a thing?
Thank you.
edit: i am willing to accept suggestions of something different rather than what is listed above.
Have you looked at QVision? It is a Qt based framework for managing video and video processing. You don't need the processing, but I think it will do what you want.
Anything that duplicates the video stream is going to cost you in performance, especially in an embedded space. In most situations for video, I think you're better off trying to use local hardware acceleration to blast the video directly to the screen. With some proper encapsulation, you should be able to use Qt for the GUI surrounding the video, and have a class that is platform specific that you use to control the actual video drawing to the screen (where to draw, and how big, etc.).
Edit:
You may also want to look at the Phonon library. I haven't looked at it much, but it appears to support showing video that may be acquired from a range of different sources.
I would like to solder a microcontroller, control buttons and an DVI/HDMI output and program this in a way, that I can store images on it and let them display as a dia-show via the outputs.
It doesn't have to have a lot of storage capacity, 128Mb would be enough.
but I don't know how to start, because I haven't done anything like this before.
My aim is to present some important images to friends by just taking this hardware, connecting it to a TV screen and showing these photos. If should be able to switch the photos manually (using a button) or automatically in a dia-show.
It should support several TV resolutions and it should be connectable to my PC (USB prefered), so that I can upload and delete photos.
So where to start and how to do that?
Thank you in advance, Andreas
If your aim is just to show some photos, there are assuredly simpler and more cost effective ways to do so; devices exist which do more or less exactly what you are proposing.
If your aim is to learn about microcontrollers and this is a project your are taking up to further that, I would recommend looking into the Arduino: http://www.arduino.cc/ or a similar kit based micro, and growing your project from that.
Microcontroller + low level language will be a huge pain to work with, particularly if you wish to handle various file formats and screen resolutions. Get a full-blown computer with an OS instead - something like http://en.wikipedia.org/wiki/PC/104
If your goal is purely to be able to display photos then I would recommend using a digital camera with video out capabilities.
If your aim is to learn about electronics and microcontrollers I would start with a good book and an Arduino board. Note that writing microcontroller code to handle file systems, image formats and video output is non-trivial. Simpler projects may be a better starting point as they are more accessible resulting in quicker progress, less frustration and more motivation!
The engineering field is a interesting field. You can start with the web site "www.microchip.com". You will need a high end device consider the PIC32MX795L512, there is a nice starter kit for it, "Ethernet Starter Kit" http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en545713. This kit has the on board debugger & programmer to do all the hard work.
You get sample projects with the package, you can program using ansi c programming.
IDE : MPLAB which is free, and the C32 compiler has a student/lite version.
Arduino also has a board with the same device.
I personally like "www.techtoys.com.hk", they have device compatible with Microchip boards like techtoys.com.hk/PIC_boards/PIC32STK%20SSD1963%20EVK/PIC32STK%20SSD1963%20EVK%20R1A.htm, or this techtoys.com.hk/PIC_boards/PIC2432EVK-RD4/PIC2432%20EVK%20RD4.htm where this board you will need a debugger/programmer like the low cost PIC Kit 3 "microchip.com/pickit3".
The trouble is you need to write the HDMI video library yourself, there are some VGA libraries available but they are only black and white and very hard to get color with these analog images. The rest of the libraries are already there, USB MSD(flash drive), SD Card, pictures (jpg) etc.
microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784
Feel free to contact me if you need some help, I might be able to help with the HDMI library.
It's a lot of fun to play with these toys.
Regards
Lucas
B-Eng Digital Engineering.
imlucanio#yahoo.com (no spamming)
Remember to add the http and www to the web links.
It sounds like you want an iPod. That is a dead simple thing to work with and it does everything you want. Otherwise, very complicated. I'd suggest the BeagleBoard and embedded Linux. Yes, it warrants that level of complexity.
The options for small microcontrollers just aren't there. The Arduino is very popular and yes, you can interface an SD card to it. That'd be your storage. Yes, you can put a digital potentiometer on it, that can be your interface. I've seen some video overlays that do simple text, but never any JPEG display (too much processing required). And certainly no 24 bit color (so that the output would actually look good) - that would take WAY too many pins to do correctly (and the Arduino doesn't have a D/A converter! You'd have to rig something up that would suck). And even then, all of the options for TV out weren't HDMI, but RCA (the old red/white/yellow cables).
So in short, no. Get a computer. That's what can do the job.