Axis IP camera video source filter doesn't work in DirectShow GraphEdit

1
votes

I'm trying to get video from an Axis P5515 IP camera to feed into DirectShow, but all I get in the render window is a black screen.

Nearly every search I do looking for an IP camera source capture filter ends at the "DirectShow Video Source Filter for JPEG and M-JPEG IP Cameras" page at http://alax.info/blog/1216 (which has the same files attached to it as the "IP Video Source: 64-bit version, resolution flexibility, Adobe FMLE" page at http://alax.info/blog/1223 where I first found them). I downloaded and installed the 32 bit IpVideoSource device. I have it configured with this URL (username and password substitution in effect):

http://user:[email protected]:1026/axis-cgi/mjpg/video.cgi?resolution=640x360

here

When I plug that URL into Firefox, Chrome and Opera, they all display the video stream without complaints. When I put it into Safari, I get a warning that it might be a phishing site because it has a username and password, but when I say OK, Safari displays the video stream. When I try to open the video stream with Internet Exploiter (11), it just says

Internet Exploiter chokes

One of my searches had turned up the "MediaTools to deliver video from network/IP cameras and video servers into DirectShow environment" page at http://alax.info/blog/741 which has a "Quick Usage Example" that I tried to follow, but I was unable to complete the filter graph in GraphEdit because the "JPEG Decoder Filter" it calls for is not available: The CodingI.dll that would contain it is not in either of the packages I downloaded. The "Quick Usage Example" should produce a graph as shown in the illustration on http://alax.info/blog/1216

illustration at alax.info/blog/wp-content/uploads/2011/05/Image0051-800x294.png

Since I couldn't get results by following the provided instructions, I tried right-clicking the output pin of the Office_cam instantiation of the IpVideoSource filter in GraphEdit, which generated this graph

auto-generated Office_cam render graph

When I try to run the graph, an Active Movie window is opened, but it's black. The C:\ProgramData\IpVideoSource.log file contains this data:

*** Exception
Process: 0x000288e0, Thread: 0x00028858, Date: 1/30/2017, Time: 11:34:59 AM, Application: graphedt.exe
Module: IpVideoSource.dll, Product Version: 1.0.3.1, File Version: 1.0.3.1506, File Time: 12.04.2015, 20:13
Code: 0xe06d7363, Flags: 0x00000001, Address: 0x75e6c54f
Parameters: 0x19930520, 0x02faea88, 0x5321d498
Native Parameters: 0x80190191, ...

** Call Stack
KERNELBASE!75E6C54F RaiseException (+ 88) @75E60000
IpVideoSource!531F7DCF @531A0000
IpVideoSource!531A281F @531A0000
IpVideoSource!531B5BD2 @531A0000
ntdll!773DF5DE RtlImageNtHeaderEx (+ 169) @773B0000

*** Exception
Process: 0x000288e0, Thread: 0x00028858, Date: 1/30/2017, Time: 11:34:59 AM, Application: graphedt.exe
Module: IpVideoSource.dll, Product Version: 1.0.3.1, File Version: 1.0.3.1506, File Time: 12.04.2015, 20:13
Code: 0xe06d7363, Flags: 0x00000001, Address: 0x75e6c54f
Parameters: 0x19930520, 0x02faea88, 0x5321d498
Native Parameters: 0x80190191, ...

** Call Stack
KERNELBASE!75E6C54F RaiseException (+ 88) @75E60000
IpVideoSource!531F7DCF @531A0000
IpVideoSource!531A281F @531A0000
IpVideoSource!531B5BD2 @531A0000
ntdll!773DF5DE RtlImageNtHeaderEx (+ 169) @773B0000

*** Exception
Process: 0x000288e0, Thread: 0x00028858, Date: 1/30/2017, Time: 11:34:59 AM, Application: graphedt.exe
Module: IpVideoSource.dll, Product Version: 1.0.3.1, File Version: 1.0.3.1506, File Time: 12.04.2015, 20:13
Code: 0xe06d7363, Flags: 0x00000003, Address: 0x75e6c54f
Parameters: 0x19930520, 0x02faea88, 0x5321d498
Native Parameters: 0x80190191, ...

** Call Stack
IpVideoSource!531F0727 @531A0000
IpVideoSource!531F5E93 @531A0000
IpVideoSource!531F61A3 @531A0000
IpVideoSource!531F6896 @531A0000
IpVideoSource!531F0819 @531A0000
ntdll!77413529 RtlDestroyEnvironment (+ 1227) @773B0000
ntdll!774134FB RtlDestroyEnvironment (+ 1181) @773B0000
ntdll!773C0143 KiUserExceptionDispatcher (+ 15) @773B0000
IpVideoSource!531F7DCF @531A0000
IpVideoSource!531A281F @531A0000
IpVideoSource!531B5BD2 @531A0000
ntdll!773DF5DE RtlImageNtHeaderEx (+ 169) @773B0000

I've tried combinations of lots of filters, including the Alax.Info HTTP Stream File Renderer, Alax.Info JPEG Frame Decoder, Alax.Info HTTP Stream Parser, AXIS MJPEG Video Decoder, MJPEG Decompressor, Smart Tee, two different Video Renderer filters, and probably others, all to no avail.

I'm having this problem on both 32 bit and 64 bit windows 7 with the DirectX SDK (June 2010) and windows 7 SDKs installed, so I suspect I've overlooked something.

Any useful suggestions will be appreciated.

1
videocameradirectshowgraphedit
While other issues were uncovered in debugging this one, it turns out that a large part of the problem was my test environment: I was running GraphEdit in a remote desktop window because using the w7 laptop isn't convenient in my office environment. When I took the laptop to a coffee shop and tried to debug the code, it suddenly started working. I didn't recognize the difference until it failed again in my office with the remote desktop. I then tried the laptop directly - and the graph ran correctly - I had a smoking gun: A remote desktop is not the same as using a computer directly. – FKEinternet

1 Answers

1
votes

IpVideoSource.log looks relevant (keyword is 0x80190191) and suggests that the problem is caused by HTTP 401 Unauthorized error sent by camera in response. That is, the camera does not accept credentials, which in turn - taking in consideration that it's Axis camera - is caused by setting on camera that requires safe HTTP authentication method such as digest.

IpVideoSource.dll currently implements DirectShow source filter which is restricted to basic authentication method only (WINHTTP_AUTH_SCHEME_BASIC).

For troubleshooting, one can disable authentication on camera to check if it helps to get the picture. As a workaround, with a camera like Axis that presumably supports HTTPS protocol as well (at the time of IpVideoSource.dll development rare IP cameras supported HTTPS, and, well, digest authentication too), it is possible to use HTTPS with basic authentication so that plain text password on the wire is protected by secure sockets layer.