Patch by Marc Hoffman mmh _at_ pleasantst.com
Subject: [Ffmpeg-devel] PATCH Blackfin UNALIGNED_STORES_ARE_BAD in bitstream.h
Date: Tue, 17 Apr 2007 06:12:02 -0400
Originally committed as revision 8777 to svn://svn.ffmpeg.org/ffmpeg/trunk
this isnt the most beautifull solution but at least it works independant of the
random height in mov and it doesnt add any secholes
Originally committed as revision 8736 to svn://svn.ffmpeg.org/ffmpeg/trunk
get stuck to 1 but then width/height would change and interlaced
wouldnt be reset ...
Originally committed as revision 8735 to svn://svn.ffmpeg.org/ffmpeg/trunk
LAVC version to be in the file and thus breaking with the last change of that)
Originally committed as revision 8734 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Joakim \ elupus chez ecce dot se /
original thread:
date: 03/19/2007 01:47 AM
subject: [Ffmpeg-devel] [RFC] Improvement for the odd timestamp generation when parser is in use.
Originally committed as revision 8725 to svn://svn.ffmpeg.org/ffmpeg/trunk
of the reference implementation it is possible to use proper libraries now.
patch by Stanislav Brabec, sbrabec suse cz, changes and bug fixes by me
Originally committed as revision 8717 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
The image data is rescaled to the nearest pix_fmt it will fit in (gray8 or
gray16). Conversion is done inside the codec in order to avoid the need
for 14 (or 65534) new pix_fmt's.
Originally committed as revision 8704 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
