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

Michael Niedermayer michaelni at gmx.at
Thu Oct 27 13:55:50 CEST 2011


On Thu, Oct 27, 2011 at 09:32:06AM +0200, Reimar Döffinger wrote:
> 
> 
> 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).

zork might be a (A)DPCM variant with 16bit output, we sadly have just
one lossy (mp3 based) reference sample (thanks to justin for that btw)
for how it is supposed to sound which makes reverse engeneering a bit
hard.

If there are no objections then ill revert these commits as i dont
think they are a step toward getting zork working

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-cvslog/attachments/20111027/be2b12bd/attachment.asc>


More information about the ffmpeg-cvslog mailing list