Stuttering playback of 4k and 8K h264 videos
Categories
(Core :: Audio/Video: Playback, defect, P2)
Tracking
()
People
(Reporter: dmitriy-muraviov, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
HW-accelerated playback of 4K and 8K videos is inferior to Chrome, it stutters.
Example 1: 8K 60 fps YouTube video
https://youtu.be/1La4QzGeaaQ?t=101
It stutters moderately on Firefox (Developer 71.0b12) (no dropped frames indicated in "Stats for nerds" though), but on Chrome it plays absolutely smoothly. Especially easily visible on jittery movement of the backround at 1:48. This is a problem with any 8K video (24-60 fps) and less visibly with any 4K 60 fps video on YouTube (4K 30 fps is fine).
Example 2: 4K xHamster video (NSFW!)
https://ru.xhamster.desi/videos/candid-collage-pawg-green-bikini-12870177
It plays smoothly on Firefox ESR 68.2.0 and on Chrome, but it stutters on Firefox Developer 71.0b12. Ignore a frame freeze baked in video at 0:26. This is a problem with any 4K video on xHamster.
I should note that I have a weak CPU - i5-760 (first gen. i5, Lynnfield), but GPU is GTX 1050 Ti, and with its HW acceleration every video plays perfectly smoothly on Chrome, old and new Edge and PotPlayer.
(Windows 10 1909 x64, newest nVidia drivers, 4K monitor, no enabled extensions)
|
||
Comment 1•4 years ago
|
||
bryce, can you help me triage this? Is this a known issue?
Testing on my machine I see drops for both Firefox and Chrome, but it's more pronounced on Firefox.
For example 1 I see a lot of dropped frames reported in "stats for nerds". This is different from comment 0, so it's not clear if I'm seeing the same performance bottleneck. I'm going to leave this unconfirmed for now as it's not clear to me if this is the issue the reporter is seeing or not.
For example 2 I see similar frame dropping. Note that xhamster will sometimes show a 4k icon on auto when it still has non-4k video buffered.
Dmitriy, you mentioned that the second video doesn't stutter as much on ESR 68.2.0. Is this only for the second video, or also for the first video? If you're seeing better performance on an older version of Firefox could you try using mozregression-gui (there's a video showing usage here) to locate where the regression takes place? Can you also confirm that you're not seeing any dropped frames reported in the YouTube statistics?
I specifically switch to 4K option on xHamster before every test, and the closest other resolution on xHamster is 720p, which is of much lower quality visually, so I would have noticed if it was not 4K.
Yes, the second video does not stutter at all on ESR 68.2.0, but it stutters on Firefox Developer 71.0b12. Not all sites with 4K videos have this problem, for example on (NSFW!) https://www.porntrex.com/categories/4k-porn/ there are no problems in any browsers of any versions.
I found the commit that caused this stuttering on xHamster using mozregression-gui (screenshot https://imgur.com/a/bp07D9U ) – bug https://bugzilla.mozilla.org/show_bug.cgi?id=1539182 commit https://hg.mozilla.org/integration/autoland/rev/b51b4dcd9a8acdbd1474c6312a6ef07c54ed6531
It is difficult to find YouTube 8K 60 fps video that can be switched to 8K on ESR 68.2.0 because bug https://bugzilla.mozilla.org/show_bug.cgi?id=1580695 is fixed only in newest versions, and on ESR 68.2.0 it causes maximum resolution to be 4K 60 fps HDR (which is a mistake because my monitor is non-HDR). Because of that, I do not know how ESR 68.2.0 would play 8K YouTube video. I confirm that there are 0 dropped frames in “stats for nerds” on Firefox Developer 72.0b1.
Bryce, maybe you see dropped frames in “stats for nerds” because your GPU is not NVidia GTX 1xxx or 2xxx? As far as I know, only NVidia GPUs can HW-decode 8K VP9, and only on Windows 10.
To demonstrate exactly how all of these problems look, I recorded my monitor with iPhone’s high-speed camera in 1080p 120 fps. You can use MPC BE and execute menu command “Play-> Decrease Rate” or press Ctrl+Down to slow recording down to 0,5x speed to see stuttering more clearly:
Example 1: https://yadi.sk/i/Nt9Z2816wOuFlA
(jittery movement of backround trees at 1:48 is showing the problem, I rewound to a slightly earlier moment to give time for initial jitter to run out)
Chrome – perfect playback
Firefox Developer – stuttering (not very obvious (especially in my recording because it’s not very sharp), seems quite slight, but it becomes annoying after prolonged watching, feeling of smoothness of motion is gone)
Firefox ESR – impossible to test because 4K HDR is maximum selectable resolution
Example 2: https://yadi.sk/i/KqVi_2iAtrKHLw
Chrome – perfect playback
Firefox Developer – very noticeable periodic freezes
Firefox ESR – perfect playback
Thanks for that follow up and the videos showing the issues. I have a relatively poor performance quadro card in the machine I used to test, which should decode VP9 in hardware, but with a lot less throughput than a 1050 -- which would explain the difference I see.
I wonder if we're seeing a couple of different issues here. The bug that's causing the regression with the xHamster video shouldn't affect VP9 videos. Since we have a fairly good idea of what's causing the problem there I think it would be worthwhile to look at that first and treat it as an isolated issue, and follow up on the other cases.
Alastor, do you have an idea on why we'd see the regression from bug 1539182 for the (NSFW) example 2 video?
Just a small correction:
If I'm not mistaken, regression in example 2 video is from fix to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1539182
Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1580695 only prevents me from testing 8K YouTube on ESR (but if you want, you can tell me which version older than 68 didn't have problem with being limited to 4K, so I would test on it and find out whether these are different issues)
Thanks for the correction. I've fixed the references.
My ESR has just autoupdated to ESR 68.3.0, and the bug that prevented me from setting 8K in YouTube got fixed on it, so I was able to test YouTube.
On ESR 68.3.0:
Example 1 (8K 60 fps YouTube) is actually much worse, much more jittery than in Developer 72.0b1.
Example 2 (4K xHamster) is playing smoothly.
So, only one of 2 issues is present, which means they are indeed two separate issues.
Thanks for confirming that. My suspicion is that the YouTube issue could be related to our compositing to the screen, rather than the decoding pipeline (which would explain why you don't see any dropped frames in the stats). It would be useful to create a separate bug to track that issue.
Should I create it now, or you’d like to wait for your colleague’s opinion?
Creating it now sounds reasonable, that way we can better track the investigations into the (likely) separate issues.
|
Reporter | |
Comment 11•4 years ago
|
||
OK, I’ll do that tomorrow, thank you.
|
|
Reporter | |
Comment 12•4 years ago
|
||
I created a separate bug for YouTube 8K issue https://bugzilla.mozilla.org/show_bug.cgi?id=1601297
|
||
Comment 13•4 years ago
|
||
I've reverted the change from bug1539182, but I can still see the issue on xHamster's video, so I think there must be other culprit.
In addition, I found that there is no any key frame between 26s to 28s where the video freezes, maybe they hide the keyframe under some special unit which we didn't handle. Like bug1539182, IMDB didn't put the key frame on the right unit, which make us to check other additional unit type.
(In reply to Alastor Wu [:alwu] from comment #13)
I've reverted the change from bug1539182, but I can still see the issue on xHamster's video, so I think there must be other culprit.
In addition, I found that there is no any key frame between 26s to 28s where the video freezes, maybe they hide the keyframe under some special unit which we didn't handle. Like bug1539182, IMDB didn't put the key frame on the right unit, which make us to check other additional unit type.
The reporter mentioned expecting the freeze at 26s, so it's possible that one is intentional (it appears in other browsers too). I think the issue they're seeing is smaller stutters outside of the large freeze at 26s.
|
|
Reporter | |
Comment 15•4 years ago
|
||
Yes, it’s the other stutters, they can be seen on recording of my screen, posted in Comment 3, only in Firefox Developer. They are absent on ESR.
|
|
||
Comment 16•4 years ago
|
||
oh, sorry I misread the comment, add NI as a reminder to check this again.
Bug 1601297 has been created to track the high resolution issues per example 1. This bug will track the issues specific to example 2 which appear to be a regression.
|
||
Updated•4 years ago
|
|
||
Comment 18•4 years ago
|
||
Is there anything for us to fix here, considering we've spun up new bugs to handle the problems?
(In reply to Paul Adenot (:padenot) (back 6th january 2020) from comment #18)
Is there anything for us to fix here, considering we've spun up new bugs to handle the problems?
My understanding is that this bug is tracking the stuttering we see in the h264 case which appears as a regression of bug 1539182. This is seen in the 2nd example from comment 0. I've updated the title to reflect this.
For the VPx case we've spun off bug 1601297, since that issue appears independent. This is the case seen when viewing example 1 in comment 0.
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
|
||
Updated•11 months ago
|
Description
•