[FFmpeg-devel] [PATCH] remove out-dated ADPCM frame_size handling in libavformat

[Michael Niedermayer]

On Wed, Sep 08, 2010 at 06:49:36PM -0400, Justin Ruggles wrote:
> Justin Ruggles wrote:
> 
> > Michael Niedermayer wrote:
> > 
> >> On Mon, Sep 06, 2010 at 08:11:38AM -0400, Justin Ruggles wrote:
> >> [...]
> >>> Index: tests/ref/acodec/g726
> >>> ===================================================================
> >>> --- tests/ref/acodec/g726	(revision 25042)
> >>> +++ tests/ref/acodec/g726	(working copy)
> >>> @@ -1,4 +1,4 @@
> >>> -5d8cce28f83dd33c3c7eaf43a5db5294 *./tests/data/acodec/g726.wav
> >>> -24082 ./tests/data/acodec/g726.wav
> >>> -4f1ba1af75dee64625a1c852e6cd01d3 *./tests/data/g726.acodec.out.wav
> >>> -stddev: 8504.69 PSNR: 17.74 MAXDIFF:31645 bytes:    96104/  1058400
> >>> +fd090ddf05cc3401cc75c4a5ace1d05a *./tests/data/acodec/g726.wav
> >>> +24052 ./tests/data/acodec/g726.wav
> >>> +74abea06027375111eeac1b2f8c7d3af *./tests/data/g726.acodec.out.wav
> >>> +stddev: 8554.55 PSNR: 17.69 MAXDIFF:29353 bytes:    95984/  1058400
> >> the number of samples encoded seems to be changing and not equal to
> >> the input
> > 
> > When the frame size in the encoder makes frames end on a byte boundary
> > without any padding, the output is always identical.  Since codes are
> > between 2 and 5 bits long, how would the decoder distinguish between
> > padding to a byte boundary and another valid code?  I'll double-check,
> > but it seems that the decoder currently treats padding as additional
> > samples.
> 
> I've confirmed that this is the cause of the difference.  The parameters
> used by the regression test give a 4-bit code size.  When the frame size
> is odd, that leads to 1 extra sample being decoded by the decoder
> because of padding.  In the current version, because of resampling from
> 44100 Hz to 8000 Hz, the frame size actually varies from frame-to-frame.
> 
> Current:
> source samples             = 264600
> resampled samples          =  47991
> number of odd-sized frames =     61
> decoded samples            =  48052
> decoded data bytes         =  96104
> 
> Patched:
> source samples             = 264600
> resampled samples          =  47991
> number of odd-sized frames =      1 (the last frame)
> decoded samples            =  47992
> decoded data bytes         =  95984
> 
> So choosing a frame size that forces the encoder to only use padding for
> the last frame (which this patch does) seems to be the appropriate thing
> to do.

the patch is ok then
the regression test still is completely broken though because it does not
seem to compare files of equal sampling rate if my guess is correctly

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100909/7487aaab/attachment.pgp>