On 11/03/2011 02:12 PM, Alex Converse wrote: > On Thu, Nov 3, 2011 at 11:08 AM, Diego Biurrun <[email protected]> wrote: >> >> --- >> libavcodec/lpc.c | 3 +-- >> libavutil/aes.c | 2 +- >> 2 files changed, 2 insertions(+), 3 deletions(-) >> >> diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c >> index 874af05..76906af 100644 >> --- a/libavcodec/lpc.c >> +++ b/libavcodec/lpc.c >> @@ -35,8 +35,7 @@ static void lpc_apply_welch_window_c(const int32_t *data, >> int len, >> double w; >> double c; >> >> - assert(!(len&1)); //the optimization in r11881 does not support odd len >> - //if someone wants odd len extend the change in r11881 >> + assert(!(len&1)); >> >> n2 = (len >> 1); >> c = 2.0 / (len - 1.0); >> diff --git a/libavutil/aes.c b/libavutil/aes.c >> index ace317f..c128297 100644 >> --- a/libavutil/aes.c >> +++ b/libavutil/aes.c >> @@ -33,7 +33,7 @@ typedef union { >> >> typedef struct AVAES { >> // Note: round_key[16] is accessed in the init code, but this only >> - // overwrites state, which does not matter (see also r7471). >> + // overwrites state, which does not matter. >> av_aes_block round_key[15]; >> av_aes_block state[2]; >> int rounds; >> -- > > Why? These provide context and are still easily findable e.g. > http://git.libav.org/?p=libav.git&a=search&h=HEAD&st=commit&s=revision+11881
+1 we could change them to git hashes if you really want to. but they should definitely stay. -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
