Re: [libav-devel] FATE dependencies
On Mon, Dec 17, 2012 at 04:34:26PM +0100, Janne Grunau wrote: > On 2012-12-17 15:18:52 +0100, Diego Biurrun wrote: > > On Mon, Dec 17, 2012 at 12:43:35AM +0100, Janne Grunau wrote: > > > On 2012-12-16 23:45:06 +0100, Diego Biurrun wrote: > > > > > > > > There are multiple ways to handle these more general components: > > > > > > > > - have avconv directly depend on some or all of them > > > > > > In configure or just for FATE_AVCONV? The second sounds reasonable > > > > My idea was to have avconv depend on them in configure. Otherwise you > > can hardly run any tests... > > avconv is not just a tool to run tests. Just to pick one of the more > obvious examples: the md5 protocol has very few use cases besides > testing. Disabling it and still using avconv is reasonable. Just let the > avconv fate tests depend on them and use the configure switch to > reenable things required for testing if testing is desired True. Let's settle which parts would be sensible as avconv dependencies and then place the rest in some sort of fate group. > > > > - have a group of "FATE deps" that get enabled automatically > > > > > > what does that mean? making it impossible to disable the file protocol > > > for example? > > > > It could be tied to avconv or tied to a configure switch. > > how is that different from the option above? Not different. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FATE dependencies
On 2012-12-17 15:18:52 +0100, Diego Biurrun wrote: > On Mon, Dec 17, 2012 at 12:43:35AM +0100, Janne Grunau wrote: > > On 2012-12-16 23:45:06 +0100, Diego Biurrun wrote: > > > > > > There are multiple ways to handle these more general components: > > > > > > - have avconv directly depend on some or all of them > > > > In configure or just for FATE_AVCONV? The second sounds reasonable > > My idea was to have avconv depend on them in configure. Otherwise you > can hardly run any tests... avconv is not just a tool to run tests. Just to pick one of the more obvious examples: the md5 protocol has very few use cases besides testing. Disabling it and still using avconv is reasonable. Just let the avconv fate tests depend on them and use the configure switch to reenable things required for testing if testing is desired > > > - have a group of "FATE deps" that get enabled automatically > > > > what does that mean? making it impossible to disable the file protocol > > for example? > > It could be tied to avconv or tied to a configure switch. how is that different from the option above? Janne ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FATE dependencies
On Mon, Dec 17, 2012 at 12:43:35AM +0100, Janne Grunau wrote: > On 2012-12-16 23:45:06 +0100, Diego Biurrun wrote: > > On Fri, Oct 19, 2012 at 07:26:02PM +0200, Diego Biurrun wrote: > > > [...] > > > > I'm mostly done with FATE dependencies and have some 50 patches in > > need of cleaning locally. > > > > There are a bunch of parts required by most or a large number of FATE > > tests. I'm not quite sure how to handle them, here's a list > > > > rawvideo: > > > > decoder, demuxer, encoder > > > > filters: > > > > afifo, anull, fifo, null, resample > > not format? we have quite a few video sample tests which require it, > tests of rgb codecs for example. Ah, I see, avconv depends already on it > inconfigure. afifo, anull, fifo, null might be candidates to always > enable in libavfilter. Anton? > > muxers: > > > > crc, framecrc, framemd5, md5, rawvideo > > > > protocols: > > > > file, md5, pipe > > > > Plus PCM_S16LE muxer and decoder, which is required by a large number of > > audio tests. > > > > There are multiple ways to handle these more general components: > > > > - have avconv directly depend on some or all of them > > In configure or just for FATE_AVCONV? The second sounds reasonable My idea was to have avconv depend on them in configure. Otherwise you can hardly run any tests... > > - just add all these components to individual deps > > that sounds insane > > > - have a group of "FATE deps" that get enabled automatically > > what does that mean? making it impossible to disable the file protocol > for example? It could be tied to avconv or tied to a configure switch. > > - have a group of "FATE deps" that get enabled via a configure switch > > That is a good idea regardlessly. using something like > > .../configure --disable-everything --enable-decoder=h264 \ > --enable-demuxer=h264 --enable-fate-minimal > > and being able to run make fate-h264 would be nice. Exactly that is the goal and I'll achieve it soon. > Having a good test > coverage for a --disable-random is probably also a good idea. Once I'm done with the deps, we can add a random FATE instance. > > - ... > > Then there are obvious groups of tests which share dependency then just > adding the dependency for that group. Sure. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FATE dependencies
On 2012-12-16 23:45:06 +0100, Diego Biurrun wrote: > On Fri, Oct 19, 2012 at 07:26:02PM +0200, Diego Biurrun wrote: > > [...] > > I'm mostly done with FATE dependencies and have some 50 patches in > need of cleaning locally. > > There are a bunch of parts required by most or a large number of FATE > tests. I'm not quite sure how to handle them, here's a list > > rawvideo: > > decoder, demuxer, encoder > > filters: > > afifo, anull, fifo, null, resample not format? we have quite a few video sample tests which require it, tests of rgb codecs for example. Ah, I see, avconv depends already on it inconfigure. afifo, anull, fifo, null might be candidates to always enable in libavfilter. > muxers: > > crc, framecrc, framemd5, md5, rawvideo > > protocols: > > file, md5, pipe > > Plus PCM_S16LE muxer and decoder, which is required by a large number of > audio tests. > > There are multiple ways to handle these more general components: > > - have avconv directly depend on some or all of them In configure or just for FATE_AVCONV? The second sounds reasonable > - just add all these components to individual deps that sounds insane > - have a group of "FATE deps" that get enabled automatically what does that mean? making it impossible to disable the file protocol for example? > - have a group of "FATE deps" that get enabled via a configure switch That is a good idea regardlessly. using something like .../configure --disable-everything --enable-decoder=h264 \ --enable-demuxer=h264 --enable-fate-minimal and being able to run make fate-h264 would be nice. Having a good test coverage for a --disable-random is probably also a good idea. > - ... Then there are obvious groups of tests which share dependency then just adding the dependency for that group. Janne ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FATE dependencies
On Fri, Oct 19, 2012 at 07:26:02PM +0200, Diego Biurrun wrote: > [...] I'm mostly done with FATE dependencies and have some 50 patches in need of cleaning locally. There are a bunch of parts required by most or a large number of FATE tests. I'm not quite sure how to handle them, here's a list rawvideo: decoder demuxer encoder filters: afifo anull fifo null resample muxers: crc framecrc framemd5 md5 rawvideo protocols: file md5 pipe Plus PCM_S16LE muxer and decoder, which is required by a large number of audio tests. There are multiple ways to handle these more general components: - have avconv directly depend on some or all of them - just add all these components to individual deps - have a group of "FATE deps" that get enabled automatically - have a group of "FATE deps" that get enabled via a configure switch - ... Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] FATE dependencies
Good news everyone! Fine-grained dependency infrastructure for FATE tests has arrived. So all we need to do now is mark up all the FATE tests with their dependencies. Volunteers are welcome to help in the effort. It's not particularly difficult for most tests: Just run avprobe on the sample in question and ensure the test using that sample depends on whatever codec / container combination the sample uses. In order to not duplicate work again I suggest we start from different ends of the list of files and/or claim the files here as a reply to this email. Here is the list of files still in need of conversion: aac.mak ac3.mak acodec.mak adpcm.mak alac.mak amrnb.mak amrwb.mak atrac.mak audio.mak avfilter.mak bmp.mak cdxl.mak cover-art.mak dfa.mak dpcm.mak ea.mak fft.mak flac.mak h264.mak image.mak lossless-audio.mak mp3.mak pcm.mak probe.mak prores.mak qtrle.mak real.mak utvideo.mak voice.mak vorbis.mak vpx.mak I claim everything starting with the letter 'a'. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
