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

Issue 617811 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: Jun 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocked on:
issue chrome-os-partner:53980

Blocking:
issue 615272



Sign in to add a comment

[H264] Fatal errors on device Blaze with hardware acceleration video decode disabled

Project Member Reported by srcv@chromium.org, Jun 6 2016

Issue description

Version: 52.0.2743.28 / 8350.19.0 dev
Device: Blaze
Reference bug: https://bugs.chromium.org/p/chromium/issues/detail?id=615272#c25

What steps will reproduce the problem?
(1) Join an apprtc loopback call from device Blaze using https://appr.tc/?debug=loopback&vsc=h264
(2) Stay in the call for 1-2 minutes


What is the expected output?
Audio and video should be clear without any freezes

What do you see instead?
1) Remote video starts after 30 sec -1min after loopback call is started
2) Remote video freezes as soon as it starts
3) V4L2 Decode WeakPTr errors as shown in : https://paste.googleplex.com/6523866897711104

Note that this issue is not seen when "Hardware-accelarated video decode Mac, Windows, chrome OS" flag is disabled in chrome://flags









 
log-060616-162227.tar.gz
954 KB Download

Comment 1 by srcv@chromium.org, Jun 6 2016

Blocking: 615272
Blockedon: chrome-os-partner:53980
Labels: VideoShortList
Components: OS>Kernel>Video
Project Member

Comment 5 by sheriffbot@chromium.org, Jun 7 2016

Labels: -M-52 M-53 MovedFrom-52
Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -M-53 -MovedFrom-52 M-52
Should WebRTC H264 related issues block M52?
The above version seems not to have the revert in  issue 615272  merged in yet. I'm also seeing evidence of HW encoder being invoked in the attached logs.

Would you be able to retest with CrOS 8350.21.0 / 52.0.2743.32 please?
posciak@, I think this bug is with SW encode and HW decode, the logs point to that. I am looking forward to srcv@ to reproduce it.

Comment 9 by srcv@chromium.org, Jun 8 2016

Status: WontFix (was: Untriaged)
This issue is not reproducible with apprtc loopback calls on device Blaze with 52.0.2743.32 / 8350.21.0 dev (tried with both Hardware decode enabled and disabled)


Actually this is more likely to have been "fixed" by turning off HW enc.
@8: FTR, the logs in #1 show evidence of HW encoder being invoked, so I believe this was actually tested with HW encoder still on.
(The above refers to the original report, HW encoder was disabled for tests in #9 on 52.0.2743.32 / 8350.21.0 dev)
Ok, sounds good then. I wasn't sure if disabling HW encode was enough as WeakPtr seemed to point at VDA.

Comment 14 by srcv@chromium.org, Jun 20 2016

Status: Verified (was: WontFix)
Marking this issue as "Verified" as per comment #10

Sign in to add a comment