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

[Michael Niedermayer]

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


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


> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180830/c6609ca9/attachment.sig>