1. 03 Sep, 2016 10 commits
  2. 02 Sep, 2016 12 commits
  3. 01 Sep, 2016 6 commits
  4. 31 Aug, 2016 7 commits
  5. 30 Aug, 2016 3 commits
    • Umair Khan's avatar
      9fbf0660
    • Simon Hailes's avatar
      avformat/crypto: add seeking support on read · a13a81a0
      Simon Hailes authored
      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.
      Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      a13a81a0
    • Simon Hailes's avatar
      libavformat/crypto - encourage reads of 4096 bytes · a2fcacc8
      Simon Hailes authored
      the current implementation reads in chunks of 149x16=2384 bytes.
      Seems more logical for it to read in chunks of 4096
      Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      a2fcacc8
  6. 29 Aug, 2016 1 commit
  7. 30 Aug, 2016 1 commit