New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 51 users
Status: Fixed
Owner:
Closed: May 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
.mjpg file doesn't display
Reported by r.poff...@gmail.com, Oct 18 2013 Back to list
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36

Example URL:
ex: internal IP-cam .mjpg stream

Steps to reproduce the problem:
1. Log into your IP-cam (mine is a D-Link)
2. Go directly to stream URL (ex: 192.168.1.100/video1.mjpg)
3. Let it don't work

What is the expected behavior?
Reproduce .mjpg

What went wrong?
After last chrome update. A week ago it worked fine.

Did this work before? Yes Up to last chrome version

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? Yes Safari v. 6.0.5 (8536.30.1)

Chrome version: 30.0.1599.101  Channel: stable
OS Version: OS X 10.8.5
Flash Version: Shockwave Flash 11.9 r900
 
Labels: Needs-Feedback
r.poffo11: Is the example URL (192.168.1.100/video1.mjpg) live? I tried to access it, and it would not load. I am a bit unclear about your issue, but is this the problem, that it simply will not load in Chrome? Have you tried in other browsers, like IE or Firefox?
Comment 2 by r.poff...@gmail.com, Oct 19 2013
The example URL is a private ip address so it won't obviously work. The problem is that any MJPG file don't load. And yes, it works on Firefox and Safari. It also worked until a week ago on Chrome
Unfortunately, I am unable to verify if this is a widespread problem without a testable URL, and do not have ready access to a cam of this type. Can you either set up a public IP or find an example that can be publicly verified?
Comment 4 by r.poff...@gmail.com, Oct 22 2013
Searching on the net I find something...

http://80.32.204.149:8080/mjpg/video.mjpg?camera=1
http://gccvideo.dynalias.com/mjpg/video.mjpg?camera=1

even if they work in their own web pages:
http://www.mjpeg.net/webcams/11352
http://www.mjpeg.net/webcams/11275

but not solo
Comment 5 by Deleted ...@, Oct 22 2013
Same problem for me.
From the version 30 I can't see anymore mjpeg stream in my html.
I'm using code like this:
<img src="http://url-to-the-camera/axis-cgi/mjpg/video.cgi?streamprofile=MJPG800&.mjpg">
It works on Firefox and on default Android browser.
Comment 6 by j...@withecom.be, Oct 23 2013
@ajnol:

Test URLs are available here:
http://mjpeg.sanford.io/
http://mjpeg.sanford.io/count.mjpeg

Someone set them up before for testing Chromes MJPEG woes.
Status: Untriaged
Issue confirmed on Linux release, Windows Dev channel
Cc: srsridhar@chromium.org tkonch...@chromium.org
 Issue 305215  has been merged into this issue.
Comment 9 Deleted
I think the merging was supposed to be the other way around. https://code.google.com/p/chromium/issues/detail?id=305215 has much more feedback, and is the first issue to be reported.
Agree with comment 10, also has to point out that the 2 issue is not the same. In https://code.google.com/p/chromium/issues/detail?id=305215 the problem is around authentication and with the --allow-cross-origin-auth-prompt command line flag the mjpg display does work.
Comment 12 by vitt...@gmail.com, Nov 23 2013
It happens to me with latest Chrome and live streams from mjpg-streamer and motion. It is without auth so unrelated to  bug 305215 .

http://mjpg-streamer-host/?action=stream <-- mjpg-streamer
http://motion-host:8081/ <-- motion
Comment 14 Deleted
I can confirm this behavior with recent Chrome on Mac and Linux, connecting to a motion stream.

Cc: xhw...@chromium.org scherkus@chromium.org
Labels: -OS-Mac -Needs-Feedback OS-All
Status: Available
Tested on M32 Linux:

http://mjpeg.sanford.io/ works:
- the mjpeg is in a <image> tag

http://mjpeg.sanford.io/count.mjpeg doesn't work
- the same link works on Firefox and Safari
- even worse, it seems the tab isn't responding

We need investigate more on this.
Labels: Hotlist-Fixit
I worked at a place where we developed a camera server. At the time FireFox, Safari, Chrome all supported MJPG. Explorer, well we all know how that goes. I spent a month trying to find ways to support MJPG in explorer from embedded WCF apps or Silverlight, and ended up creating a web page that would just continuously load still images, which was a fix listed for  bug #135337  (https://code.google.com/p/chromium/issues/detail?id=135337#c39). So to see this feature dropped from Chrome is kinda shocking. It's usually Explorer catching up not Chrome sliding back.

Either way I hope there is an intention to fix this, as the way most IP cameras are exposed is though an MJPG stream. This really takes away one of the easiest ways to start debugging a video stream or focus a camera.

The link to the example at Stanford is still valid:
http://mjpeg.sanford.io/count.mjpeg
 Issue 392403  has been merged into this issue.
I confirm streaming multipart/x-mixed-replace content directly, i.e. not via an <img> tag, fails on 36.0.1985.125 stable and 38.0.2100.0 canary on OS X. The <img> tag workaround will fail for network-enabled cameras that use basic auth because of cross-origin security.

I do have a workaround for *desktop* Chrome - putting the <img> tag in an extension and "pre-authenticating" the session with XMLHttpRequest before setting the src attribute. I've uploaded my extension to the Chrome Web Store at this link (the extension is unlisted so it can only be accessed by direct link):

https://chrome.google.com/webstore/detail/direct-mjpeg/cjdhenagcokbmneggcbfhchmibikhief

As mobile Chrome does not support extensions, this workaround won't help there. Perhaps someone could implement a similar solution on a server (e.g. at App Engine or Cloud Storage) with all cross-origin requests allowed? Lifting the HTML and javascript from the extension might even work as-is.

Please do *not* discuss the extension here unless the comments are directly relevant to this bug. Adding clutter won't help it get fixed. Extension feedback can be submitted via the above link.
Comment 21 by Deleted ...@, Sep 7 2014
SSH password protected streams do not work even with the img tag
chrome is still not support all mjpgs where the same url works fine on firefox.  as others point out this is a big issue when viewing IP cameras and the user has/likes chrome as their default browser.

since most IP cameras are on private IP address/ip ranges, here is a perfect public IP example where MJPGs dont work on chrome, but do on firefox and other browsers:

http://www.mjpeg.net/webcams/16477

or any link/cam at:

http://www.mjpeg.net/

please bring this back to chrome!!
tks
I have the same issue/// confirming.
Tested on multiple cameras encoding mjpg and using several platforms of chrome (Win,Mac,Android).

THIS NEEDS TO BE ADDRESSED!!!
Please escalate priority.
Tested MJPEG to be not working on latest ChromeOS Beta (Toshiba Chromebook 2).

Version 40.0.2214.72 beta (64-bit)
Platform 6457.59.0 (Official Build) beta-channel swanky
Firmware Google_Swanky.5216.238.5 

Tried multiple streams online and a local stream from Motion server on Raspbian Linux. I can only view streams on my Android Nexus 5 with an app. On my PC, I can only view MJPEG streams with Firefox.
Comment 25 by noel@chromium.org, Mar 29 2015
Noted in http://blog.chromium.org/2013/07/chrome-29-beta-web-audio-and-webrtc-in.html

"We’ve removed support for multipart/x-mixed-replace main resources. We will continue to support multipart images and animated images."


Cc: -scherkus@chromium.org
Comment 27 by Deleted ...@, May 17 2015
Noel, does that mean that Chrome and Chromium are going to stay broken while every other browser is not?
Cc: dalecur...@chromium.org
Owner: xhw...@chromium.org
I'll follow up to see what needs to be done.
Cc: kcwu@chromium.org
Re #22: The link http://www.mjpeg.net/webcams/16477 works in Chrome M43 on Linux for me.
Comment 32 by Deleted ...@, May 21 2015
Re #31: This is because the stream is embedded in an <img> tag. Try the actual video source, and you will see a blank page: http://cam.butovonet.ru/mjpg/video.mjpg
Firefox and other browsers however will show you the image stream.
Cc: -kcwu@chromium.org japhet@chromium.org
I tracked down this a bit but couldn't find the root cause.

+japhet@chromium.org as he's more familiar with mjpeg support.
We ripped out support for mjpeg as the whole page a couple years ago because it made a  core system even more complicated and it was virtually unused. Unless we can find a much cleaner way to re-implement it, I'm strongly opposed to adding it back in.
Re #34: Thanks for the context! When you say it's "virtually unused", did we actually measure how often it's used? From this bug it seems a lot of people are still using it. 
https://chromiumcodereview.appspot.com/16848005 was the patch which removed it, which said "used by less than 0.00001% of page loads."
Cc: abarth@chromium.org
Thanks for the info. In that case I agree it's very rarely used. Also, we have a workaround for that by using a <img> tag.

OOC: Do we have a specific UMA tracking this? It would be great to keep tracking the usage trend even though we don't support it right now.
Owner: japhet@chromium.org
I decided to go ahead and try to re-implement mjpeg main resource support as narrowly as possible. The complexity ended up being pretty well-contained, so it's up for review: https://codereview.chromium.org/1154413002. We'll see how people feel about it.
Cool, thanks for working on this!

Still, if we don't have UMA, we probably should. It'll be pretty useful tracking how often a feature is used.
Project Member Comment 40 by bugdroid1@chromium.org, May 29 2015
The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=196101

------------------------------------------------------------------
r196101 | japhet@chromium.org | 2015-05-29T00:20:37.048682Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/multipart/multipart-main-resource-expected.html?r1=196101&r2=196100&pathrev=196101
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/fetch/ImageResource.cpp?r1=196101&r2=196100&pathrev=196101
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/fetch/ImageResourceTest.cpp?r1=196101&r2=196100&pathrev=196101
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/multipart/multipart-main-resource.html?r1=196101&r2=196100&pathrev=196101
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/ImageDocument.cpp?r1=196101&r2=196100&pathrev=196101
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/fetch/ResourceLoader.cpp?r1=196101&r2=196100&pathrev=196101
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/fetch/ImageResource.h?r1=196101&r2=196100&pathrev=196101
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/ImageDocument.h?r1=196101&r2=196100&pathrev=196101
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/loader/DocumentLoader.cpp?r1=196101&r2=196100&pathrev=196101
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/fetch/ResourceLoader.h?r1=196101&r2=196100&pathrev=196101
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/loader/DocumentLoader.h?r1=196101&r2=196100&pathrev=196101

Make multipart image documents work again.

We used to have generic multipart main resource plumbing, which was removed in https://codereview.chromium.org/16848005. However, we can implement narrow support for just multipage images as the main resource (i.e., mjpeg) with relatively minor modifications to ImageDocument.

BUG= 308999 

Review URL: https://codereview.chromium.org/1154413002
-----------------------------------------------------------------
Status: Fixed
Yay! I have to think that there will be many people who appreciate this... at least those who are using the PI.
Please note that this issue is still *NOT* fixed!!!
The mjpeg stream works flawlessly in Chrome Canary 45.0.2439.0 IF you open it in directly in the URL bar, BUT if you embed it in an <img> tag it still doesn't work!

<!DOCTYPE html>
<html>
<head lang="en">
  <meta charset="UTF-8">
  <title></title>
</head>
<body>
<img src="http://user:pwd@ip_address/video.cgi">
</body>
</html>
@niccolo.belli: I had been using http://mjpeg.sanford.io/ (mentioned above), and it works for me. Where are you seeing this problem? If it's an exact copy of the html you linked, the img tag isn't properly closed.
I think niccolo.belli means providing the credentials via basic authentication doesn't work. The stream opens, but only if it doesn't require any credentials. 
Ah, got it. I latched on to the wrong part of the img tag :)

That's almost certainly a separate bug, so creating a new issue is probably the right course of action. A link to a page that's currently broken would be awesome.
Try loading "http://user:allesfrisch.99@62.68.193.82:8002/mjpg/video.mjpg" in an img-Tag, this should reproduce the issue.
I think this may have been fixed very recently, though I'm not sure by what patch. I agree the case described in #c47 is broken on dev channel, but it works for me on a build from trunk. Would you mind checking again after the next dev channel release?
Sure, thank you!
Since a new dev-channel build was released last week, I did check it today.
It still is not fixed. The file attached shows a proper mjpg-Stream in both Safari and Firefox but in Chrome it just leaves an error in the console saying: 
GET http://user:allesfrisch.99@62.68.193.82:8002/mjpg/video.mjpg 401 (Unauthorized)

The other browsers did not have any credentials cached for this img. 
test.html
191 bytes View Download
Ok, it's likely this is an issue with credentials rather than with mjpg. That should probably go in a separate bug, if you don't mind opening a new one.
Comment 53 by Deleted ...@, Aug 11 2015
I've got the same error in Chrome when trying to fetch a mjpg-stream like tobias did: unauthorized
Any solution yet? I'm somehow landing on an error page when trying to open the separate bug page...
Was the new bug filed as a security bug? I don't have access either.
Yes, it was filed as security bug. 

"tsepez@chromium.org
If that's a cross-origin img tag, then yes, basic auth is not allowed in that case to prevent image embedders from mucking with each other."

He recommends to open the browser with specific flags to restore the old behaviour. Sadly, this will not help people using it on mobile devices. 

 
He also added a link to this blog-post, it lists this issue as a security enhancement, see "Chromium 13: blocking HTTP auth for subresource loads" for details.
http://blog.chromium.org/2011/06/new-chromium-security-features-june.html

In my opinion this should be revised, I'm sure there is a better issue than simply ignoring credentials already provided.
Comment 57 Deleted
Sign in to add a comment