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

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Chris Petersen]

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.

Comment 1

[Chris Petersen]

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

[Chris Petersen]

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

[Chris Petersen]

Attachment: Stack trace from Camino

Comment 4

[Chris Petersen]

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

Comment 5

[Chris Petersen]

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

[Darin Fisher]

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

[David :Bienvenu]

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

[Chris Petersen]

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.

Comment 9

[Chris Petersen]

Attachment: 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

[Peter Lubczynski]

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

[Darin Fisher]

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

[Darin Fisher]

BTW, i can reproduce this problem on windows (win2k 2003051214 commercial trunk
build).

Comment 13

[David :Bienvenu]

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

[David :Bienvenu]

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

[David :Bienvenu]

Attachment: 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

[Darin Fisher]

Comment on attachment 123899 [details] [diff] [review]
proposed fix

sr=darin

Comment 17

[Peter Lubczynski]

Comment on attachment 123899 [details] [diff] [review]
proposed fix

r=peterl

Comment 18

[Peter Lubczynski]

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.

Comment 19

[(not reading, please use [e-mail] instead)]

Comment on attachment 123899 [details] [diff] [review]
proposed fix

a=sspitzer

Comment 20

[David :Bienvenu]

fix checked in.

Comment 21

[Chris Petersen]

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

Comment 22

[Chris Petersen]

Verified in the 2003-05-23-09 Win32 trunk build.