[FFmpeg-devel] [PATCH] avcodec_decode_audio3 and?multiple?frames in a packet

[Michael Niedermayer]

On Wed, Sep 16, 2009 at 02:52:29PM +0200, Sascha Sommer wrote:
> Hi,
> 
> On Samstag, 12. September 2009, Justin Ruggles wrote:
> > Michael Niedermayer wrote:
> > > On Fri, Sep 11, 2009 at 12:13:02PM +0200, Sascha Sommer wrote:
> > > [...]
> > >
> > >> Previously a value of 0 meant that no frame was decoded.
> > >
> > > no
> > > you read the docs backward, it says if no frame was decoded return 0
> > > it does not say that 0 means no frames have been decoded, it could
> > > equally well mean 0 bytes used
> >
> > Ah, good.  So, although the current text is technically correct if
> > interpreted that way, it is ambiguous.  Why do we need to have a 0
> > return value also possibly mean no frames have been decoded?   If
> > frame_size_ptr is set to 0, that always means no frames have been
> > decoded, without regard to the return value.  And a return value of 0
> > should mean zero bytes were used, without regard to what frame_size_ptr
> > is set to.  They seem mutually exclusive to me...
> >
> 
> I agree. The return value controls the number of input bytes, frame_size_ptr 
> the number of output bytes. I don't see why 0 needs to be returned when no 
> frame was outputted.

what exactly did the decoder then do with the data?
and what was that data it did not decode?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090916/a56b133c/attachment.pgp>