[FFmpeg-devel] [PATCH] api-h264-test: build with another api test

[Kieran Kunhya]

> 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?

You are right that the tests can be reused - Ludmila worked on the
simple cases (flac/h264) to learn about the API and how to write
tests.
For various reasons this has taken longer than expected.

The ultimate goal is to have a bunch of simple tests which can be used
to make sure the outputs from the API are the same as from ffmpeg.c
For example, we've seen already that the timestamps are different in
ffmpeg.c vs the API from these tests alone - I'm not entirely sure
what to make of this. Personally I think the outputs should be the
same, ffmpeg.c should not be a special case.

Ludmila is working on new tests that involve seeking to more than one
place based on wm4's request - from what I understand (not doing any
seeking myself) is that ffmpeg.c only seeks once ever. As an API user
it's useful to do multiple seeks, testing something not possible in
ffmpeg.c. Same goes with draw_horiz_band and I would also like to test
other features only available from the API.

Kieran