New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 163268 link

Starred by 6 users

Issue metadata

Status: Verified
Closed: Jan 2013
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug-Regression

Sign in to add a comment

Lumpy: flash hw decode - switch youtube from 360p to 1080p - video turns black and audio comes and goes

Reported by, Nov 29 2012

Issue description

Chrome Version       : 25.0.1336.0
OS Version           : 3316.0.0
Flash Version        :
Devices              : Lumpy

What steps will reproduce the problem?
1. Play a flash video in 360p
2. change resolution to 1080p
3. the video turns black and audio goes in and out

What is the expected result? video should play properly when switched from 360p to 1080p

What happens instead?the video turns black and audio goes in and out

Reproducible: 80%
Labels: ReleaseBlock-Beta
Another HW decoding case?

Comment 3 by, Nov 29 2012

Possibly. Could you please be more specific with the URL? Youtube must have dozens of videos and it may take a while to find the right one.

Comment 5 by, Nov 29 2012

Labels: Noteworthy

Comment 6 by, Nov 29 2012

I am not sure this is a Flash issue. I see strangeness and hangs going from Flash into Chrome. Maybe the V8  issue 163197 ? It needs more investigation.
Blockedon: chromium:163197
Status: Assigned
we will need to verify this once  issue 163197  is resolved
FYI, the fix for v8 issues in  (except an ARM-specific fix that shouldn't apply to this issue as it is on Intel) landed in chrome at r170545.
Labels: Iteration-70

Comment 10 by, Dec 3 2012

Blockedon: -chromium:163197
Summary: Lumpy: flash hw decode - switch youtube from 360p to 1080p - video turns black and audio comes and goes (was: Lumpy: when I switch flash youtube video from 360p to 1080p video turns black and audio comes and goes)
So, I have Chrome at 170640 and it works with software decode. Enabling hardware decode still shows the symptoms described originally described.

Comment 11 by, Dec 4 2012

What I saw before was probably V8. What I see now is that the decoder never gets fully created as we don't consume the data that would trigger this. Core flash notices this and keeps trying to recreate and so on. Investigating what is missing.

Comment 12 by, Dec 4 2012

I have to instrument this better, but it seems the 1080p decode calls get stuck in Chrome for a long time. Pawel, did anything change there recently?

Comment 13 by, Dec 6 2012

Pawel/Ami: I am not convinced this is a Flash issue. Some observations for video

1) Only lumpy has problems with 1080p. Arrow, stumpy, daisy play 1080p fine.
2) Flash sends data to the decoder. No picture buffer comes back. After 3s Flash restarts the decoding.
3) This happens with the newly rewritten Flash video decoder. It also happens with the old code that we are shipping on Daisy.
4) Problem happens on R25 but also on R23.

I could not get any meaningful logging spew with --vmodule=*content/common/gpu/*=3. I took a trace, but it just shows me 3s waits. (Can attach if of interest.) Oh, my images are amd64-generic. I assume as things are working for arrow and stumpy that there is no special sauce for lumpy?
#12: nothing's changed chrome-side for VAAPI-based decode for weeks (compatible with #13's 4)).
#13: there's no chrome-side difference between lumpy & stumpy.  Only diff I can think of is maybe heat dissipation is different, and the lumpy is overheating and slowing itself down to compensate, triggering an edge timing condition with the 3s flash restart timeout?

Comment 15 Deleted

Rootcaused to GLES2Decoder::ClearLevel calls taking ~100ms per texture. So texture_manager->ClearRenderableLevels() call in GpuVideoDecodeAccelerator::OnAssignPictureBuffers is delaying requesting pictures by a lot. Antoine suggests replacing those calls with calls that do not clear, but just mark the textures as cleared.
@posciak: FWIW, when I added that ClearRenderableLevels call in r113046 it *was* only a meta-data-clearing operation, not a pixel-clearing operation.  Or at least that's what I thought.  Do you have any idea why it takes 100ms per texture now??

(also, for color, see!topic/chrome-gpu/qJWxu9UM5Cs which is how I arrived at the above CL).

Comment 18 by, Dec 11 2012

Ami, thanks for the color! I noticed too late that Al suggested in your discussion to use SetLevelCleared, which is what I came up with as well after some reading. (This will only mark the texture as cleared, instead of wiping it.) This works and obviously should be correct if the decoder has no hickups. Do you think we may still want to call ClearRenderableLevels in the NotifyError case?
Labels: Iteration-71
Moved convo to ihf@'s CR:

Comment 21 by, Dec 12 2012

Ami has a good point, why does clearing take so long on Lumpy? On Daisy it takes 16...20ms (times 8 buffers or 150ms). On Lumpy 132..140ms (times 22 buffers).

ClearLevel calls into WrappedTexImage2D which calls glTexImage2D

glTexImage2D(target=3553, level=0, gl_internal_format=6407, width=1920, height=1088, border=0, format=6407, type=33635)

Now 33635 = 0x8363 = GL_UNSIGNED_SHORT_5_6_5
and 6407 = 0x1907 = GL_RGB

which corresponds to the textures Flash requests in ProvidePictureBuffers and explains why size per texture was only roughly 4MB and not 8MB. Changing

-                   GL_RGB,
+                   GL_RGBA,
-                   GL_RGB,
-                   GL_UNSIGNED_SHORT_5_6_5,
+                   GL_RGBA,
+                   GL_UNSIGNED_BYTE,

makes ClearLevel faster on Lumpy (average with high variance 20ms per call for a total of 426ms) even though size is 8MB now. I assume this may have been a win on Tegra2 by reducing bandwidth. Still need to check how this performs on Daisy.

Comment 22 by, Dec 12 2012

ClearLevel on daisy with the format changes from #21 now takes 60-80ms (up from 16-20ms per call for a total of 620ms). System load as judging from "top" did not change more than 10 percent, probably not at all.
Status: Started

Comment 24 by, Dec 14 2012

The Flash change to 32 bit RGBA is being rolled out with to hit CrOS R25 branch.
Ping for update.

Comment 26 by, Jan 7 2013

With the new Flash we are not hitting this anymore, but Chrome should still get a fix. Low priority though IMHO.

Comment 27 by, Jan 8 2013

Labels: -Pri-1 -ReleaseBlock-Beta Pri-2
Removing blocker.

Comment 28 by, Jan 11 2013

Labels: -Mstone-25 Mstone-26 MovedFrom-25
Bulk moving issues to Mstone-26.
Status: Fixed
the main issue is fixed here - please file a new bug for the remaining texture clearing issue

Comment 30 by, Jan 23 2013

 Issue 171617 .
Status: Verified
Project Member

Comment 32 by, Mar 9 2013

Labels: -Type-Regression -Area-UI -Feature-Flash -Noteworthy -Mstone-26 Type-Bug-Regression M-26 Hotlist-Noteworthy Cr-UI Cr-Content-Plugins-Flash
Project Member

Comment 33 by, Apr 5 2013

Labels: Cr-Blink
Project Member

Comment 34 by, Apr 6 2013

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

Sign in to add a comment