Re: [FFmpeg-devel] [PATCH] api-h264-test: build with another api test
On Sun, Jun 28, 2015 at 06:55:45PM +0200, wm4 wrote: [...] 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.) There is also a small code I wrote a while ago that might be helpful. It's attached to this mail (I didn't take the time to rebase it, but it should be straightforward). -- Clément B. From cda6011f4b98515ab27983dc7f5351c037795f88 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?= clem...@stupeflix.com Date: Thu, 12 Dec 2013 14:54:25 +0100 Subject: [PATCH] WIP: seek/playback fuzz --- configure | 2 + doc/Makefile| 1 + doc/examples/Makefile | 1 + doc/examples/playbackfuzz.c | 333 4 files changed, 337 insertions(+) create mode 100644 doc/examples/playbackfuzz.c diff --git a/configure b/configure index 12b2da5..bf8c328 100755 --- a/configure +++ b/configure @@ -1315,6 +1315,7 @@ EXAMPLE_LIST= metadata_example muxing_example remuxing_example +playbackfuzz_example resampling_audio_example scaling_video_example transcode_aac_example @@ -2610,6 +2611,7 @@ filtering_video_example_deps=avfilter avcodec avformat avutil metadata_example_deps=avformat avutil muxing_example_deps=avcodec avformat avutil swscale remuxing_example_deps=avcodec avformat avutil +playbackfuzz_example_deps=avcodec avformat avutil swresample swscale resampling_audio_example_deps=avutil swresample scaling_video_example_deps=avutil swscale transcode_aac_example_deps=avcodec avformat swresample diff --git a/doc/Makefile b/doc/Makefile index 2502922..e92a826 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -47,6 +47,7 @@ DOC_EXAMPLES-$(CONFIG_FILTERING_VIDEO_EXAMPLE) += filtering_video DOC_EXAMPLES-$(CONFIG_METADATA_EXAMPLE) += metadata DOC_EXAMPLES-$(CONFIG_MUXING_EXAMPLE)+= muxing DOC_EXAMPLES-$(CONFIG_REMUXING_EXAMPLE) += remuxing +DOC_EXAMPLES-$(CONFIG_PLAYBACKFUZZ_EXAMPLE) += playbackfuzz DOC_EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE) += resampling_audio DOC_EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video DOC_EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac diff --git a/doc/examples/Makefile b/doc/examples/Makefile index 07251fe..f3a3415 100644 --- a/doc/examples/Makefile +++ b/doc/examples/Makefile @@ -20,6 +20,7 @@ EXAMPLES= avio_reading \ metadata \ muxing \ remuxing \ +playbackfuzz \ resampling_audio \ scaling_video \ transcode_aac \ diff --git a/doc/examples/playbackfuzz.c b/doc/examples/playbackfuzz.c new file mode 100644 index 000..c2d20fc --- /dev/null +++ b/doc/examples/playbackfuzz.c @@ -0,0 +1,333 @@ +/* + * Copyright (c) 2012 Stefano Sabatini + * Copyright (c) 2013 Clément Bœsch + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the Software), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE
Re: [FFmpeg-devel] [PATCH] api-h264-test: build with another api test
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
Re: [FFmpeg-devel] [PATCH] api-h264-test: build with another api test
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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] api-h264-test: build with another api test
On Sun, 28 Jun 2015 17:46:48 +0100 Kieran Kunhya kier...@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.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] api-h264-test: build with another api test
On Sun, Jun 28, 2015 at 01:50:25AM +0300, Ludmila Glinskih 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 applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] api-h264-test: build with another api test
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
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 5380a2a..993ec09 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -547,7 +547,6 @@ TESTPROGS = seek
\
url \
TESTPROGS-$(CONFIG_NETWORK) += noproxy
-TESTPROGS-yes+= api-h264
TESTPROGS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpdh
TOOLS = aviocat \
diff --git a/libavformat/api-h264-test.c b/libavformat/api-h264-test.c
deleted file mode 100644
index 4d2a5b0..000
--- a/libavformat/api-h264-test.c
+++ /dev/null
@@ -1,183 +0,0 @@
-/*
- * Copyright (c) 2015 Ludmila Glinskih
- *
- * Permission is hereby granted, free of charge, to any person obtaining a copy
- * of this software and associated documentation files (the Software), to
deal
- * in the Software without restriction, including without limitation the rights
- * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
- * copies of the Software, and to permit persons to whom the Software is
- * furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
- * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
- * THE SOFTWARE.
- */
-
-/**
- * H264 codec test.
- */
-
-#include libavutil/adler32.h
-#include libavcodec/avcodec.h
-#include libavformat/avformat.h
-#include libavutil/imgutils.h
-
-static int video_decode_example(const char *input_filename)
-{
-AVCodec *codec = NULL;
-AVCodecContext *origin_ctx = NULL, *ctx= NULL;
-AVFrame *fr = NULL;
-uint8_t *byte_buffer = NULL;
-AVPacket pkt;
-AVFormatContext *fmt_ctx = NULL;
-int number_of_written_bytes;
-int video_stream;
-int get_frame = 0;
-int byte_buffer_size;
-int i = 0;
-int result;
-
-result = avformat_open_input(fmt_ctx, input_filename, NULL, NULL);
-if (result 0) {
-av_log(NULL, AV_LOG_ERROR, Can't open file\n);
-return result;
-}
-
-result = avformat_find_stream_info(fmt_ctx, NULL);
-if (result 0) {
-av_log(NULL, AV_LOG_ERROR, Can't get stream info\n);
-return result;
-}
-
-video_stream = av_find_best_stream(fmt_ctx, AVMEDIA_TYPE_VIDEO, -1, -1,
NULL, 0);
-if (video_stream 0) {
- av_log(NULL, AV_LOG_ERROR, Can't find video stream in input file\n);
- return -1;
-}
-
-origin_ctx = fmt_ctx-streams[video_stream]-codec;
-
-codec = avcodec_find_decoder(origin_ctx-codec_id);
-if (!codec) {
-av_log(NULL, AV_LOG_ERROR, Can't find decoder\n);
-return -1;
-}
-
-ctx = avcodec_alloc_context3(codec);
-if (!ctx) {
-av_log(NULL, AV_LOG_ERROR, Can't allocate decoder context\n);
-return AVERROR(ENOMEM);
-}
-
-result = avcodec_copy_context(ctx, origin_ctx);
-if (result) {
-av_log(NULL, AV_LOG_ERROR, Can't copy decoder context\n);
-return result;
-}
-
-result = avcodec_open2(ctx, codec, NULL);
-if (result 0) {
-av_log(ctx, AV_LOG_ERROR, Can't open decoder\n);
-return result;
-}
-
-fr = av_frame_alloc();
-if (!fr) {
-av_log(NULL, AV_LOG_ERROR, Can't allocate frame\n);
-return AVERROR(ENOMEM);
-}
-
-byte_buffer_size = av_image_get_buffer_size(ctx-pix_fmt, ctx-width,
ctx-height, 16);
-byte_buffer = av_malloc(byte_buffer_size);
-if (!byte_buffer) {
-av_log(NULL, AV_LOG_ERROR, Can't allocate buffer\n);
-return AVERROR(ENOMEM);
-}
-
-printf(#tb %d: %d/%d\n, video_stream,
fmt_ctx-streams[video_stream]-time_base.num,
fmt_ctx-streams[video_stream]-time_base.den);
-i = 0;
-av_init_packet(pkt);
-while (av_read_frame(fmt_ctx, pkt) = 0) {
-if (pkt.stream_index == video_stream) {
-get_frame = 0;
-
