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