It seems like windows MF (Media foundation) they have moved from Driver MFT's to Device MFT's for there UVC camera's. Now this wouldn't be a huge problem but almost all of the examples are for Driver MFT's. So i'm trying to figure out whats the difference. So i could remake some of the examples to work.
This is inline with this users request for a Driver MFT example.
Device MFT Implementation
Related
I am new to the topic of the MFT in NTFS. I have read a number of documents about it but so far I haven't found explicit statements on some questions that immediately come to mind.
If you have a Windows desktop and read files from a removable medium which is NTFS-formatted (say, a USB stick or removable HD), then I assume that the timeline information (access dates etc) gets written to the MFT on the removable medium. So, if the USB or HD is removed, the timeline disappears. Does the host OS (the Windows desktop) retain any information separately about which files were opened and on which removable volume?
Articles on MFT say that initially, no MFT record is deleted when a file is deleted. So the MFT grows and grows. There is mention that some of the records of deleted files will eventually get overwritten as the disk fills up: but I can't find details about the algorithm used. At the same time there is the implication that there is no upper limit on MFT size, and that it can crash thinly-resourced systems. This sounds rather extreme. So, is there any way of trimming the dead wood (eg, a utility which will permanently delete the unwanted entries)? I read that the OS won't allow the MFT size to be changed on an active system, but perhaps a utility could run before the full system loads, as CHKDSK does (I think)?
Can a hard upper limit on MFT size be set (short of completely filling the HD)?
Recently I have built a virtual camera filter using Vivek's VCam (http://tmhare.mvps.org/downloads.htm) in directshow but it works only in softwares which can show user mode filters. So to make my virtual device available in all softwares I have to built a kernel mode driver.
I have two questions.
Can I somehow overcome this problem with user mode directshow filter?
If not how can I get camera streaming through AVStream avshws driver available in WDK sample drivers or if there is anyother easy solution for it then please suggest?
I'm developping H.264 capture application executed on Windows XP SP3(32bit).
The application cause memory leak when I implement Capture Test
(I'm checking Virtual Size colum of "Process Explorer").
When I change directshow encoder filter, amount of leak is changed.
So I'm suspecting directshow H.264 filter(encoder or multiplexor or both) as the cause of the memory leak.
Would you please tell me if you have heard "Free" directshow H.264 filter which never cause memory leak?
---- Follow up 2015-07-09 ----
I execute the application on WindowsXP: leaked
I execute the application on Windows 7 : not leaked
Are there any difference related to memory allocation/free between XP and 7...?
---- Follow up 2015-07-10 ----
I checked constructed graph on WindowsXP and Windows7 using GraphStudioNext.
H.264 Encoder : the same CLSID between WindowsXP and Windows7
H.264 Multiplexor : the same CLSID between WindowsXP and Windows7
Now I have attempted the H.264 filters below.
H.264 encoder: ffdshow_rev3572_20100913_clsid, AX_components H264 encoder, x264vfw
H.264 multiplexor: GDCL-H.264Multiplexor(updated 05 Jun 2015)
On both platforms, graph is below.
[USB Camera]---->[Smart Tee]---->[H.264 Encoder]---->[H.264 Mux]--->[File Writer]
matter of concern:
In GraphStudioNext's Filter Propaties, WindowsXP using quartz.dll,
but Windows7 using proppage.dll. Is this difference important..?
On Windows XP, ALLOCATOR PROPATIES are exists, but 7 are not exists.
This might be a lame question for this site, but here goes.
Can drivers be portable? For instance, could one write a driver for the keyboard-backlight of a mac, and port it to another unix system, maybe Solaris?
or is driver portability a contradiction in terms?
any articles covering this topic would be much appreciated.
Device drivers need to serve two layers of abstraction which makes portability at least hard:
1) Of course the driver needs to be written for a specific device. Your understandable assumption is now that once I implemented a driver according to a proper device specification (data sheet, ...), why shouldn't it run on every computer that needs to access the device.
In comes point
2) Drivers are written to fit into a certain operating system. Each OS has its own means of
a) accessing devices, e.g., the functions for reading/writing I/O ports might be called differently or have different signatures. Furthermore
b), the ultimate goal of a driver is to make the device accessible to the user - be it through a file system interface or network sockets or the X input protocol. For these purposes each OS again comes with its own set of abstractions that the driver needs to fit into.
These are the reasons porting drivers is kind of hard. Nevertheless, there are approaches that try to achieve this, most of the time by wrapping the original driver with glue code that translates the expected driver/OS interface into the target interfaces.
NDISWrapper is a library that allows running Windows WiFi drivers on Linux,
Some guys from Karlsruhe proposed to use device-driver virtual machines,
Several OS frameworks I'm aware of use device-driver wrapper libraries to run Linux/BSD device drivers in their environments. See for instance Genode, L4Re, Minix3.
Yes, they can be.
Assuming a driver is written for the device specifications, the only thing that prevents the driver portability is the underlying operating systems as different operating systems have different architecture and different controls to call and load device drivers.
But there have been known implementations, wherein the underlying OS could be abstracted and a uniform platform could be provided. This can lead to driver portability.
I am currently trying to write a network monitoring software for windows mobile 6. I googled a lot and some people say that it is not possible to use a NDIS driver or WinPcap or so for monitoring any network interface. Others say that it is possible. Fact is, that I found no exaples, nor any sourcecode on the net.
Therefore I ask this community: Is it possible to write a packet capturing tool that works on data-link layer for windows mobile in C or C#?
with best regards
Desktop and Server Windows products have a very defined, generic, and pluggable structure into which you can insert hooks into the network layer. (Look up LSP or Layered Service Provider - this is how AntiVirus/Firewall programs plug themselves into monitoring your network traffic). As far as WinPCap, it plugs in one level lower at the NDIS driver level, but regardless, Windows Mobile just is not nearly as flexible when it comes to this. I don't necessarily think it's just Microsoft being short-sighted here, though - it takes much more power to provide a generic and pluggable LSP or NDIS layer that most mobile devices just can't afford.
The most important point here - NDIS Packet Capturing is not supported for Windows Mobile. Closest you can get to a mobile platform with packet capture is Windows Embedded CE.
So, in order to capture network traffic for Windows Mobile you would need to develop your own NDIS driver framework. Not a small task.
Windows Mobile uses Windows CE.
NDIS is very much present on Windows Mobile, so you can write an intermediate driver to capture traffic.
However, it already has netlog which should do the work for you: http://msdn.microsoft.com/en-us/library/ms883126.aspx