directshow H.264 encoder which never cause memory leak - directshow

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.

Related

Device MFT vs driver MFT

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

How to run C application Spike (RISC-V 32 simulator) without pk

I am porting an RTOS to RISC-V and I'd like to debug it. Trying to load the RTOS on low memory locations such as 0x0 or 0x1000 yields invalid load from debug module: 8 bytes at 0x0000000000001090. Loading it at 2GB (0x80000000), the spike does not give errors, however when I launch GDB it is unable to single step and viewing the program counter value shows a completely wrong program address 0x5c330dca.

Jprofilerti.dll 9.0.3 Crashes as App starts doing it major purposes

An Eclipse RCP application crashes in the jprofilerti.dll code once I move the app from relatively idle status to full operation.
Some initial profile results are available back on the remote GUI session. This suggests that the configuration of Jprofiler GUI, Jprofiler agent, and network settings is ok.
I wonder if the crash occurs due to buffer overruns. I ask because the network link between the remote JVM and the near laptop JProfiler GUI is very poor with a very low effective bit rate. Is it possible that the target JVM will crash if the remote GUI is too slow about consuming buffered profiling data?

ECC error injection on Intel Xeon C5500 platform and issue with unlocking Integrated memory controller registers

I am working on Error Detection module and was attempting to test using the error injection implementation mentioned in Intel® Xeon® Processor C5500/C3500 Series Datasheet, Volume 2 in section 4.12.40. It asks to program the MC_CHANNEL_X_ADDR_MATCH, MC_CHANNEL_X_ECC_ERROR_MASK and MC_CHANNEL_X_ECC_ERROR_MASK registers but attempting to write to this has no effect. Realized there is a lock for this space which is indicated by status in MEMLOCK_STATUS register (device 0: function 0: offset 88h), which in my case is reporting 0x40401 as the set value. This means MEM_CFG_LOCKED is set and I am not able to even unlock using the MC_CFG_CONTROL register (device 0:function 0: offset 90h). I am writing 0x2 to this register but that does not help to unlock the ECC injection registers for writing. How can I achieve this? I am running FreeBSD on the bare metal and not as a virtual machine.
To the best of my knowledge, the whole TXT thing that is necessary for this is not supported on FreeBSD.
But this a quite an arcane area. You might have more luck asking this on the freebsd-hackers mailing list.

How to create a local virtual IP camera that can be accessed from other software

I need to create several local virtual IP Cameras for a project I'm making. I have tried several software, and the closest I have gotten was with magic camera, because it would let me create a virtual camera, but it wont let me assign a source to that camera. I need to assign an IP address and a username with a password, so that I access the IP camera's video and use that virtual camera in a program I'm developing. the thing is that the Camera's brand is not supported by Labview, so I need to use a virtual local camera to use these cameras (3S Vision IP Cameras).
Thanks in advance!
From the National Instruments Support Knowledgebase:
Connecting to an Arbitrary MJPEG IP Camera with IMAQdx Using Third Party Virtual Camera Emulator
http://digital.ni.com/public.nsf/allkb/9446A8C25CC99F7586257A56004D513D
Here are the options for using an IP cameras in LabVIEW as of 2019:
(in case someone like me still need this)
Use Vision Acquisition Software 14.5 (February 2015)
(with LabVIEW 2014 SP1 and Vision Development Module 2014-2017 SP1)
Pros:
Official, native support;
Any # of cameras.
Cons:
You lose all the features introduced in newer versions of LabVIEW;
Cameras must support and be configured to stream in MJPEG over HTTP.
Additional info:
It's the last version to support arbitrary IP cameras. Basler and Axis IP cameras were supported until VAS 19.0.
Cameras in the same subnet should be detected automatically. If cameras are in another network, you can try to add them manually as follows:
Go to the %Public%\Documents\National Instruments\NI-IMAQdx\Data\ folder;
Open or create a file IPCameras.ini in a text editor;
If creating, place an IPCameras section on a first line:
[IPCameras]
Add a line for each camera in a following format:
cameraSerialNumber = IPAddress, MJPEG stream URL, camera brand, camera description
Save your changes and restart NI MAX.
Use DirectShow device (webcam) emulator
NI-IMAQdx driver supports USB 2.0 cameras through the DirectShow interface. By using software which creates such interface for IP cameras, they can be used as regular USB 2.0 cameras.
There are multiple tools available:
IP Video Source
Pros:
Free;
Any # of cameras.
Cons:
Each camera must be added manually through emulator's settings;
Each camera's resolution must be set manually in emulator's settings;
Cameras must support and be configured to stream in MJPEG over HTTP(S);
32/64-bit versions work independently of each other. NI MAX is a 32-bit application, so it won't show cameras emulated by 64-bit tool. However, they are still detected and can be used in LabVIEW with IMAQdx VIs.
Additional info:
Camera's alias displayed in LabVIEW can be changed in a following way:
Go to the %Public%\Documents\National Instruments\NI-IMAQdx\Data\ folder;
Select one of camX.iid files and open it in a text editor;
Find an attribute InterfaceName and set its value to a desired name. See Vendor attribute's value for a name you set to that camera in emulator's settings;
Save your changes and rename this file to the same name;
Restart LabVIEW.
Moonware Universal Source Filter [more info]
Pros:
Supports JPEG/MJPEG/MPEG4/H264 over HTTP/RTSP;
Hardware decoding;
Low latency;
Multiple cameras.
Cons:
32-bit only. 64-bit version is not likely to happen;
Adds a watermark to an image (free version) / Paid: $49 per PC (no watermark);
Each camera must be added manually through emulator's settings.
and more
Use Multimedia for LabVIEW add-on
Pros:
Native interface (LabVIEW API for FFmpeg libraries);
Supports most codecs and protocols;
Any # of cameras;
Full control over data acquisition and processing (down to individual FFmpeg options).
Cons:
Paid: $949 per PC (developer license), $19 per PC (runtime license), 30 days trial;
Lower-level analog of NI-IMAQdx driver (see more complicated).
Use libVLC to receive images from a camera
(or another similar library)
Pros:
Free;
Supports most codecs and protocols;
Possibility of hardware decoding (depends on library usage);
Any # of cameras.
Cons:
You'll have to interface with libVLC library directly through the Call Library function node;
To receive video frame by frame you'll have to write a simple C library which will be called by libVLC to provide a frame (see example below in a linked thread).

Resources