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
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to