[FFmpeg-cvslog] pcm_zork: use AV_SAMPLE_FMT_U8 instead of shifting all samples by 8.

[Reimar Döffinger]

On 27 Oct 2011, at 01:46, git at videolan.org (Justin Ruggles) wrote:

> ffmpeg | branch: master | Justin Ruggles <justin.ruggles at gmail.com> | Wed Sep 28 19:31:05 2011 -0400| [67a3b67c717e4e53b9217ec1d579f2dff5e46717] | committer: Justin Ruggles
> 
> pcm_zork: use AV_SAMPLE_FMT_U8 instead of shifting all samples by 8.
> 
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=67a3b67c717e4e53b9217ec1d579f2dff5e46717
> ---
> 
> libavcodec/pcm.c |   22 +++++++++++-----------
> 1 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/libavcodec/pcm.c b/libavcodec/pcm.c
> index e7cf874..ec2660c 100644
> --- a/libavcodec/pcm.c
> +++ b/libavcodec/pcm.c
> @@ -172,10 +172,11 @@ static int pcm_encode_frame(AVCodecContext *avctx,
>         dst += n*sample_size;
>         break;
>     case CODEC_ID_PCM_ZORK:
> -        for(;n>0;n--) {
> -            v= *samples++ >> 8;
> -            if(v<0)   v = -v;
> -            else      v+= 128;
> +        srcu8 = data;
> +        for (; n > 0; n--) {
> +            v = *srcu8++;
> +            if (v < 128)
> +                v = 128 - v;

That can't be right, now an input value of both 0 and 128 give a result of 128.
A encode-decode cycle via fate should show such issues quite obviously (at least for 8-bit data where input and final output should match).