On 24/11/14 08:17, Oleksij Rempel wrote:
Am 24.11.2014 um 00:37 schrieb Vittorio Giovara:
On Sun, Nov 23, 2014 at 11:20 PM, Timothy Gu <timothyg...@gmail.com> wrote:
On Sun, Nov 23, 2014 at 2:59 PM, Vittorio Giovara
<vittorio.giov...@gmail.com> wrote:
---
Using the test the author provided. They are going to be tested on oracle too
before pushing.
Vittorio
tests/fate/audio.mak | 4 +
tests/ref/fate/dss-lp | 737 ++++++++++++++++++++++++++++++++++++++++++++++++++
tests/ref/fate/dss-sp | 334 +++++++++++++++++++++++
3 files changed, 1075 insertions(+)
create mode 100644 tests/ref/fate/dss-lp
create mode 100644 tests/ref/fate/dss-sp
First, the samples are kinda big. The ref for dss-lp is bigger than
all but two tests in fate, one of them doesn't use a sample
(iirfilter) and the other one is an official sample.
yeah they could be limited, but i sent them full up for discussion on
purpose, so that one could spot something like below. Any good
significant value you might suggest?
Second, do you have any idea why the end of dss-lp test ref looks like this?
+0, 143040, 143040, 240, 480, 0x00000000
+0, 143280, 143280, 240, 480, 0x00000000
[dutiful snip]
+0, 176160, 176160, 240, 480, 0x00000000
+0, 176400, 176400, 240, 480, 0x00000000
Is this a bug in the decoder or is it possible to just cut it out?
I'll leave this up to Oleksij :)
Hi,
hm... this container works with static block size. If the stream was
ended, the rest of this block will be filled with "ffff ffff ffff". Are
there a good way to remove it with demuxer?
Marking it as corrupted or trim its duration should be the best.
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
