42224 - server JPG push fails after several frames and displays broken image icon

Status: VERIFIED WONTFIX

(Core :: Networking: HTTP, defect, P2)

Description

[pnunn]

bug#6074 was reopened with the following description.
Rather than mutate #6074, I'm opening this bug with the
current problem.

from Jonathan Walther <[e-mail]>:
<a href="http://216.100.231.10/">http://216.100.231.10</a> should be up
for a few months at least; when you access it it crashes Linux version 90% of
the time; on remaining platforms it either works fine, or works fine for a while
then displays only the alt tag.  If you get that far, pressing reload or
backward then forward also either crashes the browser or makes it display the
alt text in place of the image and hang.  This has been tested on Win2K, WinNT,
and Linux (Debian potato with kernel 2.2.14)
Hopefully this can be made to work soon?

----------------------------------------
from Peter Annema <[e-mail]>:
Linux, build ID 2000060908

To check what was going on, I loaded this URL:
mailto:[e-mail]

This works for a while, appending ##<number> to the URL, with number increasing.

It doesn't crash, but stops loading after a while and just displays the URL:
http://216.100.231.10:2230/xxx.jpg##11

(or ##6, or ##3)

Comment 1

[pnunn]

Notes to self:
monitor #40507. Both have similar symptoms.
-P

Comment 2

[pnunn]

The berkeley url is working, but the url,http://216.100.231.10/,
doesn't work. I'm replacing the url.

Comment 3

[pnunn]

I get this on the output window:
###!!! ASSERTION: all buffered data should be gone: '!mBuffer', file d:\work\moz
illa\netwerk\streamconv\converters\nsMultiMixedConv.cpp, line 303
###!!! Break: at file d:\work\mozilla\netwerk\streamconv\converters\nsMultiMixed
Conv.cpp, line 303


This is the message in nsMultiMixedConv::~nsMultiMixedConv(). So I'm guessing
necko thinks the data stream has finished so it destroys the class. 

Jud, would you take a look at this? 
reassigning to put on your radar.
-p

Comment 4

[Peter "jag" Annema]

I guess something went wrong while copying my comment huh :-)

In the original comment, "mailto:[e-mail]" was 
"http://216.100.231.10:2230/xxx.jpg"

Anyway, for Windows 95 and Linux, both build ID 2000070908, it now doesn't seem 
to update at all, though it's in a "busy downloading" state. Either that, or it 
crashes loading that page.

Comment 5

[Judson Valeski]

this should be fixed now. I can't hit the test url anymore.

Comment 6

[WD]

Updating URL and re-opening.   I'm seeing this with 2001041604
(with the http://dormcam.mine.nu:8080/index1.shtml , the ALT text is "Please Wait")

Comment 7

[WD]

Re-assigning

Comment 8

[Stuart Parmenter]

i only see the alt text for a short time when the 120 secs was up and it 
reloaded the cam.

Comment 9

[WD]

I could be wrong here, but according to the server logs, you're using: 20010323
Is that right??
I'm seeing this bug with 2001041604

Comment 10

[Stuart Parmenter]

i'm running a debug build that i built yesterday.  dunno about the date its 
giving you.

Comment 11

[WD]

I guess I was going by the identifier in the HTTPD logs:

"Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.8.1+) Gecko/20010323"

Comment 12

[Matthias Versen [:Matti]]

Sometimes I see only the ALT Text on that Page for 30sek.
If this happends I see the this in my console :

my_error_exit()
Not a JPEG file: starts with 0x43 0x6f
my_error_exit()
Not a JPEG file: starts with 0x00 0x6d
my_error_exit()
Not a JPEG file: starts with 0x00 0x6d

Comment 13

[WD]

Yeah, I get something similar:

my_error_exit()
Not a JPEG file: starts with 0x43 0x6f
my_error_exit()
Not a JPEG file: starts with 0xd4 0x94
my_error_exit()
Not a JPEG file: starts with 0xd4 0x94

Comment 14

[Stuart Parmenter]

if you are getting that then libjpeg doesn't know what to do with the jpeg data 
it is being fed. .  are we sure that the jpeg it is making is a valid jpeg?  (on 
the frames that die?)

Comment 15

[WD]

Wish I could tell you more...   All I know is that it works fine in Netscape 4.x

Maybe if it got a bad JPEG frame, it could skip over it and continue with the
next, rather then just stopping altogether?

Comment 16

[Stuart Parmenter]

i don't think that would be proper behavior.  there is no way for me to know 
that more data is coming.

Comment 17

[Terri Preston]

hmm, don't think I can be of much help on this one, other than to tell you that 
I am still seeing this behavior on W2k build 2001042504, sorry :-(

Comment 18

[WD]

Would it be possible to check how the NS4 architecture achieves JPEG push
without the problem Mozilla has?    Or is Moz just too different to be able to
apply the same technique?

Comment 19

[Hixie (not reading bugmail)]

Pavlov: For the frame where the image is broken, sure, we should display the
alt text. However if it's multipart/x-replaced content then when the next frame
comes in, if it is valid then we should go back to handling it. IMHO.

Comment 20

[Keyser Sose]

*** Bug 79404 has been marked as a duplicate of this bug. ***

Comment 21

[timeless]

*** Bug 79121 has been marked as a duplicate of this bug. ***

Comment 22

[timeless]

*** Bug 86157 has been marked as a duplicate of this bug. ***

Comment 23

[basic]

*** Bug 85891 has been marked as a duplicate of this bug. ***

Comment 24

[WD]

*** Bug 77168 has been marked as a duplicate of this bug. ***

Comment 25

[Judson Valeski]

http://8ball.federated.com is busted again (0.9.4)

Comment 26

[WD]

*** Bug 103057 has been marked as a duplicate of this bug. ***

Comment 27

[WD]

*** Bug 84860 has been marked as a duplicate of this bug. ***

Comment 28

[Mike Young]

From bug 103057

This URL is a live (instantaneous update) feed from a computer lab. The
administrator of the camera lives down the hall from me so if you need any info
I can get it.

http://webcam315.cede.psu.edu (From what I understand, it has a 2MBps threshold
appllied for one webcam. This means the update is as fast as your connection can
handle. :-) However, if there is a problem waiting for data or something like
that, the administrator has informed me that he can lift that restriction and
let the camera pump full duplex 10MBps data to the net. (Ahh the glories of
Internet2))

adding keywords since this is a crash. Upping severity as well.
Talkbacks (3 different systems):
TB36239560E
TB36242300W
TB36242635Q

if you want the pure data feed of the image, that is at:
http://webcam315.ecsel.psu.edu/axis-cgi/mjpg/video.cgi

Comment 29

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 104838 has been marked as a duplicate of this bug. ***

Comment 30

[WD]

After browsing directly to a JPG Push feed, I noticed that the image dimensions
displayed are way off.   That couldn't be causing any of the trouble people are
seeing here, could it??

Comment 31

[WD]

Attachment: Mozilla displaying incorrect image dimensions

Comment 32

[Ashley Cambrell]

This may be a long shot, but could it have anything to do with bug 97683?  It
seems that somewhere along the line the http connection is corrupted (mozilla
losing track of it?)?

Comment 33

[WD]

updating summary to reflect current behavior

Comment 34

[Mike Young]

*** Bug 111353 has been marked as a duplicate of this bug. ***

Comment 35

[Judson Valeski]

nom'ing nsbeta1. this affects multipart mixed images ("server push") in general.
another site is http://8ball.federated.com (which still doesn't work in
mozilla0.9.8 build)

Comment 36

[WD]

I think that bug 106166 should then also be nominated nsbeta1, as that one is
blocking this bug.

Comment 37

[WD]

See also:
http://www.camarades.com
(possibly the most popular webcam software around)

In their FAQ:
Netscape 6 Preview Release 1 is a complete mess. We'll wait for a beta release
at least before we start patching the site up for this one.

(yes, it's a little out of date, but actually JPEG push support has regressed
since NS6PR1)

Comment 38

[Nivedita (gone)]

Attachment: patch file for fixing the sever pushed images

The imageframe is set as immutable hence when a SetImageData on the frame is 
called leads to return an NS_ERROR_FAILURE. 

Hence added a check in imgRequest to fetch the contenttype of the page to set
the frame as mutable if the content type is "multipart/x-mixed-replace".
Passing the mutability of the frame got from imgrequest  to decoders and
container through the Init method.

One of my observation was that we were setting the frame as immutable, in the
in the imageConatiner if num of frames is 1 and decoders.
Though I have set the frame as immutable by default, do we need to reset the
frame as immutable once the entire request is fulfilled in case of
multipart/x-mixed-replace request.

Other observation was that only the following decoders were setting the frame
as immutable 
a) nsBMPDecoder
b) nsJPEGDecoder
c) nsPNGDecoder
Was there any specific reason for it?

Comment 39

[Nivedita (gone)]

Comment on attachment 69221 [details] [diff] [review]
patch file for fixing the sever pushed images

I making this patch as obselete because, the patch breaks the build in the
extensions\inspector\base\src\inBitmapDecoder.cpp, as I did not 
change the Init in this class, as per the idl change I did in imgIDecoder.idl. 

I had done the changes only in the classes under modules\libpr0n. 
I am working on this and would upload the correct patch once I am 
done on it.

Comment 40

[Nivedita (gone)]

Attachment: updated patch file for fixing the sever pushed images

updated the patchFile to incorporate changes in inBitmapDecoder class as well.
The comments stand the same as mentioned in comment #38 by me.

Comment 41

[Nivedita (gone)]

tested the patch against the following url's in addition to the given url.
http://solo.dc3.com/wsdocs/32demo/spsample.html
http://www.nottingham.ac.uk/meteosat/satshow.html
http://baremetal.com/gadgets/spush.html
http://engwear.org/1999/frosh/fungja/push.html

Comment 42

[WD]

OK, with this patch JPG push is working again which is great!   (This patch
seems to fix bug 106166 ?)
But the problem described in the summary is still there.

One way I can pretty regularly reproduce the problem is this:
(note:  It sometimes can be a little tricky to see if it's actually streaming,
but if you look closely, you will see the JPEG artifacts change with every frame)

1) Open a Netscape 4.x browser at http://dormcam.mine.nu:8080/moztest.html
2) Open a mozilla browser at the same URL
3) Notice the image in the Mozilla window is streaming.  Yay!  :)
4) Switch to the Netscape and watch for about 10 seconds while the video streams
5) Switch back to the Mozilla browser.  The image will be broken
6) Go back to the Netscape 4.x browser.   *Notice the image is still streaming*

Comment 43

[WD]

Ok, I've just been playing around with the page:
http://www.santacruzwharf.com/camtides.html

The problem described immediately above are much more difficult to reproduce,
but it still does happen.   Just leave the page open for a while, do other
stuff, and eventually it will come up as broken.

I think that possibly Netscape 4.x is more "robust" in handling JPG push
compared to Mozilla, and I'm seeing the results of that.   The Santacruz site
seems to be quite fast and reliable.    Perhaps the
http://dormcam.mine.nu:8080/moztest.html stream is less reliable, since the PC
that runs it is quite slow.

The thing is 4.x seems to handle the slowness in stride, while Mozilla doesn't
quite fare as well.    Perhaps if a frame is corrupt (or too late?) somewhere
along the line, Mozilla just gives up, while Netscape will just chug along
displaying the frames following it.    Just a guess?

Thanks for your work in this bug, Nivedita.  Your efforts are greatly appreciated!

Comment 44

[Mike Young]

if you want a fast test page to ensure this works, you can use
http://webcam315.cede.psu.edu/

It runs off of an enormous University connection, and the administrator lives
next door to me. 

If this is an issue of the server sending slow data, we really should be able to
handle a network lag or a missed frame and just pick up at the next image header...

Comment 45

[Stuart Parmenter]

Attachment: Patch to properly handle multipart mixed channels

This patch fixes the document load so that leaving a page with a multipart
mixed channel doesn't cause the data to be downloaded forever.

Comment 46

[Stuart Parmenter]

Comment on attachment 69456 [details] [diff] [review]
updated patch file for fixing the sever pushed images 

Nivedita,  I would prefer to add a method to imgILoad to query if the load is
from a multipart mixed channel or not rather than by adding a new flag to
imgIDecoder::Init().  Imagelib itself shouldn't tell the decoders if the frame
is mutable.  That should be up to the decoder, but the decoder probably needs
to know if the data is from a multipart stream so that it can properly handle
the data.  The only decoder that should care currently is the JPEG decoder.

Comment 47

[Nivedita (gone)]

Attachment: patch file incorporating comments given by Stuart

Using imgILoad to indicate if the channel is a multipart mixed channel.

Comment 48

[Stuart Parmenter]

Comment on attachment 69629 [details] [diff] [review]
patch file incorporating comments given by Stuart

mChannel->GetContentType(&mContentType); copies the string.  You will need to
free it.  I suggest using a nsXPIDLCString... then you can do:
nsXPIDLCString ctype;
GetContentType(getter_Copies(ctype));

then you can strcasecmp ctype.get()

Comment 49

[Nivedita (gone)]

Attachment: patch file incorporating comments given by Stuart

incorporated comments given by Stuart. Using nsXPIDLCString instead of char*.

Comment 50

[Jaime Rodriguez, Jr.]

Removing nsbeta1 nomination because this bug has been plussed.

Comment 51

[Stuart Parmenter]

Attachment: patch including both patches from this bug

Comment 52

[Simon Fraser [no longer active]]

Comments on the patch:
-    mChannel = do_QueryInterface(aRequest);
+    nsCOMPtr<nsIMultiPartChannel> mpchan(do_QueryInterface(aRequest));
+    if (mpchan)
+      mpchan->GetBaseChannel(getter_AddRefs(mChannel));
+    else
+      mChannel = do_QueryInterface(aRequest);

Be consistent about nsCOMPtr<nsIFoo> bar(do_QueryInterface(baz)) vs.
nsCOMPtr<nsIFoo> bar = do_QueryInterface(baz) to reduce brainprint.

+  if (mObservers.Count() == 0) {
+    this->Cancel(NS_IMAGELIB_ERROR_FAILURE);

Is there a reason for "this->" ?

Comment 53

[Stuart Parmenter]

huh?  mChannel is a member and you have to use =.  mpchan is a new nsCOMPtr and
is being initialized to do_QueryInterface(aRequest).

as for this->, there are too many different Cancels in the air in the code and
this-> makes me know which one it is without any confusion.

Comment 54

[Simon Fraser [no longer active]]

Uh, sorry about that; brain freeze. Yeah, this looks ok. r=sfraser

Comment 55

[Darin Fisher]

Comment on attachment 71432 [details] [diff] [review]
patch including both patches from this bug

sr=darin

Comment 56

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 71432 [details] [diff] [review]
patch including both patches from this bug

a=shaver for 0.9.9, and recording simon's review in the manager.

Comment 57

[Stuart Parmenter]

fixed.  The patch in bug 106166 is still needed to keep the cams from not
stopping after a short time I believe.

Comment 58

[Vinay Badami]

*** Bug 97683 has been marked as a duplicate of this bug. ***

Comment 59

[WD]

The patch attached to this bug is actually the fix for bug 106166
The originally described bug is definately still present.   
Re: Comment #57 , the patch for bug 106166 makes no difference here.

The steps to reproduce in Comment #42 still apply.

Re-opening.

Comment 60

[Stuart Parmenter]

If I follow the steps in comment #42 things work fine for me.  I've been 
watching it now for at least 5 minutes without it stopping.

Comment 61

[WD]

I can still reproduce this with latest 0.9.9 branch build 2002030921
Note: In order to see the broken image icon, you must switch to another
application and then back to Mozilla again.   (To force a re-draw?)

Otherwise, the image will be stuck on the last frame received.

Comment 62

[R.K.Aa.]

loaded http://dormcam.mine.nu:8080/moztest.html in background in a new tab
allowed it to load before looking
streaming was OK
then changed to first tab, and back to streaming: OK
changed back/forth once more: image was broken.

Unable to repro though - now it's been OK after 10 switches, but the streaming
stopped at some point. (Easyest to see if you study the "colors" in the ceiling)
Testing with day old CVS build, Linux.

Comment 63

[Stuart Parmenter]

giving to nivedita to investigate further

Comment 64

[Stuart Parmenter]

all the patches in this bug have been checked in and I can't reproduce the
problem that WD sees.

Comment 65

[WD]

Note:

This bug is nearly impossible to reproduce with a debug build.   But an
optimized build of the same code will show it right away.   Some sort of timing
issue perhaps?

Anyway, with a debug build, every time the JPEG stream stops I see something
like this:
JPEG decoding error:
Not a JPEG file: starts with 0x43 0x6f
JPEG decoding error:
Not a JPEG file: starts with 0x73 0x82
JPEG decoding error:
Not a JPEG file: starts with 0x73 0x82
WARNING: Never finished decoding the JPEG., file
f:\mozilla_source\mozilla\modul
es\libpr0n\decoders\jpeg\nsJPEGDecoder.cpp, line 166
WARNING: Never finished decoding the JPEG., file
f:\mozilla_source\mozilla\modul
es\libpr0n\decoders\jpeg\nsJPEGDecoder.cpp, line 166


See also comment #12 and comment #13

The thing in common here is that it's *always* 0x43 0x6F that the JPEG decoder
is seeing instead of the SOI marker.
0x43 0x6F is the ASCII code for "Co"
(as in "Content-type: image/jpeg")

Comment 66

[Olivier Cahagne]

sorry for the spam but I also have JPEG stream stopping after some "time" using
build 2002031303 on Win2k from a generic Axis camera 2120.
I load the page with JPEG stream, then open another window or mail&news and,
after some "time", I get a broken icon instead of the video stream. I've been
trying to find some reproducible steps for days (since the patch was checked in)
but I cannot trigger the bug whenever I want, it just happen some time after
having loaded the stream.

Comment 67

[timeless]

sounds like a networking problem?

Comment 68

[Nivedita (gone)]

Thanks WD for the information, I am able to reproduce the problem indicated in 
the comment 42 using the optimized build. I'll try looking into what's causing 
this problem.

Comment 69

[Nivedita (gone)]

Attachment: trace of browser interaction

I think it is the netlib which stops pumping the jpeg to the imaglib after some
time. However I am not sure about it. I'll investigate further.
I have attached the trace log, where in you find closing of connection followed
by "unable to process transaction queue at this time". This is when I see
broken image on mozilla.

Comment 70

[Nivedita (gone)]

The attachment id=74076 is a .tar.gz file. I am able to consistently reproduce 
this with the optimized build. 

Comment 71

[Nivedita (gone)]

Comment on attachment 74076 [details]
trace of browser interaction 

This is a .tar.gz file

Comment 72

[Darin Fisher]

nivedita: the log file tells me that someone is returning NS_ERROR_FAILURE from
their OnDataAvailable implementation.... possibly the nsMultiPartMixed stream
converter... or possibly imglib.

the "unable to process transaction queue at this time" line is not an error or
even a warning... it simply says that there are no more pending HTTP transactions.

Comment 73

[WD]

throwing some printf's into an optimized build, I was able to determine that
this is the line that's hit when the image breaks:

http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/nsMultiMixedConv.cpp#801

Comment 74

[WD]

Attachment: nsMultiMixedConv.cpp with lots of printfs for debugging

Comment 75

[WD]

I've attached the nsMultiMixedConv.cpp file that I've used for debugging with an
optimized build.    After further analysis, I've discovered that the JPEG stream
nearly always stops here:
http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/nsMultiMixedConv.cpp#710

and sometimes here:
http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/nsMultiMixedConv.cpp#816

In both of those cases, memory is attempted to be allocated.    

Finally, I'm not sure if bug 97683 should be blocking this bug or not.  It's
likely to be related.

Comment 76

[WD]

Attachment: Patch which fixes breakage

There are 2 places where I saw problems:
1) In the PushOverLine method, there were cases where aLen was being set to a
negative value, where that would cause problems later on with Alloc()
2) The secion of code commented "//This was the last delimiter so we can stop
processing" was producing some false positives.  This would stop the stream
before it was really done.

This patch really seems like a band-aid, but in my testing it seemed to fix the
problem.  Could somebody who knows what they're doing take a look at it.   Even
if this isn't right, it should at least be a starting point.

Comment 77

[WD]

With this patch, I see one remaining problem.
After streaming http://webcam315.cede.psu.edu/view/view.shtml for a while (10+
minutes usually) at some point in time the streaming will stop.
It is when NS_BINDING_ABORTED is returned at this line:
http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/nsMultiMixedConv.cpp#835

Comment 78

[Nivedita (gone)]

Though I suspect PushOverline at "if (aPtr[1] == nsCRT::LF)" which increments 
chars, as I observed I entered this with aLen as 1 and zero as well, hence 
aLen -= chars; would yield a negative value, in this case, with chars being 
greater than aLen. 
Additionally , we are doing a lot of arithmetic with bufLen, which  is not 
protected against negatives values. 

But above these, I encounter the problem only with the given test case site. I 
tried testing it against http://engwear.org/1999/frosh/fungja/push.html and 
some other urls, I dont encounter broken image even after 10-20 mins, whereas 
in the test case url, if I just switch to other application withing minutes of 
loading the url and get back , I find broken image.

WD, can you please test against the 
url "http://engwear.org/1999/frosh/fungja/push.html " and confirm my 
observations. Can you please upload the cgi script which is used for the test 
case url. 

Comment 79

[WD]

I have tested that URL, and it does stop after a while even with my patch. 
Where it goes bad is when BufferData is passed a negative second parameter. 
(The amount of memory to buffer).    I'm still trying to track down where this
value gets set negative.

As for the software used at http://dormcam.mine.nu:8080/moztest.html
It's truetech webcam, downloaded free from http://www.truetech.com
I was going to recommend going to http://www.camarades.com to see other cams
(100 or so maybe?) that use TrueTech software, but it seems that the site is
almost all pay-only cams now.

Comment 80

[WD]

Attachment: nsMultiMixedConv.cpp with patch and more prinfs for testing

Here's the file I'm currently using for testing with an optimized build.

Comment 81

[Olivier Cahagne]

(sorry for the spam, I don't want to submit a new bug report)
It might help you, I just crashed Mozilla watching a streaming video (Axis
Netcam), I don't know if it's related but I had a single window opened so I
believe it's related. Here's the Talkback ID using build 2002032003 on Win2k:
TB4303307Q.

Comment 82

[WD]

I too have seen crashes occasionally during streaming.   It's only been with my
patch:
http://bugzilla.mozilla.org/attachment.cgi?id=74462&action=view
It's likely that the problem has always been present but without the patch, data
would never stream long enough to run into it.

I would get a crash like this, for example:
Instruction 0x0137144a referenced memory at 0x0537b000
The specified memory could not be "read"

The section of code where it would happen is:
nsMultiMixedConv::FindToken

Can somebody check if the Talkback ID TB4303307Q is the same kind of crash?

Comment 83

[Vinay Badami]

I have observed with the given testcase url the netscape communicator also 
stops after 10 minutes or so. When observed through etheral logs I found the 
server had stopped pumping data. And in mozilla as per http logs and etheral 
trace I see a EOF encountered, hence the streaming stops. I have a patch which  
would not stop streaming untill the "EOF" is encountered. I have not 
encountered any crash so far. Hence let me test the patch if streaming for 
longer duration causes a crash.

I tested the patch against the url  http://webcam315.cede.psu.edu/ were it 
streamed for more than 40 -50 mins before it encountered an EOF.

Comment 84

[Nivedita (gone)]

The comment 83  is made by Nivedita

Comment 85

[WD]

I should have noted earlier, but the URL associated with the testcase should
pump out data for about 300 seconds or so.  At which time a reload is required
to start it up again.    The image should not be broken if switching to another
window and then back again.

I'm switching the URL for this bug to:
http://engwear.org/1999/frosh/fungja/push.html

Due to the extremely high push rate, that URL is more likely to exhibit any
anomolies in how Mozilla handles Multipart-Mixed / JPEG push data.

Comment 86

[Mike Young]

bug 103057 had several talkback reports of crashes involving the site at
http://webcam315.cede.psu.edu/

It would only happen after a while of viewing and reloading, and seemed to be
subdued when the first patch for this bug was checked in.

Comment 87

[Nivedita (gone)]

Attachment: patch file to avoid display broken image after sevral frames

added a check in PushOverline for the aLen.

Comment 88

[Asa Dotzler [:asa]]

Comment on attachment 71432 [details] [diff] [review]
patch including both patches from this bug

obsoleting patch which has landed.

Comment 89

[Marc Boullet]

*** Bug 136403 has been marked as a duplicate of this bug. ***

Comment 90

[Rob Kearey]

behaviour is still present viewing an Axis 2100 webcam in rc1.

Comment 91

[WD]

any chance we can get the most recent patch for this bug checked in?
Although still not perfect with it, that patch (03/25/02 03:05) makes it work
much better than it currently does.  (RC1 and latest trunk)

Comment 92

[greer]

Reassigning owner. Previous owner is gone.

Comment 93

[Stuart Parmenter]

Handing over to networking to deal with the current issues in the multimixedconv
code

Comment 94

[Darin Fisher]

no time to look at this fixed for 1.0

Comment 95

[Darin Fisher]

hmmm... so a packet trace reveals that the connection is terminated with a
server-side TCP/IP reset.  i assume nivedita's patch avoids crashing if the
reset occurs mid-chunk... which is probably very likely.

so what should we do if the connection fails due to the server dropping the
connection?  should we reload the URL?  or maybe we should just display the last
image?  or maybe showing a broken image icon is best.

/me tries nav4x

Comment 96

[Darin Fisher]

hmm.. nav4x doesn't seem to have any trouble with this site.

Comment 97

[Darin Fisher]

actually, i finally did get it to stale with 4x... and it continues to render
the last image... even if i temporarily cover up the browser window, etc.

netstat shows sockets in the CLOSE_WAIT state, indicating that the server closed
the connection.  now, i wonder why it took so long for the problem to appear in
nav4x.

Comment 98

[Darin Fisher]

ok, i talked with pavlov, and the fact that we display the broken image icon
seems reasonable.  we just should ensure that mozilla doesn't crash when the
server terminates the connection.

Comment 99

[Darin Fisher]

crash has been fixed... see bug 100595.  as for the broken image icon thing, i
spoke with pavlov and we agreed that to allow the broken image icon.  afterall,
that best indicates a server problem (which is what it means -- modulo some bugs
-- when the multipart stream dies).

Comment 100

[Darin Fisher]

marking FIXED

Comment 101

[Darin Fisher]

whoops, i meant WONTFIX

Comment 102

[Darin Fisher]

_WONTFIX_

Comment 103

[David Mcanulty]

Instead of showing a broken image why don't you have it reload the feed?

It will be apparent that the connection is droping and re-establishing via
server side logs, i don't see why the client would be interested in that
information.

Displaying the broken image icon may be correct, but its damn inconvient to
anyone trying to use jpeg push :)

Comment 104

[Jerome Lacoste]

*** Bug 167784 has been marked as a duplicate of this bug. ***

Comment 105

[Jerome Lacoste]

See duplicate 167784.
I intended to use mozilla to deploy on clients of our application.
Unfortunately, one page of our system points to a web server on a web cam that
generates a stream of jpeg.

After a while mozilla stops refreshing the images. It sometimes crashes (see the
talkback IDs in bug 167884) but this I am not 100% sure they are related.

IE and Opera work flawlessly. I will have to use a different browser for our
deployment as I cannot use a browser that stops refreshing on a screen without
person in front of it to refresh every 30 seconds. Too bad.

Comment 106

[John Unruh]

Verified, since bug 167784 is still open.

Comment 107

[Steven Hosgood]

Seems that this bug (or something very like it) happens when trying to view the
"multipart/x-mixed-replace" stream produced by the webcam code built into
'motion' 3.x

Happens with Mozilla 1.2a and Phoenix 0.5.

Usual symptom is that the first image of the stream is displayed, but no more.
Hitting 'refresh' produces an updated still image first time it is pressed but
doesn't do anything the second or subsequent times.

However, the bug sometimes doesn't show. If the streaming ever manages to start
up correctly (maybe 20% of the time?) it will work quite happily for days.

I don't understand how something like this can be marked "verified, wontfix"
BTW. Such a statement is an oxymoron, surely?

Comment 108

[Darin Fisher]

Steven: the bug you're describing should be filed as a separate problem specific
to the "motion" camera.  thx!

WONTFIX means that we won't automatically restart a JPG push stream when the
server drops the connection.  but, in your case it sounds like there are likely
other problems.  does it work with netscape 4.x?

Comment 109

[Steven Hosgood]

Darin:
So far the stream from 'motion' seems to work 100% with Netscape 4.76 (under
linux of course). Sorry for not pointing that out before.

Will Dormann emailed to suggest I try his patch (it's attached to this bug -
presumably that's the one dated 2002-03-25). However, I'd downloaded the
distribution binary, not the sources of the browser. If I get time, I'll grab
the sources and try. However the symptoms I see are not a broken image icon
after a few frames. I get a frozen picture after one or two frames.

I'll try and get a webcam up and visible to the world to aid diagnosis of this
problem. I am however working behind a firewall at the moment - will have to
find a machine outside or get a hole put in the firewall.

Comment 110

[Adam Olsen]

Attachment: trivial "webcam" script

This is a trivial script that does server-push PNG using whatever files match
/usr/share/pixmaps/gnome-*.png.  To use it just run nc -l -p 43210 -e
serverpush.sh, then connect to http://localhost:43210/ in the browser.

Hope this helps as a testcase.

Comment 111

[Jerome Lacoste]

to Steven comment 107, see if your camera has a firmware upgrade. Mine an Axis
camera had, that solved the streaming problem. see bug 167784.
to Adam comment 110, I changed the mime/type of your attachment to text/plain
for better viewability in the browser.

Comment 112

[Steven Hosgood]

Jerome: In comment #111 it would seem that you've got the wrong idea about the
camera. I'm not using a standalone webcam, I'm using a simple CCTV camera
plugged into a capture card on a linux box. Linux's 'video4linux' interfaces
provide images on demand to a program called 'motion'
(http://motion.technolust.cx) which, amongst many things, can provide a webcam
interface.

Comment 113

[David Mcanulty]

Since the mozilla people don't seem to give a damn about this problem i've
decided to share a little workaround for all of you, you can view it in action
(with mozilla, <GASP!>) at www.hellspark.com (click drive):

Put this in your html:
<script language="JavaScript">
function javatrick(vcar) {
   var time = new Date()
   second = time.getSeconds()
   vcar.src="http://www.hellspark.com/cgi-bin/outstill.pl?" +second
}
document.write('<img NAME="vcar"
src="http://www.hellspark.com/cgi-bin/outstill.pl" width="320" height="240"
onLoad="javatrick(this)">')
</script>

Have this in your cgi-bin:

#!/usr/bin/perl
# outstill.pl Copyright David Mcanulty ([e-mail]) 1998
#
$| = 1;
use Time::HiRes qw(sleep);
$time_to_sleep = .25;   # 1second / .074074 (for 13.5 FPS)
if (-e "image") {
        open (PIC, "image");
        print "Content-type: image/jpeg\n\n";
        while (<PIC>) {
                print $_;
        }
        close (PIC);
} else {
        open (PIC, "down4repair.jpg");
        print "Content-type: image/jpeg\n\n";
        while (<PIC>) {
                print $_;
        }
        close (PIC);
        exit;
}
sleep($time_to_sleep);
exit;

The trick of course is to feed epoch time into the script so mozilla/ie/etc
can't cash the image, the url is always diffrent! :)

Comment 114

[WD]

Although I'm not disputing that there is trouble with mozilla and certain webcam
software packages, I've been streaming the webcam from http://www.hellspark.com
for the past 45 minutes straight now, and it's still going fine.

Comment 115

[Ashley Cambrell]

I've noticed that some webcam packages (like motion) have a delay between
sending  the first head and the picture

ie:
HTTP/1.1 200 OK
Max-Age: 0
Expires: 0
Cache-Control: no-cache
Cache-Control: private
Pragma: no-cache
Content-type: multipart/x-mixed-replace;boundary=BoundaryString
******* (long wait [5secs+])
--BoundaryString
Content-type: image/jpeg
Content-Length: 88888

(picture data)


Could this affect how mozilla works and does not work.  I did hack motion so
that it used a thread to handle webcam connection so that there was no delay
there (ie connect, send header, send current picture, now wait until next one)
and it seemed to work a lot better.  Is there something in the header parser
that needs the next bit of data right away?

Comment 116

[Darin Fisher]

ashley: hmm... i don't think that sort of delay should matter as far as mozilla
is concerned.

Comment 117

[Daniel Kabs, reporting bugs since 2002]

Attachment: This page presents a server push provided by a webcam.

This page presents a server push provided by a webcam.
When the server push fails on Mozilla,
the image vanishes and the "ALT" text is displayed instead.
A javascript onerror event handler is assigned to the image object.
Thus when the server push fails you should also get an alert message saying so.

Comment 118

[Daniel Kabs, reporting bugs since 2002]

Server Push is a popular method for webcams and their software
to present a continuous stream of images on a web page. It is the
fastest, easiest and most efficient way to do this! Even better,
you don't need any javascript code to update images on your web page
nor do you need any plugins to receive the stream.

This feature is of specific importance as Internet Explorer does
not support it on the windows system and needs Active-X controls
to simulate it.

We need the server push to work flawlessly soon. It's a
major application for web pages presenting streamed images.

Therefore, this bug gets my vote.

Comment 119

[Daniel Kabs, reporting bugs since 2002]

Why oh why is this bug set to WONTFIX ?

According to "A Bug's Life Cycle" WONTFIX means:
The problem described is a bug which will never be fixed.

Can anybody change the resolution state, please?

Comment 120

[Olivier Cahagne]

maybe Mobotix (used on http://kamera3.kaiserslautern.de:8903/ ) needs to fix
their software too ? See Axis which fixed their webcam code and it now works on
Gecko: see bug 167784 comment 21.

Comment 121

[Lewis Jardine]

Whatever happened to 'be liberal in what you accept, be strict in what you
produce'? I can't think of any situation where it benefits the user to display a
broken image icon rather than reload the stream. There is a documented way to
stop streaming data cleanly, and in the abscense of this is in not a reasonable
assumption that the author intended the stream to continue being displayed?

Comment 122

[Daniel Kabs, reporting bugs since 2002]

Olivier Cahagne,

the server push used on http://kamera3.kaiserslautern.de:8903/ works
flawlessly on Netscape 4.7x and Internet Explorer for Mac. Why do you 
prefer to think that the camera's server push is incorrect instead of Mozilla
being buggy?

Did you have a look at the server push contents?

 

Comment 123

[Steven Hosgood]

Sorry I've been silent on this for a while after stirring it up. Things have
been very busy lately.

I and my colleagues have been looking at 'motion' and its webcam server. In fact
we've been rewriting it. The original code is utterly horrid, though it does
seem to produce basically compilant output.

However, our experiments seem to show that the Mozilla problem relates to the
multipart boundaries. *If* the boundary string is written in the same write()
call that writes the final block of the JPEG, then Mozilla is happy and streams
it nicely. 

If the boundary gets written in a different write() call though, it freezes.
This is true of Mozilla certainly up to 1.3b (official build-id 2003021008).

It may be more difficult to observe this over a WAN, where the MTU may be small
and network fragmentation might cause the boundary to get separated from the
final block of the JPEG. We get our results over ethernet (MTU 1500ish).

                               ***********

We are unsure as to exactly how the syntax of the boundary-string is supposed to
work, though Mozilla doesn't seem over-fussy about it. The spec *seems* to say
that you give a header of the form "Boundary-String=XXYYZZ" and that you sould
prepend "--" to this when actually generating a boundary, and if you want to
generate a final part to the stream then the last boundary should have "--" both
prepended and postpended. However, some example code on the net that shows this
in action declares the boundary string in the headers with the "--" already in
place, and then uses that string (without any more "--" prepended) as the actual
boundaries. Confusing to say the least.

Comment 124

[Mike Young]

bug 195193 has been created about comment #123 .

Please take your CCs there if you are interested in JPG push stuff.