Link To .MJPG Stream: Different Browsers/Different Results

Discussion in 'HTML' started by (PeteCresswell), May 16, 2012.

  1. This link:

    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

    - 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

    - 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.
    (PeteCresswell), May 16, 2012
    1. Advertisements

  2. Thanks, this makes investigation so much simpler. Nice beach, by the
    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
    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

    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.
    Ben Bacarisse, May 16, 2012
    1. Advertisements

  3. Per Ben Bacarisse:
    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 (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.
    (PeteCresswell), May 17, 2012
  4. 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).

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

    Ben Bacarisse, May 17, 2012
  5. Per Ben Bacarisse:
    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.

    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:

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

    IE7, OTOH, still throws the same old "The page cannot be
    (PeteCresswell), May 17, 2012
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.