- 27 Jan, 2012 2 commits
-
-
Alex Converse authored
This reverts commit fc115c80. Tests are broken.
-
Paul B Mahol authored
Signed-off-by:
Ronald S. Bultje <rsbultje@gmail.com>
-
- 09 Jan, 2012 1 commit
-
-
Paul B Mahol authored
Signed-off-by:
Ronald S. Bultje <rsbultje@gmail.com>
-
- 21 Dec, 2011 1 commit
-
-
Luca Barbato authored
Some libavifilter tests use NUT as output even if the produced files were not decodable. The support for 10bit introduced in 432f0e5b and 91b1e6f0 changed the hashes.
-
- 22 Oct, 2011 1 commit
-
-
Ronald S. Bultje authored
-
- 21 Oct, 2011 1 commit
-
-
Ronald S. Bultje authored
-
- 12 Oct, 2011 1 commit
-
-
Anton Khirnov authored
-
- 12 Aug, 2011 1 commit
-
-
Ronald S. Bultje authored
-
- 02 Aug, 2011 2 commits
-
-
Ronald S. Bultje authored
This reverts commit ac0fb593. It causes valgrind errors which I'll want to investigate before resubmitting this.
-
Ronald S. Bultje authored
-
- 21 Jul, 2011 1 commit
-
-
Joseph Artsimovich authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
- 08 Jul, 2011 3 commits
-
-
Ronald S. Bultje authored
We operated on 31-bits, but with e.g. lanczos scaling, values can add up to beyond 0x80000000, thus leading to output of zeroes. Drop one bit of precision fixes this.
-
Ronald S. Bultje authored
When using e.g. lanczos scaling, values can drop below 0, so they should never be unsigned.
-
Ronald S. Bultje authored
We would use the second half of the U plane buffer, rather than the V plane buffer, to output the V plane pixels.
-
- 29 Jun, 2011 1 commit
-
-
Ronald S. Bultje authored
This means that precision is retained when scaling between sample formats with >8 bits per component (48bit RGB, 16bit grayscale, 9/10/16bit YUV).
-
- 28 Jun, 2011 2 commits
-
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Ronald S. Bultje authored
-
- 14 Jun, 2011 1 commit
-
-
Michael Niedermayer authored
YUV planes were marked as uint16_t, but they contained signed data. Fixes issue 1108 and 675. Signed-off-by:
Ronald S. Bultje <rsbultje@gmail.com>
-
- 14 May, 2011 1 commit
-
-
Ronald S. Bultje authored
Also remove code that overwrites the C versions of functions in sws_init_swScale_altivec(), so that it uses the C functions of files if no altivec-optimized version exists.
-
- 28 Apr, 2011 1 commit
-
-
Peter Ross authored
Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
- 22 Jan, 2011 1 commit
-
-
Mans Rullgard authored
Instead of saving huge raw files, use the md5: output pseudo-protocol to calculate the checksum of the file directly. This is especially useful when testing on remote targets as it avoids transferring 3.6GB over the network.
-
- 02 Aug, 2010 1 commit
-
-
Stefano Sabatini authored
Increase readability and robustness, as the test result is not going to differ if the order of the pixfmts codes changes. Originally committed as revision 24665 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 19 Jul, 2010 1 commit
-
-
Måns Rullgård authored
This test verifies the pixdesc code by comparing the output with and without a filter which should have no effect on the image. Since the available pixel formats depend on the byte order of the machine, a simple reference checksum is not possible. The test originally tried to solve this by generating a reference file on the fly. The problem with this is that the test framework expects the reference file in the source tree, and writing to the source tree is not allowed. To avoid complicating the test framework, we instead provide two reference files and select which to use based on the byte order. Originally committed as revision 24330 to svn://svn.ffmpeg.org/ffmpeg/trunk
-