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 <mich...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >
libavformat_crypto_seek_patch.patch
Description: Binary data
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel