On 1/5/2018 4:49 PM, Jacob Trimble wrote: > diff --git a/libavutil/aes_ctr.c b/libavutil/aes_ctr.c > index e9c568fe0d..6ed69c8e10 100644 > --- a/libavutil/aes_ctr.c > +++ b/libavutil/aes_ctr.c > @@ -38,10 +38,9 @@ struct AVAESCTR *av_aes_ctr_alloc(void) > return av_mallocz(sizeof(struct AVAESCTR)); > } > > -void av_aes_ctr_set_iv(struct AVAESCTR *a, const uint8_t* iv) > +void av_aes_ctr_set_full_iv(struct AVAESCTR *a, const uint8_t* iv) > { > - memcpy(a->counter, iv, AES_CTR_IV_SIZE); > - memset(a->counter + AES_CTR_IV_SIZE, 0, sizeof(a->counter) - > AES_CTR_IV_SIZE); > + memcpy(a->counter, iv, sizeof(a->counter)); > a->block_offset = 0; > } > > @@ -52,12 +51,14 @@ const uint8_t* av_aes_ctr_get_iv(struct AVAESCTR *a) > > void av_aes_ctr_set_random_iv(struct AVAESCTR *a) > { > - uint32_t iv[2]; > + uint32_t iv[4]; > > iv[0] = av_get_random_seed(); > iv[1] = av_get_random_seed(); > + iv[2] = 0; > + iv[3] = 0; > > - av_aes_ctr_set_iv(a, (uint8_t*)iv); > + av_aes_ctr_set_full_iv(a, (uint8_t*)iv); > } > > int av_aes_ctr_init(struct AVAESCTR *a, const uint8_t *key) > diff --git a/libavutil/aes_ctr.h b/libavutil/aes_ctr.h > index f596fa6a46..5995b37bec 100644 > --- a/libavutil/aes_ctr.h > +++ b/libavutil/aes_ctr.h > @@ -67,9 +67,9 @@ const uint8_t* av_aes_ctr_get_iv(struct AVAESCTR *a); > void av_aes_ctr_set_random_iv(struct AVAESCTR *a); > > /** > - * Forcefully change the iv > + * Forcefully change the "full" 16-byte iv, including the counter > */ > -void av_aes_ctr_set_iv(struct AVAESCTR *a, const uint8_t* iv); > +void av_aes_ctr_set_full_iv(struct AVAESCTR *a, const uint8_t* iv); > > /** > * Increment the top 64 bit of the iv (performed after each frame)
You can't remove API just like that without a deprecation period. Add a new av_aes_ctr_set_full_iv() function, and either leave av_aes_ctr_set_iv() alone or deprecate it if it effectively becomes superfluous after adding the new function. Also, this patch needs to be split in three. One for the aes_crt changes, one for the encryption_info changes, and one for mov changes, with a minor libavutil version bump for the former two, and the corresponding APIChanges entry. Alternatively, you could also squash the new encryption_info API from this patch into the one that actually introduces the entire feature. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel