[BUG] Frame drop when playing video at non-native resolutions

[harryfornasier]

I've noticed recently on Youtube that low resolution videos were dropping frames. Doing some investigation makes me think that the video acceleration on my Mac Pro isn't working at all, and it's defaulted to software.

Shown in Chrome://gpu/ is an error: [4432:21251:0615/154028.419853:ERROR:vt_video_encode_accelerator_mac.cc(1004)] : Call NotifyErrorStatus(): code=7, message=VTCompressionSessionCreate failed: Error Domain=NSOSStatusErrorDomain Code=-8973 "The operation couldn’t be completed. (OSStatus error -8973.)" (codecOpenErr)

Changing the resolution to 144p on YouTube and full screening the video is causing frame dropping. I had always had a problem with 60fps content dropping frames but never low resolution video.

I found that the last version for YouTube to not drop frames in was 1130655, and it stopped working in 1135237

Desktop

• OS: Mac OS X Mavericks
• Build 114.0.5735.133.1

Not sure if relevant but computer is Mac Pro 2013 with the D700 GPUs

[krackers]

Which codec? Mavericks only supports videotoolbox decode of h264 iirc, unlike newer ones which support vp8 as well

[krackers]

Fwiw I do see a bunch of recent changes in the aforementioned file: https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/mac/vt_video_encode_accelerator_mac.cc;bpv=1

Can you figure out which commits 1130655 and 1135237 were built from?

[Wowfunhappy]

Can you figure out which commits 1130655 and 1135237 were built from?

The github releases are:

https://github.com/blueboxd/chromium-legacy/releases/tag/1130655 https://github.com/blueboxd/chromium-legacy/releases/tag/1135237

So I believe the commits are https://github.com/blueboxd/chromium-legacy/commit/b1d52e4f29b76d65ee3b9e55bdc7a9a39a317f55 and https://github.com/blueboxd/chromium-legacy/commit/063d347336aba597d7715954e2938abac5a60717 as linked to from the releases, right?

[krackers]

I can't get dir history to load for https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/mac/;bpv=1

There was quite a bit of refactoring going on in Apr-May, so probably something in there. Although https://source.chromium.org/chromium/chromium/src/+/b60f877828cfe7e0ce5a21a605f196755714a943 was May 31 which is after the supposed breakage.

[krackers]

Also VTCompressionSessionCreate is only called for compression I think, not decoding. So I'm not sure if that error is relevant

[harryfornasier]

Which codec? Mavericks only supports videotoolbox decode of h264 iirc, unlike newer ones which support vp8 as well

Oh that’s surprising. I haven’t been able to find a h.264 video in Youtube, all of them were either VP9 or AVC1. They could not play currently even in 144p but on the older version I was able to play up to 1440p at 60fps.

[krackers]

AVC1 is h264, not to be confused with AV1 which is the much newer codec. In the same way hevc = h265

[harryfornasier]

AVC1 is h264, not to be confused with AV1 which is the much newer codec. In the same way hevc = h265

Ah I did not know that. I just checked again and the videos were actually av01 not avc1. I’m not sure if I’ve seen a AVC1. But when I tested version 1130655 it was a VP9 video that could play in 1440p at 60fps. However it does only seem to happen when in fullscreen, so maybe it’s a bug with fullscreen if mavericks can only decide h.264 and nothing more.

[krackers]

There used to be an extension h264ify for youtube which tries to force it to serve the h264 encoded video.

But either way based on what you said your conclusion seems right, this seems to not be an issue with hardware decoding but instead something to do with full-screen playback. Makes it slightly harder to pin down the culprit commit I guess....

[harryfornasier]

Odd update to this while using the latest version of Chromium-Legacy. Was watching a YouTube video in 480p and it was dropping frames. switched over to 1440p 60fps, and then it stopped dropping frames. Dropped back down to 360p and it started dropping frames. I have no clue what is happening now. Although it seems like it was VP9 at 1440p and av1 at 360p. Could this mean something?

From what I can tell av1 codec drops frames in full-frame but not in windowed mode. VP9 codec drops frames in windowed mode but not in full-frame.

[harryfornasier]

@krackers I think you were right about the codec. I went back to go test version 1130655, and it does play without dropping frames at 144p because it's always in VP9. Every version after 1130655 (at least on my machine) is switching to AV1 when not playing an HD video. I tried the h264ify extension, and it does switch to the avc1 codec, however that also causes frame drops (so maybe hardware acceleration is still not working?). Edit: Media developer tools while watching an avc1 video says it's using FFmpegVideoDecoder and Hardware decoder says false.

Considering this can play VP9 videos, I think the solution would be some sort of way to configure disabling av1 playback, so it sticks to VP9.

[krackers]

Media developer tools while watching an avc1 video says it's using FFmpegVideoDecoder and Hardware decoder says false.

That's a odd, I'd think that anything that could software decode vp9 could software decode h264 as well. You could probably use https://github.com/Shimmermare/NotYetAV1 to disable av1 and fallback to vp9.

[harryfornasier]

That's a odd, I'd think that anything that could software decode vp9 could software decode h264 as well. You could probably use https://github.com/Shimmermare/NotYetAV1 to disable av1 and fallback to vp9.

Thanks, just gave this a go, it's working perfectly - is sticking to VP9 now. When watching an AVC1 video, what is the decoder supposed to say? With VP9 it says that it's using VpxVideoDecoder.

Also on Firefox 78 4k 60fps vp9 content can play no problem, is this just because Chromium-legacy is heavier? More features, security etc...

Edit: I think it may not only be a codec problem. I think it may be to do with some full screen rendering at different resolutions. Watching a 1440p 60fps in full screen on my 1080p monitor is causing frame drops, however when I move that window to my 1440p monitor and try again it will then stop dropping frames. This also happens with a 1080p video on my 1440p monitor.

[krackers]

with some full screen rendering at different resolutions

Maybe Chromium uses a different (heaver) downscaling algorithm compared to Firefox? It's a bit hard to say, since there are probably numerous differences throughout the stack that could contribute to this...

[krackers]

When watching an AVC1 video, what is the decoder supposed to say?

Say where, in the youtube diagnostic panel? Either way, assuming that VpxVideoDecoder indicates software decoding.

Chrome should be using hardware decoding for h264 on mavericks, although youtube really doesn't serve up h264 these days unless you specifically request it. If chrome is doing hardware decoding it should say VideoToolboxVideoDecoder wherever you see VpxVideoDecoder. For software h264, it's probably FFmpegVideoDecoder.

No idea why it's using a decoder other than ffmpeg though, I guess

// Libvpx video decoder wrapper. // Note: VpxVideoDecoder accepts only YV12A VP8 content or VP9 content. This is // done to avoid usurping FFmpeg for all VP8 decoding, because the FFmpeg VP8 // decoder is faster than the libvpx VP8 decoder. // Alpha channel, if any, is sent in the DecoderBuffer's side_data() as a frame // on its own of which the Y channel is taken [1]. // [1] http://wiki.webmproject.org/alpha-channel

https://source.chromium.org/chromium/chromium/src/+/main:media/base/decoder.h;l=36-60?q=VpxVideoDecoder&ss=chromium

Btw, if you're regularly using mavericks to watch video, you should probably consider using standalone player like mpv or something which should probably better on your hardware if you do minimal post-processing.

[harryfornasier]

Say where, in the youtube diagnostic panel? Either way, assuming that VpxVideoDecoder indicates software decoding.

If you're watching a video you can go into developer tools and then there's a media panel that shows everything about what you're watching. That's where I saw that it was using VpxVideoDecoder.

Btw, if you're regularly using mavericks to watch video, you should probably consider using standalone player like mpv or something which should probably better on your hardware if you do minimal post-processing.

Thanks, I just had a go at mpv but it keeps crashing for some reason on my mac. I'll keep looking for a stable one

[krackers]

but it keeps crashing for some reason on my mac.

We can discuss more in discussions (to avoid cluttering this bug). Can you post the output? Latest build should work fine on osx just compiled directly from source (unlike what macports says, you don't need to disable cocoa).

[krackers]

Also just to close this out, once the codec is forced to vp9 is the behavior between old and new version of chromium identical, or is there still a regression with regard to full screen performance?

[harryfornasier]

We can discuss more in discussions (to avoid cluttering this bug). Can you post the output? Latest build should work fine on osx just compiled directly from source (unlike what macports says, you don't need to disable cocoa).

Ah I just used the prebuilt ones from here. https://laboratory.stolendata.net/~djinn/mpv_osx/ . Is it better to build with macports?

Also just to close this out, once the codec is forced to vp9 is the behavior between old and new version of chromium identical, or is there still a regression with regard to full screen performance?

I went back to test some more and I think it's always been like this, I just noticed it more recently because it was switching to av1. I still think there is some sort of bug with full screen, since a 1080p video can't play in a 1440p window screen. Maybe it is just because it's doing all the rendering on the CPU without any acceleration. I also went back to test if video decoding ever worked, and I don't think it ever did.

Edit: I booted into my Monterey partition today and checked the same avc1 videos on YouTube, and they still don't use hardware decoding to play, so obviously not a chromium legacy issue.

[krackers]

Ah I just used the prebuilt ones from here

Those are compiled with min os too high, so it most likely will not work. I'd recommend building from source, either via macports, via homebrew, or just manually. The thing is that macports disables the cocoa portion even when it doesn't need to, so you'd need to make a custom port file. I think it should be a relatively simple change to do that, but I don't use macports.

And they still don't use hardware decoding to play, so obviously not a chromium legacy issue.

Ok, sounds good. We can probably close this issue then and continue the mpv discussion in https://github.com/blueboxd/chromium-legacy/discussions/157

Edit: Also to be clear, I think the macports port file for mpv enables x11 instead of cocoa when building on 10.9. You'd want to undo that change. And once you do that, the compile will still fail unless you make a one-line patch to change a dot-notation property access into a message send (i.e. change a.b to [a b]). I forgot the exact patch, but you'll know it when you see it.

[harryfornasier]

To close this: There's no video acceleration video in baseline chromium, so not a chromium legacy problem.

Thoughts on why it drops frames in full screen: Probably to do with chromium-legacy not having hardware acceleration (no GPU compositing).

[Wowfunhappy]

Sorry, I haven't been following this thread closely because I've been very busy teaching a summer camp the past couple weeks. But, intuitively I still don't understand why a Mac Pro of any model is dropping frames while playing a 144p (!) video, regardless of the codec in use or whether the decoding is done in software or hardware.

Just as a comparison point, my lowly Macbook Air running a Broadwell Core i7 can decode VP9 at 4K. I use QuickTime rather than Chromium (I always download videos I want to watch), but I've hooked QuickTime up to use Google's VPX decoder under the hood. Admittedly, the fans do spin up a ton, but it works.

[harryfornasier]

Sorry, I haven't been following this thread closely because I've been very busy teaching a summer camp the past couple weeks. But, intuitively I still don't understand why a Mac Pro of any model is dropping frames while playing a 144p (!) video, regardless of the codec in use or whether the decoding is done in software or hardware.

Ahh no worries. Yes it is odd, I have a feeling it is something to do with the fullscreen rendering. Like it has to scale up that 144p video to 1440p. Or maybe it's a completely different full-screen bug. I guess it could also be to do with ffmpeg, maybe it doesn't like this Mac Pro somehow. That seems to be what it's using when trying to play a h.264 video.

Just as a comparison point, my lowly Macbook Air running a Broadwell Core i7 can decode VP9 at 4K. I use QuickTime rather than Chromium (I always download videos I want to watch), but I've hooked QuickTime up to use Google's VPX decoder under the hood. Admittedly, the fans do spin up a ton, but it works.

Hmmm so if you were to watch a vp9 YouTube video on that MacBook Air on chromium-legacy it would play smoothly? No dropped frames?

[Wowfunhappy]

Hmmm so if you were to watch a vp9 YouTube video on that MacBook Air on chromium-legacy it would play smoothly? No dropped frames?

Testing with this video on my Macbook Air: https://www.youtube.com/watch?v=Mw1MWfilz_k

While it does stutter at 4K (possibly because it's a 60 fps video), it plays smoothly at even 1440p on Chromium 114.0.5735.106.1, in fullscreen on my 2014 Macbook Air. Youtube reports the codec in use as VP09. (And the fans don't even spin up.)

Edit: Playing the video all the way through (at 1440p), Youtube reports 494 dropped frames out of 4314 total. That's actually fairly significant—11.5% of all frames were dropped—and I'm surprised I didn't notice it during playback, as I consider myself sensitive to stutter.

However, when I drop down to 720p (I didn't test any in between resolutions), Youtube reports only 3 dropped frames (>0.1%). So I'm still not seeing what you are, playback is fine for me at lower resolutions.

@krackers Are you still convinced harryfornasier isn't experiencing some sort of bug?

[harryfornasier]

Testing with this video on my Macbook Air: https://www.youtube.com/watch?v=Mw1MWfilz_k

Edit: Playing the video all the way through (at 1440p), Youtube reports 494 dropped frames out of 4314 total. That's actually fairly significant—11.5% of all frames were dropped—and I'm surprised I didn't notice it during playback, as I consider myself sensitive to stutter.

However, when I drop down to 720p (I didn't test any in between resolutions), Youtube reports only 3 dropped frames (>0.1%). So I'm still not seeing what you are, playback is fine for me at lower resolutions.

I tested that same video at 144p and it dropped 465 out of 2018 frames, so like 23%. However at 1440p at 60fps it drops none. It's a very weird bug. Also just to check was that you watching it in fullscreen? it doesn't happen in a small window.

[harryfornasier]

I went to do some more testing of an old version of chromium from Feb 2021 to test what happens with GPU compositing turned on. Surprisingly I can play an 8k youtube video with zero dropped frames. I'd love to do some more testing with a version without the CFRelease bug, i'll need to keep on trying to build chromium-legacy. It might be then that it just can't scale up video on the cpu, it's just not powerful enough or something.

[krackers]

Are you still convinced harryfornasier isn't experiencing some sort of bug?

What's been described seems consistent with there being an issue related to upscaling/downscaling. IIRC MBA doesn't have a retina display, so it's resolution is basically 900p, so it makes sense that switching to 720p resolves the issue for you since it's fairly close to native resolution. Conversely for Harry, I assume that his native display resolution is somewhere close to 1440p?

Tbh a simple bilinear interpolation shouldn't be that expensive, but I don't really know what chromium is doing under the hood. Which is why I suggested building and using mpv (I have built it fine on mavericks, I just don't know how to coax macports into doing it) since you have more control over the upscaling/downscaling algorithms there.

I also don't really know enough about chromium rendering stack to know how gpu compositing fits in with video playback. At least for mpv, rendering is always done via opengl on the gpu, it's only decoding that can optionally done in software instead. (It does seem that at least on specific platforms like osx, mpv will fall back to a system provided software renderer such as Apple Software Render if you force it, or it can't create the gl context for requested pixel format).

[krackers]

I went to do some more testing of an old version of chromium from Feb 2021 to test what happens with GPU compositing turned on

If you use that same build but disable gpu compositing, can you recreate the issue?

Something else to try: instead of full-screening the video, what happens if you make the page full screen and then pinch-zoom so the video covers all of the viewport? Do you still get framedrop/slowdown?

[harryfornasier]

What's been described seems consistent with there being an issue related to upscaling/downscaling. IIRC MBA doesn't have a retina display, so it's resolution is basically 900p, so it makes sense that switching to 720p resolves the issue for you since it's fairly close to native resolution. Conversely for Harry, I assume that his native display resolution is somewhere close to 1440p?

Yeah, I have a 1440p display and two 1200p displays. However, the problem happens on all of them when not at native resolution. Even a video like this drops frames at 1440p because of the black bars, it thinks it's 2560x1351, so I guess it has to scale.

If you use that same build but disable gpu compositing, can you recreate the issue?

So just went to test it now. Disabling hardware acceleration/gpu compositing brings back the issue.

Something else to try: instead of full-screening the video, what happens if you make the page full screen and then pinch-zoom so the video covers all of the viewport? Do you still get framedrop/slowdown?

I tested this but I don't have a trackpad so I can't exactly pinch-zoom. If I full screen the page and then cinema mode the video it does framedrop still but less than it would be in fullscreen.

[krackers]

it does framedrop still but less than it would be in fullscreen.

I've never used cinema mode, I guess it doesn't fill up as much of the viewport as full-screen would? I.e. it's technically not fullscreen that matters but the resolution of the viewport we're rendering the video into vs. the native video resolution.

Disabling hardware acceleration/gpu compositing brings back the issue.

Nice, to me that's just further evidence that this is an upscaling/downscaling related issue. Could you try some more experiments?

1) Is the issue reproducible with gpu compositing disable on the last version of chrome/chromium (v67) that officially supported mavericks?

2) If you happen to have access to a machine running an osx capable of running chrome 90+ with similar specs to yours (i.e. not an m1 machine), can the issue be recreated there?

I want to test whether the fact that video upscaling/downscaling is slow without gpu compositing is an inherent limitation of Chromium, or some recent regression.

[harryfornasier]

1. Is the issue reproducible with gpu compositing disable on the last version of chrome/chromium (v67) that officially supported mavericks?

Downloaded the last Google Chrome available. It doesn't seem to drop any frames with Hardware acceleration turned off.

2. If you happen to have access to a machine running an osx capable of running chrome 90+ with similar specs to yours (i.e. not an m1 machine), can the issue be recreated there?

On my 2019 Macbook pro it doesn't drop any frames in a low-res video with Hardware acceleration turned off.

I want to test whether the fact that video upscaling/downscaling is slow without gpu compositing is an inherent limitation of Chromium, or some recent regression.

I think it must be something to do with chromium-legacy, although I don't know if it would be recent as the version from 2021 I tested which still had gpu-compositing still had dropped frames with hardware acceleration turned off.

[krackers]

Hm. I guess that does point to this being a regression that could theoretically be solved. Issue is I don't really know where to begin looking at things.

Based on below links, I get the feeling this could be an in Skia as opposed to Chromium itself?

https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome/ https://developer.chrome.com/articles/videong/ https://sking7.github.io/articles/48074838.html

https://groups.google.com/g/skia-discuss/c/-BpxC19KOFk

[harryfornasier]

Hm. I guess that does point to this being a regression that could theoretically be solved. Issue is I don't really know where to begin looking at things.

Based on below links, I get the feeling this could be an in Skia as opposed to Chromium itself?

https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome/ https://developer.chrome.com/articles/videong/ https://sking7.github.io/articles/48074838.html

https://groups.google.com/g/skia-discuss/c/-BpxC19KOFk

In that case, is it worth reopening this?

[krackers]

Maybe it's worth reopening just to document that this is an issue, although I suspect it probably won't be resolved any time soon... I'd probably edit the title to Frame drop when playing video at non-native resolutions.

I tried skimming https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:third_party/blink/renderer/platform/graphics/video_frame_submitter.cc;l=643;drc=b73134cfcce34a13f25202d077c0aa9dc03b662e;bpv=0

https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:third_party/blink/renderer/platform/media/video_frame_compositor.cc;l=363;drc=b73134cfcce34a13f25202d077c0aa9dc03b662e;bpv=0

but nothing stood out in terms of recent changes.

[harryfornasier]

After some investigation, it appears that hardware acceleration never worked, at least for me on chromium-legacy. There is frame drop when playing videos at non-native resolution.

[Wowfunhappy]

@harryfornasier What happens if you:

1. Install this Chrome Extension: https://chrome.google.com/webstore/detail/windowed-floating-youtube/gibipneadnbflmkebnmcbgjdkngkbklb
2. Set Full Screen on Youtube to open as "Windowed"
3. Open a Youtube video, click the full screen button on Youtube, then full screen the window which opens using the Apple native full screen button?

[krackers]

Wouldnt' that be similar to this experiment

Something else to try: instead of full-screening the video, what happens if you make the page full screen and then pinch-zoom so the video covers all of the viewport? Do you still get framedrop/slowdown?

I tested this but I don't have a trackpad so I can't exactly pinch-zoom. If I full screen the page and then cinema mode the video it does framedrop still but less than it would be in fullscreen.

[Wowfunhappy]

^ Oh, yes it would!

[harryfornasier]

Just an update to this with some thoughts I had. I was wondering if any of these things could be relevant to this bug?

My Video acceleration information on Chrome://GPU shows that it should be able to decode 4096x4096 for h264 so i'm unsure why it's not being used for decoding:

It also only seems to be an issue with my 1440p monitor. I can watch 4K video on my 1200p monitor no problem, along with all other resolutions.

And also just a new log message I noticed in chrome://gpu that I thought might be related:

[krackers]

You're saying the same video works fine with 1200p monitor but not with 1440p monitor? It's probably not a decoding issue then, and unlikely to be a compositing issue since I doubt the upscale is that expensive. The CVDisplayLink issue is interesting, error code corresponds to "display is invalid" from https://learn.microsoft.com/en-us/dotnet/api/corevideo.cvreturn?view=xamarin-ios-sdk-12

Question is how are they using a displaylink here, normally video presentation based on audio-timed mode should not need to use a displaylink at all, it can rely on opengl swap blocking. I really don't want to dig through chrome code to figure out what they're doing, if you can do some research and see if they're gating frame presentation on the displaylink callbacks somehow, then it will give clues.

Also just to confirm, the display link error is only with the display that results in dropped frames right, the other display does not produce any errors?

[krackers]

I guess quickly looking based on https://source.chromium.org/chromium/chromium/src/+/main:components/viz/service/frame_sinks/external_begin_frame_source_mac.cc;drc=c177416839ec7a3fe2fe6e91a7e8e519248f96bd;bpv=0;bpt=1;l=150 they're implementing pull-based approach which would naturally make use of cvdisplaylink. And if displaylink fails to be created then they use a timer (albeit slightly more sophisticated since it tries to account for delays https://source.chromium.org/chromium/chromium/src/+/main:components/viz/common/frame_sinks/delay_based_time_source.cc;l=96;drc=c177416839ec7a3fe2fe6e91a7e8e519248f96bd;bpv=0;bpt=1

I mean if it's as simple as the displaylink fails to be created (for whatever reason) with your problematic display then yeah that's probably the culprit, a timer based approach would almost certainly lead to some dropped frames for video.

[harryfornasier]

You're saying the same video works fine with 1200p monitor but not with 1440p monitor? It's probably not a decoding issue then, and unlikely to be a compositing issue since I doubt the upscale is that expensive. The CVDisplayLink issue is interesting, error code corresponds to "display is invalid" from https://learn.microsoft.com/en-us/dotnet/api/corevideo.cvreturn?view=xamarin-ios-sdk-12

So from what I can see when playing a 4K video on one of my 1200p monitors it will drop some frames but only for a few seconds when the video starts. Once it gets playing it'll stop dropping frames. However, maybe this is a fluke it could just be that the scale on a 1200p monitor is not too hard to handle but on a 2k monitor it's too much.

Question is how are they using a displaylink here, normally video presentation based on audio-timed mode should not need to use a displaylink at all, it can rely on opengl swap blocking. I really don't want to dig through chrome code to figure out what they're doing, if you can do some research and see if they're gating frame presentation on the displaylink callbacks somehow, then it will give clues.

Also just to confirm, the display link error is only with the display that results in dropped frames right, the other display does not produce any errors?

Now that i've rebooted my computer I can't seem to see the error again. I'm gonna keep an eye out for it though as I use the computer today. But as for which display it was, i'm unsure I saw that error at the bottom of chrome://GPU and i'm not sure it specifies which monitor was causing the error.

However, another error I noticed is this in console.log, is this important?

02/11/2023 09:06:15.713 Chromium Helper (GPU)[858]: AVF encoder error: fail to create accelerator instance

Also had a play around with chromium-legacy 91.0.4435.0, the last with gpu-compositing. I noticed that with hardware acceleration on I am able to play an 8k video with no dropped frames, which is pretty impressive because when I boot into Monterey on this computer standalone chrome is unable to do that. However when disabling hardware-acceleration, the problem comes back, with frame drop at every resolution other than 1440p.

I've also noticed that chrome://gpu has some slightly different information on version 91.0.4435.0 vs current. I'll paste the whole thing but just some thoughts. Whereas in 91.0.4435.0 would read software only, those same rows now read GPU_READ... Not sure if it means anything but just thought it might be useful to look for differences.

91.0.4435.0:

Current:

Also the two GPUs used to be separated into GPU0 and GPU1 and now they seem to have been combined into just GPU0:

Chrome://GPU - 90.0.4412.0 Old Chromium - Compositing.zip

Chrome://GPU- Current about-gpu-2023-11-02T09-42-05-224Z.txt

[krackers]

1200p monitor is not too hard to handle but on a 2k monitor it's too much.

Maybe there's something in the compositing process here that's expensive. When you're playing your 4k video on a 1200p monitor the video gets downscaled then composited so it could maybe work with sw compositing but not with hw.

I noticed is this in console.log, is this important?

That seems like encoder error, probably unrelated?

the last with gpu-compositing. I noticed that with hardware acceleration on I am able to play an 8k video with no dropped frames

er I thought gpu compositing was enabled by default, @Wowfunhappy remind me again the extent to which things are gpu accelerated on recent builds?

it might be useful to look for differences. For video I think it's yuv420 layout that we care about? No idea what scanout_front_rendering is, or if it can be disabled.

I mean with enough time and patience I'm confident it should be possible to identify the root cause here. After all dropped frames happen when some part of the rendering->display pipeline takes more than 1/fps sec, so literally just adding print statements would be sufficient. The only thing is compiling chrome is a pain, and I don't know if you want to go through it either. It also seems kind of pointless to me when one could just play videos in an external video player.

[harryfornasier]

er I thought gpu compositing was enabled by default, @Wowfunhappy remind me again the extent to which things are gpu accelerated on recent builds?

I think from what I remember GPU-compositing is disabled when being built so there isn't a way to turn it back on after. I think hardware acceleration stays on for both video-decoding and video-encoding, although I haven't seen hw video-decoding work on neither my Macbook Pro 2012 or my Mac pro.

I mean with enough time and patience I'm confident it should be possible to identify the root cause here. After all dropped frames happen when some part of the rendering->display pipeline takes more than 1/fps sec, so literally just adding print statements would be sufficient. The only thing is compiling chrome is a pain, and I don't know if you want to go through it either. It also seems kind of pointless to me when one could just play videos in an external video player.

I'm so used to using youtube in the browser and watching it that way, I think that's just the way I like to use it rather than in an external player. I'm happy to try compiling chrome again, but my knowledge is pretty limited in this. I'll give it another shot today and see where i'm at.

[krackers]

random idea: can you trying adding like opacity: 0.9 !important to the video element, to try to force compositing? I know that when f.lux users had some issue with OS messing up video elements, doing this seemed to force a different compositing pathway

[harryfornasier]

I gave this a go and I think I put it in the right place, but from what I could see it made performance worse.