attribute_unused and attribute_used respectively to ease compiling on non-gcc.
Originally committed as revision 9024 to svn://svn.ffmpeg.org/ffmpeg/trunk
Patch by Mean % fixounet A free P fr %
Original thread:
Date: Apr 29, 2007 2:00 PM
Subject: Re: [Ffmpeg-devel] [patch] h264.c, dont go beyond buffer in h264_decode_nal_unit
Originally committed as revision 8858 to svn://svn.ffmpeg.org/ffmpeg/trunk
This allows building shared libraries on AMD64 again.
based on a patch by Diego 'Flameeyes' Pettenò and suggestions by Michael
original thread:
Date: Wed, 18 Apr 2007 11:26:12 +0200
Subject: [Ffmpeg-devel] [PATCH] (try 2) Build shared libraries on AMD64 again
Originally committed as revision 8849 to svn://svn.ffmpeg.org/ffmpeg/trunk
Patch by Limin Wang % lance P lmwang A gmail P com %
Original thread:
date: 04/09/2007 03:54 PM
subject: [Ffmpeg-devel] [PATCH] fix segment fault in h264_parse if buf_size is zero
Originally committed as revision 8714 to svn://svn.ffmpeg.org/ffmpeg/trunk
calls decode_rbsp_trailing() and therefore bit_length might get negative.
Although the remaining code is able to handle a negative bit_length, avoid
the calculation at all by setting bit_length to 0 for dst_length == 0.
patch by Reinhard Nissl, rnissl gmx de
Originally committed as revision 8690 to svn://svn.ffmpeg.org/ffmpeg/trunk
Consider the following byte sequence
00 00 01 0a 00 00 00 01 09 ...
^ ^
A B
decode_nal() determines dst_length to be 1 (i. e. the byte between label
A and B above). However, this byte is a trailing zero byte as the spec
says the the current NAL unit is terminated by a byte sequence 00 00 00.
The current code used a loop to decrement dst_length accordingly. But the
loop doesn't start as the loop condition checks for dst_length > 1, which
should read dst_length > 0.
patch by Reinhard Nissl, rnissl gmx de
Originally committed as revision 8689 to svn://svn.ffmpeg.org/ffmpeg/trunk
i.e. the four bytes 00 00 01 0a.
When decode_nal() decodes the end of sequence NAL unit, it returns with
dst_length == 0. The original code leads to a return -1 which discards
the current properly decoded frame.
patch by Reinhard Nissl, rnissl gmx de
Originally committed as revision 8688 to svn://svn.ffmpeg.org/ffmpeg/trunk
interested in using a debugger to debug FFmpeg.
Original thread:
Subject: [PATCH] Fix compilation when using --disable-opts
Date: 2007-03-15 16:58:35 GMT
Originally committed as revision 8549 to svn://svn.ffmpeg.org/ffmpeg/trunk
144095->142319 dezicycles for hl_decode_mb() on duron
trailing whitespace removed by me
Originally committed as revision 8106 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
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
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
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
Reimar Döffinger
Diego Biurrun
Aurelien Jacobs
Mean
Limin Wang
Reinhard Nissl
Stefan Huehner
Panagiotis Issaris
Baptiste Coudurier
Michael Niedermayer
Michel Bardiaux
Alexander Strange
Loren Merritt
Francois Oligny-Lemieux
Alex Beregszaszi
Guillaume Poirier
Måns Rullgård