User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release) Build ID: 2014021500 Steps to reproduce: open the motion JPEG stream in Firefox: http://www.zurich-airport.com/passengers-and-visitors/shopping-and-attractions/webcams-en/webcam-dock-b (Behind firewalls the stream could switch do a JavaScript stream, so test only with a firewall if it's supporting server push.) or open http://cam-i.switch.ch/login.cgi?b=p&ch=2&l=1 or open http://richti2.redics.ch/login.cgi?b=p&ch=0&l=0 Actual results: At stream start everything is ok. Depending on bandwidth, image size, etc. motion jpeg images begin to flicker after about 80-240 seconds. ( If I compare the different stream setups, it seems flickering starts after about 16 MByte stream data or about 500 MByte decompressed raw image data. ) While flickering it can happen, that the stream stops and no image is displayed. Or after about 20-60 seconds of flickering the motion jpeg images are displayed correctly until the end of the stream, as if there was noting. On a faster Windows 7 PC (i7-950 3.06 GHz with Nvidia GTX470) I can reproduce flickering all the time. On slower (Windows XP) PC's only some single frames flicker. But it can also be ok. On Linux (openSUSE) all Firefox versions are ok. From Firefox 25.0 (or even some older versions) until Firefox Nightly 31.0a1 (2014-03-21) the problem is the same. Expected results: The video stream should be displayed until the stream end (server timeout) and the last frame should be visible.

I have some additional informations to the problem: If the image flickers and there is no size of the img tag in the html file specified, also the img element collapses, because there is temporary no known image size. example: http://cam-i.switch.ch/login.cgi?b=p&ch=2&l=1 If I disable the antivirus software (avast 2014.9.0.2008) there are no problems with server push in firefox. After an update of the antivirus software to avast 2014.9.0.2016 on my faster Win7 PC there is no more flickering of the stream, but the stream stalls now and then for up to 2 seconds. On my slower WinXP PC with the newest avast 2014.9.0.2016 flickering is still there, even more then before ... On all conditions the motion JPEG stream works with no problems in chrome and opera. Also if I have this error only in combination with the antivirus software avast, there could be other cases witch produces the same error. conclusion: It seems the current frame is cleared some time too early, at a time when the new frame is not really ready for display.

Example 3 is no longer online. So current tests links are: http://www.zurich-airport.com/passengers-and-visitors/shopping-and-attractions/webcams-en/webcam-dock-b http://cam-i.switch.ch/login.cgi?b=p&ch=2&l=1 http://richti.redics.ch/login.cgi?b=p&ch=0&l=0

(In reply to Reto Diethelm from comment #1) > conclusion: > It seems the current frame is cleared some time too early, at a time when > the new frame is not really ready for display. I've observed this happening in other situations because the server sent a corrupt frame. It could be that Opera and Chrome just drop that frame and keep displaying the previous one in this situation, while we actually "display" the corrupt frame. To be sure if that is really the problem, I'd have to investigate more.

Tests with corrupt date (JPEG header, JPEG data or HTTP header) never caused the same flickering. The result was more or less the same on all browsers (opera, chrome). But I was not able to cause flickering of the hole frame and see the alternative text "behind", as it is the case with avast enabled. With enabled avast I saved the MJPEG stream (Image save as..) in firefox. This stream data are correct. So I think the problem is not caused by corrupt data. I tested with delays at different points in the stream: Windows XP, Firefox 30.0, avast 2014.9.0.2016: If the boundary string is sent directly after the last frame, the described flickering issue is there. If the boundary string is sent directly bevore the http header and new jpeg frame, there is no flickering. Windows XP, Firefox 30.0, avast disabled: If the boundary string is sent directly after the last frame, some times the lower part (about 10%-50%) of the image is newer then the upper part. If this happens then mostly it stays some time. If the boundary string is sent directly bevore the http header and new jpeg frame, everything is okay. On other pc's everything is okay. The issue occurs only on specific circumstances. So it seems I can solve the problem when I send the boundary string later, with the new header. But in firefox there is still the risk of flickering or partially updated images.

As of Firefox 36, motion JPEG server push virtually stopped working. Loading an image through multipart/x-mixed-replace will at most time display no image at all or only flash it once in an while. Try, e.g. http://130.89.113.150/control/faststream.jpg?stream=full&fps=16&html The same page works flawlessly on Firefox 35. Here, I'm running Firefox on a Mac, OS 10.8.5 (and of course no "avast").

Whoa! Agreed, that page is totally busted in 36! I just tested in Nightly and it works perfectly. I expect that means it got fixed in 37, almost certainly by bug 1112972, which completely reimplemented multipart/x-mixed-replace images. I'd expect that this bug is now totally fixed, though unfortunately none of the older links in this bug work for me anymore. I'll need to verify that bug 1112972 is indeed responsible for fixing this issue, and once that's confirmed I can look into requesting uplift to 36. I'm going to go ahead and set it as a blocker speculatively.

I suppose that actually Firefox 35 *is* affected, though it seems to have had much less severe problems than 36. At any rate, it's too late to uplift to 35, so not much we can do there.

Will this issue be fixed for Firefox 36 or will we have to wait until Firefox 37 is out?

(In reply to Daniel Kabs, reporting bugs since 2002 from comment #8) > Will this issue be fixed for Firefox 36 or will we have to wait until > Firefox 37 is out? I don't know for certain, because the patch has to be approved for uplift. I'm in the process of verifying that bug 1112972 fixes this issue now.

Confirmed, bug 1112972 fixes this issue. I'm requesting uplift now.

Seth, Firefox 36 Beta 8 seems to be unaffected. Does this mean that the fix has been included into FF 36 Beta 8 or has the test failed me? Thanks.

(In reply to Daniel Kabs, reporting bugs since 2002 from comment #11) > Seth, Firefox 36 Beta 8 seems to be unaffected. Does this mean that the fix > has been included into FF 36 Beta 8 or has the test failed me? Thanks. Yep, the fix made it in to 36!

That's great, thanks. I'm curios, can you glean this fact from this Bugzilla page? I only noticed that you set this bug to resolution "fixed" but otherwise without your answer, I'd not know where the fix landed.

Ah, maybe I have to rather look at bug 1112972 to figure where the fix landed. :-)

You do have a point though. Setting the appropriate flag (status-firefox36) to indicate that this was fixed on 36 by bug 1112972.