On Sat, Jun 27, 2015 at 6:50 PM, Ludmila Glinskih <lglins...@gmail.com> wrote:
> Location of api-h264-test changed to special directory for api tests. > --- > libavformat/Makefile | 1 - > libavformat/api-h264-test.c | 183 > -------------------------------------------- > tests/api/Makefile | 1 + > tests/api/api-h264-test.c | 183 > ++++++++++++++++++++++++++++++++++++++++++++ > tests/fate/api.mak | 9 ++- > tests/fate/libavformat.mak | 4 - > 6 files changed, 192 insertions(+), 189 deletions(-) > delete mode 100644 libavformat/api-h264-test.c > create mode 100644 tests/api/api-h264-test.c So I have a more conceptual question, maybe Kieran can help answer this also. Why are these tests called api-$codec tests? I don't see anything flac/h264 specific in these tests so far, and they could basically be reused for any video (h264) or audio (flac) test (for audio: as long as there's an encoder and it's zero-delay). Which then begs the question: if we extend this to multiple codecs with delay and no encoder and so on, aren't we rewriting ffmpeg? So, conceptually, what are we trying to accomplish here? We're not testing the h264/flac api, which is what the name suggests. What _is_ the ultimate goal for these tests? Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
