Hi, On Thu, Sep 15, 2011 at 2:35 PM, Alex Converse <[email protected]> wrote: > 2011/9/15 Måns Rullgård <[email protected]>: >> Alex Converse <[email protected]> writes: >> >>> --- >>> tests/fate.mak | 2 +- >>> tests/ref/fate/ea-tqi-adpcm | 1 - >>> 2 files changed, 1 insertions(+), 2 deletions(-) >>> >>> diff --git a/tests/fate.mak b/tests/fate.mak >>> index a349e5c..a049783 100644 >>> --- a/tests/fate.mak >>> +++ b/tests/fate.mak >>> @@ -93,7 +93,7 @@ fate-ea-tgv-ima-ea-eacs: CMD = framecrc -i >>> $(SAMPLES)/ea-tgv/INTRO8K-partial.TG >>> FATE_TESTS += fate-ea-tgv-ima-ea-sead >>> fate-ea-tgv-ima-ea-sead: CMD = framecrc -i $(SAMPLES)/ea-tgv/INTEL_S.TGV >>> -pix_fmt rgb24 >>> FATE_TESTS += fate-ea-tqi-adpcm >>> -fate-ea-tqi-adpcm: CMD = framecrc -i >>> $(SAMPLES)/ea-wve/networkBackbone-partial.wve >>> +fate-ea-tqi-adpcm: CMD = framecrc -i >>> $(SAMPLES)/ea-wve/networkBackbone-partial.wve -vframes 26 >>> FATE_TESTS += fate-ea-vp60 >>> fate-ea-vp60: CMD = framecrc -i $(SAMPLES)/ea-vp6/g36.vp6 >>> FATE_TESTS += fate-ea-vp61 >>> diff --git a/tests/ref/fate/ea-tqi-adpcm b/tests/ref/fate/ea-tqi-adpcm >>> index c79eed5..4fbc117 100644 >>> --- a/tests/ref/fate/ea-tqi-adpcm >>> +++ b/tests/ref/fate/ea-tqi-adpcm >>> @@ -49,4 +49,3 @@ >>> 0, 144000, 115200, 0x65fd5e60 >>> 1, 144000, 5936, 0x2174304d >>> 0, 150000, 115200, 0x0c256424 >>> -0, 156000, 115200, 0xa9cdd8d2 >>> -- >> >> What bug is this really hiding? >> > > We fall back to a previous frame data if a frame is truncated which is > an implementation detail due to the use of av_fast_malloc(). This > looks kind of funny http://imgur.com/a/PySOc#GXrJ2 , isn't correct and > therefore shouldn't be something we test for.
I agree we shouldn't decode it. I also think we should remove the data from the fate sample, so that the -vframes option is no longer necessary. Is that possible? Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
