Crash when playing mp4 on ARM on Chromium

[wjvds]

When I use this layer to install Chromium (both on X11 and Wayland in all currently available versions) on my ARMv7 (Rockchip RK3288) board and compile with the proprietary-codecs PACKAGECONFIG, I get an error while playing video (or audio) in an mp4 container. The browser simply says "Oh snap! Something went wrong", and with gdb I can trace the error back to a call to ffmpeg. However, I am having a hard time finding out what goes wrong inside ffmpeg as I am not familiar with its internals and chromium seems to compile it in a strange way.

[otavio]

@wjvds which OE-Core branch did you use for the build?

[wjvds]

@otavio The Pyro branch.

[kraj]

Can you check if its using internal version of ffmpeg or system version

[wjvds]

It is using the internal version.

[Caesar-github]

Interesting, do we have supported the video hard-coding on chromium-x11?

hmmm..I saw the the ffmpeg supported the rockchip SoCs on upstream. /src$ vi third_party/ffmpeg/libavcodec/rkmppdec.c @wjvds How to enable it? I'm running the ycoto to build it. (Just enable the rkmpp for ffmpeg building)

wait...build it for now. ... ...Currently 4 running tasks (4631 of 5610) 82% |############################################################################# | 0: chromium-x11-64.0.3282.119-r0 do_compile (pid 17408) 13% |##########

[wjvds]

@Caesar-github In the longer term, I want to get the rkmppdec working as well, but just building ffmpeg with rkmppdec is not nearly enough to get chromium to use it. Chromium does not understand ffmpeg's DRM buffer wrapping, so an additional hwaccel will have to be implemented in media/gpu (based on this code and the code in media/filters/ffmpeg_video_decoder.cc probably). This will also only work with the Ozone backend considering Chromium only supports rendering DRM buffers with Ozone.

The problem in this issue, however, is completely seperate. This problem arises when you compile chromium without any modifications. (Or at least, when I do it...It would really help me if you could verify this issue.)

[rakuco]

Is this a regression or has this never worked before for you? I've tried a qemux86-64 image here with proprietary codecs and everything worked fine (with the Rocko branch).

[wjvds]

@rakuco I remember this did work back when I tried it with chromium 60 and it did not work with chromium 61 (both back when it was still hosted in the meta-crosswalk repo). It may have gotten broken due to other changes in my environment (i.e. other layers) around that time, although I do not recall any of those being significant. Then I did not check again until just before I posted this issue.

[rakuco]

Hmm, is there a more common MACHINE that also exhibits this behavior? Ideally I'd set it to something like "qemuarm" to try to reproduce it here, for example. For now, I'm launching a qemuaarch64 build here with rocko since I already have it at hand.

[rakuco]

I can't get my qemuarm64 image to launch X11 for some reason. @msisov does this sound familiar to you?

[msisov]

@rakuco not really. We had problems on R-car m3 board, which were about not played mp4 files, but it was because of proprietary codecs were not used

[wjvds]

I have done some more attempts to discover the cause of this issue. First of all, I upgraded Yocto to the Rocko branch. This did not change anything. Enabling the use of the system version of ffmpeg did not change anything either.

I have tried building an image using qemu but Chromium requires a more modern ARM CPU than the one specified in the qemuarm MACHINE and that causes a compilation error. Changing this CPU to something resembling the RK3288 (by manually constructing such a machine configuration file) causes a kernel panic during boot. Is there an easier or better way to select the type of ARM CPU to use?

[rakuco]

That's something I've also struggled with. I can get qemuarm64 builds to work, but the stock qemuarm configuration isn't supported by Chromium as you've noticed. You could try choosing a machine configuration with an ARMv7 CPU as a starting point, but I think this is the furthest I can help with this.

[wjvds]

I have managed to reproduce the problem on a Raspberry Pi 3 (using the standard meta-raspberrypi BSP image and adding X11 support and the chromium-x11 package). This is an ARMv8 CPU but it runs in 32-bit mode and is otherwise very similar to the ARMv7 CPU from the RK3288. Raspbian comes with Chromium version 60, which worked just as well as it did for me earlier. I do not think there is a packaged version of a newer Chromium version available on Raspbian.

Whilst digging into Chromium's bug tracker I found that from version 65,0.3325.xx (I believe this is the first beta for version 65?), this commit is included which revamps the support for proprietary codecs entirely. MP4 support will be compiled in unconditionally, and only codecs such as H264 will be optional. This may affect the behaviour and I will try building this version as well to see if anything changes.

[rakuco]

Thank you for investigating this. Did you manage to build M65 and check if that commit works for you?

[wjvds]

Sadly, I got stuck on a compilation error related to some templated function in the "base" namespace, and debugging template functions in C++ is not fun so I have not continued working on that yet.

[msisov]

You can paste it here. It might be that some of us have already faced that issue and resolved it

[otavio]

@wjvds any news in testing the most recent release?

[wjvds]

Due to other obligations I have not have had any time to work on this project for the past few months. I am not sure when I can continue working on this.

[otavio]

No activity since June 16th. Closing it.