[Ffmpeg-devel] Re: [Ffmpeg-cvslog] r6161 - in trunk: libavcodec/dv.c libavcodec/dvdata.h libavformat/avformat.h libavformat/dv.c tests/ffmpeg.regression.ref tests/libav.regression.ref tests/rotozoom.regression.ref

[Roman Shaposhnik]

Hi

On Tue, 2006-09-05 at 23:43 -0700, Michale wrote:
> >   I would expect fifo_peek to benefit *a lot* by being a static inline,
> > since its being used in a pretty hot loop. 
> 
> i would expect it to benefit more if the % wherent there, and calling it
> twice for x and x+1 also seems not optimal at all, maybe a fifo_peek()
> which always returns 4 byte in an big endian int would be more generically
> useable and faster for the specific case in dv

  That is a good suggestion indeed.

> IMO move all the fifo specific stuff (together with the 2 new functions)
> to its own header, maybe fifo.h, none of this belongs to avformat.h,
> maybe we could one day move it to avutil but thats a seperate issue, it
> definitly doesnt belong to the main public header of libavformat though

  Agreed. I'll prepare a patch and send it to -devel for review first.
I'm back from my business trip now.

> http://ffmpeg.mplayerhq.hu/ffmpeg-doc.html#SEC36

  Fair enough. I'm sorry I overlooked it.

> thats indeed a little long ago, i thought it was not that long ago so
> maybe ive overreacted but still, developers should not randomly change
> code maintained by others, it simply leads to bugs and chaos especially
> as the number of developers increases

  Agreed. Lets just settle on a fact that we have both 
overreacted and stick to the policy you've outlined above. 
Which is especially simple because the policy is a reasonable
one.

> and furthermore fact is i was pretty tired when i wrote my reply to you
> which probably didnt improve my politeness level either, in real world
> people would have noticed that i was tired. on a mailinglist things like
> that arent noticed which causes further missunderstandings ...

  That I completely understand and can relate to. 

Thanks,
Roman.