From: "Martin Storsjö" <martin@martin.st>
To: FFmpeg development discussions and patches
<ffmpeg-devel@ffmpeg.org>,
FFmpeg development discussions and patches
<ffmpeg-devel@ffmpeg.org>, Cosmin Stejerean <cosmin@cosmin.at>
Subject: Re: [FFmpeg-devel] Add Mediacodec audio decoders support
Date: Fri, 19 Jul 2024 22:59:50 +0300 (EEST)
Message-ID: <6d1ee9a6-ea8e-486d-fa1a-9aa789c8bdc@martin.st> (raw)
In-Reply-To: <172120911304.21847.16652588338657358575@lain.khirnov.net>
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 <remi@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-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2024-07-19 20:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-12 13:42 Matthieu Bouron
2024-06-12 13:42 ` [FFmpeg-devel] [PATCH 1/2] avcodec/mediacodecdec_common: ensure input buffer timestamp is positive Matthieu Bouron
2024-06-12 13:42 ` [FFmpeg-devel] [PATCH 2/2] avcodec: add Mediacodec audio decoders support Matthieu Bouron
2024-07-10 8:47 ` Matthieu Bouron
2024-07-28 15:23 ` Zhao Zhili
2024-06-12 14:00 ` [FFmpeg-devel] Add " Paul B Mahol
2024-07-10 13:54 ` Zhao Zhili
2024-07-10 16:31 ` Matthieu Bouron
2024-07-16 13:20 ` Matthieu Bouron
2024-07-16 14:58 ` Zhao Zhili
[not found] ` <2009DBEE-686A-42F6-A5DF-35147272EEF0@cosmin.at>
2024-07-16 15:48 ` Cosmin Stejerean via ffmpeg-devel
2024-07-16 16:04 ` Zhao Zhili
[not found] ` <057FD6DF-E71C-49D0-8D11-7A7E4D5FB5CC@cosmin.at>
2024-07-16 16:42 ` Cosmin Stejerean via ffmpeg-devel
2024-07-16 18:24 ` Rémi Denis-Courmont
[not found] ` <205EB89E-F6F9-438D-A9BC-E76E5439C7C7@cosmin.at>
2024-07-16 20:14 ` Cosmin Stejerean via ffmpeg-devel
2024-07-17 9:38 ` Anton Khirnov
2024-07-17 12:19 ` Michael Niedermayer
2024-07-19 19:59 ` Martin Storsjö [this message]
2024-07-17 15:39 ` Paul B Mahol
[not found] ` <4F1B9768-96C8-4708-92ED-AC8E1C9FC46F@cosmin.at>
2024-07-17 17:35 ` Cosmin Stejerean via ffmpeg-devel
2024-07-23 11:35 ` Martin Storsjö
2024-07-23 11:44 ` Zhao Zhili
2024-07-23 13:43 ` Anton Khirnov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6d1ee9a6-ea8e-486d-fa1a-9aa789c8bdc@martin.st \
--to=martin@martin.st \
--cc=cosmin@cosmin.at \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git