[Ffmpeg-devel] Re: [Ffmpeg-cvslog] r7570 - trunk/libavutil/fifo.c

Michael Niedermayer michaelni
Fri Jan 26 13:27:38 CET 2007


On Thu, Jan 25, 2007 at 10:59:04PM -0800, Roman Shaposhnik wrote:
> Hi
> On Wed, 2007-01-24 at 11:15 +0100, Michael Niedermayer wrote:
> > >   Right. That's the price paid for av_fifo_peek()'s performance. Now,
> > > currently the way DV audio is shuffled we have to 'peek' every time we
> > > need to get to the next byte in the FIFO. As I pointed out it is
> > > possible to restructure the code so that we would go over the bytes
> > > stored in FIFO in a linear fashion and thus eliminate the peeking
> > > process. But even though that would let us get rid of av_fifo_peek()
> > > it will introduce a different kind of ugliness where I would have
> > > to supply a stateful 'thunk' to av_fifo_generic_read.
> > 
> > maybe the whole could be done easier without using a AVFifoBuffer?
>   That's what I'm going to try over the weekend.
>   Now, going forward I'm sure the questions like the one asked about
> av_fifo_peek() will get asked from time to time -- so it'll be
> interesting to have you state your position explicitly. Do you always
> prefer solutions which *explicitly* manipulate the internals of a
> particular data type on a caller site over the solutions which 
> abstract that manipulation into a dedicated function, but for
> performance reasons provide it in a header file, thus suffering 
> >from a potential ABI breakage.

i prefer if the user application does not become entangled with the
internals of various parts of libav*, also i prefer if the libav* libs
themselfs dont get too entangled with each other ...

if its unavoidable to access the internals then yes a static inline
function in an header like fifo.h is better then dumping the code into
a random other file but only if its really unavoidable, not if its just
saving a few hours work ...


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070126/e671cdd0/attachment.pgp>

More information about the ffmpeg-devel mailing list