|
Hello. AFAIK, you can stream h264 live video from IP camera on windows media player. But when I enter URL (rtsp://xxx.xxx.xxx.xxx:7070), following message is shown
Windows Media Player can not play the file because the specified protocol is not supported.
Now the same url works fine on VLC player but NOT on windows media plyer. I have read the following knowledge base article but could not fix the issue. What could be wrong? Thanks for any pointer.
modified 14-Apr-14 2:23am.
|
|
|
|
|
|
I read most of them but could not find the solution. Most of them are repetition of the KB article I provided the link of. Just not sure what should I try now.
|
|
|
|
|
Why doesn't the Bluetooth for android allow hands free talk and text like the windows does?
|
|
|
|
|
Why don't you ask Google?
|
|
|
|
|
It does... I have a Nexus phone and you can certainly do hands-free calling.
|
|
|
|
|
I have a Samsung Galaxy S4, it allows hands-free calling and text, and my previous phone, the Samsung Stratosphere v2 also did, not that I used it much since it had a keyboard. Just takes a little setup.
|
|
|
|
|
Does anyone remember Tetradyne DriverX windows driver software for WinXP and prior? I am looking for a copy of the file DxIntr3.h to build the kernel. I have all other sources. I bought a source license but Tetradyne Software is gone now. Much appreciation.
More information:
I started out just hoping someone had a copy of the file. W/o a copy I see I need to reinvent the missing file.
I have gotten it to compile with the definitions:
typedef struct
{
ULONG nOffset;
ULONG cb;
} READ_WRITE_DMA_BUFFER_INPUT, *PREAD_WRITE_DMA_BUFFER_INPUT;
typedef unsigned char *PUCHAR;
The whole function that requires these definitions is extracted from the file DxDriver.c:
NTSTATUS DxReadWriteDmaBuffer(PDXDEV_EXTENSION pExtension, PVOID pIoBuffer,
ULONG cbInput, PMDL mdl, BOOLEAN read)
{
PREAD_WRITE_DMA_BUFFER_INPUT params;
PUCHAR pOutBuffer;
// Validate parameters
if (!pIoBuffer || (cbInput < sizeof(READ_WRITE_DMA_BUFFER_INPUT)))
return STATUS_INVALID_PARAMETER;
params = (PREAD_WRITE_DMA_BUFFER_INPUT) pIoBuffer;
if ((params->nOffset + params->cb) > pExtension->nDmaBufSize)
return STATUS_INVALID_PARAMETER;
if (!mdl || (MmGetMdlByteCount(mdl) < params->cb))
return STATUS_INVALID_PARAMETER;
if (!pExtension->pDmaBuffer)
return STATUS_UNSUCCESSFUL;
pOutBuffer = MmGetSystemAddressForMdl(mdl);
if (!pOutBuffer)
return STATUS_UNSUCCESSFUL;
if (read)
{
RtlCopyMemory(
pOutBuffer,
(PUCHAR) pExtension->pDmaBuffer + params->nOffset,
params->cb);
}
else
{
RtlCopyMemory(
(PUCHAR) pExtension->pDmaBuffer + params->nOffset,
pOutBuffer,
params->cb);
}
return STATUS_SUCCESS;
}
Anyone see any problem here?
Thanks for the help and clues. Now I move to debug. Bless you all.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Thanks Mr. Muchies for clues and hints. I have it actually working now. Turned out the DMA part was crucial. Now the trick is to port to Windows 7. Any advice or good links you have? Seems like eliminating the HAL calls will be a large part.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
modified 9-Apr-14 14:59pm.
|
|
|
|
|
Blimey, never heard of it, and I have been writing windows drivers since the 90s.
Can you recreate it? Sounds like it might have some defines, some wrappers round WDM api funcs, that kind if thing.
"The whole idea that carbon dioxide is the main cause of the recent global warming is based on a guess that was proved false by empirical evidence during the 1990s." climate-models-go-cold
|
|
|
|
|
To build a version 4xxx kernel driver they use some stuff defined for the version 3xxx driver. Most is interrupt related and since the user mode part of the driver compiles just fine w/o it I concluded that I did not need the old interrupt parts so I faked it.
However the DMA parts wrap new methods around the methods of the prior versions and therefore need some definitions for the driver to compile. At the moment I need definition/declarations for PREAD_WRITE_DMA_BUFFER_INPUT and PUCHAR. These might be structures based on compile errors I get when I typedef'd them to integers to see what would happen.
I was hoping in the vastness of space and time and the Internet someone had a copy of the file DxIntr3.h that they would share.
Thanks for caring.
|
|
|
|
|
I guess the second one is unsigned char * (Pointer to Unsigned CHAR). The first one may be the same or more likely a pointer to the second (unsigned char ** as pointer to address of DMA input buffer).
|
|
|
|
|
Thank you. I think you are exactly right about PUCHAR. However, the other is more complicated. Still working on that one.
|
|
|
|
|
As Joachim says a puchar is just a 32 bit (or 64 bit) pointer, in this case, to an unsigned char.
PREAD_WRITE_DMA_BUFFER_INPUT is also going to be a generic pointer, and will be the size of the addressing on the OKS, so 32 or 64 bit, so a pvoid will do, or pulong, (or if you are doing it properly use SIZE_T since it cross compiles).
"The whole idea that carbon dioxide is the main cause of the recent global warming is based on a guess that was proved false by empirical evidence during the 1990s." climate-models-go-cold
|
|
|
|
|
Thanks.
I have edited the original post to include the code involved. Comments would be appreciated.
|
|
|
|
|
Looks OK. Your definitions fit with the code, time to run it up and see if it crashes! 
"The whole idea that carbon dioxide is the main cause of the recent global warming is based on a guess that was proved false by empirical evidence during the 1990s." climate-models-go-cold
|
|
|
|
|
Yes, I must now put together a WinXP system to test it. Take me a day or so. This code is in the kernel driver. The corresponding user mode driver in this configuration does not as best as I can tell contain a path that calls the function in question so I just needed it to compile (I hope). O/w I am pretty sure it will crash for lack of an actual buffer.
If it works my next chore is to port it to Win7 x64, so I may be back! Appreciate the support to date.
Thanks.
George
|
|
|
|
|
Try using SIZE_T for pointers, they automatically map to 32 and 64 bit addresses depending on which platform you compile for.
"The whole idea that carbon dioxide is the main cause of the recent global warming is based on a guess that was proved false by empirical evidence during the 1990s." climate-models-go-cold
|
|
|
|
|
Thanks Mr. Muchies for clues and hints. I have it actually working now. Turned out the DMA part was crucial. Now the trick is to port to Windows 7. Any advice or good links you have? Seems like eliminating the HAL calls will be a large part.
Thanks again.
|
|
|
|
|
Whats it running on now, XP?
THe 32 bit image will run on win7 (unless its USB, in which case it might need a tweak or two).
As for 64 bit, all your pointers are going to need looking at to make sure they are compatible, that's why I suggested using SIZE_T as it macros to the right size automatically.
Apart form thagt its just a case of building it in the 64 bit env and running it up the pole to see what happens
"The whole idea that carbon dioxide is the main cause of the recent global warming is based on a guess that was proved false by empirical evidence during the 1990s." climate-models-go-cold
|
|
|
|
|
It is running in XP, but I was suspicious when the DDK seemed to be making a Win7 x86 driver. Gave lots of "deprecated" warnings but built anyway [these warnings did not trigger the "warning same as error" switch]. It worked in XP, but Win7 x86 did not like my inf file. Anyway, on a hunch I installed Windows 7 32 bit on my test rig and gave it a try. So far it won't work but I am working on my inf file.
It is a simple driver that maps memory to my device where I have memory mapped control/status areas and some DMA memory for i/o. I am hopeful that may work since it is not USB or storage or network.
As for Win7 x64, thanks for the SIZE_T suggestion. I am sure it will help. Not so sure what to do about the Hal_xxx calls which are not defined in the amd64/x64 model.
Anyway, still plugging. To run on Win7 x86 would be a step forward since my customers don't like running XP anymore. Thanks for your input!
|
|
|
|
|
So it looks like you used the win7 32 bit build env, why not use the XP32 bit one?
Ad for the inf file, run it through chkinf, its a tool that's part of the DDK, it will tell you whats missing.
Hal_xxx? Ah, you could be screwed then. Are you calling x86 specific hal funcs? THey shouldn't be visible, are you sure they are part of the allowed api or are they a hidden func? If you are calling them MSFT wont sign your driver. If you stick to the allowed api it should be the same for all hardware platforms. NT4 used to run on Dec Alphas, Mips, x86, all sorts of stuff.
"The whole idea that carbon dioxide is the main cause of the recent global warming is based on a guess that was proved false by empirical evidence during the 1990s." climate-models-go-cold
|
|
|
|
|
"So it looks like you used the win7 32 bit build env, why not use the XP32 bit one? >>> Actually I got confused building an XP driver and when it worked in XP I was really confused. Gave me the idea to try Win7 x86.
"Ad for the inf file, run it through chkinf, its a tool that's part of the DDK, it will tell you whats missing." >>> I did do that and it was helpful. Apparently not all things are required, though, such as the CAT (certificate). Just have to confirm at install time.
"Hal_xxx? Ah, you could be screwed then. Are you calling x86 specific hal funcs?" >>> Yes. As I said, I did get deprecation warnings but it ran in XP. It may run in Win7 x86 if I can fix it. Seems to be having trouble with initialization. I do use the registry functions also and that is where my current efforts lie.
When I try to build for Win7 x64 the Hal_xxx deprecation warnings turn to undefined errors. So I am guessing that Hal_xxx functions are present in Win7 x86. Maybe Win7 x86 is really a jazzed up XP? Can't find any info about that.
My current efforts now turn to setting up a debug environment so I can trace what is going wrong. The device manager is flagging the initialization, but that covers a lot of ground. Thanks for suggestions.
|
|
|
|
|
Ah, win 7 signing, cat files.
OK, for win7 32 bit run a command shell and type bcdedit -set testsigning on and bcdedit -set loadoptions DDISABLE_INTEGRITY_CHECKS
When you restart you should see 'TestMode' appear in the bottom right.
For win7 64 bit you need to test sign the driver, and do the above. Look at test signing on loine, you need to use inf2cat and signtool and import the certificate into certstore.
Debugging looks daunting at first, but when you get it going its a doddle. WUndbg, and I use firewire, it is quicker than serial. Look at symSrv for MSFTs public symbols, they are very useful.
As for Hal, I wasn't aware they had dropped some funcs from the kernel API, but perhaps they have, or they were forbidden funcs. Look in the DDK documentation, if you cant find them, they are forbidden.
"The whole idea that carbon dioxide is the main cause of the recent global warming is based on a guess that was proved false by empirical evidence during the 1990s." climate-models-go-cold
|
|
|
|
|
As far as signing, the Device Manager driver install hassled me with Q&A about did I really want to do it this and then seemed to try to install. That is when I got the init error.
"DDISABLE_INTEGRITY_CHECKS" >>> I put in both DDISABLE_INTEGRITY_CHECKS and DISABLE_INTEGRITY_CHECKS to be sure. Both were accepted and it worked, system booted in test mode as you said.
I use Remote Desktop to run the target test machine and I have a 1 Gb Ethernet connection. I will have to read the docs to figure out how to run debugger. For regular apps I install the Visual Studio remote debugger on the target and hook Visual Studio to it over the LAN. Pretty sure this will not work for kernel mode debugging.
Sorry, I did not understand your debugging suggestion. Any good docs, links, etc. you would recommend?
And thank you very much for your support. It is appreciated. I figure I will baby step my way to a full Win7 x64 driver. Win7 x86 is a good stepping stone I think.
Thanks again.
|
|
|
|
|
GeorgeMayfield wrote: regular apps I install the Visual Studio remote debugger on the target and hook
Visual Studio to it over the LAN. Pretty sure this will not work for kernel mode
debugging
It wont.
You need to enable debug in the kernel, its the ini file on XP, or system configuration on win7. I like firewire, its quick, but not all machines have it, but you can get firewore pccards and pic cards. For info on this just google it, MSDN will be a good source, OSR online is another great kernel source, very good n fact.
Have fun! Its the bitchiest learning curve in the world, but when you master the windows kernel, everything else is childs play!
"The whole idea that carbon dioxide is the main cause of the recent global warming is based on a guess that was proved false by empirical evidence during the 1990s." climate-models-go-cold
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
