lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Sat, 9 Nov 2019 13:56:57 +0100
From:   Paul Kocialkowski <>
To:     Stefan Monnier <>
Subject: Re: [linux-sunxi] Re: [PATCH 1/3] media: cedrus: Properly signal
 size in mode register

Hi Stefan,

On Thu 07 Nov 19, 09:24, Stefan Monnier wrote:
> > Do you know if we have a way to report some estimation of the maximum supported
> > fps to userspace? It would be useful to let userspace decide whether it's a
> > better fit than software decoding.
> Even if the fps ends up too low for the player's taste, I can't imagine
> why software decoding would be preferable: it seems it could be only
> even (substantially) slower.  Or are there speed-up options in software
> decoding not available in hardware decoding (such as playing only every
> N'th frame, maybe?).

This may be true for the Allwinner case as we know it today but not true in
general. It could happen that the CPU is perfectly able to decode as fast as or
faster than the hardware implementation, but userspace would still try to use
hardware video decoding when it can provide good enough performance so that the
CPU can do other things in the meantime.

Having a good idea of the expected performance is important for userspace to
make this kind of policy decision.

This is kind of a common misconception that hardware offloading always implies
a performance improvment. In our cases where the CPU is a bottleneck, it is
more often true than not, but this is by far not true in general.



Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists