[FFmpeg-devel] [RFC] use ff_avc_find_startcode in ff_find_start_code

Trent Piepho xyzzy
Wed Feb 20 03:00:50 CET 2008


On Tue, 19 Feb 2008, Reimar [iso-8859-1] D?ffinger wrote:
> mine:
> 852 dezicycles in A2, 15912 runs, 472 skips
> 843 dezicycles in A2, 31824 runs, 944 skips
> 844 dezicycles in A2, 63644 runs, 1892 skips
> real    0m6.943s
> user    0m6.680s
> sys     0m0.248s
>
> Problem:
> START_/STOP_TIMER and "time" vastly disagree.
> And yes, I remembered to disable speedstep this time.

A problem with START_/STOP_TIMER is that is doesn't handle code that can
take a vastly different amount of time depending on what data it is run on.

Obviously finding a start code is far faster when you start searching at
the start code's location instead of needing to search through 100s or more
bytes of data.

If 97% of the start codes are very fast to find, and 3% are very hard,
START_/STOP_TIMER will totally ignore time from the hard ones.  What it's
measuring is the average time for easy to find start codes only, not the
average time for hard start codes, or what's really the desired value, the
average time overall based on the typical distribution of start codes.

You can easily tell that the number of skips is far too high.  63644 runs
times 84.4 cycles per run = 5.4 megacycles.  If your CPU is a measly 540
MHz, that's only 1/100th of a second.  1892 skips in that time would be
189,200 interrupts/second if skips were due only to interrupts.  Which is
of course far too high, and only gets worse if your code is faster than 540
MHz.

Virtually all of those skips are because some start codes were slower to
find than others.  The actual number of interrupts should be 10 or less,
given the total run time of the code and a sane interrupt rate.




More information about the ffmpeg-devel mailing list