Tag Archives: camera

Using IP Video Source programmatically as a standalone DirectShow Video Source Filter for JPEG and M-JPEG IP Cameras

Posted by on July 17, 2011 No comments

Recent IP Video Source class/module is not limited to use via registration as a video input/capture/source device. The filter is also registered as a regular filter and can be used programmatically in a regular way: CoCreateInstance, AddFilter etc.

A C++ code snippet below shows how to import interface definition, create an instance of the filter, set it up and start video from a camera:

#include <dshow.h>
#pragma comment(lib, "strmiids.lib")

#import "libid:BDCE8B49-8895-4605-8278-E9A1FBC889AC" no_namespace raw_interfaces_only raw_dispinterfaces named_guids // IpVideoSource

// [...]

inline VOID ATLENSURE_INLINE_SUCCEEDED(HRESULT nResult)
{
    ATLENSURE_SUCCEEDED(nResult);
}

// [...]

CComPtr<IBaseFilter> pBaseFilter;
ATLENSURE_INLINE_SUCCEEDED(pBaseFilter.CoCreateInstance(CLSID_JpegVideoSourceFilter));
CComQIPtr<IJpegVideoSourceFilter> pJpegVideoSourceFilter = pBaseFilter;
ATLENSURE_THROW(pJpegVideoSourceFilter, E_NOINTERFACE);
ATLENSURE_INLINE_SUCCEEDED(pFilterGraph->AddFilter(pBaseFilter, L"Source"));

ATLENSURE_INLINE_SUCCEEDED(pJpegVideoSourceFilter->put_Location(CComBSTR(_T("http://p.viewnetcam.com:60001/nphMotionJpeg?Resolution=640x480&Quality=Standard"))));
ATLENSURE_INLINE_SUCCEEDED(pJpegVideoSourceFilter->put_Width(640));
ATLENSURE_INLINE_SUCCEEDED(pJpegVideoSourceFilter->put_Height(480));

#pragma region Render Output Pin
CComPtr<IEnumPins> pEnumPins;
ATLENSURE_INLINE_SUCCEEDED(pBaseFilter->EnumPins(&pEnumPins));
CComPtr<IPin> pPin;
ATLENSURE_THROW(pEnumPins->Next(1, &pPin, NULL) == S_OK, E_FAIL);
ATLASSERT(pPin);
ATLENSURE_INLINE_SUCCEEDED(pFilterGraph->Render(pPin));
#pragma endregion

This starts M-JPEG video from Panasonic BB-HCM381A camera available to public online at http://p.viewnetcam.com:60001/nphMotionJpeg?Resolution=640×480&Quality=Standard

UPDATE: ATLENSURE_SUCCEEDED macro in the snippet replaced with ATLENSURE_INLINE_SUCCEEDED – see additional post on this.

C#.NET code snippet will look like this (using DirectShowLib):

using DirectShowLib;
using AlaxInfoIpVideoSource;

// [...]

FilterGraph filterGraph = new FilterGraph();
IJpegVideoSourceFilter sourceFilter = Activator.CreateInstance(Type.GetTypeFromCLSID(new Guid("{A8DA2ECB-DEF6-414D-8CE2-E651640DBA4F}"))) as IJpegVideoSourceFilter;
IBaseFilter sourceBaseFilter = sourceFilter as IBaseFilter;
(filterGraph as IFilterGraph2).AddFilter(sourceBaseFilter, "Source");
sourceFilter.Location = @"http://p.viewnetcam.com:60001/nphMotionJpeg?Resolution=640x480&Quality=Standard";
sourceFilter.Width = 640;
sourceFilter.Height = 480;
IPin pin = DsFindPin.ByDirection(sourceBaseFilter, PinDirection.Output, 0);
(filterGraph as IFilterGraph2).Render(pin);
(filterGraph as IMediaControl).Run();
EventCode eventCode;
(filterGraph as IMediaEvent).WaitForCompletion(-1, out eventCode);

IP Video Source: Pure JPEG URLs and Software Version

Posted by on June 7, 2011 8 comments

This does not update the software with new features, but there are a few simple things worth mentioning explicitly.

The first is that virtual DirectShow camera device can be set up with both M-JPEG and JPEG URLs. That is, IP cameras which do not implement M-JPEG, or implement it in a buggy way (there is a *huge* deal of such out there) can still be set up to send video as individual video frames/images as long as they implement JPEG snapshots. This is taking place often at a lower frame rate, but still works.

The driver will automatically detect type of URL (by response from the device) and will choose best access method for the given URL.

Second is that if you are looking for IP Video Source software version, such as to check against available updates, it is here on the UI (right click the caption):

IP Video Source: 64-bit version, resolution flexibility, Adobe FMLE

Posted by on June 5, 2011 7 comments

The IP Video Source update provides several improvements to the driver:

  • copy/paste feature to backup, restore, or synchronize installed devices between 32-bit and 64-bit versions
  • 64-bit version and .MSI
  • dynamic video resizing (via Video Resizer DSP)
  • Adobe FMLE compatibility

Updates in greater detail follow.

Device Copy/Paste Feature

The video device management window is providing Copy and Paste buttons, which let user transfer device information, including name and settings, through clipboard for various purposes:

  • save data in order to be able to restore devices later
  • restore devices from saved list, or re-create from a list saved on another machine
  • duplicate a device
  • synchronize devices between 32-bit and 64-bit versions

The device data is a text, one line per device, lines in comma-separated values (CSV) format.

Read more »

DirectShow Video Source Filter for JPEG and M-JPEG IP Cameras

Posted by on May 23, 2011 1 comment

This implements a DirectShow driver/wrapper over a HTTP based JPEG/M-JPEG streamed video, widely available with IP cameras. Once installed, it provides a Start Menu shortcut to manage video capture devices, where a user can add/remove devices. The devices are automatically registered with DriectShow and are available to applications.

The compatibility list includes:

  • Windows SDK AmCap Sample (reference)
  • VideoLan VLC
  • Skype (see below)
  • Google Talk Video Chat
  • Luxriot (as rather an example as Luxriot has its own generic JPEG/M-JPEG device driver, however this still demonstrates compatibility and interoperability of applications)
  • GraphEdit, GraphStudio and similar tools

Read more »

MediaTools: How to manually configure filters to render M-JPEG video stream from an IP camera

Posted by on August 5, 2009 No comments

Media Tools DirectShow Filters can be used to acquire, parse and decoder M-JPEG encoded video stream from an IP camera or a video server, however for a quick start it is necessary to properly register filters on system and create a DirectShow graph.

To register the filters, it is necessary to download DLLs from repository. While Acquisition.dll does not require special prerequisites installed, CodingI.dll is using Intel Integrated Performance Primitives (IPP) version 6.0.0 internally and requires its [at least] redistributables installed before DLLs are being registered using regsvr32.

Intel went further with new releases of IPP, which are incompatible with the version used to build CodingI.dll, so it is version 6.0.0 (in downloads on Intel website: version 6.0 build 0) has to be installed. Note that Intel DLLs from C:\Program Files\Intel\IPP\6.0.0.044\ia32\bin (version 6.0.0.062 is known to be also compatible) need to be on system search path, or copied to C:\Windows\system32 directory.

Once Intel IPP is prepared, it is required to register CodingI.dll using regsvr32. This registers filters and they are available in GraphEdit and for applications. It is important that on the way of constructing graph which renders video using standard video renderers it is required to specify correct resolution for video, or otherwise graph might fail to start with a message “The graph could not change state”, caused by video renderer failure to dynamically change to different (effective) resolution.

To create rendering graph, add Alax.Info HTTP Stream Source Filter from the filter list and provide camera URL in properties, e.g. http://cam15001.miemasu.net/nphMotionJPEG?Kind=1

Adding Alax.Info HTTP Stream Source Filter

Read more »

MediaTools: HTTP Stream File Renderer Filter and more

Posted by on February 14, 2009 2 comments

In order to better troubleshoot network cameras and other devices, I added a new DirectShow filter to write HTTP response headers and body into a single file, one file (actually a pairs of files, the second file contains UTF-8 formatted HTTP response headers) per HTTP response.

While troubleshootting JPEG artefact issue with I used the following graph:

HTTP Stream File Renderer Filter in Filter Graph

which started M-JPEG streaming from a camera and had entire stream written into Response-01586228-0001-0001-Headers.txt (Headers) and Response-01586228-0001-0001.dat (Data) files, while parsed JPEG frames were also written into individual files and were available for comparison.

Other changes include:

  • new HTTP Stream File Renderer Filter (details are below)
  • attachable media types on internally used memory allocators, which enable filters to effectively reagree media types in running state
  • workaround for Panasonic BL-C140 camera (may be also helpful for other models), details here

There also seems to be a bug in Intel IPP 6.0 JPEG decoder that leaves bottom right image block incorrectly decoded, only when a sequence of images is decoded and the frame is not the first in the sequence.

A partial Visual C++ .NET 2008 source code is available from SVN, release binary included.

Read more »

JPEG Multi File Video Capture Source Filter, a virtual DirectShow camera

Posted by on January 17, 2009 11 comments

Provided that there already is a JPEG Multi File Source Filter that can act as a video source streaming video from local JPEG files, it looked to be useful to build a virtual camera on top of this filter. This is the main difference: an existing filter is generic and customizable: it requires to be provided a directory with the files, other settings may also apply. A virtual camera is the filter that has to work out of the box: a video enabled application, such as AMCap Sample, Media Player Classic, VideoLAN, Skype, Windows Media Encoder enumerates video capture sources, instantiate the one of the interest and it should already be ready to stream.

Implementation Details

The very first question is embedding of an existing filter into new filter. The two most common methods are:

  • COM aggregation
  • embedding a fully featured graph with a sink/renderer that intercepts media samples downstream and forwards to a higher level filter so that it streams them as a source filter

The COM aggregation methods is much easier in implementation but it is subject to a few constraints, the two most important of which are:

  • embedded filter should support instantiation as an aggregated object
  • it is the only underlying filter, not a chain of filters, which can produce required data

COM aggregation is quite fitting for the purpose, so the second embedding method is being left for another topic (with a certain luck to be appear very soon, a DirectShow video capture source filter for a real network/IP camera).

The next step is a check of sufficient implementation in an underlying filter. Obviously, a video source that pretends to be a live video capture source needs an endless stream of media samples, while original implementation streams JPEG files as media samples once only, we need an option to loop the streaming and automatically repeat the sequence.

Playback looping is added to the original JPEG Multi File Source Filter and its controlling private interface IJpegMultiFileSourceFilter received additional properties:

interface IJpegMultiFileSourceFilter : IDispatch
{
...
    [propget, id(2)] HRESULT AutoRepeat([out, retval] VARIANT_BOOL* pbAutoRepeat);
    [propput, id(2)] HRESULT AutoRepeat([in] VARIANT_BOOL bAutoRepeat);
    [propget, id(3)] HRESULT RepeatDelay([out, retval] LONG* pnRepeatDelay);
    [propput, id(3)] HRESULT RepeatDelay([in] LONG nRepeatDelay)

as well the new property page:

Read more »