@Reporter:
Thanks for filing the issue.

@dalecurtis:
Could you please confirm whether the issue:  811736  is similar to issue: 801245

Thanks!

I reverted to 63.0.3239.132 and tried 720p@60fps video at youtube.

Still obvious frame drop.

So may not be a regression in chromium, but maybe some other parts.
Any hint about such problem? (Maybe a problem of the window manager?)

The CPU is Ryzen 1700 OC @ 3.8G so performance should not be problem at all.
GPU is Gefore 1060, with closed source driver.

Thank you for providing more feedback. Adding requester "viswa.karala@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

And strangely, when frame dropps unacceptably, the video codecs is avc1.4d4020(298).
While firefox is using 302 codecs.

And I just tried again this time, even in 1080P 60fps, the frame drop is way below 1% and completely acceptable.

Pretty strange here.

Hmm, that's strange, so you're saying YouTube vp9 videos play smoothly, but h264 videos do not?

Not sure about vp9, but at least when video codec is 302/303, chromium is playing video without problem (Although still small drops, but below 1%)

But when codec is 298, it's dropping frames even for 720p videos.

Tested the issue on chrome reported version 64.0.3282.140 using Ubuntu 14.04 with steps mentioned below:
1) Launched chrome reported version, opened youtube and played 720p video
2) Right clicked on video and clicked on "Stats for neds" and observed value of "Dropped Frames"
3) After playing the video for around 5min, observed the Dropped frame value of ~9/7027
Observations: Tested this issue on 60.0.3072.0, observed the Dropped Frames value of ~6/6741 for playiong the video around 5min

@Reporter:
Please find the attached screenshot for your reference and let us know your inpus on it which helps us in further triaging it.

@dalecurtis:
Could you please confirm whether the issue:  811736  is similar to issue: 801245

Thanks!

Deleted: 811736.mp4 8.8 MB

	811736.mp4 8.8 MB View Download

I tested with 720P 60fps, with latest chromium as it doesn't look like a regression.

The drop is about 1.5%, even using codecds 302/mp4a.40.2(140).
It's more or less acceptable. And I believe it's Firefox which doesn't report the dropped frames correctly.

And BTW, subtitles seems to make the drops more obvious.

And for issue 801245, unfortunately I don't have a windows on my physical machine, so unable to confirm that.

What I could try is to use other window manager/DE on Linux.

Deleted: Screenshot from 2018-02-16 17-12-55.png 32.8 KB

	Screenshot from 2018-02-16 17-12-55.png 32.8 KB View Download

Thank you for providing more feedback. Adding requester "viswa.karala@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@dalecurtis:
Could you please confirm whether the issue:  811736  is similar to issue: 801245

Do you have dual monitors?

@viswa: I don't have enough info to say if this is the same issue yet. It's not even clear what issue 801245 is either.

Yes, I'm using dual monitors.

Two 1920x1080@60Hz.

For monitor layout and conf:

Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 32767 x 32767
DVI-D-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 509mm x 286mm
   1920x1080     60.00*+
   1680x1050     59.95  
   1440x900      59.89  
   1280x1024     75.02    60.02  
   1280x960      60.00  
   1280x720      60.00  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   800x600       75.00    72.19    60.32    56.25  
   640x480       75.00    72.81    59.94  
HDMI-0 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080     60.00*+  59.94    50.00    60.00    50.04  
   1680x1050     59.95  
   1440x900      74.98    59.89  
   1280x1024     75.02    60.02  
   1280x720      60.00    59.94    50.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       59.94  
   640x480       75.00    72.81    59.94    59.93  
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DVI-D-1 disconnected (normal left inverted right x axis y axis)

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

You might try seeing if a single monitor makes it better. Root cause is probably inconsistent vsync. I've seen similar issues with all apps on my dual monitor workstation too. Seems to be a classic Linux thing :/

Not sure why it might be exacerbated by codec, so maybe something else though. Unless timestamps are better on the vp9 variant.

Single monitor setup seems to improve it a little.

But still drops. About 0.5%~1%.

So I'm not 100% sure about if it's related to dual monitor setup.
But using single monitor sacrifices a lot of productivity, it doesn't really sounds to be a reasonable solution. 

Unable to reproduce the issue on chrome reported version 64.0.3282.140 using Ubuntu 14.10, tested the issue on dual monitor setup using Windows-10 as dual monitor setup for Linux system is not available at ET team, observed the dropped frames of ~7/6942, as it is not reproducible from ET end, hence removing Needs-Bisect label.
Could anyone from the Internals > Media team have a look at this issue.

Thanks!

Extra info about this problem.

For 60fps high bitrate videos, the CPU usage of one single chromium progress could easyily go beyond 90%. (using top)

And under certain case, it could even go a little beyond 100%. (not sure how this is possible)

At least this means that, chromium (even for firefox) uses way too much CPU to decode 720P video.

For mpv video playback, it only takes less 30% CPU for similar video. (using -vo xv --hwdec=no).


There are too many other factors here.
Factors like CPU (Ryzen has lower IPC compared to Intel, but not that obvious), CPU governor, and video driever (Nvidia proprietary driver) could make it harder to reproduce.
But when I got extra systems, I could add extra info about this.

Yeah, I wasn't suggesting single monitor as a solution, just a test to see if it did improve things.

60fps high bit rate vp9 should be the videos you said are not dropping frames. While the mpv ones are h264 and the ones dropping frames. Can you confirm that's what you're implying?

If that's the case it could be scheduling throttling the cpu too much when cpu usage is low.

How to check the video format?
By video codecs?

But I can only see numeric codec name like 298/302, without knowing the format.


And I also tried Chrome on Windows, with much lower hardware spec. (Intel 8250U)
Although Chome on Windows supports hardware decode, it can still sometimes drops frames (less than 0.5% though).

And when frame drops, I also observed CPU usage spike on one CPU core, while normally the CPU usage is much lower than Linux for CPU core/thread.

dalecurtis@ request you to provide an update on this issue and reply to comment #21.

Thanks..

Sorry I forgot to reply. "stats for nerds" for me always says the video codec:

"vp09.00.51.08.01.01.01.01 (247) / opus (251)" or "avc1.4d401f (136) / mp4a.40.2 (140)"

is what I see on YouTube. 302 is VP9 60fps material though, 298 is H264 60fps. So if you're saying you see more frame drops with 298 that's surprising.

Can you try using some sort of cpu load tester to impose a load and then try the h264 format video to help rule out throttling?

I am working on some improvements to software decoded video that I hope to have out by next week or so which might help here too.

Only found several vp9/opus video.

And it looks good now.
Dropped frames 191/13270.

No handy CPU stresser here, so I just compile kernel at background using "make -j 8". (The CPU has 16 threads)
No obvious difference I would say, until the final linking part (which is single threaded), where frame drops happens for a short period.

Despite that I found that most drops happens at the very beginning of the video, although there would be 1 or 2 drops during playing, it's much less than the starting dropping.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I can confirm the bug with newest version of Chrome and Chromium on Debian with Nouveau and Nvidia drivers. Frame Drops and audio drops occur on YouTube when the menu bar is visible and they occur more intensely when its used. The used codec is completely irrelevant, I tested different ones and quality settings and the problem still occurs even at 144p. Firefox works flawless and the previous Chrome version worked flawless, too.

as per c#24, the dropped frame number is relatively low(191/13270, ~1%) and mostly happen in the begining of a playback. I think this is a won't fix since it doesn't really affect the playback quality

This should be much better on the latest M67 dev channel. Let me know if you still see issues. The work was done under 801245 which is needlessly private; but I can't clear the label for some reason.

It got better, but not perfect but with disabled hardware acceleration on a strong CPU I get no frame drops whatsoever. Google Maps is also much smoother now, could be a problem with canvas or something like that also the drops occurred much heavier when the menu or the bar were visible and very extreme when they were used.