Measured Bandwidth of IP Camera Stream

EDIT: My first measurement attempt was not correct, as pointed out by those below. I believe I had the incorrect reporting period, or stalled client/camera.

(I will redo…)

Hello everyone: I thought I would post a measurement that I did with a network analysis probe that I have access to from my employer. It allows full flow diagnostics of traffic passing through it. I placed the axis camera behind this probe, and opened up a web live video link to it on the other side of it. The video settings was 320x240, the same recommended setting for competitions. Attached is the report. With IP overhead, a single stream appears to only use 120kbps of bandwidth. My next test will be to connect via a robot and a driver station displaying the 2 video streams on the driver station. I will measure this configuration and post my results. I thought everyone would be interested in this.

The image was not changing much, I will also repeat this by making the video move.

Yours,

Michael, Mentor Team 772.

Your charts units appear to list bits per second, not Kbps

Something doesn’t look right. The 120 bps is much too small (even with a static image). Are you sure it’s actually capturing the camera data? What was the IP address of the computer displaying the stream?

The default dashboard and LabVIEW dashboard present the data usage just beneath the image display. This display shows the payload data and doesn’t include header overhead and retransmissions, but will give you a pretty good estimate of how fps, compression, and resolution will impact the usage.

The camera can also display similar data overlayed on the image. I believe this is encouraged for Java and C++ teams, but it will work for any usage of the camera.

Greg McKaskle

Folks, I will redo the snapshot. The IP address of the camera was 10.7.72.11, and the receiving pc was 10.110.10.209. Yes I mistakingly added k and it is only bps, so perhaps I did not have the measuring window correct, or the camera actively streaming.

Stay tuned, another run will appear.

(Thanks folks)

md