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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
