[FFmpeg-devel] [PATCH] libmp3lame: 32 bit encoding

[Reimar Döffinger]

On Sat, Apr 16, 2011 at 11:13:02PM +0200, Peter Belkner wrote:
> On 16.04.2011 22:16, Reimar Döffinger wrote:
> >On Sat, Apr 16, 2011 at 08:12:35PM +0200, Peter Belkner wrote:
> >>On 16.04.2011 17:14, Michael Niedermayer wrote:
> >>>>On the other hand I corrected casting the frame buffer provided by
> >>>>FFmpeg to (int32_t *).
> >>>your mono code looks like it would fail with 64bit long
> >>Fixed it with it's own copy loop, cf. revised patch below.
> >Why are you not just using the lame_encode_buffer_int function?
> 
> What's the difference? As far as I know "int" has also platform
> dependent size.

In reality not really.
Running the a conversion even if 99.9% of all cases don't need
it doesn't seem reasonable.
I don't mind much how it is done, but I'd probably just make it
fail (and preferable not advertise the feature in the first place)
when int isn't 4 bytes.

> @@ -151,7 +167,13 @@ static int MP3lame_encode_frame(AVCodecContext *avctx,
>  
>      /* lame 3.91 dies on '1-channel interleaved' data */
>  
> -    if(data){
> +    if(NULL == data){

I'd very much appreciate without such pointless changes

> +        lame_result= lame_encode_flush(
> +    }else if(AV_SAMPLE_FMT_S16 == avctx->sample_fmt){
> +            lame_result = lame_encode_buffer_long2(
> +        } else {

And a bit more consistent way of placing spaces.
I know it can seem quite pointless, but in the long run
such small things also make the difference between
code most people like working with or code they
seriously consider running away from it screaming.