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

[Michael Niedermayer]

On Wed, Sep 15, 2010 at 05:46:23PM -0400, Justin Ruggles wrote:
> Michael Niedermayer wrote:
> 
> > On Sun, Sep 12, 2010 at 04:10:14PM -0400, Justin Ruggles wrote:
> >> Michael Niedermayer wrote:
> >>
> >>> On Sat, Sep 11, 2010 at 06:26:55PM -0400, Justin Ruggles wrote:
> >>>> Justin Ruggles wrote:
> >>>>
> >>>>> Michael Niedermayer wrote:
> >>>>>
> >>>>>> On Sat, Sep 11, 2010 at 11:30:07AM -0400, Justin Ruggles wrote:
> >>>>>>> Michael Niedermayer wrote:
> >>>>>>>
> >>>>>>>> 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 dont know about g726 but mpeg4/h264 pad the bitstream so that one can find
exactly where it ends by looking at the bits at the end
the trick works along the line of appending 1 and then padding with 0 till a
byte boundary, this can be undone by just looking backward for the 1 bit

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/20100923/1ade920d/attachment.pgp>