On 27/03/2024 13:53, Anton Khirnov wrote:
Quoting Tobias Rapp (2024-03-27 13:46:40)
On 27/03/2024 13:06, Stefano Sabatini wrote:
On date Wednesday 2024-03-27 11:51:31 +0100, Tobias Rapp wrote:
Depending on the filters used the filtergraph can produce trailing data
after feeding it the last input frame. Update the example to include the
necessary loop for draining the filtergrap.
Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
doc/examples/decode_filter_video.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/doc/examples/decode_filter_video.c
b/doc/examples/decode_filter_video.c
index 454c192..a57e6df 100644
--- a/doc/examples/decode_filter_video.c
+++ b/doc/examples/decode_filter_video.c
@@ -276,6 +276,25 @@ int main(int argc, char **argv)
}
av_packet_unref(packet);
}
+ if (ret == AVERROR_EOF) {
+ /* signal EOF to the filtergraph */
+ if (av_buffersrc_add_frame_flags(buffersrc_ctx, NULL, 0) < 0) {
+ av_log(NULL, AV_LOG_ERROR, "Error while closing the
filtergraph\n");
+ goto end;
+ }
+
+ /* pull remaining frames from the filtergraph */
+ while (1) {
+ ret = av_buffersink_get_frame(buffersink_ctx, filt_frame);
+ if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
+ break;
how are we supposed to handle the EAGAIN case? Shouldn't this be a
sleep and retry?
Good suggestion. I could add something like usleep(100) upon EAGAIN.
No, EAGAIN from a filter after EOF on all inputs is a bug.
Ok. Also from a second look at the example all the other locations where
EAGAIN is handled do not perform a retry. So adding that would be
orthogonal to this patch, IMHO.
Regards, Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
