Chromium

[Comment Deleted]

[again via @drpizza] Other users are reporting similar issues. All AMD.

Given the recent information about AMD / ATI cards having some decode issues, could it be a remnant?

I just asked him what is the mimetype to see if it is vp9 (I'm guessing) or 264.

I just asked him what is the mimetype, to see if it is vp9 (I'm guessing) or 264?

I repro'd this on my Lenovo X1 Carbon.  https://www.youtube.com/watch?v=7_64VHqDHQQ, stats for nerds shows VP9.  Interestingly it also doesn't show dropped frames, but is pretty clear there's a bunch of stutter that becomes smoother when using the 720p stream.

Are you on M40 as well? What about shutting off some of the gpu rendering options? And lastly can you capture a trace?

I tested on my (z600) for both M39 and M40 and it was fine.

Also stats for nerds says 7_64VHqDHQQ is 1080p@30.

So this video, for example: https://www.youtube.com/watch?v=NnKKTc-11AE

video/mp4; codecs="avc1.64002a"

The first few seconds play back normally, then the massive frame loss starts.

[Empty comment from Monorail migration]

YouTube productforums complaint with similar data:

https://productforums.google.com/forum/#!category-topic/youtube/playing-and-watching-videos/IIMbk3lRi28

At the 90%ile for VP9 HFR playbacks, we're dropping on average 10% of frames, compared to < .1% of frames at 30fps.

This does not appear to be a problem for Chrome H.264 playbacks in the HTML5 player.

The video I linked above (https://www.youtube.com/watch?v=NnKKTc-11AE) is now playing back as 1080p60 WebM, and that's fine. It seems that it's only the H.264 that's an issue. I don't know if there's any way to force YouTube to offer H.264 versus WebM.

Re: c#13

@drpizza - are you saying that it is only for H.264 that you are seeing dropped frames in the AMD/ATI scenario? Can you provide more details on the machine setup - processor / graphics card details?

Also can you try chrome://flags/#disable-accelerated-video-decode
* disable hardware accelerated video decode and try on another H.264 1080p@60fps file?

Thanks.

I don't know how to force YouTube to offer me an H.264 1080p60 file so cannot test anything at present.

It seems that it is only the H.264 files that are dropping frames; the WebM was fine (though I assume WebM doesn't have the same level of hardware acceleration).

Processor is a Sandy Bridge i7-2600 (4C8T, up to 3.4 GHz). GPU is a Radeon HD 6850. Running Windows 8.1 Pro, 64-bit, and Chrome-dev 64-bit.

re: c#15 - here's a video in 1080p@60 - https://www.youtube.com/watch?v=bisxgQpqGYM that *I* see as H.264

Can you
a) test if it drops frames?
b) toggle chrome://flags/#disable-accelerated-video-decode and check if the issue persists?

Thanks.

OK, that one is showing as H.264.

With acceleration enabled, frames are dropped en masse.
With acceleration disabled, no frames are dropped, using about 8% CPU (so, about 2/3 of one thread on one core).

Thanks for the confirmation. This clearly indicates that hardware H.264 is the one causing issues -

1. Can you share your driver version number for us to note? Thanks.

@dalecurtis: next steps - include the GPU team?
@ericde: FYI - confirmed issues on H.264 decode only.

The driver package is branded as "14.9" by AMD, it reports its version to Windows as 14.301.1001.0.

+windows gpu video decoding folk.

Do you only see this with M40 or also with M38 or M39?

https://www.youtube.com/watch?v=TWI0LNAU2Z4 indicates others are affected and it's system-wide for affected drivers

Using this 1080p60 test file http://cdn.gsmarena.com/vv/reviewsimg/lg-g2/review/camera/gsmarena_v001.mp4

I'm playing the file in MPC-HC's integrated decoder, LAV, (which lets me choose between software, QuickSync, and DXVA2) (http://mpc-hc.org/). There are two DXVA2 modes; "native" (the default) and "copy back". I assume "native" leaves the decoded picture in a GPU memory-resident buffer, and "copy back" copies it back to system memory.

Software playback is solid 60fps. QuickSync playback is solid 60fps. DXVA2 "native" playback (using the GPU) is 30fps, dropping a ton of frames.

DXVA2 in "copy back" mode, however, plays perfectly.

This suggests to me that the hardware can certainly manage to decode the stream, but that there is some issue around DXVA2. Perhaps something that a driver update can fix.

@drpizza: Are you playing that file locally or over the network? Over the network, the first time through seems to hit buffering issues when the hardware decoder is used. The second playthrough is smooth for me though. Is that true for you?

It looks like the video in c#22 is high profile, so dropped frames issues are related to https://crbug.com/chromium/426707. I can reproduce this locally with that patch reverted. ananta@ is in the process of getting that fix merged back to M39.

For the people in which h264 hardware decoded is playing poorly please paste the entire chrome://gpu page.

Also, if your video driver is more than a year old, please update your video driver anyways.

Also, if you a switchable gpu deal like http://en.wikipedia.org/wiki/AMD_Hybrid_Graphics let us know.

My chrome://gpu log: https://dl.dropboxusercontent.com/u/2648/Google%20Chrome%20GPU%20log%20AMD%20HD%206950%201GB.txt

I use an AMD HD 6950 1GB GPU.
And I use the latest non-beta AMD driver: v14.9. Released on 29/09/2014 (DD/MM/YYYY)

I'm not gonna repeat myself: all the information I have so far provided can be found at the topic that's already been mentioned: https://productforums.google.com/forum/#!category-topic/youtube/playing-and-watching-videos/IIMbk3lRi28
Username there is Asgaro. :)

Thank you.

Can those of you having issues with playback, start playing a video and then open another tab to chrome://inducebrowsercrashforrealz ? It will crash the browser and should leave a crash id in chrome://crashes -- please report that id here.

Please also try starting chrome with --disable-gpu and see if that helps.

I have the same experience as sebfisch...@gmail.com: I don't get to see a crash report in chrome://crashes.

Regarding --disable-gpu:
Yes, that fixes videos previously freezing to now work fluently.
I checked the video codec before and after using that option.
Before it's AVC and after it's VP9.

I'm assuming this option does the same as disabling hardware acceleration in the user accessible options menu?

Hmm, that's really weird, I definitely see a crash id when I execute a browser crash in that way.

Can you try restarting your computer after enabling "Automatically send usage statistics and crash reports to Google" in chrome://settings? It's possible Chrome notifications is keeping Chrome running in the background.

Hi all, I'm experiencing the same issues as above, where videos playing in 1080p60 on the h264 codec are experiencing large amounts of stuttering, whereas the vp9 codec is fine.

An example video is here: (warning; loud) https://www.youtube.com/watch?v=sC1XEwsVKzU
The video plays as h264 for me. Disabling hw acceleration improves playback.

Pastebin of my chrome://gpu; http://pastebin.com/C6AG40JU
Forcing tab to crash: Crash ID 143c89dd145169a6 (Chrome)

Windows 7, AMD driver 14.301.1001.0 Catalyst version 14.9
Google Chrome   39.0.2171.62 (Official Build) beta-m
Revision        6ac5b3b7a7861707e68ff88605ec7e2e1dd3f941-refs/branch-heads/2171@{#415}

sebfischer64: From looking at the crash dump it looks like your Avast anti-virus might be injecting something into Chrome which can cause problems. Are you using the latest version of Avast?  I also see FRAPS being injected, can you try disabling that?  You might try switching to the x64 version of chrome dev channel to see if things are better:

https://www.google.com/chrome/browser/?platform=win64&extra=devchannel

@joshgrant1091: That's not the right crash id. Can you try restarting your computer and forcing the crash again?

After digging into this, it's pretty clear Chrome's DXVA decoder can't keep up with 60fps H264 streams in all cases. On my local workstation I can trigger horrible performance by opening two DXVA compatible videos at once.  The ones I used were:

http://www.youtube.com/watch?v=ffrN0CVSIm4 
http://www.clickspace.tv/sites/default/files/Azul2YouTubeIntro_0.mp4

Tracing (attached) shows that we're spending > 8ms almost every frame in GetData():

https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu/media/dxva_video_decode_accelerator.cc&l=342

That loop also frequently hits the iteration cap which seems to result in the frame being dropped. Compounding all of this is DoDecode() taking upwards of 30ms every now and then:

https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu/media/dxva_video_decode_accelerator.cc&l=822

Tripling up on those problems is the fact that DXVA decoding happens on the main GPU thread, which results in janking the entire browser; roughly ensuring that almost every frame which makes the above gauntlet is probably dropped during rendering/compositing :(

Sadly, there doesn't appear to be any easy way to fix this with the current implementation:
- Unavoidable texture copy due to ANGLE restrictions on actually talking to the D3D output device...
- Slow IMFTransform::ProcessOutput()
- ???

It's possible there's some way to defer these actions with some intelligent status checks, but I couldn't find anything obvious that seemed to help.  We may need to just blacklist 1080p60 DXVA decoding in Chrome for now.  I believe these are the same problems that result in issues with high profile H264 decoding; see https://crbug.com/chromium/426707.

If anyone is seeing these issues with VP9 we should discuss that on a new bug.

[Empty comment from Monorail migration]

cpu: Can your team take a look? Short of blocking 1080p60 H264 for DXVA I don't have a better suggestion :(

Will look into this next week

[Empty comment from Monorail migration]

re #38: perhaps this is the correct crash ID: Crash ID d954c846d73e0e79

I replaced my video card recently with an NVIDIA model so I'm afraid I am no longer able to repro any issues.

In replacing it, I learned my old card was actually an HD6950, not 6850. Not that this changes the analysis, of course.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1dd7d968e3f77ec0c90a80c944cd1ec4da8aab11

commit 1dd7d968e3f77ec0c90a80c944cd1ec4da8aab11
Author: ananta <ananta@chromium.org>
Date: Thu Dec 04 23:24:40 2014

Move the DXVA decoder off the GPU thread.

The DXVA decoder runs on the GPU thread today. When the decoder has enough data to produce an output frame
the IMFTransform::ProcessOutput call blocks while waiting for the media foundation threads to produce the output
frame. This causes lots of jankiness and dropped frames while playing H.264 videos especially HD 1080P videos.

The approach we are taking to resolve this is to move the actual IMFTransform decoding off the GPU thread. This is
implemented by creating a worker thread per DXVA decoder instance. The lifetime of this thread is dependent on the
lifetime of the DXVAVideoDecodeAccelerator class. The IMFTransform decoder instance is created and destroyed on the main
thread. However the calls to ProcessInput/ProcessOutput etc happen on the decoder thread. The decoder state is modified
on both the GPU thread and the worker thread. The methods to get and set the state are now thread safe via InterLocked API
calls.

The copying of the decoded texture to the GPU texture is still done on the main thread. Will work on moving this to the
worker thread in a future patch.

BUG=426675, 430375, 426707

Review URL: https://codereview.chromium.org/765533005

Cr-Commit-Position: refs/heads/master@{#306929}

[modify] http://crrev.com/1dd7d968e3f77ec0c90a80c944cd1ec4da8aab11/content/common/gpu/media/dxva_video_decode_accelerator.cc
[modify] http://crrev.com/1dd7d968e3f77ec0c90a80c944cd1ec4da8aab11/content/common/gpu/media/dxva_video_decode_accelerator.h

[Empty comment from Monorail migration]

@shiden86: ananta's fix only works for h264/avc videos, not vp9 which will be software decoding. We are working on improving vp9 playback.  I believe there should be some fixes coming soon on the YT side which should improve things.

Hello, this is still an issue for me on an AMD Radeon HD 5750 as of todays Google Chrome Canary:

Google Chrome   41.0.2271.0 (Official Build) canary
Revision        ff3b4402237d177cc1cc57f8e44824dc3b2bd23a-refs/heads/master@{#310751}

I still experience the same stutter on 1080p60 whilst 720p60 is a-okay. Thanks.

Where is the flag option to turn off vp9? I dont want vp9 if it burns my laptop...

Been suffering from this for a while with a AMD 6950.  Get this, one of the other people talked about Avast AV injecting something into the browser.  On a whim I uninstalled Avast, guess what?  All of the frame drops/audio glitches went away.  

TL;DR... If you happen to be running Avast AV, try uninstalling it.

[Empty comment from Monorail migration]

Here's my situation: non VP9 streams play just fine without h264ify and VP9 stutters. After I installed h264ify everything stutters.
Configuration: Radeon HD6850 & AMD FX8350.

Not fixed, too bad Google ignores bugs that someone has incorrectly marked fixed.

Everyone who's been posting recently, please note: even if you may be experiencing similar _symptoms_, they are due to a different bug. This bug is fixed.

If anyone is still having problems, please try Chrome 44 or above. It's quite a bit better. If you still have problems on 44, please find and file a new bug.

Proteus, I note that you're running Chrome 33, which predates this bug being filed, much less fixed. Please upgrade your browser.

@str...@google.com: It's still the same bug, it's just that what was determined by the engineers as the cause of this bug didn't actually fix the problem.

With my system, like the others, 1080p60 avc videos drop tons of frames but 720p60 and 1080p30 is just fine, as well as 1080p60 with vp9 videos. When I disable hardware acceleration, then 1080p60 works just fine with avc videos too, but that's a lousy way to "fix" the issue.

I've attached my GPU page here just in case you guys are willing to re-open this and I really hope you do because, well, it's just not fixed!

bug actual - 1080p60fps@avc on youtube slideshow. 1080p30fps@avc or 720p60fps@avc - normal.
chrome 48.0.2564.97, win7/64, hd6850

HW off - bad idea: bug actual ONLY to youtube.
In youtube can select 720p60fps@avc, but video blurs on FHD monitors. Not comfortable.
Good solution - add checkbox 30fps/60fps on youtube. 30fps better, than blurs.
vp9 - solution, i use, but not all video present in vp9. And new video present only avc, vp9 adding only after some hours, or next day.
So it goes.

I'm experiencing the exact same problem.

You can see my issue here:

https://bugs.chromium.org/p/chromium/issues/detail?id=644225

This issue was migrated from crbug.com/chromium/430375?no_tracker_redirect=1

[Monorail components added to Component Tags custom field.]