video_ChromeHWDecodeUsed failures in CQ / PFQ |
||||||||||
Issue descriptionThere are a huge number of autofiled issues with the following symptom, several per week: Reason: Media.GpuVideoDecoderInitializeStatus not loaded or histogram bucket not found or histogram bucket found at < 100%. Query: https://bugs.chromium.org/p/chromium/issues/list?can=2&q=video_ChromeHWDecodeUsed Filing this as a tracking bug for these failures, and linking some of the more recent failures.
,
Jan 6 2017
I took a brief look at the previous link. HW decode on lumpy failed. Nothing in the kernel/chrome logs though. http://cautotest.corp.google.com/afe/#tab_id=view_job&object_id=94587667 The same DUT ran video_VideoSanity.vp8 before and passed, which is of course software decode. https://uberchromeos-server38.corp.google.com/new_tko/#tab_id=spreadsheet_view&row=job_tag&column=subdir&condition=afe_job_id+%3D+94587667+AND+hostname+%3D+''+AND+test_name+%3D+'video_ChromeHWDecodeUsed'&show_incomplete=true https://uberchromeos-server38.corp.google.com/new_tko/#tab_id=test_detail_view&object_id=410207066
,
Jan 6 2017
Overall the behavior of the test is not terrible, but on occasion there are problems. https://wmatrix.googleplex.com/unfiltered?hide_missing=True&tests=video_ChromeHWDecodeUsed&days_back=10
,
Jan 7 2017
,
Jan 13 2017
Could be relevant to issue 652793 which is duped into issue 602295
,
Jan 24 2017
Chrome on Chrome OS gardener here (out sick, but looking in anyway). warx@ is seeing persistent failures on these tests over the last 12 hours or so: https://bugs.chromium.org/p/chromium/issues/list?can=2&q=video_ChromeHWDecodeUsed&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids For example on tricky: https://uberchromegw.corp.google.com/i/chromeos.chrome/builders/tricky-tot-chrome-pfq-informational A histograms-related CL landed recently. I'm not sure if that's related or not. Details at issue 602295 . Any idea if something changed recently with these tests?
,
Jan 24 2017
We are working on a bisect now. Range is #445466 - #445545. I suspect: https://codereview.chromium.org/2640573002 or https://codereview.chromium.org/2628133002 (We should file a separate issue to track this, it's clearly a recent regression)
,
Jan 24 2017
I was setting up my bisect, but I will let you go ahead. Just curious, is it broken video or broken histogram?
,
Jan 24 2017
The test error result is: video_ChromeHWDecodeUsed: ERROR: Media.GpuVideoDecoderInitializeStatus not loaded or histogram bucket not found or histogram bucket found at < 100%, new report FWIW, the chrome log contains a warning, but I haven't checked to see whether the warning is "normal": WARNING:vaapi_video_decode_accelerator.cc(299)] Picture id 11 does not exist
,
Jan 24 2017
Some logs may suggest broken GPU. Now I did build ToT Chrome at 445829 + 58.0.2992.0 image on Samus and hardware decode works (Flash h264). html5 h264 decode seems not to work with the test. White tab. Video right clickable but does not play. test_that $DUT video_ChromeHWDecodeUsed.h264
,
Jan 24 2017
vp8/vp9 video plays, but does not report it did.
,
Jan 24 2017
Constant failure starts on #3260 tricky-tot-chrome-pfq-informational with last revision 445545. https://uberchromegw.corp.google.com/i/chromiumos.tryserver/builders/chrome_pfq_informational/builds/21 This is what I ran for this revision on peach_pit (excuse me for this not tricky, peach_pit hits the same errors and I just submitted new test for tricky). It should fail but it pass. Any ideas?
,
Jan 24 2017
To clarify "should fail" - it is failing consistently on tricky-tot-chrome-pfq-informational, peach_pit-tot-chrome-pfq-informational, and many (but not all) of the PFQ builders. I have no idea why it did not fail on the tryserver; it appears to be running the bvt-cq stage, but the output is pretty sparse.
,
Jan 25 2017
I did some tests on my local peach_pit device, with chromeos version 9217.0 (not tot, but lastest), and then run video_ChromeHWDecodeUsed.h264.mse tests. Chromium revision #445466 fails the test, even the first revision of latest successful tricky build #445400 fails the test. that should tell it is not revision from chromium that breaks this?
,
Jan 25 2017
,
Jan 25 2017
ihf@: for #10 and #11, did you build Chrome with branding/proprietary codecs enabled? If not, that would explain why H264 didn't work, but VP8/9 did.
,
Jan 25 2017
fyi, for comment 14, I didn't do "build Chrome with branding/proprietary codecs enabled"
,
Jan 25 2017
Re 16: I had an external checkout as I recently switched my machine. So it was without the cros chrome-sdk --internal flag (and hence without proprietary codecs).
,
Jan 25 2017
local DUT bisect shows the culprit CL is: https://codereview.chromium.org/2647353003, reverted CL is created at: https://codereview.chromium.org/2649973007/
,
Jan 25 2017
For discussion of culprit CL see issue 602295 Include Persistent Histograms in chrome://histograms
,
Feb 1 2017
https://codereview.chromium.org/2658163002/ now forces a full merge of histograms from all sub-processes with every load of chrome://histograms so I should be able to again land the enable-by-default of the persistent histograms experiment and not cause a problem with these builds. Is there any way you can verify this before-hand?
,
Feb 1 2017
It has to run tests locally on chromebook. I see it is already landed. +xdai@ for this week's gardener to track.
,
Feb 1 2017
Re#22: Thanks! Seems all the informational builders are quite happy. So I think this CL should be fine.
,
Feb 13 2017
,
Apr 17 2017
,
Apr 20 2017
Verified on https://wmatrix.googleplex.com/unfiltered?hide_missing=True&tests=video_ChromeHWDecodeUsed&days_back=60 |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by lpique@chromium.org
, Jan 6 2017