hmm... not sure i understand fate, even after a quick look. Is there an explanation more complete than on the website?
I'm guessing that the ideal test for this would be to exercise the url functions directly from code; e.g.: 1. write some known data through crypto:, compare with pre-prepared output of openssl. 2. read the same data linearly through crypto: , and check it's the same as it should be. 3. read the same data non-linearly through crypto: , and check it's the same as it should be. 4. try to write some known data with seek, and expect failure? Seems fate has some dedicated test programs; libavformat/tests/aes.c may be a good example to start with? Seems to just return 0 if OK, and 1 if fail? s On Tue, Aug 30, 2016 at 4:17 PM, Michael Niedermayer <mich...@niedermayer.cc > wrote: > On Tue, Aug 30, 2016 at 09:47:12AM +0100, Simon H wrote: > > > > > crypto.c | 116 ++++++++++++++++++++++++++++++ > +++++++++++++++++++++++++++++++-- > > 1 file changed, 114 insertions(+), 2 deletions(-) > > a8d9d6638d0be86896de1cb2fa5f9a9f60d7b3c3 libavformat-crypto-add-seek. > patch > > From a0c4d274b2b1712e6ca26a18083edccb55032b94 Mon Sep 17 00:00:00 2001 > > From: Simon Hailes <btsim...@googlemail.com> > > Date: Tue, 30 Aug 2016 09:40:14 +0100 > > Subject: [PATCH] cyrpto 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 maked 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. > > --- > > libavformat/crypto.c | 116 ++++++++++++++++++++++++++++++ > ++++++++++++++++++++- > > 1 file changed, 114 insertions(+), 2 deletions(-) > > applied > > can you add a fate test for this case ? > > thanks > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > When you are offended at any man's fault, turn to yourself and study your > own failings. Then you will forget your anger. -- Epictetus > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
