Hi 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>
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