- 16 Mar, 2017 1 commit
-
-
Michael Niedermayer authored
Fixes: 857/clusterfuzz-testcase-5319093760557056 Benchmark changes from 335->333 (so if its not a random fluctuation then it would be faster) Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 02 Mar, 2017 1 commit
-
-
Michael Niedermayer authored
Fixes: 689/clusterfuzz-testcase-6029352737177600 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 28 Feb, 2017 1 commit
-
-
Michael Niedermayer authored
Fixes: 677/clusterfuzz-testcase-6635120628858880 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpegReviewed-by: Steven Liu <lingjiujianke@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 22 Feb, 2017 1 commit
-
-
Michael Niedermayer authored
Fixes: 652/clusterfuzz-testcase-6174944410992640 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 21 Jun, 2016 1 commit
-
-
Anton Khirnov authored
This is more consistent with the naming of other decoders.
-
- 26 Mar, 2014 1 commit
-
-
Diego Biurrun authored
-
- 10 Apr, 2013 1 commit
-
-
Ronald S. Bultje authored
The non-intra-pcm branch in hl_decode_mb (simple, 8bpp) goes from 700 to 672 cycles, and the complete loop of decode_mb_cabac and hl_decode_mb (in the decode_slice loop) goes from 1759 to 1733 cycles on the clip tested (cathedral), i.e. almost 30 cycles per mb faster. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 19 Feb, 2013 1 commit
-
-
Ronald S. Bultje authored
The non-intra-pcm branch in hl_decode_mb (simple, 8bpp) goes from 700 to 672 cycles, and the complete loop of decode_mb_cabac and hl_decode_mb (in the decode_slice loop) goes from 1759 to 1733 cycles on the clip tested (cathedral), i.e. almost 30 cycles per mb faster. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 14 Feb, 2013 1 commit
-
-
Diego Biurrun authored
-
- 23 Jan, 2013 1 commit
-
-
Diego Biurrun authored
It does not help as an abstraction and adds dsputil dependencies. Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
- 15 Aug, 2012 1 commit
-
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 06 Mar, 2012 1 commit
-
-
Ronald S. Bultje authored
Results of IDCT can by far outreach the range of ff_cropTbl[], leading to overreads and potentially crashes. Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
- 21 Oct, 2011 1 commit
-
-
Baptiste Coudurier authored
Signed-off-by: Diego Biurrun <diego@biurrun.de> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
- 14 Aug, 2011 1 commit
-
-
Baptiste Coudurier authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 20 Jul, 2011 1 commit
-
-
Mans Rullgard authored
Use of these has been broken ever since the h264 idct was changed to always use transposed inputs. Furthermore, they were only ever used if some *other* non-default idct was requested. Signed-off-by: Mans Rullgard <mans@mansr.com>
-
- 05 Jul, 2011 1 commit
-
-
Diego Biurrun authored
This naming scheme is used elsewhere, so it's sensible to be consistent.
-
- 04 Jul, 2011 1 commit
-
-
Diego Biurrun authored
-
- 03 Jul, 2011 1 commit
-
-
Diego Biurrun authored
-
- 14 Jun, 2011 1 commit
-
-
Jason Garrett-Glaser authored
Note: this is 4:4:4 from the 2007 spec revision, not the previous (now deprecated) 4:4:4 mode in H.264.
-
- 13 Jun, 2011 2 commits
-
-
Jason Garrett-Glaser authored
Needs some ARM/PPC asm modifications.
-
Jason Garrett-Glaser authored
Note: this is 4:4:4 from the 2007 spec revision, not the previous (now deprecated) 4:4:4 mode in H.264.
-
- 11 May, 2011 2 commits
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
seems git missed them and we temporary lost our improvments in them. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 10 May, 2011 4 commits
-
-
Oskar Arvidsson authored
This patch lets e.g. dsputil_init chose dsp functions with respect to the bit depth to decode. The naming scheme of bit depth dependent functions is <base name>_<bit depth>[_<prefix>] (i.e. the old clear_blocks_c is now named clear_blocks_8_c). Note: Some of the functions for high bit depth is not dependent on the bit depth, but only on the pixel size. This leaves some room for optimizing binary size. Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Oskar Arvidsson authored
Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Oskar Arvidsson authored
Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Oskar Arvidsson authored
Needed for high bit depth h264 decoding. Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
- 10 Apr, 2011 3 commits
-
-
Oskar Arvidsson authored
This patch lets e.g. dsputil_init chose dsp functions with respect to the bit depth to decode. The naming scheme of bit depth dependent functions is <base name>_<bit depth>[_<prefix>] (i.e. the old clear_blocks_c is now named clear_blocks_8_c). Note: Some of the functions for high bit depth is not dependent on the bit depth, but only on the pixel size. This leaves some room for optimizing binary size. Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
Needed for high bit depth h264 decoding. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 19 Mar, 2011 1 commit
-
-
Mans Rullgard authored
Signed-off-by: Mans Rullgard <mans@mansr.com>
-
- 21 Jan, 2011 1 commit
-
-
Ronald S. Bultje authored
(cherry picked from commit 66c6b5e2)
-
- 20 Jan, 2011 1 commit
-
-
Ronald S. Bultje authored
-
- 15 Jan, 2011 1 commit
-
-
Jason Garrett-Glaser authored
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
-
- 14 Jan, 2011 2 commits
-
-
Jason Garrett-Glaser authored
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
-
Jason Garrett-Glaser authored
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
-
- 22 Jun, 2010 1 commit
-
-
Måns Rullgård authored
Originally committed as revision 23728 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 20 Apr, 2010 1 commit
-
-
Diego Biurrun authored
Passing an explicit filename to this command is only necessary if the documentation in the @file block refers to a file different from the one the block resides in. Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 01 Feb, 2009 1 commit
-
-
Diego Biurrun authored
Otherwise doxygen complains about ambiguous filenames when files exist under the same name in different subdirectories. Originally committed as revision 16912 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 26 Jan, 2009 1 commit
-
-
Diego Biurrun authored
Originally committed as revision 16811 to svn://svn.ffmpeg.org/ffmpeg/trunk
-