Link To .MJPG Stream: Different Browsers/Different Results

[(PeteCresswell)]

This link:

http://ExtremeSurfcam.DynDNS.org:8080/mjpg/Cam3/video.mjpg

works in some browsers, but not others.

(at the login prompt, ID="x" and PW="x" - which will expire after
2012 May 20)

What the link does is hook into an IP camera server called
"BlueIris" and get a stream from one of the cameras.

It works a-ok in Google Chrome and probably in Firefox - but it
seems tb failing in other browsers. If you get a picture and it
seems to lack motion, it's probably OK: the bandwidth there is
miserable and we're only getting about 1 frame every 2-3 seconds.

Here's what I hear so far (from asking other people to try the
link):'

- Chrome 18.0.1025.168 m: Seems to work every time

- Safari (iPod): Arcane text - as if the image stream
were being rendered as text.

- Safari 4.1.3 (MacIntosh): "Just a lot of garble"

- Firefox 9.0.1: "Continuously loading images." (which may be
just showing it like it is bco abovementioned bandwidth issue.

- IE9: "This link doesn't work" (that comment from a web
developer).

- IE 6.0.29: Browser returns "The page cannot be displayed"

- Boxee (media extender): Arcane text

- IE 7: Does not seem tb able to parse the link.

I know *nothing* about HTML or web development, but my feeling is
that I am making some sort of syntax error in the link itself
when it comes to IE. Safari/Boxee.... dunno.

 

[Ben Bacarisse]

This link:

http://ExtremeSurfcam.DynDNS.org:8080/mjpg/Cam3/video.mjpg

works in some browsers, but not others.

(at the login prompt, ID="x" and PW="x" - which will expire after
2012 May 20)

Thanks, this makes investigation so much simpler. Nice beach, by the
way!

What the link does is hook into an IP camera server called
"BlueIris" and get a stream from one of the cameras.

It works a-ok in Google Chrome and probably in Firefox - but it
seems tb failing in other browsers. If you get a picture and it
seems to lack motion, it's probably OK: the bandwidth there is
miserable and we're only getting about 1 frame every 2-3 seconds.

Also, the frame size and compression is going to be costly. MJPEG is
not the most efficient video compression, and 1280x720 is quite a large
frame size. Maybe the camera can stream in other sizes and video
formats?

Here's what I hear so far (from asking other people to try the
link):'

- Chrome 18.0.1025.168 m: Seems to work every time

- Safari (iPod): Arcane text - as if the image stream
were being rendered as text.

- Safari 4.1.3 (MacIntosh): "Just a lot of garble"

- Firefox 9.0.1: "Continuously loading images." (which may be
just showing it like it is bco abovementioned bandwidth issue.

- IE9: "This link doesn't work" (that comment from a web
developer).

- IE 6.0.29: Browser returns "The page cannot be displayed"

- Boxee (media extender): Arcane text

- IE 7: Does not seem tb able to parse the link.

I know *nothing* about HTML or web development, but my feeling is
that I am making some sort of syntax error in the link itself
when it comes to IE. Safari/Boxee.... dunno.

There is no syntax problem with the link. The actual data coming from
the camera looks a little odd. It starts:

--ccboundaryContent-Type: image/jpeg
Content-Length: 404745

What's odd is that the Content-Type header is joined on to the boundary
marker. This might have some effect on the receiving software, though
it does not seem to bother the viewers I tried (Chromium and mplayer).
Also, there are no other headers. I'd expect something like this:

HTTP/1.0 200 OK
Content-Type: multipart/x-mixed-replace; boundary=--ccboundary

--ccboundary
Content-Type: image/jpeg
Content-Length: 404745
....

Maybe the camera setting can be changed.

Secondly, not all browsers know what to do with such a stream, even if
it's got all the right headers and boundary marks. What a lot of people
do is embed an application into the page (Java is common) and
it is that application that requests and displays the stream.

 

[(PeteCresswell)]

Per Ben Bacarisse:

Also, the frame size and compression is going to be costly. MJPEG is
not the most efficient video compression, and 1280x720 is quite a large
frame size. Maybe the camera can stream in other sizes and video
formats?

I started out at 1920x1080... and you know where *that* went.. -)

The function of the cam is to let people see for themselves if
it's worth driving down to go windsurfing - as opposed to calling
the owner of the shop, whose phone rings about every three
minutes on a windy day.

To that end, a certain amount of detail is needed.

How much detail?

I've tried 640x480 and am pretty sure that isn't going to do the
job. OTOH, a frame every 3 seconds isn't going to work
either.... OTOOH, I tried to sell the guy on a PTZ camera but
he wouldn't bite. My rational for PTZ was that we could use a
longer lens (same perceived rez in the smaller view with fewer
bits per frame) and let the users hunt around for the most
meaningful view (which changes depending on the wind direction).

OTOOOH, what I think doesn't matter - so once I get a link/stream
type that 90% of people can view in their browser of choice we'll
try different resolutions and try to arrive at a consensus.


The bandwidth down there is rated "F-" by SpeedTest.net (about 45
kB/s) and I'm leaning on the owner to sign up for Comcast cable,
which claims tb "...a minimum of 4+ times faster than dsl..".
Whether the upload speed is any improvement remains tb seen.


I am trying to investigate the MJPEG thing. The camera itself
is putting out H.264. It's the camera server that's putting out
whatever stream you are seeing. I've been posting questions
about different stream types in the server publisher's fora, but
haven't gotten any nibbles yet.


Any thoughts on why IE is telling us that the page does not even
exist? Choking on the stream, I can understand... but saying
there is no such page?


In parallel with this, I'm pursuing a fallback position: FTP-ing
20-second clips to a PC that has some decent bandwidth.

The clips have been coming through without a hitch for a couple
of days now and the motion and detail are every thing I could
wish for. If I ever figure out how to present those clips to
users in a meaningful way, that might get around the bandwidth
issue if Comcast doesn't deliver.

I'm hearing "Apache" and "PHP"... Maybe install an environment on
my home PC, get something working, and then port it to whatever
pay-for-play service I can talk the owner into.

 

[Ben Bacarisse]

The bandwidth down there is rated "F-" by SpeedTest.net (about 45
kB/s) and I'm leaning on the owner to sign up for Comcast cable,
which claims tb "...a minimum of 4+ times faster than dsl..".
Whether the upload speed is any improvement remains tb seen.

When I view the stream from here in UK, I can get it at 128K bytes/sec
(1Mbps). That's a lot more than 45kB/s. than Bandwidth is usually
quoted in bits/sec but I am assuming you capital B in 45kB/s is bytes
(bits are written with a small b).

Any thoughts on why IE is telling us that the page does not even
exist? Choking on the stream, I can understand... but saying
there is no such page?

No, sorry. Are you getting an error from the server? Do you know how
to see what HTTP headers are present in the result?

<snip>

 

[(PeteCresswell)]

Per Ben Bacarisse:

When I view the stream from here in UK, I can get it at 128K bytes/sec
(1Mbps). That's a lot more than 45kB/s. than Bandwidth is usually
quoted in bits/sec but I am assuming you capital B in 45kB/s is bytes
(bits are written with a small b).

That is probably because you are connecting to a server on my
home PC - which has Verizon's FIOS. The server on my PC connects
to the camera down where the bandwidth bottleneck is. My
rationale is that this keeps the number of concurrent connections
to the problem site down to just one: my server.

I'm glad to hear that it's visible across the pond.

No, sorry. Are you getting an error from the server? Do you know how
to see what HTTP headers are present in the result?

On IE6, I just tried removing the ID/PW and the results changed.
With ID/PW it was throwing up the standard "The page cannot be
displayed... The page you are looking for might have been removed
or had its name changed."

After removing the ID/PW, IE6 threw up an ID/PW prompt. After
filling it in, though, it then threw up a "File Download... Do
you want to save this file...Name: video.mjpg, Type: Unknown File
Type From: extremesurfcam.dyndns.org.

So I guess IE6, at least, does not know what to do with the
stream.

IE7, OTOH, still throws the same old "The page cannot be
displayed...".