[FFmpeg-devel] [PATCH] avformat/utils: Don't parse encrypted packets.
modmaker at google.com
Tue Sep 11 21:41:57 EEST 2018
On Thu, Aug 30, 2018 at 8:43 AM Jacob Trimble <modmaker at google.com> wrote:
> On Wed, Aug 29, 2018 at 4:37 PM Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> > On Wed, Aug 29, 2018 at 03:30:39PM -0700, Jacob Trimble wrote:
> > > On Wed, Aug 29, 2018 at 3:20 PM James Almer <jamrial at gmail.com> wrote:
> > > >
> > > > On 8/29/2018 7:07 PM, Michael Niedermayer wrote:
> > > > > On Tue, Aug 28, 2018 at 10:58:43AM -0700, Jacob Trimble wrote:
> > > > >> If a packet is full-sample encrypted, then packet data can't be parsed
> > > > >> without decrypting it. So this skips the packet parsing for those
> > > > >> packets. If the packet has sub-sample encryption, it is assumed that
> > > > >> the headers are in the clear and the parser will only need that info.
> > > > >>
> > > > >> Signed-off-by: Jacob Trimble <modmaker at google.com>
> > > > >> ---
> > > > >> libavformat/utils.c | 21 ++++++++++++++++++++-
> > > > >> 1 file changed, 20 insertions(+), 1 deletion(-)
> > > > >
> > > > > Hmm, please correct me if iam wrong but IIUC
> > > > > 1. The demuxer has set need_parsing, indicating that it _requires_ a parser
> > >
> > > There isn't a flag for "try parsing and ignore errors". So my choice
> > > (from an app) is to either require parsing or don't do parsing at all
> > > (which can result in incorrect timestamps).
> > >
> > > > > 2. Parsing cannot be done before decrypting
> > > > >
> > > > > If all this and the set values are correct, logically, the fix would be
> > > > > to decrypt the packet before the parser not to skip the parser.
> > >
> > > There are cases where the packet can't be decrypted before getting to
> > > this point.
> > Can you elaborate on these cases ? I dont think its obvious what these
> > cases are, at least its not obvious to me what exactly you are thinking
> > of here. And i think its not helpfull if i guess what you mean and then
> > argue/comment on that because maybe you meant something entirely different ...
> Fair warning, I am working on a DRM solution. I know many of you may
> not agree with DRM, but it is a requirement imposed by content
> creators. FFmpeg doesn't have to support DRM itself, but you should
> still consider its usages.
> At that point in the code, the packet can only be decrypted by the
> demuxer. For example, in MP4 this can be done by passing the
> -decryption_key parameter. But that requires that FFmpeg handle the
> decryption. In my case, we are passing the packet to a CDM (content
> decryption module) to handle the decryption and that might be a
> hardware-secure decryptor. In most DRM situations, we can't get the
> raw key at all, all we can do is say "decrypt this block of memory".
> So the only way to have the packet decrypted before this point would
> be to introduce a callback to the app to decrypt the packet.
> This is why I have been working on exposing the encryption info. My
> app (or more correctly the CDM) needs to handle the decryption and we
> can't just give the key to libavformat so the demuxer can decrypt the
> > > This point is between the demuxer creating the packet and
> > > giving to the app. So the only way to decrypt the frame (as of now)
> > > is for the demuxer to do this. There is no way for the app to handle
> > > the decryption before this point.
> > >
> > > From the app's perspective, I would expect the packet to remain
> > > encrypted for as long as possible.
> > why ?
> Because the point of encryption is to ensure that nefarious parties
> don't get access to the data. Even though the packet data is stored
> in memory, it could still be retrieved by a malicious user. Usually
> for protected media, the frames are only decrypted when needed and in
> some cases are decrypted in a secure CPU and isn't even accessible to
> the app. There are platforms that support what is called "direct
> render" where the app gives the platform the encrypted packets and a
> discrete hardware unit will decrypt the packet, decode it, and render
> it directly; this happens on some smart TVs. There are also cases
> which require decrypt-decode where we give the platform an encrypted
> packet and it will decrypt and decode the packet, ensuring the
> decrypted packet data is never in main memory. So there are cases
> where we can't even see the encoded packet and decoding is handled by
> the platform.
> > > My app will store the packet for a
> > > while, then decrypt it right before passing it to the decoder and
> > > drawing the frame. So requiring the packet to be decrypted at this
> > > point is not ideal.
> > >
> > > >
> > > > And if that can't be done, then the demuxer could perhaps set
> > > > st->need_parsing to 0 and skip parsing altogether?
> > >
> > > I would want to still have parsing if possible. For example, a lot of
> > > content has a clear lead where the first few seconds are clear. So
> > > they could be used to adjust the starting timestamps (and whatever
> > > parsing needs) and the encrypted content later can be deduced based on
> > > that.
> > >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> > Modern terrorism, a quick summary: Need oil, start war with country that
> > has oil, kill hundread thousand in war. Let country fall into chaos,
> > be surprised about raise of fundamantalists. Drop more bombs, kill more
> > people, be surprised about them taking revenge and drop even more bombs
> > and strip your own citizens of their rights and freedoms. to be continued
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
More information about the ffmpeg-devel