[FFmpeg-devel] [PATCH] avfilter/vf_idet: Fixes issue with idet not flushing last frame.
Uses a similar approach as vf_yadif to flush the last frame in idet.
Quick test with 50 frames from vsynth1:
./ffmpeg.old -i fate-suite/ffmpeg-synthetic/vsynth1/%02d.pgm -vf idet -f mp4 -y
/dev/null 21 | grep Multi
(gives) [Parsed_idet_0 @ 0x261ebb0] Multi frame detection: TFF:0 BFF:0
Progressive:48 Undetermined:1
./ffmpeg -i fate-suite/ffmpeg-synthetic/vsynth1/%02d.pgm -vf idet -f mp4 -y
/dev/null 21 | grep Multi
(gives) [Parsed_idet_0 @ 0x35a0bb0] Multi frame detection: TFF:0 BFF:0
Progressive:49 Undetermined:1
Fate tests have been updated.
(In testing, it seems this filter will also need a subsequent patch for single
frame input)
Signed-off-by: Neil Birkbeck neil.birkb...@gmail.com
---
libavfilter/vf_idet.c | 31 +++
libavfilter/vf_idet.h | 1 +
tests/ref/fate/filter-idet | 2 +-
3 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_idet.c b/libavfilter/vf_idet.c
index 339f4a6..b9c4070 100644
--- a/libavfilter/vf_idet.c
+++ b/libavfilter/vf_idet.c
@@ -191,6 +191,35 @@ static int filter_frame(AVFilterLink *link, AVFrame
*picref)
return ff_filter_frame(ctx-outputs[0], av_frame_clone(idet-cur));
}
+static int request_frame(AVFilterLink *link)
+{
+AVFilterContext *ctx = link-src;
+IDETContext *idet = ctx-priv;
+
+do {
+int ret;
+
+if (idet-eof)
+return AVERROR_EOF;
+
+ret = ff_request_frame(link-src-inputs[0]);
+
+if (ret == AVERROR_EOF idet-cur) {
+AVFrame *next = av_frame_clone(idet-next);
+
+if (!next)
+return AVERROR(ENOMEM);
+
+filter_frame(link-src-inputs[0], next);
+idet-eof = 1;
+} else if (ret 0) {
+return ret;
+}
+} while (!idet-cur);
+
+return 0;
+}
+
static av_cold void uninit(AVFilterContext *ctx)
{
IDETContext *idet = ctx-priv;
@@ -253,6 +282,7 @@ static av_cold int init(AVFilterContext *ctx)
{
IDETContext *idet = ctx-priv;
+idet-eof = 0;
idet-last_type = UNDETERMINED;
memset(idet-history, UNDETERMINED, HIST_SIZE);
@@ -279,6 +309,7 @@ static const AVFilterPad idet_outputs[] = {
.name = default,
.type = AVMEDIA_TYPE_VIDEO,
.config_props = config_output,
+.request_frame = request_frame
},
{ NULL }
};
diff --git a/libavfilter/vf_idet.h b/libavfilter/vf_idet.h
index ef29fff..57332df 100644
--- a/libavfilter/vf_idet.h
+++ b/libavfilter/vf_idet.h
@@ -50,6 +50,7 @@ typedef struct {
ff_idet_filter_func filter_line;
const AVPixFmtDescriptor *csp;
+int eof;
} IDETContext;
void ff_idet_init_x86(IDETContext *idet, int for_16b);
diff --git a/tests/ref/fate/filter-idet b/tests/ref/fate/filter-idet
index f1396c5..2f9f11c 100644
--- a/tests/ref/fate/filter-idet
+++ b/tests/ref/fate/filter-idet
@@ -1 +1 @@
-idet1790336872e844c867a53150b8ee8810
+idet005e6ddc8a5daf11cf866a1ec76c2572
--
2.1.0.rc2.206.gedb03e5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add build tree's directories to rpath
Le decadi 30 vendémiaire, an CCXXIII, Lukasz Marek a écrit :
Building with static link is much slower.
I agree patch is wrong, it could be controlled by separate option, just
for devel, but nvm.
It can be controlled by LD_LIBRARY_PATH, as Derek pointed out. I use this
(zsh):
libs=($src/lib*(/:t))
ld_library_path=($build/${^libs})
export LD_LIBRARY_PATH=${(j.:.)ld_library_path}
Note that what you proposed could devolve into a security issue for people
building in /tmp or similar directories: once the build dir has been
cleaned, any user can create it and hijack all users' ffmpeg sessions.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] opw at ffmpeg mail alias
Michael Niedermayer michaelni at gmx.at writes: does any mentor want to be added to the opw at ffmpeg alias if so, tell me and ill add you Is there an archive of this mailing list? (Or is this no mailing list?) Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] matroskadec: execute seekheads recursively
On Oct 21, 2014, at 19:19, Carl Eugen Hoyos ceho...@ag.or.at wrote: Rodger Combs rodger.combs at gmail.com writes: This fixes https://trac.ffmpeg.org/ticket/3934 but I'm not sure if there was a good reason for this to be here to begin with. Perhaps a protection against infinite recursion (though I believe EBML_MAX_DEPTH serves that purpose to some degree)? Is all this related to ticket #2263? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Yes. That sample (seekhead-at-end.mkv) seeks slowly because we don't execute seekheads recursively, and is fixed by this patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: Fix cluster parsing loop which gathers seek information
On Oct 21, 2014, at 21:38, Michael Niedermayer michae...@gmx.at wrote:
Fixes Ticket2263
Fixes Ticket3934
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/matroskadec.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index b742319..2ef3222 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2921,11 +2921,11 @@ static int matroska_read_seek(AVFormatContext *s, int
stream_index,
goto err;
timestamp = FFMAX(timestamp, st-index_entries[0].timestamp);
-if ((index = av_index_search_timestamp(st, timestamp, flags)) 0) {
+if ((index = av_index_search_timestamp(st, timestamp, flags)) 0 ||
index == st-nb_index_entries - 1) {
avio_seek(s-pb, st-index_entries[st-nb_index_entries - 1].pos,
SEEK_SET);
matroska-current_id = 0;
-while ((index = av_index_search_timestamp(st, timestamp, flags))
0) {
+while ((index = av_index_search_timestamp(st, timestamp, flags)) 0
|| index == st-nb_index_entries - 1) {
matroska_clear_queue(matroska);
if (matroska_parse_cluster(matroska) 0)
break;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Looks good to me, and does fix the problem for my files.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] How to deal with libavfilter buffer overflows?
Le decadi 30 vendémiaire, an CCXXIII, Stefano Sabatini a écrit : $ ffmpeg -f lavfi -i testsrc=d=10, split[t0][t1]; [t0]select='gte(t,5)',setpts=PTS-STARTPTS[s0]; [t1] select='lt(t,5)', setpts=PTS-STARTPTS[s1]; [s0][s1] concat -y outtest.mp4 [...] Input #0, lavfi, from 'testsrc=d=10, split[t0][t1]; [t0]select='gte(t,5)',setpts=PTS-STARTPTS[s0]; [t1] select='lt(t,5)', setpts=PTS-STARTPTS[s1]; [s0][s1] concat': Duration: N/A, start: 0.00, bitrate: N/A Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 1000k tbn, 1000k tbc [...] Output #0, mp4, to 'outtest.mp4': Metadata: encoder : Lavf56.9.101 Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv444p, 320x240 [SAR 1:1 DAR 4:3], q=-1--1, 25 fps, 12800 tbn, 25 tbc Metadata: encoder : Lavc56.8.102 libx264 Stream mapping: Stream #0:0 - #0:0 (rawvideo (native) - h264 (libx264)) Press [q] to stop, [?] for help [out @ 0x3140560] 100 buffers queued in out, something may be wrong. frame= 125 fps=0.0 q=-1.0 Lsize= 25kB time=00:00:04.92 bitrate= 42.4kbits/s video:23kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 9.620967% I frequently stumble upon situations when buffer overflows happen, and they are usually a showstopper in many applications. For example when recombining streams with the concat filter, or when overlaying. The output is usually playable but misses audio or video frames. For example in the case above, the command is trying to switch order of the two input parts, but only the second part is displayed and the user is left with the vague message something may be wrong. So the current buffering system sometimes fails, and the user has no clue to understand where the problem lies. I want at least to improve diagnostics, but I want to listen about other developers experience first, and if you have ideas to tackle such issues. Hi. I am well aware of the problem too, and actually I have recently started writing a summary to try address it, along with the other problems of the current lavfi API. There are several underlying issues that are raised by your example: * You have AB, and you want to split and merge it into BA, but you only get B: it looks like it is just a bug. The issue disappears if I test with ffmpeg -lavfi filter instead of ffmpeg -f lavfi -i filter. I have yet to fully understand if the bug is in lavd/lavfi or in lavfi itself, but even in the former case, there is still the problem that the API is almost impossible to use correctly. * Apart from this bug, this command works, but that is a bit of luck. Someone raised the input buffer queue for concat to 256, and your graph requires 128. The warning you see is just a warning. But if you were to raise the duration of the first segment to something above 256 frames, it would indeed fail. The message to look for is Buffer queue overflow, dropping., not 100 buffers queued in output stream. * You have AB from a non-replayable input and you want BA. That can not work reliably. If your input were replayable, you could replay it as A1B1 and A2B2 and produce B2A1. But since it is not replayable, you need to buffer all A as decoded frames in memory. In this particular case, that is 5×25×320×240×3 = 27 Mo, still acceptable. But imagine the same thing with a full-HD credits sequence: 5×90×1920×1080×3/2 = 1.3 Go. When it has already eaten half a gigaoctet of memory, ffmpeg/lavfi can only guess whether this is expected and the memory consumption will soon stop or if the graph has a bug (arithmetic mistake in setpts, links connected to the wrong pad) that makes it eat memory indefinitely. Since the second case is likely to lead to memory and swap exhaustion, making the host machine unusable, ffmpeg should not attempt it without explicit user consent. You can usually give that user consent by inserting the fifo filter somewhere. In this particular case, inserting fifo at the s1 link does the trick. We could enhance the Buffer queue overflow message to print the exact link name where it happens, so the user can know where the fifo is needed. But that is not a very good solution because fifos are dangerous too. The solution I consider to propose involves moving the FIFO service directly into the framework. That would allow a few goodies, such as global allocation of the queue and statistics. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: Fix cluster parsing loop which gathers seek information
On Wed, Oct 22, 2014 at 06:09:10AM -0500, Rodger Combs wrote:
On Oct 21, 2014, at 21:38, Michael Niedermayer michae...@gmx.at wrote:
Fixes Ticket2263
Fixes Ticket3934
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/matroskadec.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index b742319..2ef3222 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2921,11 +2921,11 @@ static int matroska_read_seek(AVFormatContext *s,
int stream_index,
goto err;
timestamp = FFMAX(timestamp, st-index_entries[0].timestamp);
-if ((index = av_index_search_timestamp(st, timestamp, flags)) 0) {
+if ((index = av_index_search_timestamp(st, timestamp, flags)) 0 ||
index == st-nb_index_entries - 1) {
avio_seek(s-pb, st-index_entries[st-nb_index_entries - 1].pos,
SEEK_SET);
matroska-current_id = 0;
-while ((index = av_index_search_timestamp(st, timestamp, flags))
0) {
+while ((index = av_index_search_timestamp(st, timestamp, flags))
0 || index == st-nb_index_entries - 1) {
matroska_clear_queue(matroska);
if (matroska_parse_cluster(matroska) 0)
break;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Looks good to me, and does fix the problem for my files.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] How to deal with libavfilter buffer overflows?
On Wed, Oct 22, 2014 at 01:39:07PM +0200, Nicolas George wrote: Le decadi 30 vendémiaire, an CCXXIII, Stefano Sabatini a écrit : $ ffmpeg -f lavfi -i testsrc=d=10, split[t0][t1]; [t0]select='gte(t,5)',setpts=PTS-STARTPTS[s0]; [t1] select='lt(t,5)', setpts=PTS-STARTPTS[s1]; [s0][s1] concat -y outtest.mp4 [...] Input #0, lavfi, from 'testsrc=d=10, split[t0][t1]; [t0]select='gte(t,5)',setpts=PTS-STARTPTS[s0]; [t1] select='lt(t,5)', setpts=PTS-STARTPTS[s1]; [s0][s1] concat': Duration: N/A, start: 0.00, bitrate: N/A Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 1000k tbn, 1000k tbc [...] Output #0, mp4, to 'outtest.mp4': Metadata: encoder : Lavf56.9.101 Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv444p, 320x240 [SAR 1:1 DAR 4:3], q=-1--1, 25 fps, 12800 tbn, 25 tbc Metadata: encoder : Lavc56.8.102 libx264 Stream mapping: Stream #0:0 - #0:0 (rawvideo (native) - h264 (libx264)) Press [q] to stop, [?] for help [out @ 0x3140560] 100 buffers queued in out, something may be wrong. frame= 125 fps=0.0 q=-1.0 Lsize= 25kB time=00:00:04.92 bitrate= 42.4kbits/s video:23kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 9.620967% I frequently stumble upon situations when buffer overflows happen, and they are usually a showstopper in many applications. For example when recombining streams with the concat filter, or when overlaying. The output is usually playable but misses audio or video frames. For example in the case above, the command is trying to switch order of the two input parts, but only the second part is displayed and the user is left with the vague message something may be wrong. So the current buffering system sometimes fails, and the user has no clue to understand where the problem lies. I want at least to improve diagnostics, but I want to listen about other developers experience first, and if you have ideas to tackle such issues. Hi. I am well aware of the problem too, and actually I have recently started writing a summary to try address it, along with the other problems of the current lavfi API. There are several underlying issues that are raised by your example: * You have AB, and you want to split and merge it into BA, but you only get B: it looks like it is just a bug. The issue disappears if I test with ffmpeg -lavfi filter instead of ffmpeg -f lavfi -i filter. I have yet to fully understand if the bug is in lavd/lavfi or in lavfi itself, but even in the former case, there is still the problem that the API is almost impossible to use correctly. * Apart from this bug, this command works, but that is a bit of luck. Someone raised the input buffer queue for concat to 256, and your graph requires 128. The warning you see is just a warning. But if you were to raise the duration of the first segment to something above 256 frames, it would indeed fail. The message to look for is Buffer queue overflow, dropping., not 100 buffers queued in output stream. * You have AB from a non-replayable input and you want BA. That can not work reliably. If your input were replayable, you could replay it as A1B1 and A2B2 and produce B2A1. But since it is not replayable, you need to buffer all A as decoded frames in memory. In this particular case, that is 5×25×320×240×3 = 27 Mo, still acceptable. But imagine the same thing with a full-HD credits sequence: 5×90×1920×1080×3/2 = 1.3 Go. When it has already eaten half a gigaoctet of memory, ffmpeg/lavfi can only guess whether this is expected and the memory consumption will soon stop or if the graph has a bug (arithmetic mistake in setpts, links connected to the wrong pad) that makes it eat memory indefinitely. Since the second case is likely to lead to memory and swap exhaustion, making the host machine unusable, ffmpeg should not attempt it without explicit user consent. the fifo/buffer que should grow the ability to buffer frames to disk and to do so using lossless and lossy compression that way much larger delays can be achived with such buffers without exhaustig memory true seek support should be added to the source filters so that one can just specify which sections to play in which order without the need to use large buffers [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: Fix cluster parsing loop which gathers seek information
On Wed, 22 Oct 2014 06:09:10 -0500
Rodger Combs rodger.co...@gmail.com wrote:
On Oct 21, 2014, at 21:38, Michael Niedermayer michae...@gmx.at wrote:
Fixes Ticket2263
Fixes Ticket3934
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/matroskadec.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index b742319..2ef3222 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2921,11 +2921,11 @@ static int matroska_read_seek(AVFormatContext *s,
int stream_index,
goto err;
timestamp = FFMAX(timestamp, st-index_entries[0].timestamp);
-if ((index = av_index_search_timestamp(st, timestamp, flags)) 0) {
+if ((index = av_index_search_timestamp(st, timestamp, flags)) 0 ||
index == st-nb_index_entries - 1) {
avio_seek(s-pb, st-index_entries[st-nb_index_entries - 1].pos,
SEEK_SET);
matroska-current_id = 0;
-while ((index = av_index_search_timestamp(st, timestamp, flags))
0) {
+while ((index = av_index_search_timestamp(st, timestamp, flags))
0 || index == st-nb_index_entries - 1) {
matroska_clear_queue(matroska);
if (matroska_parse_cluster(matroska) 0)
break;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Looks good to me, and does fix the problem for my files.
But it's not a complete fix, or is it?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Finding residuals in h264 decoding in ffmpeg
On Tue, Oct 21, 2014 at 01:11:39PM +0200, Norbert Schmitt wrote: Hello, I am trying to understand how the H.264 Decoder in ffmpeg works and saving data (Macroblock types and motion vectors for example) from the decoding of a H.264 video. I also want to save the residuals for each frame but I cant seem to find them. There is something I am missing. It goes directly from CABAC/CAVLC decoding to pre-loop-filter values as far as I understand it. I already looked in the H264Context struct because most of the other information I want can be found there. If the residuals or the prediction values are stored in a H264Context struct I cannot find out which variable or pointer referes to them. Can someone please point me in the right direction where the residuals and or the predicted values for each frame are stored? look at decode_cabac_residual_internal() and decode_residual() and the related code [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] opw at ffmpeg mail alias
On Wed, Oct 22, 2014 at 08:56:58AM +, Carl Eugen Hoyos wrote: Michael Niedermayer michaelni at gmx.at writes: does any mentor want to be added to the opw at ffmpeg alias if so, tell me and ill add you Is there an archive of this mailing list? (Or is this no mailing list?) its no ML atm, i can create a ML if people want but if we do maybe we should choose a more generic name so we can use it for opw and gsoc as well as any other similar project in the future ffmpeg-mentors maybe ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Outreach program for Women
Hello I am a final year student and developed interest in programming sometimes back.The idea was just to develop an application.In order to do so I searched internet settled on developing a windows app since its resources were abundant.But then,I realized that I need to learn C# and voila!!,I did.I have been practicing it which seems like for a while now and now is the right time to take it to the next step.Is there any way I could contribute to your projects? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] v4l2: setting device parameters early
Hello, this was probably wrong and has caused https://trac.ffmpeg.org/ticket/3517 . Will investigate. Giorgio Vazzana 2014-01-05 17:17 GMT+01:00 Michael Niedermayer michae...@gmx.at: On Sun, Jan 05, 2014 at 12:33:42PM +0100, Federico Simoncelli wrote: Any feedback? looks good, thus applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_idet: Fixes issue with idet not flushing last frame.
Hi,
On Tue, Oct 21, 2014 at 11:40 PM, Neil Birkbeck neil.birkb...@gmail.com
wrote:
Uses a similar approach as vf_yadif to flush the last frame in idet.
Quick test with 50 frames from vsynth1:
./ffmpeg.old -i fate-suite/ffmpeg-synthetic/vsynth1/%02d.pgm -vf idet -f
mp4 -y /dev/null 21 | grep Multi
(gives) [Parsed_idet_0 @ 0x261ebb0] Multi frame detection: TFF:0 BFF:0
Progressive:48 Undetermined:1
./ffmpeg -i fate-suite/ffmpeg-synthetic/vsynth1/%02d.pgm -vf idet -f mp4
-y /dev/null 21 | grep Multi
(gives) [Parsed_idet_0 @ 0x35a0bb0] Multi frame detection: TFF:0 BFF:0
Progressive:49 Undetermined:1
Seems ok.
Note that it seems to be reporting one extra frame always. E.g.:
./ffmpeg -i test.mov -vframes 3 -an -vf idet -f null /dev/null 21 | grep
idet
[Parsed_idet_0 @ 0x7feab8500160] Single frame detection: TFF:0 BFF:0
Progressive:4 Undetermined:0
[Parsed_idet_0 @ 0x7feab8500160] Multi frame detection: TFF:0 BFF:0
Progressive:4 Undetermined:0
or, with 1 frame:
./ffmpeg -i test.mov -vframes 1 -an -vf idet -f null /dev/null 21 | grep
idet
[Parsed_idet_0 @ 0x7fc958600c80] Single frame detection: TFF:0 BFF:0
Progressive:2 Undetermined:0
[Parsed_idet_0 @ 0x7fc958600c80] Multi frame detection: TFF:0 BFF:0
Progressive:2 Undetermined:0
Fate tests have been updated.
(In testing, it seems this filter will also need a subsequent patch for
single frame input)
Signed-off-by: Neil Birkbeck neil.birkb...@gmail.com
---
libavfilter/vf_idet.c | 31 +++
libavfilter/vf_idet.h | 1 +
tests/ref/fate/filter-idet | 2 +-
3 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_idet.c b/libavfilter/vf_idet.c
index 339f4a6..b9c4070 100644
--- a/libavfilter/vf_idet.c
+++ b/libavfilter/vf_idet.c
@@ -191,6 +191,35 @@ static int filter_frame(AVFilterLink *link, AVFrame
*picref)
return ff_filter_frame(ctx-outputs[0], av_frame_clone(idet-cur));
}
+static int request_frame(AVFilterLink *link)
+{
+AVFilterContext *ctx = link-src;
+IDETContext *idet = ctx-priv;
+
+do {
+int ret;
+
+if (idet-eof)
+return AVERROR_EOF;
+
+ret = ff_request_frame(link-src-inputs[0]);
+
+if (ret == AVERROR_EOF idet-cur) {
+AVFrame *next = av_frame_clone(idet-next);
+
+if (!next)
+return AVERROR(ENOMEM);
+
+filter_frame(link-src-inputs[0], next);
+idet-eof = 1;
+} else if (ret 0) {
+return ret;
+}
+} while (!idet-cur);
+
+return 0;
+}
+
static av_cold void uninit(AVFilterContext *ctx)
{
IDETContext *idet = ctx-priv;
@@ -253,6 +282,7 @@ static av_cold int init(AVFilterContext *ctx)
{
IDETContext *idet = ctx-priv;
+idet-eof = 0;
idet-last_type = UNDETERMINED;
memset(idet-history, UNDETERMINED, HIST_SIZE);
@@ -279,6 +309,7 @@ static const AVFilterPad idet_outputs[] = {
.name = default,
.type = AVMEDIA_TYPE_VIDEO,
.config_props = config_output,
+.request_frame = request_frame
},
{ NULL }
};
diff --git a/libavfilter/vf_idet.h b/libavfilter/vf_idet.h
index ef29fff..57332df 100644
--- a/libavfilter/vf_idet.h
+++ b/libavfilter/vf_idet.h
@@ -50,6 +50,7 @@ typedef struct {
ff_idet_filter_func filter_line;
const AVPixFmtDescriptor *csp;
+int eof;
} IDETContext;
void ff_idet_init_x86(IDETContext *idet, int for_16b);
diff --git a/tests/ref/fate/filter-idet b/tests/ref/fate/filter-idet
index f1396c5..2f9f11c 100644
--- a/tests/ref/fate/filter-idet
+++ b/tests/ref/fate/filter-idet
@@ -1 +1 @@
-idet1790336872e844c867a53150b8ee8810
+idet005e6ddc8a5daf11cf866a1ec76c2572
--
2.1.0.rc2.206.gedb03e5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Outreach program for Women
On Wed, Oct 22, 2014 at 07:33:45PM +0530, Geetika Batra wrote: Hello I am a final year student and developed interest in programming sometimes back.The idea was just to develop an application.In order to do so I searched internet settled on developing a windows app since its resources were abundant.But then,I realized that I need to learn C# and voila!!,I did.I have been practicing it which seems like for a while now and now is the right time to take it to the next step.Is there any way I could contribute to your projects? FFmpeg is written in C not C# though maybe you want to write a GUI to some of the tools, but time is a bit short with the deadlines of OPW also passing a qualification task is mandatory, which requires submiting a patch, and passing review, which generally requires multiple iterations. So if you think you can pass qualification before oct 31 then sure you can try to submit an application really quickly before its deadline today. Also note, we might end up having more qualified students than slots on the 31st ... Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: avoid endlessly reading from one input while another is unavailable
Le primidi 1er brumaire, an CCXXIII, Michael Niedermayer a écrit : Testcase in Ticket 4051 Signed-off-by: Michael Niedermayer michae...@gmx.at --- ffmpeg.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) I am not entirely sure this will not break a few corner cases, but it looks more correct than the current version. There are still a few unsatisfactory cases, but they require more complex handling. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_idet: Fixes issue with idet not flushing last frame.
On Wed, Oct 22, 2014 at 7:43 AM, Pascal Massimino pascal.massim...@gmail.com wrote: Hi, On Tue, Oct 21, 2014 at 11:40 PM, Neil Birkbeck neil.birkb...@gmail.com wrote: Uses a similar approach as vf_yadif to flush the last frame in idet. Quick test with 50 frames from vsynth1: ./ffmpeg.old -i fate-suite/ffmpeg-synthetic/vsynth1/%02d.pgm -vf idet -f mp4 -y /dev/null 21 | grep Multi (gives) [Parsed_idet_0 @ 0x261ebb0] Multi frame detection: TFF:0 BFF:0 Progressive:48 Undetermined:1 ./ffmpeg -i fate-suite/ffmpeg-synthetic/vsynth1/%02d.pgm -vf idet -f mp4 -y /dev/null 21 | grep Multi (gives) [Parsed_idet_0 @ 0x35a0bb0] Multi frame detection: TFF:0 BFF:0 Progressive:49 Undetermined:1 Seems ok. Note that it seems to be reporting one extra frame always. E.g.: ./ffmpeg -i test.mov -vframes 3 -an -vf idet -f null /dev/null 21 | grep idet [Parsed_idet_0 @ 0x7feab8500160] Single frame detection: TFF:0 BFF:0 Progressive:4 Undetermined:0 [Parsed_idet_0 @ 0x7feab8500160] Multi frame detection: TFF:0 BFF:0 Progressive:4 Undetermined:0 or, with 1 frame: ./ffmpeg -i test.mov -vframes 1 -an -vf idet -f null /dev/null 21 | grep idet [Parsed_idet_0 @ 0x7fc958600c80] Single frame detection: TFF:0 BFF:0 Progressive:2 Undetermined:0 [Parsed_idet_0 @ 0x7fc958600c80] Multi frame detection: TFF:0 BFF:0 Progressive:2 Undetermined:0 it seems the option -vframes is applied after the filter chain. You can check by doing: ffmpeg -i test.mov -vframes 1 -vf showinfo,idet,showinfo -f null /dev/null 21 | grep Parsed_showinfo_0 [Parsed_showinfo_0 @ 0x3643860] n:0 pts:4 pts_time:4.4e-05 pos:564959 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:1 type:I checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:1 pts:3758 pts_time:0.0417556 pos:565077 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:B checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:2 pts:7512 pts_time:0.0834667 pos:565094 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:B checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:3 pts:11265 pts_time:0.125167 pos:565058 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:P checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:4 pts:15019 pts_time:0.166878 pos:565131 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:B checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:5 pts:18773 pts_time:0.208589 pos:565148 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:B checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:6 pts:22527 pts_time:0.2503 pos:565111 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:P checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:7 pts:26280 pts_time:0.292 pos:565184 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:B checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:8 pts:30034 pts_time:0.333711 pos:565201 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:B checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:9 pts:33788 pts_time:0.375422 pos:565165 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:P checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:10 pts:37542 pts_time:0.417133 pos:565237 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:B checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:11 pts:41295 pts_time:0.458833 pos:573273 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:B checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:12 pts:45049 pts_time:0.500544 pos:565218 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:P checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:13 pts:48803 pts_time:0.542256 pos:573309 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:B checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] [Parsed_showinfo_0 @ 0x3643860] n:14 pts:56310 pts_time:0.625667 pos:573290 fmt:yuv420p sar:0/1 s:640x360 i:P iskey:0 type:P checksum:A1E65077 plane_checksum:[A0094348 02828690 02828690] and you will see that more than 1 frame are injected in the filter. but if you look at the output file, it will contains 1 frame only. Fate tests have been updated. (In testing, it seems this filter will also need a subsequent patch for single frame input) Signed-off-by: Neil Birkbeck neil.birkb...@gmail.com --- libavfilter/vf_idet.c | 31 +++ libavfilter/vf_idet.h | 1 + tests/ref/fate/filter-idet | 2 +- 3 files changed, 33 insertions(+), 1 deletion(-) diff --git a/libavfilter/vf_idet.c b/libavfilter/vf_idet.c index 339f4a6..b9c4070 100644 ---
Re: [FFmpeg-devel] [PATCH 1/4] ffserver: move configuration code to separate file
Config parsing changeset LGTM. Feel free to push. Bests, -- Reynaldo H. Verdejo Pinochet Open Source Group Samsung Research America / Silicon Valley ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] ffserver_config: clean up variable initialization
On 10/21/2014 07:10 AM, Stefano Sabatini wrote: [..] LGTM. Agree. Bests, -- Reynaldo H. Verdejo Pinochet Open Source Group Samsung Research America / Silicon Valley ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] ffserver_conf: factorize parse function per config tag
Feel free to push after removing the explicit/redundant initialization of FFServerConfig config as Reimar suggested. While you are at this though, can you remove braces on single statement ifs? appreciated. Thanks -- Reynaldo H. Verdejo Pinochet Open Source Group Samsung Research America / Silicon Valley ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] ffserver_config: postpone codec context creation
Hi
On 10/20/2014 06:57 PM, Lukasz Marek wrote:
So far AVCodecContext was created without codec specified.
This causes internal data to not be initialized to defaults.
This commit postpone context creation until all information are gathered.
are/is
Partially fixes #1275
---
ffserver.c| 8 +-
ffserver_config.c | 286
--
ffserver_config.h | 9 +-
3 files changed, 183 insertions(+), 120 deletions(-)
diff --git a/ffserver.c b/ffserver.c
index 22560ce..8c65d12 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -212,8 +212,12 @@ static FFServerConfig config = {
.warnings = 0,
.audio_id = AV_CODEC_ID_NONE,
.video_id = AV_CODEC_ID_NONE,
-.audio_enc = {0},
-.video_enc = {0},
+.video_opts = NULL,
+.video_conf = NULL,
+.audio_opts = NULL,
+.audio_conf = NULL,
+.video_preset = NULL,
+.audio_preset = NULL,
};
Guess you are already considered dropping the explicit initialization
code as Reimaer suggested.
Looks good otherwise. Feel free to push.
Bests,
--
Reynaldo H. Verdejo Pinochet
Open Source Group
Samsung Research America / Silicon Valley
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: avoid endlessly reading from one input while another is unavailable
On Wed, Oct 22, 2014 at 07:52:37PM +0200, Nicolas George wrote: Le primidi 1er brumaire, an CCXXIII, Michael Niedermayer a écrit : Testcase in Ticket 4051 Signed-off-by: Michael Niedermayer michae...@gmx.at --- ffmpeg.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) I am not entirely sure this will not break a few corner cases, but it looks more correct than the current version. ok, applied, i had a similar feeling ... thx There are still a few unsatisfactory cases, but they require more complex handling. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Added STL demuxer and decoder
On Tue, Oct 21, 2014 at 11:04:31PM +0200, Clément Bœsch wrote: [...] So the patch is now queue and will be pushed soon. Patch applied. [...] -- Clément B. pgpugD9HZUuqI.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] ffserver_config: postpone codec context creation
On 22.10.2014 22:05, Reynaldo H. Verdejo Pinochet wrote:
Guess you are already considered dropping the explicit initialization
code as Reimaer suggested.
Looks good otherwise. Feel free to push.
I've attached updated patch.
To save your time:
1. I updated ffserver_apply_stream_config function,
2. added comments in FFServerConfig struct in header (according to
Stefano's remark)
3. in ffserver_parse_config_stream, at the end added:
av_freep(config-video_preset);
av_freep(config-audio_preset);
and checking result of ffserver_apply_stream_config calls
From ca5e53e39254ce8ed205598b6ffc3ef0a3a41138 Mon Sep 17 00:00:00 2001
From: Lukasz Marek lukasz.m.lu...@gmail.com
Date: Sun, 19 Oct 2014 21:29:40 +0200
Subject: [PATCH] ffserver_config: postpone codec context creation
So far AVCodecContext was created without codec specified.
This causes internal data to not be initialized to defaults.
This commit postpone context creation until all information is gathered.
Partially fixes #1275
---
ffserver_config.c | 302 +-
ffserver_config.h | 9 +-
2 files changed, 193 insertions(+), 118 deletions(-)
diff --git a/ffserver_config.c b/ffserver_config.c
index e44cdf7..65b7554 100644
--- a/ffserver_config.c
+++ b/ffserver_config.c
@@ -238,9 +238,8 @@ static void add_codec(FFServerStream *stream, AVCodecContext *av)
st = av_mallocz(sizeof(AVStream));
if (!st)
return;
-st-codec = avcodec_alloc_context3(NULL);
+st-codec = av;
stream-streams[stream-nb_streams++] = st;
-memcpy(st-codec, av, sizeof(AVCodecContext));
}
static enum AVCodecID opt_codec(const char *name, enum AVMediaType type)
@@ -269,12 +268,15 @@ static int ffserver_opt_preset(const char *arg,
FILE *f=NULL;
char filename[1000], tmp[1000], tmp2[1000], line[1000];
int ret = 0;
-AVCodec *codec = avcodec_find_encoder(avctx-codec_id);
+AVCodec *codec = NULL;
+
+if (avctx)
+codec = avcodec_find_encoder(avctx-codec_id);
if (!(f = get_preset_file(filename, sizeof(filename), arg, 0,
codec ? codec-name : NULL))) {
fprintf(stderr, File for preset '%s' not found\n, arg);
-return 1;
+return AVERROR(EINVAL);
}
while(!feof(f)){
@@ -284,18 +286,17 @@ static int ffserver_opt_preset(const char *arg,
e|= sscanf(line, %999[^=]=%999[^\n]\n, tmp, tmp2) - 2;
if(e){
fprintf(stderr, %s: Invalid syntax: '%s'\n, filename, line);
-ret = 1;
+ret = AVERROR(EINVAL);
break;
}
-if(!strcmp(tmp, acodec)){
+if (audio_id !strcmp(tmp, acodec)) {
*audio_id = opt_codec(tmp2, AVMEDIA_TYPE_AUDIO);
-}else if(!strcmp(tmp, vcodec)){
+} else if (video_id !strcmp(tmp, vcodec)){
*video_id = opt_codec(tmp2, AVMEDIA_TYPE_VIDEO);
-}else if(!strcmp(tmp, scodec)){
+} else if(!strcmp(tmp, scodec)) {
/* opt_subtitle_codec(tmp2); */
-}else if(ffserver_opt_default(tmp, tmp2, avctx, type) 0){
+} else if (avctx (ret = ffserver_opt_default(tmp, tmp2, avctx, type)) 0) {
fprintf(stderr, %s: Invalid option or argument: '%s', parsed as '%s' = '%s'\n, filename, line, tmp, tmp2);
-ret = 1;
break;
}
}
@@ -502,6 +503,95 @@ static int ffserver_parse_config_feed(FFServerConfig *config, const char *cmd, c
return 0;
}
+static int ffserver_apply_stream_config(AVCodecContext *enc, const AVDictionary *conf, AVDictionary **opts)
+{
+static const char *error_message = Cannot parse '%s' as number for %s parameter.\n;
+AVDictionaryEntry *e;
+char *tailp;
+int ret = 0;
+
+#define SET_INT_PARAM(factor, param, key) \
+if ((e = av_dict_get(conf, #key, NULL, 0))) { \
+if (!e-value[0]) { \
+av_log(NULL, AV_LOG_ERROR, error_message, e-value, #key); \
+ret = AVERROR(EINVAL); \
+} \
+enc-param = strtol(e-value, tailp, 0); \
+if (factor) enc-param *= (factor); \
+if (tailp[0] || errno) {\
+av_log(NULL, AV_LOG_ERROR, error_message, e-value, #key); \
+ret = AVERROR(errno); \
+} \
+}
+#define SET_DOUBLE_PARAM(factor, param, key)\
+if ((e = av_dict_get(conf, #key, NULL, 0))) { \
+if (!e-value[0]) { \
+av_log(NULL, AV_LOG_ERROR, error_message, e-value, #key); \
+ret = AVERROR(EINVAL); \
+} \
+enc-param = strtod(e-value, tailp);
[FFmpeg-devel] Evolution of lavfi's design and API
[ CCing Anton, as most that is written here also apply to libav too, and this would be a good occasion to try a cross-fork cooperation; if that is not wanted, please let us know so we can drop the cc. ] 1. Problems with the current design 1.1. Mixed input-/output-driven model Currently, lavfi is designed to work in a mixed input-driven and output-driven model. That means the application needs sometimes to add input to buffersources and sometimes request output to buffersinks. This is a bit of a nuisance, because it requires the application to do it properly: adding input on the wrong input or requesting a frame on the wrong output will cause extra memory consumption or latency. With the libav API, it can not work at all since there is no mechanism to determine which input needs a frame in order to proceed. The libav API is clearly designed for a more output-driven implementation, with FIFOs anywhere to prevent input-driven frames to reach unready filters. Unfortunately, since it is impossible from the outside to guess what output will get a frame next, that can cause frames to accumulate anywhere in the filter graph, eating a lot of memory unnecessarily. FFmpeg's API has eliminated FIFOs in favour of queues in filters that need it, but these queues can not be controlled for unusual filter graphs with extreme needs. Also, there still is an implicit FIFO inside buffersink. 1.2. Recursive implementation All work in a filter graph is triggered by recursive invocations of the filters' methods. It makes debugging harder. It also can lead to large stack usage and makes frame- and filter-level multithreading harder to implement. It also prevents some diagnosis from working reliably. 1.3. EOF handling Currently, EOF is propagated only through the return value of the request_frame() method. That means it only works in an output-driven scheme. It also means that it has no timestamp attached to it; this is an issue for filters where the duration of the last frame is relevant, like vf_fps. 1.4. Latency Some filters need to know the timestamp of the next frame in order to know when the current frame will stop and be able to process it: overlay, fps are two examples. These filters will introduce a latency of one input frame that could otherwise be avoided. 1.5. Timestamps Some filters do not care about timestamps at all. Some check and have a proper handling of NOPTS values. Some filters just assume the frames will have timestamps, and possibly make extra assumptions on that: monotony, consistency, etc. That is an inconsistent mess. 1.6. Sparse streams There is a more severe instance of the latency issue when the input comes from an interleaved sparse stream: in that case, waiting for the next frame in order to find the end of the current one may require demuxing a large chunk of input, in turn provoking a lot of activity on other inputs of the graph. 2. Proposed API changes To fix/enhance all these issues, I believe a complete rethink of the scheduling design of the library is necessary. I propose the following changes. Note: some of these changes are not 100% related to the issues I raised, but looked like a good idea while thinking on an API rework. 2.1. AVFrame.duration Add a duration field to AVFrame; if set, it indicates the duration of the frame. Thus, it becomes unnecessary to wait for the next frame to know when the current frame stops, reducing the latency. Another solution would be to add a dedicated function on buffersrc to inject a timestamp for end or activity on a link. That would avoid the need of adding a field to AVFrame. 2.2. Add some fields to AVFilterLink AVFilterLink.pts: current timestamp of the link, i.e. end timestamp of the last forwarede frame, assuming the duration was correct. This is somewhat redundant with the fields in AVFrame, but can carry the information even when there is no actual frame. AVFilterLink.status: if not 0, gives the return status of trying to pass a frame on this link. The typical use would be EOF. 2.3. AVFilterLink.need_ts Add a field to AVFilterLink to specify that the output filter requires reliable timestamps on its input. More precisely, specify how reliable the timestamps need to be: is the duration necessary? do the timestamps need to be monotonic? continuous? For audio streams, consistency between timestamps and the number of samples may also be tested. For video streams, constant frame rate may be enforced, but I am not sure about this one. A fixpts filter should be provided to allow the user to tweak how the timestamps are fixed (change the timestamps to match the duration or change the duration to match the timestamps?). When no explicit filter is
