The original functions did not work correctly for edge pixels, e.g.
when CODEC_FLAG_EMU_EDGE is set, leading to corrupt output in e.g. VLC.
Based on a patch by Daniel Kang <daniel d kang gmail com>.
Signed-off-by: Ronald S. Bultje <rsbultje gmail com>
Improves CABAC performance about ~1.2%.
Trick originates from x264 and has also been used in ffvp8. It's useful because
coded block flags are usually zero, so it helps to have the early termination
inlined into the main function.
Originally committed as revision 26375 to svn://svn.ffmpeg.org/ffmpeg/trunk
The hunk is not fully understood but it just makes a check tighter so its
safer for us to apply until it is fully understood.
Might fix issue 2550 (and Chrome issue 68115 and unknown CERT issues).
Our bugtracker issue though should stay open until this has been fully
investiagted
Patch by Frank Barchard, fbarchard at google
Originally committed as revision 26368 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fixes issue 2548 (and Chrome issue 68115 and unknown CERT issues).
Patch by Frank Barchard, fbarchard at google
Originally committed as revision 26365 to svn://svn.ffmpeg.org/ffmpeg/trunk
instead of real width, this fixes decoding of some Bink files with odd width.
Originally committed as revision 26364 to svn://svn.ffmpeg.org/ffmpeg/trunk
color value instead of always taking 0 (resulting in green frames).
Fixes issue issue2531.
Originally committed as revision 26363 to svn://svn.ffmpeg.org/ffmpeg/trunk
exponent strategies for a single channel to compute_exp_strategy_ch().
This allows for removal of the temporary pointer arrays.
Originally committed as revision 26356 to svn://svn.ffmpeg.org/ffmpeg/trunk
No speed improvement, but necessary for some future stuff.
Also opens up the possibility of asm chroma dc idct/dequant.
Originally committed as revision 26349 to svn://svn.ffmpeg.org/ffmpeg/trunk
Doesn't help speed as there isn't an asm implementation yet, but consistency
is a good thing.
Originally committed as revision 26348 to svn://svn.ffmpeg.org/ffmpeg/trunk
Since we no longer have non-transposed scantables, the problem it warns about
no longer exists.
Originally committed as revision 26339 to svn://svn.ffmpeg.org/ffmpeg/trunk
Useful so that we don't have to run the hierarchical DC iDCT if there aren't
any coefficients. Opens up some future opportunities for optimization as well.
Originally committed as revision 26337 to svn://svn.ffmpeg.org/ffmpeg/trunk
About 2.5x the speed.
NOTE: the way that the asm code handles large qmuls is a bit suboptimal.
If x264-style dequant was used (separate shift and qmul values), it might
be possible to get some extra speed.
Originally committed as revision 26336 to svn://svn.ffmpeg.org/ffmpeg/trunk
It was an ugly hack to begin with and didn't give any performance.
NOTE: this patch opens up some future simplifications to be made (such as
removing some of the scantables from H264Context) but doesn't take advantage
of them yet.
Originally committed as revision 26329 to svn://svn.ffmpeg.org/ffmpeg/trunk
