A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://ffmpeg.org/pipermail/ffmpeg-devel/2007-January/028042.html below:

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

[Ffmpeg-devel] Re: [Ffmpeg-cvslog] r7570 - trunk/libavutil/fifo.c [Ffmpeg-devel] Re: [Ffmpeg-cvslog] r7570 - trunk/libavutil/fifo.cRoman Shaposhnik rvs
Fri Jan 26 07:59:04 CET 2007
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.

Thanks,
Roman.



More information about the ffmpeg-devel mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4