[AG-TECH] VIC with AXIS Communications 2130 PTZ NetworkCamera?

[Lawrence A. Rowe]

Markus Buchhorn wrote:
> 
> At 14:09 13/02/2004 -0700, Adam Serediuk wrote:
> >As far as I know they have no multicast support. I've used several of the
> >AXIS cameras for other applications, the embedded linux is fairly simple and
> >allows next to zero customization.
> 
> What is the network stream that comes out of them? The specs suggest motion-jpeg is the codec, but no mention of the transport - is it rtp?
> 
> "It shouldn't be hard(tm)" :-) to write a proxy to grab the mjpeg stream (rtp or not) and remulticast it. Issues might be control (getting into the stream without a web browser), and receiver (mjpeg support is a bit thin on the ground so far, but there is some code out there, e.g. rtptv).
> 
> The braver types could try and write a VfL/WDM/whatever driver for it that fakes it as an analogue video source for vic to capture, but that doesn't seem necessary here.
----

hi -

i played with the axis technology 2-3 years ago and eventually gave up on it. 
it does work as advertised -- show video in a web page -- but, we tried to run
the win32 software library they supplied for accessing the stream in a program
and couldn't get it to work.  to make it work you really have to know the MS C++
programming tools (i.e., OCX's, Visual Studio, etc.) since that is what they
deliver.  After spending 1-2 weeks we couldn't even get it to compile correctly.

marcus, it would take some effort to reformat the compressed data into the RTP
format (IETF standard for video streaming) used by vic. moreover, after our
experience with RTPtv, i'd guess it would be a lot more work than people realize
since you have to worry about RTP format headers and, among other things, stream
format (i.e., single picture frames, interfaced fields, etc.), quantization
(i.e., RTP jpeg payload format has some specific rules about specifying the
q-scale used, etc.
	Larry
p.s. in answer to the question about multicast loss rates, this is very
dependent on the networking equipment you are using.  we have seen error
behavior where it is less than 1% for long periods of time followed by 60-90
seconds during which it goes up to 40% or higher and then settles back down to
1%.  we traced it to a timeout problem on the mcast session state in the
routers.  talking to our netop folks at berkeley they reported situations where
mcast loss goes up depending on load -- again dependent on the specific router
hardware.