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

Issue metadata

Status: Fixed
Owner:
Closed: May 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
link

Issue 308999: .mjpg file doesn't display

Reported by r.poff...@gmail.com, Oct 18 2013

Issue description

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
 

Comment 1 by ajnolley@chromium.org, Oct 18 2013

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

Comment 3 by ajnolley@chromium.org, Oct 21 2013

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.

Comment 7 by ajnolley@chromium.org, Nov 5 2013

Status: Untriaged
Issue confirmed on Linux release, Windows Dev channel

Comment 8 by ajnolley@chromium.org, Nov 8 2013

Cc: srsridhar@chromium.org tkonch...@chromium.org
 Issue 305215  has been merged into this issue.

Comment 9 Deleted

Comment 10 by philippe...@gmail.com, Nov 8 2013

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.

Comment 11 by akos.sch...@gmail.com, Nov 8 2013

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

Comment 15 by r...@spacecoaster.org, Nov 27 2013

I can confirm this behavior with recent Chrome on Mac and Linux, connecting to a motion stream.

Comment 16 by xhw...@chromium.org, Feb 12 2014

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.

Comment 17 by xhw...@chromium.org, Feb 28 2014

Labels: Hotlist-Fixit

Comment 18 by chrismsm...@gmail.com, Jun 25 2014

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

Comment 19 by scherkus@chromium.org, Jul 16 2014

 Issue 392403  has been merged into this issue.

Comment 20 by roy.hash...@gmail.com, Jul 21 2014

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

Comment 22 by j...@validusdata.com, Oct 19 2014

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

Comment 23 by christop...@christopherbeaumont.com, Jan 15 2015

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.

Comment 24 by mike.joh...@gmail.com, Jan 16 2015

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."

Comment 26 by scherkus@chromium.org, Apr 21 2015

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?

Comment 28 by xhw...@chromium.org, May 18 2015

Cc: dalecur...@chromium.org

Comment 29 by xhw...@chromium.org, May 18 2015

Owner: xhw...@chromium.org
I'll follow up to see what needs to be done.

Comment 30 by xhw...@chromium.org, May 18 2015

Cc: kcwu@chromium.org

Comment 31 by xhw...@chromium.org, May 19 2015

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.

Comment 33 by xhw...@chromium.org, May 23 2015

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.

Comment 34 by japhet@chromium.org, May 26 2015

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.

Comment 35 by xhw...@chromium.org, May 26 2015

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.

Comment 36 by japhet@chromium.org, May 26 2015

https://chromiumcodereview.appspot.com/16848005 was the patch which removed it, which said "used by less than 0.00001% of page loads."

Comment 37 by xhw...@chromium.org, May 26 2015

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.

Comment 38 by japhet@chromium.org, May 27 2015

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.

Comment 39 by xhw...@chromium.org, May 27 2015

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.

Comment 40 by bugdroid1@chromium.org, May 29 2015

Project Member
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
-----------------------------------------------------------------

Comment 41 by japhet@chromium.org, May 29 2015

Status: Fixed

Comment 42 by christop...@christopherbeaumont.com, May 30 2015

Yay! I have to think that there will be many people who appreciate this... at least those who are using the PI.

Comment 43 by niccolo....@gmail.com, Jun 29 2015

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>

Comment 44 by japhet@chromium.org, Jun 29 2015

@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.

Comment 45 by tobias.w...@loxone.com, Jun 30 2015

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.

Comment 46 by japhet@chromium.org, Jun 30 2015

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.

Comment 47 by tobias.w...@loxone.com, Jul 1 2015

Try loading "http://user:allesfrisch.99@62.68.193.82:8002/mjpg/video.mjpg" in an img-Tag, this should reproduce the issue.

Comment 48 by japhet@chromium.org, Jul 1 2015

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?

Comment 49 by tobias.w...@loxone.com, Jul 2 2015

Sure, thank you!

Comment 50 by tobias.w...@loxone.com, Jul 20 2015

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

Comment 51 by japhet@chromium.org, Jul 20 2015

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...

Comment 54 by japhet@chromium.org, Aug 11 2015

Was the new bug filed as a security bug? I don't have access either.

Comment 55 by tobias.w...@loxone.com, Aug 24 2015

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.

Comment 56 by tobias.w...@loxone.com, Aug 24 2015

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