See bug 787899 comment 29. On a particular webcam, it seems that nsMultiMixedConv is losing synchronization with a multipart/x-mixed-replace stream. Specifically: > What's apparently happening: due to variations in the data lengths, a part comes through at > an offset that makes |nsMultiMixedConv| think that no header information is available for > that part. > > It sets the MIME to the |x-unknown-content-type|, which means the next data goes to the > |nsUnknownDecoder|, which is why the user is prompted for download. That's why the downloaded > data contains the whole part, headers and all. This means that if you navigate directly to one of the webcam streams on the linked URL (username/password test/test), occasionally you'll be prompted to save a part, because its mime type gets set to application/x-unknown-content-type.

Note that this happens on multiple streaming cameras, not just the one I'm working on. See: http://82.70.90.38/ User/pass = test/test [then click on "4 x view"] http://82.70.90.38/mjpg/video.cgi?view=1&clientid=dgDja http://webcam01.lugano.ch/ http://webcam01.lugano.ch/axis-cgi/mjpg/video.cgi?camera=&resolution=352x288&1347869406006

One other thing: while streaming multipart motion jpeg images to FireFox, every five minutes or so an "Image corrupt or truncated" message pops up in the Web Console - and this is true from FF14 (if not earlier) through to a very recent nightly build. All the same, the image stream continues regardless, so this isn't an obviously harmful issue. Yet the camera server itself isn't reporting any encoding or transmission errors, while WireShark is showing no TCP errors in the previous 20 seconds (which is as far back as I bothered to go). Hence there seems no good reason for the image to be corrupt or truncated - might this be part of the same underlying problem?

Bug 858600 seems like it may be related to this. I'm speculatively marking it as depending on this bug. Feel free to undo this if it's not accurate.