[FFmpeg-devel] Patch for libavformat/crypto to add seeking on read

[Simon H]

thanks Michael,

try the attached file.  I assume the corruption came from email word
wrapping? or was there something else wrong?

simon

On Mon, Aug 29, 2016 at 6:11 PM, Michael Niedermayer <michael at niedermayer.cc
> wrote:

> On Mon, Aug 29, 2016 at 11:08:36AM +0100, Simon H wrote:
> > crypto allows reading of data which has been aes-128-cbc encrypted given
> a
> > key and an iv.
> > But it did not handle filetypes which require seeking...  e.g. it failed
> on
> > an encrypted .mp4 file.
> >
> > example:
> > take 25.mp4 created with:
> > ffmpeg -f lavfi -i sine=frequency=1000:beep_
> factor=2:r=48000:duration=720.0
> > -f lavfi -i testsrc=duration=720.0:rate=25 -vcodec libx264 -cmp 22
> > -timecode 10:00:00:00 -r 25 -y out\25.mp4
> >
> > encrypt with:
> > openssl enc -aes-128-cbc -K 12345678901234567890123456789012 -iv
> > 12345678901234567890123456789012 -in 25.mp4 -out 25.enc
> > then to transcode in ffmpeg:
> > ffmpeg -key 12345678901234567890123456789012 -iv
> > 12345678901234567890123456789012 -i crypto:25.enc -vcodec mpeg4 -r 25 -y
> > 25dec.mp4
> >
> > prior to this modification, the transcode would fail.
> >
> > Note also:  crypto previously marked both reads and writes as streamed,
> > which caused the whole file
> > to be read before the transcode started.  Now, for read only, if the
> > underlying layer is not marked as streamed,
> > then crypto is not.  This should enable efficient reading of encrypted
> > containers which require seeking.
> >
> > this is my first patch for ffmpeg; guidance appreciated.
> > ---
> >  libavformat/crypto.c | 115
> > +++++++++++++++++++++++++++++++++++++++++++++++++--
> >  1 file changed, 112 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/crypto.c b/libavformat/crypto.c
> > index 2999f50..23bc0a6 100644
> > --- a/libavformat/crypto.c
> > +++ b/libavformat/crypto.c
> > @@ -26,7 +26,8 @@
> >  #include "internal.h"
> >  #include "url.h"
> >
> > -#define MAX_BUFFER_BLOCKS 150
> > +// encourage reads of 4096 bytes - 1 block is always retained.
> > +#define MAX_BUFFER_BLOCKS 257
> >  #define BLOCKSIZE 16
> >
> >  typedef struct CryptoContext {
> > @@ -36,6 +37,8 @@ typedef struct CryptoContext {
> >              outbuffer[BLOCKSIZE*MAX_BUFFER_BLOCKS];
> >      uint8_t *outptr;
> >      int indata, indata_used, outdata;
> > +    int64_t position;  // position in file - used in seek
> > +    int flags;
> >      int eof;
> >      uint8_t *key;
> >      int keylen;
> > @@ -109,6 +112,7 @@ static int crypto_open2(URLContext *h, const char
> *uri,
> > int flags, AVDictionary
> >      const char *nested_url;
> >      int ret = 0;
> >      CryptoContext *c = h->priv_data;
> > +    c->flags = flags;
> >
> >      if (!av_strstart(uri, "crypto+", &nested_url) &&
> >          !av_strstart(uri, "crypto:", &nested_url)) {
> > @@ -117,6 +121,8 @@ static int crypto_open2(URLContext *h, const char
> *uri,
> > int flags, AVDictionary
>
> patch corrupted by newlines
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If a bugfix only changes things apparently unrelated to the bug with no
> further explanation, that is a good sign that the bugfix is wrong.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libavformat_crypto_seek_patch.patch
Type: application/octet-stream
Size: 7233 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160829/5a457f21/attachment.obj>