I forgot to mention. When gstreamer does not fail, it takes 3-4 seconds to pull a single frame out of a 5-second video. That's on a Nexus 4.
It would be almost (but not quite) as fast to just play the video and take a screenshot while the video is running... Michi. On 24 Jun 2015, at 21:29 , Michi Henning <michi.henn...@canonical.com> wrote: > 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. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
