These could be kept, but they are not overly useful. The only thing they
had over the remaining mp3 gapless test was seeking, which was incorrect
in the toc test, and only by chance correct in the notoc test.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It's the most useful mode, because it seeks accurately, and does not
break features like gapless audio.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
"-usetoc 2" now invokes the generic seek and indexing mode. This mode
skips data until the seek target is reached, and this is exact. It also
makes gapless audio actually work if a seek past the start of the file
is involved.
Change the fate-gapless-mp3 test to use the new mode, and move the old
one to fate-gapless-mp3-toc (since the test forces use of the Xing TOC).
The new mode has a different result for the seek - this result is
actually correct.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Some players do not support setting minimumUpdatePeriod to zero.
This patch adds a new parameter that will let the users set any
value to this field. Also updates the test and the documentation.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This patch adds support for creating DASH manifests for WebM Live
Streams. It also updates the documentation and adds a fate test to
verify the behavior of the new muxer flag.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'acbe15a99f158dbb0edb837fb6557171dc4376d4':
fate: Add test for DCA XLL
Conflicts:
tests/fate/audio.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Regression test for the bug from trac ticket #4359 fixed in commit efff3854
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '62139b14e621f096d0f8ed90920d042b92867e40':
fate: Specify the idct to use for the aic-oddsize test
Conflicts:
tests/fate/video.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
