[FFmpeg-devel] [PATCH] avformat/utils: Don't parse encrypted packets.

[Jacob Trimble]

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.  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.  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.

>
> >
> > Am i missing something ?
> >
> > thx
> >
> > [...]
> >
> >
> >
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel