|
Use PreTranslateMessage.
BOOL CMyDlg::PreTranslateMessage(MSG* pMsg)
{
if (pMsg->message == WM_KEYDOWN)
{
int nKey = pMsg->wParam ;
if ( nKey == VK_ESCAPE )
{
return TRUE;
}
}
return CDialog::PreTranslateMessage(pMsg);
}
|
|
|
|
|
Fast man! I was about to type it, but had to ask Alok a question 
He is no fool who gives what he cannot keep to gain what he cannot lose.
- Jim Elliot
|
|
|
|
|
Taken chance, when you was not alert. 
|
|
|
|
|
Override OnCancel(). To allow the window to be closed, call CDialog::OnCancel(), otherwise don't.
/ravi
|
|
|
|
|
(Sorry for the cross posting, but I figured there may be people here who don't visit the lounge.)
Are there any DirectShow gurus here? (I'd rather ask some complex questions to someone with a ready answer than wade through Microsoft's absolutely horrible documentation on this.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
I'm no guru but I use DirectShow quite a bit.
If nothing else I can probably direct you to the right place in the documentation 
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Since my posting, some of my questions were resolved by running a simple test that showed our embedded hardware simply couldn't do what the bosses originally requested. However, we're moving on to plan B, which still leaves some open questions.
The main one is whether there is a straightforward method of capturing video straight to memory (no preview)?
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
My solution was to use a custom renderer filter. It's implemented as a renderer so it handles
all the necessary allocator stuff but instead of rendering it calls a callback function for each
frame of video.
It's similar to a frame grabber filter but is a renderer - only has an input pin.
I used one of the DirectShow samples as a starting point - I'm trying to figure out which one
it was! I'm pretty sure it was the "Grabber Filter Sample".
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
hi,
someone could explain to me how it works and with a simple example how could i after:
OpenProcess(); then -> duplicatehandles() into the currentprocess how can i use NtQueryObject to list the open objects handles from that current process..
my problem is how can i list the objects, i cant realy understand very much from the examples in this forum, or in some webpages, coz the examples are very diferent and use structures in c++...
if someone could just give a simple example, i dont know if i do NtQueryObject to the handle that was stored the duplicateHandle() information and how can i list... coz i use toolhelp32 to get processid and other information and to list the process's you have functions like process32next to go into the next line and next line to list the process's but in NtQueryObject i dont understand how to list...
pls help thanks
|
|
|
|
|
van-ux wrote: ...the examples are very diferent and use structures in c++...
Here is a non-C++ example.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
That example uses a bunch of structures! 
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Hi,
I was wondering what is the maximum limit (size) of an RWCString. I believe, it used to be 64K with 16 bit plateforms. Is there any limitations in 32 bit and 64 bit plateforms?
Will appreciate if you could provide me this info.
THanks
|
|
|
|
|
You have the source code, so why don't you look yourself? My guess is 2 billion characters (MAX_INT).
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
RWCString::length() returns maximum byte count of size_t
|
|
|
|
|
|
I've been looking all over for an answer to this, no luck, so maybe someone here has encountered it before...
I'm using DirectShow to do a video app, and creating another window on the secondary monitor for the mixed output from multiple graphs.
I won't bore you with all the DS details of the allocator/swap chain, but it works ok. The problem is, when the window is created on the secondary monitor, the CPU usage runs 90-100%, and the app is not robust, to say the least.
If the window is created on the primary monitor, no problem with CPU usage.
I see that with DS sample apps as well, when you drag them to the 2nd (dual view), they eat up much more usage.
I can run VJ type apps that do similar, and they seem to work fine on the same hardware setup, so I doubt it's hardware/driver related, probably more to do with how I'm creating the window (standard CreateEx stuff).
If anyone has done this sort of stuff before, I would love to hear how you did it, as it's very frustrating, with the docs being so bad for DS...
Thanx.
|
|
|
|
|
What video renderer filter are you using?
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
I'm using the VMR9 with multiple graphs. This is being presented by a modified version of the MultiVMR9 allocator/presenter.
I basically create an additional swap chain to present the additional window on the second monitor.
|
|
|
|
|
Are you using the IVMRMonitorConfig9 interface on the renderer to set the playback monitor?
I ask because it sounds like it's DirectX related. I have no problem on multple monitors with
a custom renderer which uses GDI. It uses close to 0 CPU.
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Mark,
I've had no luck in getting SetMonitor to work, which is why I went to the MultiVMR9 sample.
The MS folks on the DirectShow forum, told me to use an additional swapchain or device, and I managed to get each way working, but they both still have the same problem with CPU usage when the window is created from my app on the secondary monitor, and then passed as an HWND to the MultiVMR9 allocator.
The MultiVMR9 is a complicated beast to work with, but so far, has proven the only way I can get this thing presenting to more than one monitor.
Here's what it kinda looks like:
Player 1 goes to a VMR9 renderer (has own small window on primary).
+ to the allocator
Player 2 goes to a VMR9 renderer (has own small window on primary).
+ to the allocator
Each of these are a separate renderer in the subgraphs.
Both original VMRs go to the MultiVMR9 DLL A/P, which renders onto a preview window on the primary display.
That is StretchRect'ed onto the additional swapchain in the allocator, which is the window I created on the secondary monitor in my app.
I require the separate graphs, as I need control over each of the input streams/files, for seeking, alpha, etc.
I've tried looking at this with Spy++, but see no messages coming through.
Totally befuddled, since I can look at other apps that do it...
|
|
|
|
|
Hmm your setup makes total sense, but the CPU usage doesn't (but you knew that already ).
If you set up your additional swapchain to go to a window on the primary display does the CPU
usage stay down?
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
If I create the window on the primary monitor, CPU usage hovers around 15% while rendering the video, about what I would expect. When I create it on the second monitor, it hovers around 95%.
What's kind of weirder, is that it's using high CPU (70+%), even when not rendering or having a file loaded. At that stage, the window has already been created and handle passed to the A/P.
I'm not sure how Windows handles the secondary monitor internally, but obviously something is going on behind the scenes, and I don't see any messages being passed...
|
|
|
|
|
Yeah that's what makes me suspect a DirectX (actually, more specifcally, a Direct3D) issue.
Sounds like it's in the renderer stage, not the DirectShow part.
I'm no multi-monitor video adapter expert, but I remember reading something in the past about
some adapters that support 2 monitors use the onboard video RAM for the primary but if there's
not enough video RAM for the secondary it uses system RAM...I wish I could remember the
details
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
I appear to have gotten somewhere...
By changing the adapter parameter from D3DADAPTER_DEFAULT to 1, in the CreateDevice, it seems to work much better (although still a bit more CPU than if on the primary).
I'm not sure I totally understand that though, since the CreateDevice is done on the preview window on the primary display, and the additional swapchain is what handles the secondary monitor...
Since the MultiVMR9 DLL is so complex, I think I'm gonna have a stab at writing my own custom A/P, and just incorporating it into my app, as opposed to using their DLL.
If I get it working well, I'll post it here as an article, so hopefully nobody else will have to go through this tangled mess
|
|
|
|
|
Again I use custom renderers implemented using GDI so the Direct3D stuff is vague to me
Did you mention, are you using 1 video adapter or 2?
I guess it's obvious the CPU is doing a bunch of work that normally the DirectX-enabled video
processor handles...
Also, are you actually mixing two streams into one VMR or just using multiple VMRs (I'm unclear
how you are using MultiVMR9 dll)?
For my software, I needed multiple viewers of individual media streams (filter graphs).
My solution was to create my own render filters (I use two - one for actual rendering, and one
is more of a framegrabber but implemented as a renderer filter so it completes a filter graph).
For each graph, I implemented it kind of like sockets (I call 'em video sockets).
The graph is built and run using the dumb renderer sitting on an infinite tee. I do that so the
graph can be running already when I attach viewers.
Each time I need a new viewer I just connect an instance of my renderer to the infinite tee
(kinda like a socket). I added a callback to the renderer so I can get a look at every frame
before it's displayed and perhaps mix something (or draw on) with the frame.
The rendering is done with simple old GDI.
The performance is great. With only one graph per stream, the CPU usage is whatever it takes to
capture and move frames given the frame rate and frame size. Adding more views doesn't add
any noticeable CPU (I test this every once in a while - open 20 or 30 video windows on multiple
monitors LOL).
Good luck - I'll look forward to the article!
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
