Attempting to display a qt movie results in a corrupted audio and video track followed by a crash




16 years ago
16 years ago


(Reporter: chrispetersen, Assigned: peterlubczynski-bugs)


({crash, regression})

crash, regression

Firefox Tracking Flags

(Not tracked)



(3 attachments)



16 years ago
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
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.

Comment 1

16 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.

Comment 2

16 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).

Comment 3

16 years ago
Created attachment 123847 [details]
Stack trace from Camino


16 years ago
Keywords: crash, nsbeta1, regression

Comment 6

16 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

Comment 7

16 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?

Comment 8

16 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. 

If you click on the QT link (streaming or download), the movie content that
begins to download becomes corrupted.

Comment 9

16 years ago
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.

Comment 10

16 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

16 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

16 years ago
BTW, i can reproduce this problem on windows (win2k 2003051214 commercial trunk
OS: MacOS X → All
Hardware: Macintosh → All

Comment 13

16 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

16 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

16 years ago
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 16

16 years ago
Comment on attachment 123899 [details] [diff] [review]
proposed fix

Attachment #123899 - Flags: superreview+

Comment 17

16 years ago
Comment on attachment 123899 [details] [diff] [review]
proposed fix

Attachment #123899 - Flags: review+

Comment 18

16 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 on attachment 123899 [details] [diff] [review]
proposed fix

Attachment #123899 - Flags: approval1.4? → approval1.4+

Comment 20

16 years ago
fix checked in.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 21

16 years ago
Verified in the 2003-05-22-08 Macho trunk build under 10.2.6. Need to check
windows build.

Comment 22

16 years ago
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.