Tag Archives: camera - Page 2

MediaTools to deliver video from network/IP cameras and video servers into DirectShow environment

Posted by on January 10, 2009 14 comments

I decided to gather DirectShow code and filters related to processing video from network/IP cameras and video servers into a library (in fact, a few libraries) so that it could be easily used for testing, research and other purposes. As time is going to permit, documentation and sample code will be provided, further development will be carried out.

This initial post publishes two libraries (DLLs) which host DirectShow filters to receive JPEG or M-JPEG video from network using HTTP based protocol, decode video with the help of Intel IPP 6.0 library (UMC version of the JPEG implementation), as well as perform additional helpful features, including writing series of frames into .JPG files and emulating video feed from saved .JPG files, conversion filters to obtain video in 24-bit and 32-bit RGB formats, YUY2 and YV12 formats.

File and Class Summary

Acqusition.dll

Acqusition.dll (download) hosts the following classes:

  • DirectShow Filters
    • HTTP Stream Source Filter, to receive HTTP content and deliver into DirectShow environment through output pin
    • JPEG HTTP Stream Parser Filter, to parse HTTP content (typically received from HTTP Stream Source Filter) of image/jpeg and multipart/x-mixed-replace types and output JPEG frames
    • JPEG Multi File Renderer Filter, to write parsed JPEG frames (typically received from JPEG HTTP Stream Parser Filter) into files
    • JPEG Multi File Source Filter, to read JPEG files (typically written by JPEG Multi File Renderer Filter) and stream video into DirectShow environmentto emulate video feed

Acqusition.dll is dependent only on well known DLLs and does not require presence/redistribution of specific dependency files.

CodingI.dll

CodingI.dll (download) hosts the following classes:

  • DirectShow Filters
    • JPEG Frame Decoder Filter, to parse JPEG data and pass frames downstream with a corresponding mediatype provided with VIDEOINFOHEADER format and correct resolution; in case of resolution changes the filter is capable of dynamically re-agreeing media type with downstream peer
    • JPEG Decoder Filter, to decode JPEG data into 24-bit/32-bit RGB (unfortunately Intel IPP codec has limited capabilities of decoding video into YUV pixel formats)
    • YUY2 Encoder Filter, to convert RGB data into YUY2 pixel format
    • YV12 Encoder Filter, to convert RGB data into YV12 pixel format
  • Shell Extensions
    • JPEG File Resolution Shell Property Page, to provide additional information (such as sampling, color format, resolution) about .JPG and .JPEG files through a shell property page

CodingI.dll is dependent on Intel IPP 6.0 library DLLs and relies on availability of these dependencies in the system. For the CodingI.dll to be operationable, it is required to have a free, trial or registered version of Intel IPP library installed. In particular, the files that are sufficient to be present/redistributed are:

  • libguide40.dll, libiomp5md.dll
  • ippcore-6.0.dll
  • ippi-6.0.dll, ippj-6.0.dll, ipps-6.0.dll, ippcc-6.0.dll, ippvc-6.0.dll
  • ippipx-6.0.dll, ippjpx-6.0.dll, ippspx-6.0.dll, ippccpx-6.0.dll, ippvcpx-6.0.dll

Quick Usage Example

Given a M-JPEG compatible network camera on IP address 98.76.54.32, the graph constructed as shown below is capable to deliver video data and render it through standard Video Mixing Renderer Filter.

Assume the camera is StarDot NetCam SC series, with /jpeg.cgi HTTP request to query for JPEG image and /nph-mjpeg.cgi HTTP request to query for M-JPEG video feed.

To construct the graph in GraphEdit (GraphStudio), first it is required to manually add Alax.Info HTTP Stream Source Filter and provide HTTP URL for the request in the property page:

Then an Alax.Info JPEG HTTP Stream Parser Filter is added and connected downstream to the previously added source filter:

A this point it is possible to automatically render output pin and DirectShow intelligent connect will add the rest of required filters, Alax.Info JPEG Frame Decoder (I), Alax.Info JPEG Decoder (I) and Video Renderer.

However, in order for the graph to run in GraphEdit it is required to manually provide correct video resolution in the properties of JPEG Frame Decoder Filter and once applied reconnect all downstream connections up to video renderer in order to enforce new media type.

Running the graph will start streaming video.

Class Overview

HTTP Stream Source Filter

The filter sends one or series of HTTP requests to receive data from network location and stream received data into DirectShow environment.

Read more »

Network Cameras and Video Servers

Posted by on September 2, 2008 No comments

An example to give an idea of how robust and reliable network cameras and video servers today are. Fl***h made video encoder hardware.

The request is http://***.***.***.***/cgi-bin/***.cgi?***, it informs on capabilities of the device.

...
SupportDigitalOutputCount=4
SupportDigitalIutputCount=4
...

IQeye camera video quality

Posted by on August 20, 2008 No comments

That was a good one. Quality setting UI title vs. internal identifier on an IQeye705 camera:

  • “superfine” = xlow
  • “fine” = low
  • “high” = medium
  • “medium” = high

Mobotix cameras online (updated)

Posted by on August 20, 2008 No comments

Mobotix cameras online, various models discovered by web spider bot, see previous list here:

Basic

D10D-Secure

D12D-Sec

Read more »

Y-Cam Black camera

Posted by on August 10, 2008 1 comment

A customer complained that he was unable to get things working with Y-Cam Black camera. Naming models using colors is already a sign that problems are inevitable. The camera either had old firmware and implemented a different protocol (other than documented) or the documentation sucked but I would like to mention a different thing.

I was impressed that the camera did not accept HTTP authentication from FireFox. Sure it claims to be RFC 2616 (Hypertext Transfer Protocol — HTTP/1.1) compliant, it would get insulted being suspected in not abiding it by, but still the fact: open camera URL from Internet Explorer and you get authorized after a propmt for a password and a valid entry. Open it using FireFox and you will be kept prompted for the password infinitely. No firmware updates available free, one should be requested by email. People are seriously releasing and selling such a crappy stuff.

There is a demo camera, a different model however (White) http://guest:guest@y-cam.dtdns.net:8152/, it is free from this issue.

I am whining about software/firmware only, if you need a comprehensive review on the camera, you can find it on networkwebcams.co.uk/blog.

Read more »

TRENDnet Cameras Online

Posted by on July 26, 2008 No comments

Found at http://trendnet.com/demo/

One more time TRENDnet guys proved they can screw any great idea. M-JPEG content sent by TV-IP422W cameras has no indication of proper MIME type. We can survive this, thanks blokes you are at least giving Content-Length value! The major problem is that IJG decoder stumbles with exception on the JPEGs: each frame is prepended by 28 byte informational header (hopefully – I will have to look into the source code to find out) messing video decoder. I hope in future TRENDnet devs will discover APPn JPEG markers or multipart/mixed content-type subheaders and find it more approprioate to put this information into these cozy places.

TV-IP301W just has a typo in multipart/mixed header:

GET /goform/video3 HTTP/1.0
User-Agent:
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=
Connection: Keep-Alive

Content-Type: multipart/mixed;boundry=cellvision
–cellvisionContent-Type: image/mpeg
HTTP/1.1 200 OK

OMG!!! Response line goes after Content-Type header… There is just nothing to say about this.

By “image/mpeg” (I have not found it in MIME type reference) they mean server-pushed stream of JPEG images, by the way.

BUT! These new models TV-IP212/TV-IP212W/TV-IP312/TV-IP312W/TV-IP422/TV-IP422W are much much better than older on the product line and they are still not expensive. I believe they are going to be very popular.

See also:

More about APIs

Posted by on July 2, 2008 No comments

Just recently there was a problem discovered in considered to be stable DirectShow component (the problem itself is not fatal – access violation while being used in improbable scenario – and thus it may appear it is even ignored), another “pleasant” thing came up with an API from another vendor.

The camera vendor is recognized in the industry and even considered to be among leaders, kind of “cheap for superior quality”. Their SDK/API has always been offered to reach several goals: the first was to cover product line with unified access method; the second was to embed implementation of a not so much popular TFTP protocol used for this type of hardware (rivals use more popular protocols: HTTP, RTSP). These not include regular things like to documented access to variety of features, availability for Win32 and Linux etc.

API documentation has always been not very much accurate as if it was given insufficient attention but luckily it was quite simple to figure things out. Another warning thing was that native software worked directly, without SDK: it was not very good for independent software vendors like us because there was a suspicion that SDK was something complimentary and was undertested. Fortunately however, the vendor decided to change this and their mainstream software started using the same SDK redistributables available for independent vendors also.

The first incident was recently when the vendor changed SDK implementation without changing published API and without giving any notice in documentation on one of the features. It did not break compilation or anything in our software, however it started working differently in production environment. We started receiving complaints and since we did not find any documentation changes, contacted the vendor’s support for comments and found out that implementation has been changed…

Now we got a new issue. As mentioned before, SDK’s advantage was to cover product line being constantly extended. New hardware from the product line appears to be quite sophisticated – a camera with multiple sensors. I believe this was not the thing foreseen when original SDK was designed so there was a kind of solution to workaround indexed access to individual sensor parameters in the API. However it appeared now that new products don’t support some of the older product features and SDK instead of returning a kind of “unsupported” error code to the requests, instead it messes other values. So it appeared that unified access to the product line was broken…

Everything was finally sorted out but in total it took a lot of time to. First of all, the problem due to its nature spread to production from where the dealer started receiving complaints from his client. The dealer in his turn forwarded the issue to us where we had problems investigating it because this particular piece of hardware is a kind of rare and expensive. When we gather sufficient data to think of the case as an SDK bug we forwarded the issue to the vendor.

Obviously the vendor responded with ridiculous suggestions assuming us to be complete lamers. Still we were in position to help our client and resolve the case, so spent some time to gather additional information to prove the supposition of an SDK bug. It took quite some time at our expense while finally we could work out a workaround for the problem and soon after receive a confirmation for a bug… Can we expect it to be fixed with next SDK update? “We will do this some time later”.

Why things happen this way? OK we are a small ISV with our own problems getting things work as expected. The vendor, however, is a high technology leader, well known and recognized throughout the industry, a subject of a completely different scale. Expensive hardware ans software is involved and we are still getting ridiculous problems at the output.