This is a small change, but it does have a big impact on bit allocation.
all the regressions marked in the report have no audible
difference (I didn't check them all though), but the improvements can
be heard.
This affects mostly high bit rates. It's related to issue #2686.
In the report, A is the patched version, B is unpatched, all
comparisons show deltas in the form (A-B), so a positive pSNR delta
means a better quality in the patched version, and negative a
regression. Regressions are only considered for pSNR deltas below
-1db, they're considered serious below -6db.
All measurements were done with tiny_psnr.
The summary of the report inline for quick reading:
Files: 58
Bitrates: 6
Tests: 347
Serious Regressions: 0 (0%)
Regressions: 10 (2%)
Improvements: 54 (15%)
Big improvements: 26 (7%)
Worst regression - sine_tester.flac - 384k
- StdDev: 1.68 pSNR: -3.05 maxdiff: -178.00
Best improvement - 07 - Bound.flac - 384k
- StdDev: -1700.05 pSNR: 20.64 maxdiff: -29595.00
Average - StdDev: -55.67 pSNR: 1.20 maxdiff: -1593.00
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ce52869c22738ad584995d48103ce3aa2301736b':
fate: Rename fate-dts test to fate-dca-core
Conflicts:
tests/fate/audio.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a982c5d74fbc7ff5bd2f2f73af61ae48e9b1bcc6':
tests: drop bc dependency
Conflicts:
tests/fate-run.sh
See: d47eeff274
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Outputting DNxHD into .mov containers 'corrupts' following atoms until end of stsd
ffmpeg and qtdump could not decode pasp/colr atoms in the files made by ffmpeg,
when outputting DNxHD due to the incorrect padding placement. Now we add the
padding in the correct place
Tidy up FATE changes due to padding changes.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e21d85309943a51b7808f5e01dd258b262e09148':
FATE: add a test for the SVQ1 header byte swapping
Conflicts:
tests/fate/qt.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Avid prefers mpeg range [16-235] by default this change brings
ffmpeg into line with that. To obtain the old behaviour use
'-color_range jpeg' on the command line prior to the ouput
filename.
Signed-off-by: Kevin Wheatley <kevin.j.wheatley@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is not sufficient to run "make fate-ffprobe" on a remote system:
The ffprobe output contains the relative path to the testfile, it is
necessary to run the test from the build directory.
One solution is to use a script like the following as --target-exec:
ssh target "cd /remote/build/directory; $(printf "%q " "$@")"
This is a bit ugly as it attempts to keep most of the computation
in integers before the double based fps code. The use of integers
is to reduce the chances of rounding differences between platforms
Previously the timestamp was rounded to the encoder timebase
before being converted back to double precision which could cause loss
of precision
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The tests which use encoders which either use slices or store the encoder thread count
keep a hardcoded value of 1
This will help test more threading code like in filters
Found-by: ubitux
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '50036c30df83b609bc5a95276f1287f8b9b8bdd6':
fate: Use bitexact conversions in the dpxparser test
Conflicts:
tests/fate/image.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
