On Wed, Jun 24, 2015 at 1:32 PM, Michi Henning <[email protected]> wrote:
> 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. > Doing hardware decoding requires some time to set-up and clean-up HW resources and we are limited there by the vendor's implementation. In my opinion software decoding would be faster if we just need a thumbnail, and it was what Android was doing last time I looked into this. However, we have not enabled that code path yet. > > 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 <[email protected]> > 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 : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
