IP Video Source: Pure JPEG URLs and Software Version

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):

10 Replies to “IP Video Source: Pure JPEG URLs and Software Version”

  1. Hi,

    Now this is a very nice app. But I do have a question. How can get it to use JPEG or PNG images on a local disk or webserver. And update or pull down new as I update my images on disk or on the webserver?

    Is it possible?

    Or how do I make an M-JPEG stream from jpeg pictures (.NET)?

    Thanks!

    • Hi Ken,

      You have a few options here, however if you are planning to interface streaming from your .NET application you would perhaps first of all like to use DirectShow.NET library as a wrapper over DirectShow API, and from there create a filter graph based on my source filter and use Sample Grabber or something similar to capture video.

      This application delivers uncompressed video for best compatibility with applications, showing up IP camera as close as possible to regular webcam. However, capture of original JPEG is also possible.

      Anyway, start with DirectShow.NET, then if you have specific needs or questions, get back in touch for an advice.

  2. Thanks Roman,

    Yes my plan is “send” images from my .NET C# app to a virtual sourcefilter that I can use in UStream or Flash encoder.

    I have played some with DirectShow.NET and graphs some years ago. So I can access your source filter from DirectShow.NET, thats interesting I will have a look.

    /Ken

    • When it comes to filter creation, I would personally prefer native code. Or, if .NET is necessary it would rather be perhaps native code filter with COM interface for interoperability with managed code (alternative option is C++/CLI on the way). But it is perhaps more a choice of favorite tools.

      From .NET domain you will most likely have to use DirectShow.NET wrapper, and perhaps it is going to be good enough for what you are trying to achieve.

  3. Hello, Roman!

    I want to thank you for the least buggy DirectShow filter for IP cameras. So, really thank you =)

    But still there are some bugs in the filter:

    1. When I push the button “Webcam settings” in Skype
    it shows nothing (may be you can make “Manage Video Devices” application to be shown in that case).

    2. Skype and Adobe Flash Applications, which uses webcams can’t control a resolution of an image from IP video source with they standard methods of webcam control.

    3. I don’t know why, but video stream (MJPEG) in Adobe Flash apps slows – either it is of high quality or low.

    It still great work you’ve made, I think a lot of people will be glad if you don’t give up upgrading of the filter to make it perfect.

    tolix

    • 1. Webcam settings – they are trying to show property page in a specific way, there might be a reason to fail doing so, and maybe you are right I could fix it.

      Anyway, because you create a camera and set it up outside of Skype, it might be a good idea to let Skype use it “as is” without modifications in settings. I will check this out when I have a free minute for this.

      2. Skype is actually incapable of using high res video, it will anyway cut its 640×480 from the center of the image. With this behavior I don’t see a good reason of tuning the driver just for Skype.

      But this is perhaps not the main reason. This is a generic driver, and with M-JPEG URL only we cannot really change camera’s resolution.

      To ensure compatibility with applications (including *awfully* made Adobe FMLE) the driver will resize video in code to change resolutions. Any application can take advantage of this in code, but not through UI.

      I don’t see a reason why the driver needs to resize video in software without a reason, it is not a good mode of operation. Changing resolution on camera is specific to camera and model. There is no support for this with generic URL. I could do it for specific model, but not in generic driver.

      3. Flash won’t process JPEG as is, it recompresses video. This is where tit loses quality.

  4. and i’ve forgot to say: I couldn’t get mjpeg stream from d-link DCS-910. I used different URLs “http://:@ipaddress:80/video.cgi”, “http://:@ipaddress:80/video/mjpg.cgi”, i tried same requests in VLC player – it didn’t work, but in firefox browser it did. Then I tried to do it with JPEG (“http://:@ipaddress:80/image/jpeg.cgi”) and it worked.

    What is the problem with that cam?

    • D-Link DCS-900, 950 models are very old and I have been dealing with them years ago. My memory suggest that they send a broken or otherwise non-standard M-JPEG stream. I don’t remember details.

      Later D-Link cameras were OEM models mauufactured by Vivotek – those were the models easy to deal with (with definitely good M-JPEG). At some point later, D-Link again changed their partner and the cameras again were not as good in terms of M-JPEG.

  5. Hi!
    We are finding that the Alax.Info JPEG Video Input Devices could match our requirements.

    We need to broadcast from a network camera using Microsoft Expression Encoder to use its smooth streaming feature.

    The 1st problem is that MEE does not accept urls as live source. At this point your app makes the trick as when configured, it exposes new live sources to MEE and works fine.
    The test has been done using an AxisP1346 camera and is is ok (http://user:pwd@ip/axis-cgi/mjpg/video.cgi?resolution=640×480&camera=1&compression=25).

    The problem is that the production environment has Panasonic WV-SC385 cameras and has not been possible to configure them in a proper way to make the JPEG video source accept its stream. Neither is this stream accepted by the WMP, so I suppose that non standard mjpeg is broadcasted by these cameras. On the other side, VLC does recognizes this stream.
    So several alternatives spring to mind:

    – One attempt now would be to make VLC broadcast the Panasonic input stream in such a way that could be valid for your JPEG video source. Which settings should we use for this to be ok for your app?
    – Another would be using a different filter that accept the Panasonic stream, but how could we expose it to Microsoft Expression Encoder?

    Regards

    • If you put your camera online and email me it’s IP address, port, admin/username, vendor, model (believe it or not, sometimes you cannot figure out model through web interface; and also this time I know it is Panasonic WV-SC385), I can take a look if it can be set up with my library.

      Without this, you one normally checks this out with vendor’s HTTP/CGI reference and/or using network sniffing tools.

Leave a Reply