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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
