New issue
Advanced search Search tips

Issue 155437 link

Starred by 30 users

Issue metadata

Status: Duplicate
Merged: issue 154798
Owner: ----
Closed: Oct 2012
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Sign in to add a comment

Chrome's Pepper Flash crashes when publishing a stream using RTMFP

Reported by, Oct 12 2012

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4

Steps to reproduce the problem:
1. Go to opentok reference | basic tutorials --
2. click connect
3. click "Start Publishing" button
4. If the Flash Player Settings dialog is displayed, click the Allow button. This grants access to camera / mic
5. Observe Chrome's pepper crashes.

What is the expected behavior?
Chrome's pepper does not crash and able to publish a stream using rtmfp protocol

What went wrong?
Attached crash dump and we observed that it only crashes when it establishes a connection via rtmfp. A similar issue has been logged already --

Did this work before? N/A 

Chrome version: 22.0.1229.94  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
139 KB Download
Windows 7 SP1 64-bit/Intel HD Graphics 3000 driver ver.

I have confirmed that this same Chrome version crashes with Pepper Flash enabled when on this site:

It also crashes when visiting other webcam sites that use RTMPE in addition to RTMFP. I can provide details via PM.

Disabling Pepper Flash and enabling Adobe Flash works around the problem.
Confirmed in Windows 8 as well -- however, there is no workaround. 

Combined with, Google is killing off businesses that rely on real-time video chat via Flash Player. Please PLEASE fix these two bugs!
I forgot to post the Flash Crash ID: 05fcf7faeb764ec7
Folks, This bug is critical as said here. It is killing our Video-chat business after a similar problem was solved last month on the previous version!!SOLVE IT PLEASE ASAP. 
The culprit seems to be version 22.0.1229.92, released on October 8th (the most recent stable version is 22.0.1229.94 which was released on October 10th). The changelog can be viewed here:

There is only 1 commit related to Pepper - a fullscreen crash fix -, but the bundled version was upgraded from 11.3  (on .72) to 11.4 (on .94). I don't know where this upgrade is logged.

RTMFP does not seem to be the cause of this bug. Cirrus - a demo app from Adobe which relies solely on RTMFP, does not crash Pepper -
I'm not sure if it it protocol related or if it is in fact caused when Flash finds and connects to the webcam. I tested the Logitech HD C615, HD C270 and the C260 -- in each instance, Flash crashed.

@assaf: Can you please provide a URL -- or post a Flash file here -- that demonstrates the bug you are seeing?
Our team has confirmed the bug and we have a workaround for it, including a reduced test case. 

Since Chrome 22.0.1229.92, any call to Camera#setMode (AS3) that includes two specific resolutions (640x480 or 320x240) will lead to a crash. The default values when calling Camera#getCamera (160x120) do not cause any issue at all.

According to our test case, 640x480 will lead to an instant crash (upon load), while 320x240 only randomly does so (after around 4 or 5 consecutive page loads). No other "common" resolutions were found to cause similar crashes.

A simple workaround is to call Camera#setMode with a resolution of 640x479 and 320x239. The FPS parameter does not have any impact on this bug.

A reduced test is available at
The workaround is great news to all of us in the Flash video chat business!

Comment 9 by, Oct 12 2012

Thank you for suggesting this workaround.  We will test its efficacy this morning.

However, I have to point out that in the last 3 months, Chrome has gone from being the most stable browser on my desktop to the least.  I do not know what is up with your now-nonexistant QA process, but the continuous stream of problems you are inflicting on end users is creating real issues for companies who make use of Flash.

It is incredible to me that Internet Explorer has now become a preferred browser to Chrome.  Someone in the Chrome team should be paying real attention to the fundamental degradation in quality.

Agreed. A short-term solution for Google would be to just add NPAPI back in as the *default* Flash plugin until PPAPI is truly usable -- and tested!! -- and a lot of headaches would go away. The bugs that we've discovered are so end-user-visible and so painfully easy to uncover that it seems impossible that Google would not have caught them prior to release...and yet...

It wouldn't be so bad if updates weren't automatically pushed out. I mean, it would be bad, but at least we would have more control over the impact Google has of pushing out buggy code. Google's balance between providing a secure product and the hastiness it goes through to push out updates needs a complete reset.
Thanks for suggesting the workaround -- it is indeed not an RTMFP problem and we applied the workaround  suggested in comment #7 and verified it works. 
Labels: Feature-Flash

Comment 13 by, Oct 15 2012

Voting for comment #9 and #10.  The PepperFlash plug-in has been a nightmare for us Flash based companies.
We've also been able to replicate the immediate crash when using the following resolutions:


There may be others that fail, but those were tested and did indeed fail.

Comment 15 by, Oct 16 2012

IMHO no *release* should be released with such a huge and obvious bug. 
If it happen then it should be fixed ASAP, auto-update allow to do this.

This situation shows that there is something broken in the quality-assurance/non-regression process of Pepper Flash. 
I suggest you take this bug seriously: fix it ASAP and fix your pre-release tests to ensure this never happen again.

Comment 16 by, Oct 17 2012

This is the same as  issue 154798 . In my first tests using the workaround I noticed that the video encoding performance using H264 is extremely bad. If I remember correctly the hardware acceleration only works if the width/height of the video is a power of 8. So with this workaround we would lose the hardware acceleration for all browsers.

I think the preferred step in this case is to continue blocking chrome/chromium users from using the in-browser video chat service instead of making it perform badly for all browsers.

Can this performance problem be confirmed by anyone else (using the workaround)?

Comment 17 by, Oct 17 2012

My flash crashes with resolution of 640x360, so the workaround doesn't solve the problem.
Firefox seems to be using the following flash version with no crashes (Regarding the webcam): 11.4.402.287.
I'd suggest upgrading flash version ASAP.

Unfortunately, currently I recommend our users use FF or IE. 

Try 639 - confirmed we can stop the crash by changing width OR height from 320 to 319 or 240 to 239

Comment 19 by, Oct 17 2012

We've updated our test case from comment #7 to facilitate testing various resolutions. You can find an advanced version of the test flash here:

We were not able to get Chrome's PepperFlash to crash with 640x360.

Comment 20 by, Oct 17 2012

Regarding comment #16, we are able to confirm significant performance issues with pepper. Don't think this is an encoding side issue though based on our tests. We tried a test with RTMP running both a publisher and subscriber. The following are the results:

Pepper Plugin - Disabled (RTMP) : (320x240, 320x241, 160x120) - Publisher side - ok, Subscriber latency as expected.

Pepper Plugin - Enabled (RTMP) :  (320x240, 320x241, 160x120) - Publisher side - ok, Subscriber latency is very bad. Significant incidence of freezing, latency and crashes. We did the (320,240) test just to baseline against the control case.

Chrome version: 22.0.1229.94/Windows 7

Comment 21 by Deleted ...@, Oct 18 2012

Test cases all well and good, but do we have any ETA on a proper fix for this? I have many clients complaining, and updating everyone's applications to work around this is going to be problematic

Comment 22 by, Oct 18 2012

Yes, it would be great if someone can comment about an ETA for a proper fix. This is massively impacting our users.
Agree with the above - I have reports from important clients on this one, an ETA would be very useful.

Comment 24 by Deleted ...@, Oct 18 2012

yes, please. ANY ETA would be helpful to pass along.

Comment 25 by, Oct 23 2012

Labels: Feature-Plugins-Pepper
There was an off-by-one bugfix in early October which would have affected resolutions where x*y*4 was exactly divisible by 4096.  Which seems to match the resolutions described in comment #14.  Based on the version number, I would have expected the fix to be present in PPAPI Flash versions described, I'll go track down whether this fix is present or not.

Meanwhile - I see no reports of this on M-23 (beta) or M-24 (dev/canary), does this match your experience?

This is very frustrating. Chrome has introduced numerous bugs, all related to flash video chat. Currently we have the following issues which are all 'breaking' for video chat. Is this googles subtle way of pushing webrtc/hangouts? I cant believe these issues made it through QA and still have not been fixed. Most of these issues appeared on August 1st- Nearly 3 months!

Summarized below is the list of everything currently wrong in the flash video-chat ecosystem. Most are likely related to each other in one way or another.

Dan from Tinychat

Long latency in flash video chat

Audio Stuttering:

Echo cancellation doesnt work and/or induces bad quality depending on speex/nelly:

Flash crashes upon broadcasting common resolutions ( rtfmp/rtmpe)

Retina display macbooks crash when attempting to broadcast webcam:
Labels: not-webrtc
Mergedinto: 154798
Status: Duplicate
Probably a dupe. It should be fixed in M23. Please test on beta.

Comment 29 by Deleted ...@, Nov 5 2012

Found a workaround by using StageVideo. Since Flash11.4 the StageVideo class has a new method attachCamera.
Our product is Flash10.2 compatible, so we had to check existence of the StageVideo.attachCamera method at runtime, without calling it explicitely like this :
var sv:StageVideo = stage.stageVideos[0];
var attachCameraEnabled:Boolean = sv.hasOwnProperty ("attachCamera");
if (attachCameraEnabled) sv["attachCamera"](cam);

Since we used this workaround, we didn't reproduce any crash on every configurations tested.

Comment 30 by Deleted ...@, Dec 10 2012


Project Member

Comment 31 by, Mar 10 2013

Labels: -Area-UI -Feature-Flash -Feature-Plugins-Pepper Cr-UI Cr-Content-Plugins-Flash Cr-Content-Plugins-Pepper
Project Member

Comment 32 by, Apr 5 2013

Labels: Cr-Blink
Project Member

Comment 33 by, Apr 6 2013

Labels: -Cr-Content-Plugins-Flash Cr-Internals-Plugins-Flash
Project Member

Comment 34 by, Apr 6 2013

Labels: Cr-Internals-Plugins
Project Member

Comment 35 by, Apr 6 2013

Labels: -Cr-Content-Plugins-Pepper Cr-Internals-Plugins-Pepper

Sign in to add a comment