ubuntu-phone team mailing list archive

[Michi Henning <michi.henning@xxxxxxxxxxxxx>]

HI Simon,

> This sounds very bad and should be investigated, we can't rely on device
> detection code in every app.

It's not an app. This is for the system-wide thumbnailer. But I agree. This just has "hack" written all over it and is bad.

> CPU detection will also already fail right
> now because
> 
> - the Aquaris E4.5 (krillin) and the Aquaris E5 (vegetahd) share the
> same SoC
> 
> - devices with the same SoC use different device enablement packages
> 
> - gstreamer relies on hardware acceleration that is provided by Android
> blobs in the device enablement package
> 
> So you could easily end up with having to work around an issue on
> krillin, which is at the same time not present on vegetahd, and two
> months later you have to update all your workarounds because all phones
> got an update in the meantime.

Yes, the whole thing is brittle. What's at the core of it all is that gstreamer is hopelessly broken on Arm, and is broken (albeit less severely) on the desktop for H264 decoding. (We haven't seen issues with decoding mp3 files so far.)

What we are seeing is that gstreamer successfully pulls a thumbnail out of a file 80 times in a row and then, on the 81st run, suddenly delivers an error "negotiation failed". That's for the same physical untouched file. Other times, we are seeing it hang, crash, try to allocate 24 GB of memory, returning a black thumbnail at random, or hanging (at uninterruptible priority, so a SIGKILL followed by waitpid() hangs). The fewer cores and the less powerful a CPU we have, the worse it gets if we run more than one process that uses gstreamer at a time.

But, even with only a single process using gstreamer (system-wide), we are still seeing random failures.

> (Not to mention that you will not be able to ship all the correct
> workarounds for all devices, at the end of this year there will likely
> already be five different devices on the market.)
> 
> 
> So if you want to ship your app right now, you obviously have to add a
> workaround for krillin, but in the long term there will be no way around
> filing all those issues against ubuntu-system-image and/or gstreamer.

The simple matter of the fact is that, if we are running on the BQ, we cannot have more than one process trying to pull a thumbnail out of a video file at a time. If we do, we get tons of gstreamer failures. On the Nexus 4, we can run two processes at a time that each use gstreamer, and get away with it most of the time. If we try to run 3 or 4, we are seeing the same avalanche of failures.

So, we either come up with a reliable way to limit the number of concurrent gstreamer processes on the BQ to 1, and allowing 2 concurrent gstreamer processes on other Arm devices, or we have to pick the lowest common denominator for all Arm devices and just say "if on Arm, run only one thumbnail extractor at a time". The latter option is unpalatable because it means that we are only half as fast as we could be on the Nexus and other Arm devices. That's a heavy price to pay...

So, back to my question: is there a way that I can tell a BQ from everything else on Arm that doesn't require parsing /proc/cpuinfo? If so, I'd love to learn about it. If not, I'm afraid it'll be down to parsing the output from cpuinfo until gstreamer is fixed (if ever).

Cheers,

Michi.