chromium-browser attempt to play youtube video leads to error and freeze with infinite progress icon

[qrp73]

Steps to reproduce: 1) Open chromium-browser 2) Open link https://www.youtube.com/watch?v=Qjjf4dTO1Qo

Expected result: video is played

Actual result: video playback freezes and error appears in the log:

[ 9682.038036] bcm2835-codec bcm2835-codec: vidioc_s_fmt: Current buffer size of 314880 < min buf size 322560 - driver mismatch to MMAL

Firefox with disabled hw acceleration playing this video with no issue. With enabled hw acceleration Firefox also playing it ok. I tried to disable all extensions in chromium-browser, but it didn't helped.

PS: I also catch some strange freeze in chromium-browser during video playback which leads to complete UI freeze of chromium-browser, app restart didn't helped and unable to kill chromium-browser process with timeout during attempt to reboot. But I'm not sure it was related with this issue, because it was happened on some other video, I didn't notice which one cause it.

[ghollingworth]

Can you confirm hardware and software configuration here?

I'm unsure whether the reference to MMAL is just a mistake in the driver or whether this is actually using the MMAL driver (in which case this is not supported in Bookworm)

[6by9]

I'm unsure whether the reference to MMAL is just a mistake in the driver or whether this is actually using the MMAL driver (in which case this is not supported in Bookworm)

The V4L2 codec driver is sitting on top of MMAL in the firmware. The kernel has computed what it believes is the correct buffer size, but when it is passed to the firmware it got back a different number. The question is why kernel and firmware have a mismatch, and that is likely to be down to exact stream geometry. I'm downloading it now to analyse.

[qrp73]

hardware is RPI4 4GB v1.5

$ cat /etc/rpi-issue
Raspberry Pi reference 2023-09-22
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 40f37458ae7cadea1aec913ae10b5e7008ebce0a, stage4

$ vcgencmd version
Apr 17 2024 17:27:09 
Copyright (c) 2012 Broadcom
version 86ccc427f35fdc604edc511881cdf579df945fb4 (clean) (release) (start)

$ uname -a
Linux raspi 6.6.28+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.28-1+rpt1 (2024-04-22) aarch64 GNU/Linux

$ sudo rpi-eeprom-update
*** UPDATE AVAILABLE ***
BOOTLOADER: update available
   CURRENT: Mon 15 Apr 13:12:14 UTC 2024 (1713186734)
    LATEST: Wed 17 Apr 12:51:36 UTC 2024 (1713358296)
   RELEASE: latest (/lib/firmware/raspberrypi/bootloader-2711/latest)
            Use raspi-config to change the release.

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138c0
    LATEST: 000138c0

This issue is stable reproduced.

[6by9]

360x290 or 328x240 would appear to be the potential answers.

Adding alignment means we're most likely looking at 328x240, aligned to 352x240 and RGBA giving 314880 bytes. I suspect the firmware is looking for 64 byte alignment, so https://github.com/raspberrypi/linux/blob/rpi-6.6.y/drivers/staging/vc04_services/bcm2835-codec/bcm2835-v4l2-codec.c#L266 is incorrect declaring 32 (also line 259).

[6by9]

There's something different in your configuration than mine.

Asking my Pi4 running Wayfire to play that URL in Chromium, and it works fine. It also asks the decoder for YUV420, not RGBA, so my buffer sizes end up as 126720 bytes for the 328x240 stream.

@jc-kynesim is there some magic for how Chromium chooses the pixel format?

[qrp73]

I still can reproduce it, here is Stats for nerds:

I also found that when I switch video quality it leads to different buffer size in error:

for 240p:

[26130.084047] bcm2835-codec bcm2835-codec: vidioc_s_fmt: Current buffer size of 314880 < min buf size 322560 - driver mismatch to MMAL

for 144p:

[26156.030180] bcm2835-codec bcm2835-codec: vidioc_s_fmt: Current buffer size of 115200 < min buf size 119808 - driver mismatch to MMAL

If it matters, I'm using display with resolution 1280x1024@75025. Also I have enabled some plugins in wayfire.ini:

[core]
plugins = alpha animate autostart autostart-static command cube pixdecor expo fast-switcher fisheye grid idle invert move oswitch place resize switcher vswitch window-rules wm-actions wobbly wrot zoom winshadows

[jc-kynesim]

I can reproduce the fail. The h/w accel path we use in chrome changed in v124 as the old (functional, efficient) video decode accelerator (VDA) path went away and was replaced by the direct(?) decoder. The latter will typically end up asking for RGBX from V4L2. When it works it works well, but it looks like I need some init patches similar to what I had to do in VDA. Not sure (yet) what is different here to working video. Will fix.

[6by9]

@jc-kynesim if you can reproduce then as per my earlier comment I think it's just that https://github.com/raspberrypi/linux/blob/rpi-6.6.y/drivers/staging/vc04_services/bcm2835-codec/bcm2835-v4l2-codec.c#L266 and https://github.com/raspberrypi/linux/blob/rpi-6.6.y/drivers/staging/vc04_services/bcm2835-codec/bcm2835-v4l2-codec.c#L259 should be reading 64 across the board. I hadn't managed to reproduce, hence wasn't going to totally guess on it.

[jc-kynesim]

OK - I'll try that and report back

[jc-kynesim]

That might be necessary but it isn't sufficient - I think the issue is that chrome(?) ends up doing a S_FMT based on crop size rather than picture size. Still investigating.

[jc-kynesim]

Scratch that - I'm an idiot - I wasn't running the kernel I thought I was running. Fix works fine - do you want to PR it or should I?

[6by9]

Done - https://github.com/raspberrypi/linux/pull/6162

[qrp73]

Done - raspberrypi/linux#6162

just tried to install this pull request with sudo rpi-update pulls/6162 it fixes the issue. Thanks

When it will be available with apt upgrade?

[qrp73]

it looks like it also helps to fix some issues with video playback on other video hosting like telegram

[6by9]

When it will be available with apt upgrade?

It's now merged into our main kernel branch, so sudo rpi-update will get it from now on without having to specify the PR. Apt updates are done every few months, or as and when anything really useful is merged into the kernel/firmware. I couldn't say when the next one will be.

[qrp73]

I'm not sure if it was fixed in pull/6162 or it just include some other fixes, but when I installed this pulls/6162 I notice very significant improvement in video playback in browsers (both - firefox and chromium-browser). Now it plays much more smooth than before. Thanks a lot. :)

Also I notice that web browsing now is also more smooth.

[jc-kynesim]

Honestly I think it must be something else, that fix would affect a minority of videos - croppped_width & height are going to a multiple of 16 in most cases (which will work fine both before & after the patch) and that is the only thing that fix will change. Subjectively I thought chrome v124 was smoother than v122 but I could easily have been kidding myself. If there are useful fixes they are in Wayland.