[FFmpeg-devel] Pipeline: H.264 speed improvements

[Michael Niedermayer]

On Tue, Dec 23, 2008 at 04:08:26AM -0500, Jason Garrett-Glaser wrote:
> I've put together a list of all the possible speed improvements I can
> see, including both some obvious ones and non-obvious ones.  If you're
> interested in implementing anything here, say so to make sure your
> work isn't duplicated by Michael or I.  Also feel free to discuss some
> of the more nutty ideas, like the VLC table, or tell me that I'm wrong
> about something.
> 
> Non-assembly stuff:
[...]
> av_log2 is unnecessarily powerful for use in h264.c.  All signed
> golomb values in H.264 fit in 16-bit, and all unsigned golomb values
> other than headers fit in 8-bit.  Thus all ordinary unsigned golomb
> code reads can literally be put in a 256-byte VLC table and replaced
> with a single array lookup.

it may be that all ue golomb coded values are <256 outside the headers,
though even this seems wrong for mb_skip_run the way i understand the spec.
But a value of 255 corresponds to a 15bit long vlc code.
a 256 (or 128) entry LUT limits one to values 0-15 512 (or 1024) to 0-31

Now there are surely a few left that are that small but thats far from
all non header values.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081223/7c462211/attachment.pgp>