Move decode_significance_x86() and decode_significance_8x8_x86() to
i386-specific file from cabac.h.
New file is h264-oriented and only included from h264.c
Resolves compilation when configured with --disable-optimizations due to
decode_significance_8x8_x86 using last_coeff_flag_offset_8x8, which is
only defined in h264.c
Originally committed as revision 12846 to svn://svn.ffmpeg.org/ffmpeg/trunk
i386-specific file from cabac.h.
New file is h264-oriented and only included from h264.c
Resolves compilation when configured with --disable-optimizations due to
decode_significance_8x8_x86 using last_coeff_flag_offset_8x8, which is
only defined in h264.c
Originally committed as revision 12838 to svn://svn.ffmpeg.org/ffmpeg/trunk
h264.c:2093: warning: unused variable 's'
h264.c:2406: warning: suggest parentheses around arithmetic in operand of ^
h264.c:2412: warning: suggest parentheses around arithmetic in operand of ^
Originally committed as revision 11680 to svn://svn.ffmpeg.org/ffmpeg/trunk
in both mpegvideo and h264 decoder. Fixed by allowing all (master and duplicate)
contexts to fully initialize in MPV_frame_start and copying these into
H264Contexts.
Mailing list discussion:
[FFmpeg-devel] Memory leak in h264
Tue, 22 Jan 2008 15:22:55
Originally committed as revision 11657 to svn://svn.ffmpeg.org/ffmpeg/trunk
(iam not sure if this might have been exploitable)
fixes issue332 / CVCANLMA2_Sony_C.jsv
Other solutions which waste a few bytes less are welcome ...
Originally committed as revision 11605 to svn://svn.ffmpeg.org/ffmpeg/trunk
Actually unreference removed pics
And check for too many reference frames as originally intended, not equal
to max reference frames.
Originally committed as revision 11218 to svn://svn.ffmpeg.org/ffmpeg/trunk
max frame count, which is limited to less than the size of the
reference buffers, thereby preventing overflow.
Part of fix for issue 281.
Originally committed as revision 11216 to svn://svn.ffmpeg.org/ffmpeg/trunk
many reference frames. Also check max num ref frames against our internal
ref buffer sizes.
Part of fix for roundup issue 281
Originally committed as revision 11215 to svn://svn.ffmpeg.org/ffmpeg/trunk
Namely, that it should not be called if you are starting to decode a B
frame without any reference pictures.
Prevents an endless allocation cycle in MPV_frame_start that will end in
picture buffer overflow and abort.
Fixes roundup issue 216.
Originally committed as revision 11214 to svn://svn.ffmpeg.org/ffmpeg/trunk
Based on original patch by Martin Zlomek martin.zlomek a email D cz
ffmpeg-devel thread: H264: Fix non_zero_count_cache for deblocking in fields
Fri, 30 Nov 2007 9:58:23
Originally committed as revision 11212 to svn://svn.ffmpeg.org/ffmpeg/trunk
to clear last_picture_ptr, next_picture_ptr for proper picture
management. Prevents crashes in error concealer following seeks.
Fixes Roundup issue 189.
Originally committed as revision 11049 to svn://svn.ffmpeg.org/ffmpeg/trunk
in decoding order would always be assigned to a field pair's poc.
Original thread: H.264: Fix poc for field pairs, 6 Nov 2007 17:41:02
Originally committed as revision 10937 to svn://svn.ffmpeg.org/ffmpeg/trunk
in display order, based on decoding information in decoding order. Now
set properly, immediately upon completion of decode.
Based on original patch from Reinhard Nissl, rnisssl % gmx , de
Original Thread: [FFmpeg-devel] H.264 + PAFF: BBC HD recording shows
extreme interlacing artefacts, Thu, 01 Nov 2007 22:43:09
Originally committed as revision 10931 to svn://svn.ffmpeg.org/ffmpeg/trunk
setting Picture.reference to indicate parity for all Pictures in
reference list.
Patch by Jeff Downs, heydowns T borg O com
Originally committed as revision 10744 to svn://svn.ffmpeg.org/ffmpeg/trunk
