Closed
Bug 206530
Opened 21 years ago
Closed 21 years ago
Attempting to display a qt movie results in a corrupted audio and video track followed by a crash
Categories
(Core Graveyard :: Plug-ins, defect)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: chrispetersen, Assigned: peterlubczynski-bugs)
Details
(Keywords: crash, regression)
Attachments
(3 files)
9.30 KB,
text/plain
|
Details | |
328 bytes,
text/html
|
Details | |
1003 bytes,
patch
|
peterlubczynski-bugs
:
review+
darin.moz
:
superreview+
sspitzer
:
approval1.4+
|
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.
Reporter | ||
Comment 1•21 years ago
|
||
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.
Reporter | ||
Comment 2•21 years ago
|
||
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).
Reporter | ||
Comment 3•21 years ago
|
||
Reporter | ||
Updated•21 years ago
|
Reporter | ||
Comment 4•21 years ago
|
||
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
Reporter | ||
Comment 5•21 years ago
|
||
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
Comment 6•21 years ago
|
||
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...
Comment 7•21 years ago
|
||
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?
Reporter | ||
Comment 8•21 years ago
|
||
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.
Reporter | ||
Comment 9•21 years ago
|
||
I reduced the page down to a simple test case that uses a single embed element and minimal attributes.
Assignee | ||
Comment 10•21 years ago
|
||
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.
Comment 11•21 years ago
|
||
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?
Comment 12•21 years ago
|
||
BTW, i can reproduce this problem on windows (win2k 2003051214 commercial trunk build).
OS: MacOS X → All
Hardware: Macintosh → All
Comment 13•21 years ago
|
||
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.
Comment 14•21 years ago
|
||
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?
Comment 15•21 years ago
|
||
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 16•21 years ago
|
||
Comment on attachment 123899 [details] [diff] [review] proposed fix sr=darin
Attachment #123899 -
Flags: superreview+
Assignee | ||
Comment 17•21 years ago
|
||
Comment on attachment 123899 [details] [diff] [review] proposed fix r=peterl
Attachment #123899 -
Flags: review+
Assignee | ||
Comment 18•21 years ago
|
||
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 19•21 years ago
|
||
Comment on attachment 123899 [details] [diff] [review] proposed fix a=sspitzer
Attachment #123899 -
Flags: approval1.4? → approval1.4+
Comment 20•21 years ago
|
||
fix checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 21•21 years ago
|
||
Verified in the 2003-05-22-08 Macho trunk build under 10.2.6. Need to check windows build.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 22•21 years ago
|
||
Verified in the 2003-05-23-09 Win32 trunk build.
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•