[FFmpeg-devel] [PATCH] fixes and optimization for?ff_find_start_code ()
Thu Feb 26 18:55:38 CET 2009
On Thu, Feb 26, 2009 at 05:34:27PM +0100, Matthias Dahl wrote:
> On Thursday 26 February 2009 17:03:49 you wrote:
> > this mixes cosmetic and functional changes and thus is unreviewable
> Sorry, the attached patch is strictly functional changes.
> > > + *state = 0xFFFFFFFF;
> > this though looks very wrong
> Currently ff_find_start_code() puts garbage in state when no start code could
> be found. That garbage can be anything. This way the caller has a way to
> actually know if a valid start code was found or not. I reviewed all users of
> this function and there will be no problem with this. We can even remove code
> here and here which tries to deal with exactly that problem. Or is there
> something I am not seeing?
ff_mpeg1_find_frame_end() as one example can be feeded with only buf_size=1
at a time, this isnt likely to occur in reality but startcodes can be split
across buffers in reality ...
> The simplified version seems to be easier optimizable for gcc 4.3.x
> as with -O3 and some artificial benchmarks I made, the new version
> is approx. 33% faster in all cases. A oprofile in mythtv revealed
> also a speed up.
a 1/3 speedup is nice but for such trivial C code that actually isnt really
changed, i have my doubts about this being consistent accross gccs and
-optimization-opitions for gcc.
also it might be worth investigating to rewrite this function is asm()
if gcc has problems with it, this at least leads to stable code that
isnt going to change speedwise for trivial changes ...
and tabs ar forbidden in ffmpeg svn
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel