Closed Bug 434439 Opened 16 years ago Closed 16 years ago

MJPEG streams not closing when leaving the page (closing the tab / navigating away / not broken).

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 373701

People

(Reporter: digdilem, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008051206 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008051206 Firefox/3.0

When viewing single or multiple mjpeg streams from CCTV cameras (IE, Axis 206, 207, 211's but probably all cams - note, this is the pure server-push mjpeg stream, not a wrapped mpeg4 or similar.)

On closing that tab, FF3 continues to use very high CPU loads (80-90%) indefinately (timed for 30 minutes plus), just as if it was continuing to receive and parse the mjpeg streams.

Also seems to affect stability of FF3, once a mjpeg stream has been opened the likelyhood of FF3 crashing seems to be much higher.

Bug was not present in FF2*. I use a html page with twelve small mjpeg streams on multiple firefoxes on multiple computers on the intranet without problem.

After restarting FF3 either normally or post-crash, problem is resolved.

Reproducible: Always

Steps to Reproduce:
1. Visit a server push mjpeg stream. (Size or fps doesn't seem to matter)
2. Close tab.

Actual Results:  
FF3 CPU usage goes high when viewing stream as normal, and on close tab remains high even when a single low-impact tab is remaining.

Expected Results:  
CPU usage should have dropped to almost nothing on tab close.

No themes, no addons of any kind other than AdblockPlus and Flashblock
I can confirm this behavior on Mac OS X (Leopard), Windows Vista 64bit, and Linux (Ubuntu 8.04).

It seems active sockets are kept active even when they're not used anymore. They seem to stay open until FF3 is restarted. Closing windows and tabs do not kill the sockets, only restart of the process.
I can confirm this on Firefox 3 RC 1 on Windows XP, it also occurred on at least beta 4, and probably several before this, but I can't be sure. I did not occur with Firefox 2. I am viewing the output of Motion (http://motion.sf.net), which is a stream of multipart/x-mixed-replace JPEG images. IMHO firefox never tries to close the TCP connection, but that is the only way to break the stream, since the server will stream forever (i.e. the content length is infinite). Firefox 2 would kill the connection as soon as you went to a different page or closed the tab, which is the expected behavior.
I actually can't confirm this.  I'm using Vista with Firefox RC1.  I have wireshark running and after the close tab, I see a couple of TCP retransmission requests from the camera to my machine, but those stop occurring after a few seconds.  And there is no further communication taking place with that computer after the close tab.

Firefox 3 does a bit more stuff in the background than firefox 2 did.  So, the CPU impact you're seeing could be that extra processing.  However, that processing should certainly not result in as high of a CPU as processing a video would.  Can any of you try to recreate this using a network monitoring tool like wireshark and post your results here?
Testing with: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0   (Vista 64bit)

I enter the mainpage of my Axis-networkcamera, which continuously sends an MJPEG-stream to the browser, which renders the "video" through an <img>-tag. I can see this traffic in Wireshark, one single stream of jpeg-data with boundary-headers between each frame. This kind of traffic continues after closing the tab.

However, I created a simple script on a webserver that outputs a single dot every second and never stops. I loaded the page in the browser, discovered the traffic in Wireshark and followed it. When I then close the tab, the traffic stops immediately. 

This makes me wonder if this bug only affects the <img>-tag? It doesn't seem to affect the page as a whole at least.

Hope this helps to clarify.
I am having this problem as well.  I believe Harald is on to something regarding the issue being related to the img tag somehow.  It seems that when the motion-jpeg images are embedded in an html document, the streams are not closed when the tab or window is closed.  But, if you copy and paste the URL for the motion-jpeg image into the address bar directly, *without* it being embedded in the body of an html document, the streams do appear to close when the tab or window is closed.  I have confirmed this behavior with wireshark.

I also found a live internet webcam page that exhibits this behavior.  Open this page in a separate tab, let it stream for a-few seconds, then close the tab but keep Firefox open.  Here's the link:

http://www.opentopia.com/showcam.php?camid=5484

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

Not on site with cams to test until Thursday, but that's definately not the case for me.

Open FF3 and say, Google's homepage. CPU steady at <5%

Visit a mjpeg stream (Note: Server PUSH). CPU jumps to 80-90%

Close tab or visit another page. CPU remains steady at 80-90% indefinately.

Starting over, visiting any other type of page and then reverting to Google or closing tab, CPU stays steady at <5%

If you saw retransmissions requests it suggests you're not viewing a server push mjpg stream as I believe the server keeps sending until the client says "stop" or the socket is closed.
From an Axis camera, a url like this will bring up an example mjpg stream

http://axis.camera.ip/axis-cgi/mjpg/video.cgi?resolution=640x480

I'm fairly sure FF3 is not tidying up fully on tab close, either leaving a socket open with a thread processing it, or not shouting STOP! at the camera when it's done.

I don't think the camera is at fault. Axis software is generally very good and as I said, has worked fine on FF2 and even Internet Explorer (with activex mjpg wrapper). Even if it was, I'd expect Firefox to handle it a touch more gracefully. :)

(Above in response to Chris Talbot btw, sorry)
It definitely is not the fault of the Axis camera, as it is happening with other motion-jpeg sources, including the open-source Zoneminder camera server.

Ok. I am able to reproduce a crash with the link given in comment #5. 
Note there was no hang or high CPU usage as mentioned in the bug. After visiting the link and navigating away to other pages.(tab closed) and letting firefox open for sometime(10mins approx) crashes it.
Crash report - http://crash-stats.mozilla.com/report/index/a6b61f91-3078-11dd-965e-0013211cbf8a?p=1
It seems related as the stack mentions a error in nsJPEGDecoder.cpp.
I am trying to repro again.
For me, CPU utilization does not go up significantly.  But, network utilization does.  Once the tab with the mjpeg image is closed, the network connection is very slow because FF is keeping the mjpeg stream open.  This has been confirmed with Wireshark.  This is especially true if you open and close a tab with a mjpeg image two or three times.  The network connection becomes unusable.  On slower systems, I could see where this may also cause high CPU utilization.


Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a1pre) Gecko/2008060202 Minefield/3.1a1pre
I can see packets keep flowing long after the tab with http://m-cam.uchicago.edu/view/view.shtml?imagePath=/mjpg/video.mjpg&size=1 is closed.
URL: http://-OnIntranet → http://m-cam.uchicago.edu/view/view.s...
OS: Windows XP → All
Version: unspecified → Trunk
Summary: Mjpeg streams not closing. → MJPEG streams not closing when leaving the page (closing the tab / navigating away / not broken).
A related (same?): bug 338815.
This bug looks like a dupe of bug 373701, which may itself be a dupe of bug 338815.
Okay, 338815 and 373701 are probably the same.  I'm going to dupe this to bug 373701 because that has more CC'ed users and flags set than bug 338815.  Please re-open or re-dupe if you disagree.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Same problem with Firefox 3.0.3 on Windows XP
Firefox 3.0.3 keeps receiving mjpeg stream after tab has been closed.
see http://samara.vt.ru/?id=19676
However Firefox 2.0.0.17 works well.
Besides see
http://support.mozilla.com/tiki-view_forum_thread.php?forumId=1&comments_parentId=101826
http://groups.google.com/group/mozilla.feedback.firefox/browse_thread/thread/a3772c3d5c811cce
You need to log in before you can comment on or make changes to this bug.