On Tue, 5 Apr 2016 at 20:39 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Mon, Apr 04, 2016 at 08:18:47PM +0000, Kieran Kunhya wrote: > > On Mon, 4 Apr 2016 at 18:41 Michael Niedermayer <mich...@niedermayer.cc> > > wrote: > > > > > On Mon, Apr 04, 2016 at 03:26:30PM +0000, Kieran Kunhya wrote: > > > > On Mon, 4 Apr 2016 at 01:43 Michael Niedermayer > <mich...@niedermayer.cc> > > > > wrote: > > > > > > > > > On Sun, Apr 03, 2016 at 04:02:55AM +0200, Michael Niedermayer > wrote: > > > > > > On Sun, Apr 03, 2016 at 12:20:59AM +0200, Michael Niedermayer > wrote: > > > > > > > On Sat, Apr 02, 2016 at 11:14:29PM +0200, wm4 wrote: > > > > > > > > On Sat, 2 Apr 2016 18:01:47 -0300 > > > > > > > > James Almer <jamr...@gmail.com> wrote: > > > > > > > > > > > > > > > > > On 4/2/2016 5:53 PM, wm4 wrote: > > > > > > > > > > On Sat, 2 Apr 2016 22:05:35 +0200 > > > > > > > > > > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > > > > > > > > > > > > > > > > > >> Signed-off-by: Michael Niedermayer > <mich...@niedermayer.cc> > > > > > > > > > >> --- > > > > > > > > > >> tests/fate/demux.mak | 3 + > > > > > > > > > >> tests/ref/fate/ts-opus-demux | 514 > > > > > ++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > >> 2 files changed, 517 insertions(+) > > > > > > > > > >> create mode 100644 tests/ref/fate/ts-opus-demux > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > Maybe you should wait with all these new tests until the > > > codecpar > > > > > > > > > > changes have been merged. > > > > > > > > > > > > > > > > > > Why? None of these new tests should generate conflicts > when the > > > > > > > > > codecpar branch is rebased to current git head. And they > may > > > even > > > > > > > > > reveal new regressions once they are run afterwards. > > > > > > > > > > > > > > > > I'm sure they will reveal regressions, because michaelni > seems > > > to be > > > > > > > > specifically hunting for them. When the branch gets merged, > there > > > > > > > > should be no failing fate tests, so adding such tests would > hold > > > back > > > > > > > > the merge. > > > > > > > > > > > > > > > > While it's normally a good thing to catch such regressions > (and > > > to > > > > > fix > > > > > > > > them before a big thing is merged), the codecpar merge has > been > > > going > > > > > > > > on for weeks. It's holding back merging of other important > > > features > > > > > > > > (like vaapi encoding to name a particularly popular one), and > > > > > there's a > > > > > > > > limit to which extend we can load further work on daemon and > nev. > > > > > > > > > > > > > > > > So I suggest that such arguably less important > tests/regressions > > > are > > > > > > > > applied and fixed later, so that merging can go on and none > of > > > the > > > > > devs > > > > > > > > have to die from stress. > > > > > > > > > > > > > > We can add the tests now and then just disable them in the > merge > > > > > > > if the people working on the merge belive that that is the best > > > choice. > > > > > > > It should make it easier to keep track of issues > > > > > > > > > > > > note, i intend to push these soon > > > > > > if someone objects, please state so > > > > > > > > > > tested with and without codecpar, pass in both cases now > > > > > (so this should not add any stress to anyone) > > > > > > > > > > applied > > > > > > > > > > Where does this 7.1 sample come from? > > > > Kieran > > > > > > it should be a part cut out of > > > http://chui-pas.net/~fun/test-8-7.1.opus.ts > > > > > > > > > > > Has this file been compared with the Opus in TS spec: > > https://wiki.xiph.org/OpusTS > > i think nothing in the fate samples has been compared to any spec > > That doesn't answer the question. *We wrote the spec* so it would be stupid to take this file and assume it's correct when it was made during spec development. Kieran _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
