fixes:
CANL4_SVA_B.264
NL3_SVA_C.264
NL3_SVA_E.264

Originally committed as revision 8055 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 8047 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 8026 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 8017 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 8016 to svn://svn.ffmpeg.org/ffmpeg/trunk

remove more silly ref_count checks
use list_count where appropriate

Originally committed as revision 8000 to svn://svn.ffmpeg.org/ffmpeg/trunk

remove silly ref_count<0 and ref_count==0 checks its impossible for this variable to have such a value

Originally committed as revision 7999 to svn://svn.ffmpeg.org/ffmpeg/trunk

add list_count

Originally committed as revision 7998 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7997 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7996 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7995 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by Francois Oligny-Lemieux % eucloid A gmail P com %
Original thread:
Date: Feb 9, 2007 12:00 AM
Subject: [Ffmpeg-devel] h264.c patch, always decoding extradata when on non avc stream

Originally committed as revision 7904 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7671 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7664 to svn://svn.ffmpeg.org/ffmpeg/trunk

increase delayed_pic buffer size (one temporary is used and a terminating NULL is assumed by most code so it has to be 18 large)

Originally committed as revision 7663 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7661 to svn://svn.ffmpeg.org/ffmpeg/trunk

some of these might have been exploitable

Originally committed as revision 7591 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7587 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7586 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by Frank %eucloid A gmail P com%
date: Jan 18, 2007 6:48 PM
subject: Re: [Ffmpeg-devel] h264, protection against corrupted data (second try patch)
AND
date: Jan 17, 2007 8:22 PM
subject: [Ffmpeg-devel] h264, protection against corrupted data

this also fixes a possible security issue (the sps and pps ids where not checked,
then used as index into an array of sps/pps structs which was then filled with data from the bitstream)

Originally committed as revision 7585 to svn://svn.ffmpeg.org/ffmpeg/trunk

Avoids a crash due to dsp.clear_blocks being NULL when called.

Originally committed as revision 7547 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7440 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7256 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7245 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7244 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7232 to svn://svn.ffmpeg.org/ffmpeg/trunk

patch by Alexander Chemeris % ipse P ffmpeg A gmail.com %
Original thread:
date: Dec 5, 2006 7:26 PM
subject: [Ffmpeg-devel] [PATCH] Fix crush when truncated slice passed to H.264 decoder

Originally committed as revision 7229 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7228 to svn://svn.ffmpeg.org/ffmpeg/trunk

in other code.

Originally committed as revision 7226 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6992 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6955 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6863 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6853 to svn://svn.ffmpeg.org/ffmpeg/trunk

the semantics of ARCH_X86 to mean both 32 and 64 bits.

Originally committed as revision 6852 to svn://svn.ffmpeg.org/ffmpeg/trunk

!PIC but gets used without a check for !PIC.

Originally committed as revision 6834 to svn://svn.ffmpeg.org/ffmpeg/trunk

8% faster decode_cabac_residual() (8x8 case only) on P3

Originally committed as revision 6750 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6735 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6734 to svn://svn.ffmpeg.org/ffmpeg/trunk

x86 is 4% faster on P3
C sign stuff + x86 code for everything else is also faster then before (sorry forgot to test pure C)
... and if i replace the second occurance of the sign decoding in decode_residual by the asm too then everything gets slower iam starting to think that it might be best to write the whole function in asm, playing this avoid random deoptimizations game with gcc is not fun at all

Originally committed as revision 6732 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6725 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6724 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6685 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6675 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6674 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6673 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6666 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6664 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6655 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6653 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6609 to svn://svn.ffmpeg.org/ffmpeg/trunk