ubuntu-phone team mailing list archive

[Alfonso Sanchez-Beato <alfonso.sanchez-beato@xxxxxxxxxxxxx>]

On Wed, Jun 24, 2015 at 1:32 PM, Michi Henning <michi.henning@xxxxxxxxxxxxx>
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 <michi.henning@xxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>