On 27.05.2016 13:49, Nicolas George wrote:
Le nonidi 9 prairial, an CCXXIV, kl222 a écrit :
Signed-off-by: KangLin <kl...@126.com>
---
doc/filters.texi | 23 +++++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_snapshot.c | 256 ++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 281 insertions(+)
create mode 100644 libavfilter/vf_snapshot.c
diff --git a/doc/filters.texi b/doc/filters.texi
index aa208f1..a75005a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12037,6 +12037,29 @@ in [-30,0] will filter edges. Default value is 0.
If a chroma option is not explicitly set, the corresponding luma value
is set.
+@section snapshot
+
+it can save a snapshot picture. Supports .png, .jpg, .bmp formats
+Snapshot with process_command api.
Can you explain your use case for this filter?
I ask because I am very uncomfortable with filters that perform direct
output instead of producing frames for the rest of the graph. They need to
duplicate the encoding and muxing code, usually with fewer options and
features, and that duplicated code becomes itself a maintenance burden in
case of API changes and such.
+1
The first option I'd be missing here would be some output picture
quality option.
IMHO, a better solution would be some kind of "interactive select" (or just
an option of plain select) filter, and encode its output as image2.
I agree. Adding filter command support to the existing "select" filter
which allows to update the expression string might solve the use-case
and provides more flexibility.
[...]
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
