9.30 KB, text/plain
328 bytes, text/html
1003 bytes, patch
|Details | Diff | Splinter Review|
Build: Macho: 2003-05-20-03 Camino: 2003-05-17-04 Platform: OS X Expected Results: QT movie should play as it's being downloaded. No corruption or crash should result. What I got: As the movie begins to play during the download process, the audio track become corrupted and produces a lot of static noise. The video track also freezes on a single frame. Steps to reproduce: This problem is most reproduceable when the cache is empty without the movie data being previously loaded. It's important to have cleared the cache and history before you can reproduce each time. 1) Go to http://homepage.mac.com/chrispetersen/iMovieTheater26.html 2) QT plugin is intialized and movie data starts to load 3) Within a few seconds of the movie beginning to play, you should notice the audio track becoming corrupted followed by the video track I have QT 6.2 installed ( QuickTime Plugin.plugin) running under 10.2.6.
Note: This happens on both Camino (2003-05-20-04) and Macho Nightly builds (2003-05-20-03). I have isolated the regression on when the problem started to appear on the Camino build. The problem first appeared on the 2003-05-06-04 Camino nightly since I can reproduce this problem using the 2003-05-05-04.
Oops, I mean I can't reproduce on the 2003-05-05-04 Camino build but it does occur on the next camino nightly (2003-05-06-04).
Here are some possible checkins that around this timeframe: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fnetwerk&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=05%2F05%2F2003+04%3A00&maxdate=05%2F06%2F2003+04%3A00&cvsroot=%2Fcvsroot
Perhaps this one maybe more related: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fmodules%2Fplugin&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=05%2F05%2F2003+04%3A00&maxdate=05%2F06%2F2003+04%3A00&cvsroot=%2Fcvsroot
of the three possible changes listed in comment #4, i think the change to the ODA size is the most likely candidate here. the other two seem unrelated to data streaming. i wonder if the plugin is not able to deal with larger data buffers...
Major bummer, and ironic since increasing the ODA size benefitted Mac OSX the most. Can we get Chris a build that has the ODA throttled back to see if that's really the cause? And would it be possible to change the ODA for plugins, i.e., have plugin channels configure the ODA differently, once we have configurable ODA amounts on channels? Or do we even know the channel is for a plugin?
Sure, I would be happy to use the test build if it is provided. I'm finding other sites that have this problem too. http://www.kia.com/041703.shtml. If you click on the QT link (streaming or download), the movie content that begins to download becomes corrupted.
Created attachment 123893 [details] Simple test case from homepage.mac site I reduced the page down to a simple test case that uses a single embed element and minimal attributes.
hmm.., it's probably the ODA size. What bug changed this and what's the new max? We can fix this for Quicktime pretty easily by making the NPAPI stream listener in ns4xPluginInstance.cpp aware of the new size. There is a #define for MAX_PLUGIN_NECKO_BUFFER in ns4xPlguinStreamListener.h that's currently set to 16k. We should also double check XPCOM plugins like Java and Real which use our stream listeners directly.
peter: the new max is 64k, but hard coding that seems dangerous, and the size is actually configurable at build time (minimo builds have a much small max size). there is no pref that you can check unfortunately. why does that code need to artificially limit the ODA size?
BTW, i can reproduce this problem on windows (win2k 2003051214 commercial trunk build).
OS: MacOS X → All
Hardware: Macintosh → All
I'm pretty sure it's the 16K ODA check - I put that back in, and the last test case plays for me. (I think the kia site is busted - it didn't work in IE either). I can try the change in plugin instance.
that plugin instance code looks like it tries to handle the case where it gets more data than the stream buffer size - it does keep looping. Is there a bug in that loop code, or something in the plugin itself that doesn't like getting called over and over in the loop?
Created attachment 123899 [details] [diff] [review] proposed fix pass in the correct number of bytes to read each time through the do loop. this seems to fix it for me. I'll test some more.
Comment on attachment 123899 [details] [diff] [review] proposed fix sr=darin
Attachment #123899 - Flags: superreview+
Comment on attachment 123899 [details] [diff] [review] proposed fix r=peterl
Attachment #123899 - Flags: review+
Comment on attachment 123899 [details] [diff] [review] proposed fix requesting approval for 1.4: this fixes a regression with network streams and plugins, without this fix plugins may crash or display currupt data.
Attachment #123899 - Flags: approval1.4?
Comment on attachment 123899 [details] [diff] [review] proposed fix a=sspitzer
Attachment #123899 - Flags: approval1.4? → approval1.4+
fix checked in.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Verified in the 2003-05-22-08 Macho trunk build under 10.2.6. Need to check windows build.
Status: RESOLVED → VERIFIED
Verified in the 2003-05-23-09 Win32 trunk build.
You need to log in before you can comment on or make changes to this bug.