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

[wm4]

On Sun, 28 Jun 2015 17:46:48 +0100
Kieran Kunhya <kierank at obe.tv> wrote:

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

That is strange. Though I wouldn't be surprised if either ffmpeg.c or
the muxer API (which is also used for framecrc etc.) messes with the
timestamps.

We should just make sure if the resulting timestamps is what we
expected.

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

From what I know, ffmpeg.c indeed seeks only once. At least I couldn't
find out how to make it seek several times in the same file last I
checked.

Note that here is a seek test in libavformat/seek-test.c. But what I'd
like to be tested is whether decoding from start, and seeking back to a
certain position returns the same result. This tests for example
whether decoder flushing really resets the the entire decoder state.
(It often seems to happen that it does, either by design or by
accident.)