On Wed, 17 Jul 2024, Anton Khirnov wrote:
Quoting Cosmin Stejerean via ffmpeg-devel (2024-07-16 22:14:19)
> On Jul 16, 2024, at 8:24 PM, Rémi Denis-Courmont <r...@remlab.net> wrote:
>
> Le tiistaina 16. heinäkuuta 2024, 18.48.06 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>> To add another data point, the platform decoders might also be more secure
>> due to sandboxing. I believe as of Android Q the software decoders provided
>> by MediaCodec have been moved to run within a constrained sandbox.
>
> Platform decoders are in all likelihood strictly less secure than software
> decoders. Software decoders will run in a user-space sandboxed within their
> respective application. Platform decoders will run in a more privileged system
> service, with direct access to a kernel driver in EL1, through that to the
> firmware running on the video DSP.
>
> More performant and energy-efficient. But also way way less secure.
>
> The only viewpoint whence this is more secure, is the content publisher's:
> this model enables DRM with hardware pass-through (but that does not even
> apply if you use FFmpeg as the front end).
>
Platform provided *software* decoders should be more secure than bundled
software decoders due to the sandboxing of software decoders in recent versions
of Android.
If that is such an important feature to someone then it is not
inconceivable to implement some sort of sandboxing inside avcodec.
I'm not a big fan of the argument "we should provide passthrough to
proprietary decoders because they are more secure".
My 2 cents on this matter: I don't care much about the arguments about
more secure or less secure here - I don't see that as affecting the
decision either way.
We generally don't add wrappings of third party proprietary
encoders/decoders.
But for codecs shipped as part of the OS, I don't see an issue with us
allowing accessing those codecs. It's not like we're favouring any
specific third party, we're just facilitating access to whatever is
already there.
And especially in this case, we already have the general code for
accessing the MediaCodec API for codecs on Android - I don't have a
problem with extending this to a few more codecs, as that's not much more
than just providing mappings to the codec identifiers.
Similarly, we already allow decoding and encoding of a long range of
codecs via AudioToolbox on Apple platforms - I don't see MediaCodec on
Android as any different than that.
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
