Is this a recent regression? Does this happen in M49? 

Not reproducible on Chrome  49.0.2623.111/ CrOS 7834.66.0- Blaze

Reproducible in Chrome 50.0.2661.57/ CrOS 7978.36.0 -Blaze

Thanks, Song!

Joseph, could you try on other ARM devices?

Hi Rohit,
My test as below:
1.the issue no reproduce on other ARM devices. I have checked with daisy and jaq. 
2.the flicker is only on Ads but normal video is fine.
3.issue also see on Hulu

The flicker happens on normal video/cnn.com - Blaze device.
I'm seeing the issue after hovering off the seekbar, or exiting Fullscreen, or just playing the video.

Deleted: cnn.png 553 KB

	cnn.png 553 KB View Download

Is this tegra ARM devices only? Can you post a feedback report?

We have a bug, say,  issue 542475  where cropping is not honored and Flash reads outside of the texture. Bad enough. Traditionally Flash sets TEXTURE_WRAP as CLAMP_TO_EDGE. But in this case it sounds like it is not working here (bad graphics driver?) and garbage/out of bounds is read?

songsuk@/hsiangc@ - Please share which devices it is reproducible on and whether this is seen on any other sites than CNN and Hulu. This is currently release-block stable and the cut off for the first early stable is coming up this tuesday/tomorrow. ihf@ who should be the owner for this issue?

feedback from big:
Report ID: 7898984507.

Song, Joseph, is this reproducible on Daisy, Peach, Veyron ARM families? 

the issue only see on nyan families 

Nothing too interesting in the logs. Also verified no corruption on nyan_big with build 7845 with either R20 or 21.0.0.216 Flash.

this probably regressed it, try reverting https://chromium-review.googlesource.com/#/c/327372/

There are no problems on R50-7933.0.0-nyan-big, also no signs of  issue 542475  like clamping.

Yes, corruption starts happening with 7934 without any notices in the logs. Trying to revert on master.

Reverting fixes the problem.

I am wondering if this could have been caught by running video_VideoDecodeAccelerator. Unfortunately that test was broken on nyan in December (M49 timeframe), see  issue 565759 .

Yes, the thumbnail MD5 test included in video_VideoDecodeAccelerator should've caught it.

Josafat: I can revert the NVIDIA driver drop. But that only makes sense if we skip shipping M50 on nyan, as this is a major change requiring longer soaking (even if it is a revert). Otherwise this will become a WontFix or ExternalDependency on NVIDIA (for instance if we find no other issues on nyan and decide we can live with the corruption).

Pawel: It could. It doesn't quite happen on every Flash video, more like 1/2. Do we know it happens on html5?

I'll flash my device with a bad build again.

Just running the unittest on this video could be simplest if possible?

IIRC, this drop also stopped unconditionally scaling output content from visible rect to coded size, instead providing a texture of coded size with only visible rect-sized decoded content. Do you know what are the sizes for it? Does visible to coded inequality correlate with the videos that reproduce?

From what I gather this is only blocking nyan devices? In that case we could prevent these from being updated till we resolve this issue. ihf@ Can you please share an ETA for when we could have a CL for this fix?

We would need to ask NVIDIA for a new driver. Could take months.

We could also disable hardware decode on nyan, if this fixes things, or work around in other ways.

ok. Can you share who the owner for these devices is from the partner eng team?

Does this reproduce with HTML5 video? We did test this drop in HTML5, and AFAIR it didn't have this issue. +kcwu for confirmation if possible please.

Does this correlate with visible rect != coded rect? Are we able to check whether Flash handles visible rect correctly? We still have  issue 558799  and  issue 550046  open, which suggest there may possibly be a problem in Flash with that...

Also, perhaps if we wanted to disable HW acceleration, could we disable it only for Flash?

Well, it is good that you checked html5 video but it still broke Flash. I don't know why you think Flash can be changed? It uses identical code on Mac and Windows and is not broken there.

Sorry, I thought Flash had a flag/parameter to enable HW decode?

Mac and Windows do not handle visible rect correctly and fall back to coded size as far as I know (please see comments in https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu/media/vt_video_decode_accelerator_mac.cc and https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu/media/dxva_video_decode_accelerator_win.cc).

I don't understand. Yes Flash uses hardware acceleration and yes we could add to the sessionmanager to disable it on nyan. But maybe it can be fixed?

Can we do the same as Mac and Windows for CrOS Flash?

If we decide to disable HW accel for 50/51, perhaps it would be possible to do that only for Flash and only on nyan.

In order to fix it, we would have to answer the question of whether/how Flash handles visible rect.

As for doing it in the same way as Mac and Windows, I guess we could change how Flash VDA client class in Chrome handles visible/coded sizes and override visible with coded, but that's a temporary workaround.

Reverting the drop would not be preferable, it provided other important fixes as well, which we would really like to keep.

posciak@/ihf@ Can we see if the temporary workaround fixes it for now till we find an actual fix? THis is currently blocking M50 Stable.

issue can see on www.techcrunch.com now.

thanks hsiangc@ ihf@ can we get this workaround for tonite's build?

Doesn't look like it.

Can someone try adding --ppapi-flash-args=enable_hw_video_decode=0 in /etc/chrome_dev.conf? Re-login. Then see if the issue is gone.

From a chat:
> Does flash look at visible size in media::Picture? 

There is no visible size in the PictureReady that Flash gets
https://code.google.com/p/chromium/codesearch#chromium/src/ppapi/c/dev/ppp_video_decoder_dev.h&l=82
If you look at this file
https://code.google.com/p/chromium/codesearch#chromium/src/ppapi/proxy/ppapi_messages.h&q=pictureready%20file:%5Esrc/ppapi/&sq=package:chromium&type=cs&l=1370
there are 2 interfaces:
1) PPP_VideoDecoder_Dev which Flash uses (does not have visible_rect)
2) And VideoDecoder which nobody uses (does have visible_rect)

Adobe has stated they won't switch the interface
https://bugs.chromium.org/p/chromium/issues/detail?id=378547#c15
so I don't see what can be done on the Flash side.

Now again, this should all be fixable in VDA, as Mac/Windows don't run into this. Also I don't see any benefits in letting ChromeOS Flash video diverge from Mac/Windows.

ihf@ so looks like neither approach is ideal. What would you recommend as the path forward on this?

Issue 604026 has been merged into this issue.

Why is this RVG?

I don't know.

ihf@ can you please comment on #38?

I am taking a closer look at the crop parameter handling in Flash.

I found a problem in Flash and fixed that. Which reduces the flickering from 8 lines to one faint line (1 anti aliased line). I suppressed the later temporarily, but in future nyan builds we will see a thin flickering bottom line from time to time until NVIDIA fixes its driver. This is tracked in crosbug.com/p/52466.

The Flash fix should squash corresponding Intel mirrored lines in  issue 542475 .

 Issue 542475  has been merged into this issue.

Verified on build 8712.6.0/51.0.2704.15, 7978.59.0/50.0.2661.81 & flash 21.0.0.216 -r2

Notice with 21.0.0.232+ (which I just landed) there will be a very faint single random line on the bottom until crosbug.com/p/52466 is fixed.

 Issue 558799  has been merged into this issue.

with build 8302.0.0/52.0.2727.0 & flash 22.0.0.147 -r1 flicker at bottom of video screen on CNN Live

Yes, Adobe did not integrate into 22 branch yet. This will be fixed in the next binary.

I have a similar problem with the current version of Google Chrome with a plain HTML5-banner... but built using Flash Canvas.
Here, you can see a working example: http://www.videobanner.dk/test/html5test/inferno/
I got around the problem by testing for Chrome - and if so, displaying a .webm-version, but it involves significant more work, if we have to produce all movies in two versions, so the search for a solution goes on.

Deleted: 2016-10-10_12-35-51.jpg 49.1 KB

	2016-10-10_12-35-51.jpg 49.1 KB View Download

I forgot to mention that the problem doesn't look quite like the one, described in the top - but I see that the issue at https://bugs.chromium.org/p/chromium/issues/detail?id=558799 has been merged with this one.

Also, the problem only seems to occur on computers, using a nVidia-based GPU.

Please file a new issue with details from about:gpu and about:flash. This problem was Chromebook specific.