Re: [FFmpeg-devel] [PATCH v2] Add GBRAP12 pixel format
On Sat, Feb 06, 2016 at 12:36:10AM +, Kieran Kunhya wrote: > Output still looks a bit odd though how can this be reproduced ? > > --- > libavutil/pixdesc.c | 28 > libavutil/pixfmt.h| 4 > libswscale/input.c| 4 > libswscale/swscale_unscaled.c | 3 +++ > libswscale/utils.c| 6 ++ > 5 files changed, 45 insertions(+) change in libavcodec/utils.c are missing see grep GBRP12 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. 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/mp3enc: Assert that the header we assembled is valid
On Fri, Feb 05, 2016 at 10:41:26AM -0500, Ronald S. Bultje wrote: > Hi, > > On Fri, Feb 5, 2016 at 9:34 AM, Hendrik Leppkes wrote: > > > On Fri, Feb 5, 2016 at 3:33 PM, Derek Buitenhuis > > wrote: > > > On 2/5/2016 2:19 PM, Michael Niedermayer wrote: > > >> because the code builds the header a few lines above, i assume > > >> the header we just build is correct > > > > > > Perhaps you could elaborate what CID1351343 is then, in the commit > > > messages. > > > > > > > A Coverity ID, a false positive which we decide to "fix" with an > > assertion instead of marking it as such in the tool? > > > So, I don't mind the patch, that's fine. But the commit message is > misleading. It suggests that there's a bug and that this patch fixes the > bug. That's incorrect. There is no bug, and this patch does not fix > anything. It asserts something, and as asserts go, they don't fix anything, > they just assert (=confirm) expected behaviour. > > So, can we change the commit message to not include the word "fix" or any > other misleading derivative thereof? absolutely, agree do you want to suggest some wording ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] dirac_dwt: Don't pass information in context as arguments
On 6 February 2016 at 03:37, Timothy Gu wrote: > --- > libavcodec/dirac_dwt.c | 13 ++--- > libavcodec/dirac_dwt_template.c | 25 + > 2 files changed, 19 insertions(+), 19 deletions(-) > > LGTM d->temp = (uint8_t *)(((TYPE *)d->temp) + 8); might appear confusing to someone as it modifies the actual pointer but that's okay since the pointer itself is supplied upon DWT init which happens on every single frame (since the wavelet transforms can differ between frames). Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] dirac_dwt: Rename init2 to init
On 6 February 2016 at 03:37, Timothy Gu wrote: > The functions are all private. > --- > libavcodec/dirac_dwt.c | 12 ++-- > libavcodec/dirac_dwt.h | 6 +++--- > libavcodec/dirac_dwt_template.c | 10 +- > libavcodec/diracdec.c | 4 ++-- > 4 files changed, 16 insertions(+), 16 deletions(-) LGTM This probably happened because the unmerged encoder and the decoder were developed at the same time and shared the same file for the transforms (at least initially). Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add metadata filters
Hi,
patch attached.
From c719b95ce84bb1c3db3e6b751d80a840f35726b0 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sat, 6 Feb 2016 11:19:45 +0100
Subject: [PATCH] avfilter: add metadata filters
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 45 ++
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 2 +
libavfilter/f_metadata.c | 211 +++
4 files changed, 260 insertions(+)
create mode 100644 libavfilter/f_metadata.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 664ebe8..54ea63e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8444,6 +8444,51 @@ format=rgb24,mergeplanes=0x000102:yuv444p
@end example
@end itemize
+@section metadata, ametadata
+
+Manipulate frames metadata.
+
+This filter accepts the following options:
+
+@table @option
+@item m
+Set mode of operation of the filter.
+
+Can be one of the following:
+
+@table @samp
+@item select
+If both @code{value} and @code{key} is set, select frame
+which have such metadata. If only @code{key} is set, select
+every frame that have such key in metadata.
+
+@item add
+Add new metadata @code{key} and @code{value}. If key is already available
+do nothing.
+
+@item modify
+Modify value of already present key.
+
+@item delete
+If @code{value} is set, delete only keys that have such value.
+Otherwise, delete key.
+
+@item print
+Print key and value if metadata was found.
+@end table
+
+@item key
+Set key used with all modes, Must be set.
+
+@item value
+Set metadata value which will be used. This option is mandatory for modify
+and add mode.
+
+@item length
+Set length of how much characters of two metadata values need to match to be
+considered same. Default is all available characters.
+@end table
+
@section mpdecimate
Drop frames that do not differ greatly from the previous frame in
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 8ffd693..664c773 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -39,6 +39,7 @@ OBJS-$(CONFIG_AINTERLEAVE_FILTER)+= f_interleave.o
OBJS-$(CONFIG_ALIMITER_FILTER) += af_alimiter.o
OBJS-$(CONFIG_ALLPASS_FILTER)+= af_biquads.o
OBJS-$(CONFIG_AMERGE_FILTER) += af_amerge.o
+OBJS-$(CONFIG_AMETADATA_FILTER) += f_metadata.o
OBJS-$(CONFIG_AMIX_FILTER) += af_amix.o
OBJS-$(CONFIG_ANULL_FILTER) += af_anull.o
OBJS-$(CONFIG_APAD_FILTER) += af_apad.o
@@ -186,6 +187,7 @@ OBJS-$(CONFIG_LUTYUV_FILTER) += vf_lut.o
OBJS-$(CONFIG_MASKEDMERGE_FILTER)+= vf_maskedmerge.o framesync.o
OBJS-$(CONFIG_MCDEINT_FILTER)+= vf_mcdeint.o
OBJS-$(CONFIG_MERGEPLANES_FILTER)+= vf_mergeplanes.o framesync.o
+OBJS-$(CONFIG_METADATA_FILTER) += f_metadata.o
OBJS-$(CONFIG_MPDECIMATE_FILTER) += vf_mpdecimate.o
OBJS-$(CONFIG_NEGATE_FILTER) += vf_lut.o
OBJS-$(CONFIG_NNEDI_FILTER) += vf_nnedi.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index d4d37c9..f56b390 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -59,6 +59,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(ALIMITER, alimiter, af);
REGISTER_FILTER(ALLPASS,allpass,af);
REGISTER_FILTER(AMERGE, amerge, af);
+REGISTER_FILTER(AMETADATA, ametadata, af);
REGISTER_FILTER(AMIX, amix, af);
REGISTER_FILTER(ANEQUALIZER,anequalizer,af);
REGISTER_FILTER(ANULL, anull, af);
@@ -207,6 +208,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(MASKEDMERGE,maskedmerge,vf);
REGISTER_FILTER(MCDEINT,mcdeint,vf);
REGISTER_FILTER(MERGEPLANES,mergeplanes,vf);
+REGISTER_FILTER(METADATA, metadata, vf);
REGISTER_FILTER(MPDECIMATE, mpdecimate, vf);
REGISTER_FILTER(NEGATE, negate, vf);
REGISTER_FILTER(NNEDI, nnedi, vf);
diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c
new file mode 100644
index 000..e248322
--- /dev/null
+++ b/libavfilter/f_metadata.c
@@ -0,0 +1,211 @@
+/*
+ * Copyright (c) 2016 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg;
Re: [FFmpeg-devel] [PATCH] avformat/mp3enc: Assert that the header we assembled is valid
Hi, On Sat, Feb 6, 2016 at 5:32 AM, Michael Niedermayer wrote: > On Fri, Feb 05, 2016 at 10:41:26AM -0500, Ronald S. Bultje wrote: > > Hi, > > > > On Fri, Feb 5, 2016 at 9:34 AM, Hendrik Leppkes > wrote: > > > > > On Fri, Feb 5, 2016 at 3:33 PM, Derek Buitenhuis > > > wrote: > > > > On 2/5/2016 2:19 PM, Michael Niedermayer wrote: > > > >> because the code builds the header a few lines above, i assume > > > >> the header we just build is correct > > > > > > > > Perhaps you could elaborate what CID1351343 is then, in the commit > > > > messages. > > > > > > > > > > A Coverity ID, a false positive which we decide to "fix" with an > > > assertion instead of marking it as such in the tool? > > > > > > So, I don't mind the patch, that's fine. But the commit message is > > misleading. It suggests that there's a bug and that this patch fixes the > > bug. That's incorrect. There is no bug, and this patch does not fix > > anything. It asserts something, and as asserts go, they don't fix > anything, > > they just assert (=confirm) expected behaviour. > > > > So, can we change the commit message to not include the word "fix" or any > > other misleading derivative thereof? > > absolutely, agree > do you want to suggest some wording ? I like Hendrik's earlier wording, something along the lines of "Makes false-positive CID1351343 disappear", or "Related to false-positive CID1351343". Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mp3enc: Assert that the header we assembled is valid
On 2/6/2016 10:42 AM, Ronald S. Bultje wrote: > Hi, > > On Sat, Feb 6, 2016 at 5:32 AM, Michael Niedermayer > wrote: > >> On Fri, Feb 05, 2016 at 10:41:26AM -0500, Ronald S. Bultje wrote: >>> Hi, >>> >>> On Fri, Feb 5, 2016 at 9:34 AM, Hendrik Leppkes >> wrote: >>> On Fri, Feb 5, 2016 at 3:33 PM, Derek Buitenhuis wrote: > On 2/5/2016 2:19 PM, Michael Niedermayer wrote: >> because the code builds the header a few lines above, i assume >> the header we just build is correct > > Perhaps you could elaborate what CID1351343 is then, in the commit > messages. > A Coverity ID, a false positive which we decide to "fix" with an assertion instead of marking it as such in the tool? >>> >>> >>> So, I don't mind the patch, that's fine. But the commit message is >>> misleading. It suggests that there's a bug and that this patch fixes the >>> bug. That's incorrect. There is no bug, and this patch does not fix >>> anything. It asserts something, and as asserts go, they don't fix >> anything, >>> they just assert (=confirm) expected behaviour. >>> >>> So, can we change the commit message to not include the word "fix" or any >>> other misleading derivative thereof? >> >> absolutely, agree >> do you want to suggest some wording ? > > > I like Hendrik's earlier wording, something along the lines of "Makes > false-positive CID1351343 disappear", or "Related to false-positive > CID1351343". > > Ronald The couple times i dealt with a trac ticket that wasn't a bug i used "addressed" instead of "fixed". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add metadata filters
On Sat, Feb 06, 2016 at 12:47:25 +0100, Paul B Mahol wrote:
> patch attached.
Nice. (Untested.)
> +Manipulate frames metadata.
Either:
frame metadata [using this as a generic term]
or:
frames' metadata
I prefer the former.
> +If both @code{value} and @code{key} is set, select frame
^ frames (plural)
> +every frame that have such key in metadata.
has (singular)
> +Print key and value if metadata was found.
I'm not sure I've understood whether this can apply to only matching
metadata (key, key/value), or to any metadata.
> +Set metadata value which will be used. This option is mandatory for modify
> +and add mode.
for 'modify' and 'add' modes (note the quoting and the plural).
> +Set length of how much characters of two metadata values need to match to be
many
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] build: use a link instead of changing current directory when compiling
On 03.02.2016 00:41, Andreas Cadhalpun wrote: > I see, it passes '-b $(SRC_PATH)' to lcov, which is now unnecessary/harmful > for out-of-tree builds using the src link. > The first attached patch changes it to simply use the current directory in > that case. > The second patch was necessary to fix the following error: > lcov: ERROR: cannot write to coverage.info! > > Does it work for you without that patch? I'd still be interested in an answer, but I've pushed the patches now to unbreak coverage.ffmpeg.org. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] build: use a link instead of changing current directory when compiling
On 02.02.2016 01:04, Andreas Cadhalpun wrote: > Subject: [PATCH] configure: fall back to using full path if src is a directory > > Or when building in-tree. > Also don't try to remove src on distclean in these cases. > > Signed-off-by: Andreas Cadhalpun > --- > Makefile | 5 - > configure | 2 +- > 2 files changed, 5 insertions(+), 2 deletions(-) As there were no further comments, I've pushed this now. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mp3enc: Assert that the header we assembled is valid
L'octidi 18 pluviôse, an CCXXIV, James Almer a écrit : > The couple times i dealt with a trac ticket that wasn't a bug i used > "addressed" instead of "fixed". I would say it "addresses" a ticket if the ticket is valid but the commit does not really fix the issue, for example print a helpful specific error message instead of a generic one. Maybe "silence CID #XXX"? Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On 27.01.2016 01:22, Andreas Cadhalpun wrote: > On 27.01.2016 01:16, Ronald S. Bultje wrote: >> Please wait until my patch is finished. > > Do you think that will happen in the coming days? This seems not to be the case, so I intend to push these two patches soon. They can easily be reverted once your patch is ready. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On Sat, 6 Feb 2016 17:25:42 +0100 Andreas Cadhalpun wrote: > On 27.01.2016 01:22, Andreas Cadhalpun wrote: > > On 27.01.2016 01:16, Ronald S. Bultje wrote: > >> Please wait until my patch is finished. > > > > Do you think that will happen in the coming days? > > This seems not to be the case, so I intend to push these two > patches soon. > They can easily be reverted once your patch is ready. I disagree with pushing those patches. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On 06.02.2016 17:31, wm4 wrote: > On Sat, 6 Feb 2016 17:25:42 +0100 > Andreas Cadhalpun wrote: > >> On 27.01.2016 01:22, Andreas Cadhalpun wrote: >>> On 27.01.2016 01:16, Ronald S. Bultje wrote: Please wait until my patch is finished. >>> >>> Do you think that will happen in the coming days? >> >> This seems not to be the case, so I intend to push these two >> patches soon. >> They can easily be reverted once your patch is ready. > > I disagree with pushing those patches. So what do you suggest instead to get VLC's hwaccels working again soon? Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On Sat, 6 Feb 2016 17:32:12 +0100 Andreas Cadhalpun wrote: > On 06.02.2016 17:31, wm4 wrote: > > On Sat, 6 Feb 2016 17:25:42 +0100 > > Andreas Cadhalpun wrote: > > > >> On 27.01.2016 01:22, Andreas Cadhalpun wrote: > >>> On 27.01.2016 01:16, Ronald S. Bultje wrote: > Please wait until my patch is finished. > >>> > >>> Do you think that will happen in the coming days? > >> > >> This seems not to be the case, so I intend to push these two > >> patches soon. > >> They can easily be reverted once your patch is ready. > > > > I disagree with pushing those patches. > > So what do you suggest instead to get VLC's hwaccels working again soon? Send a patch to VLC. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On 06.02.2016 17:35, wm4 wrote: > On Sat, 6 Feb 2016 17:32:12 +0100 > Andreas Cadhalpun wrote: > >> On 06.02.2016 17:31, wm4 wrote: >>> On Sat, 6 Feb 2016 17:25:42 +0100 >>> Andreas Cadhalpun wrote: >>> On 27.01.2016 01:22, Andreas Cadhalpun wrote: > On 27.01.2016 01:16, Ronald S. Bultje wrote: >> Please wait until my patch is finished. > > Do you think that will happen in the coming days? This seems not to be the case, so I intend to push these two patches soon. They can easily be reverted once your patch is ready. >>> >>> I disagree with pushing those patches. >> >> So what do you suggest instead to get VLC's hwaccels working again soon? > > Send a patch to VLC. Writing such a patch is not easy. Feel free to prove me wrong by doing it. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On Sat, 6 Feb 2016 17:38:45 +0100 Andreas Cadhalpun wrote: > On 06.02.2016 17:35, wm4 wrote: > > On Sat, 6 Feb 2016 17:32:12 +0100 > > Andreas Cadhalpun wrote: > > > >> On 06.02.2016 17:31, wm4 wrote: > >>> On Sat, 6 Feb 2016 17:25:42 +0100 > >>> Andreas Cadhalpun wrote: > >>> > On 27.01.2016 01:22, Andreas Cadhalpun wrote: > > On 27.01.2016 01:16, Ronald S. Bultje wrote: > >> Please wait until my patch is finished. > > > > Do you think that will happen in the coming days? > > This seems not to be the case, so I intend to push these two > patches soon. > They can easily be reverted once your patch is ready. > >>> > >>> I disagree with pushing those patches. > >> > >> So what do you suggest instead to get VLC's hwaccels working again soon? > > > > Send a patch to VLC. > > Writing such a patch is not easy. > Feel free to prove me wrong by doing it. We don't give in to blackmail (which is pretty what that VLC dev did) just because it's more convenient for you. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On 06.02.2016 17:42, wm4 wrote: > On Sat, 6 Feb 2016 17:38:45 +0100 > Andreas Cadhalpun wrote: > >> On 06.02.2016 17:35, wm4 wrote: >>> On Sat, 6 Feb 2016 17:32:12 +0100 >>> Andreas Cadhalpun wrote: So what do you suggest instead to get VLC's hwaccels working again soon? >>> >>> Send a patch to VLC. >> >> Writing such a patch is not easy. >> Feel free to prove me wrong by doing it. > > We don't give in to blackmail (which is pretty what that VLC dev did) I think you misunderstood something. We shouldn't gratuitously break API users. > just because it's more convenient for you. This has nothing to do with my convenience. It is about fixing an important regression caused by a commit you reviewed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On Sat, 6 Feb 2016 17:48:17 +0100 Andreas Cadhalpun wrote: > On 06.02.2016 17:42, wm4 wrote: > > On Sat, 6 Feb 2016 17:38:45 +0100 > > Andreas Cadhalpun wrote: > > > >> On 06.02.2016 17:35, wm4 wrote: > >>> On Sat, 6 Feb 2016 17:32:12 +0100 > >>> Andreas Cadhalpun wrote: > So what do you suggest instead to get VLC's hwaccels working again soon? > > >>> > >>> Send a patch to VLC. > >> > >> Writing such a patch is not easy. > >> Feel free to prove me wrong by doing it. > > > > We don't give in to blackmail (which is pretty what that VLC dev did) > > I think you misunderstood something. > We shouldn't gratuitously break API users. It's not an API break. > > just because it's more convenient for you. > > This has nothing to do with my convenience. It is about fixing an > important regression caused by a commit you reviewed. It's not a regression in FFmpeg or its API. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On 06.02.2016 18:02, wm4 wrote: > On Sat, 6 Feb 2016 17:48:17 +0100 > Andreas Cadhalpun wrote: > >> On 06.02.2016 17:42, wm4 wrote: >>> On Sat, 6 Feb 2016 17:38:45 +0100 >>> Andreas Cadhalpun wrote: >>> On 06.02.2016 17:35, wm4 wrote: > On Sat, 6 Feb 2016 17:32:12 +0100 > Andreas Cadhalpun wrote: >> So what do you suggest instead to get VLC's hwaccels working again soon? >> > > Send a patch to VLC. Writing such a patch is not easy. Feel free to prove me wrong by doing it. >>> >>> We don't give in to blackmail (which is pretty what that VLC dev did) >> >> I think you misunderstood something. >> We shouldn't gratuitously break API users. > > It's not an API break. > >>> just because it's more convenient for you. >> >> This has nothing to do with my convenience. It is about fixing an >> important regression caused by a commit you reviewed. > > It's not a regression in FFmpeg or its API. That's splitting hairs. VLC's hwaccels worked before that commit and don't work after it, which is a clear regression. All of that has been said before. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add threshold filter
Hi, patch attached. From 5352dbf21552746b2bf4359abd36b67a1b73a1bf Mon Sep 17 00:00:00 2001 From: Paul B Mahol Date: Sat, 6 Feb 2016 17:11:07 +0100 Subject: [PATCH] avfilter: add threshold filter Signed-off-by: Paul B Mahol --- doc/filters.texi | 49 +++ libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_threshold.c | 323 + 4 files changed, 374 insertions(+) create mode 100644 libavfilter/vf_threshold.c diff --git a/doc/filters.texi b/doc/filters.texi index 5991dd4..95a71d6 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -11522,6 +11522,55 @@ PAL output (25i): 16p: 3334 @end example +@section threshold + +Apply threshold effect to video stream. + +This filter needs four video streams to perform thresholding. +First stream is stream we are filtering. +Second stream is holding threshold values, third stream is holding min values, +and last, fourth stream is holding max values. + +For example if first stream pixel's component value is less then threshold value +of pixel component from 2nd threshold stream, third stream value will picked, +otherwise fourth stream pixel component value will be picked. + +Using color source filter one can perform various types of thresholding: + +@subsection Examples + +@itemize +@item +Binary threshold, using gray color as threshold: +@example +ffmpeg -i 320x240.avi -f lavfi -i color=gray -f lavfi -i color=black -f lavfi -i color=white -lavfi threshold output.avi +@end example + +@item +Inverted binary threshold, using gray color as threshold: +@example +ffmpeg -i 320x240.avi -f lavfi -i color=gray -f lavfi -i color=white -f lavfi -i color=black -lavfi threshold output.avi +@end example + +@item +Truncate binary threshold, using gray color as threshold: +@example +ffmpeg -i 320x240.avi -f lavfi -i color=gray -i 320x240.avi -f lavfi -i color=gray -lavfi threshold output.avi +@end example + +@item +Threshold to zero, using gray color as threshold: +@example +ffmpeg -i 320x240.avi -f lavfi -i color=gray -f lavfi -i color=white -i 320x240.avi -lavfi threshold output.avi +@end example + +@item +Inverted threshold to zero, using gray color as threshold: +@example +ffmpeg -i 320x240.avi -f lavfi -i color=gray -i 320x240.avi -f lavfi -i color=white -lavfi threshold output.avi +@end example +@end itemize + @section thumbnail Select the most representative frame in a given sequence of consecutive frames. diff --git a/libavfilter/Makefile b/libavfilter/Makefile index 664c773..800d493 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -245,6 +245,7 @@ OBJS-$(CONFIG_SUPER2XSAI_FILTER) += vf_super2xsai.o OBJS-$(CONFIG_SWAPUV_FILTER) += vf_swapuv.o OBJS-$(CONFIG_TBLEND_FILTER) += vf_blend.o dualinput.o framesync.o OBJS-$(CONFIG_TELECINE_FILTER) += vf_telecine.o +OBJS-$(CONFIG_THRESHOLD_FILTER) += vf_threshold.o OBJS-$(CONFIG_THUMBNAIL_FILTER) += vf_thumbnail.o OBJS-$(CONFIG_TILE_FILTER) += vf_tile.o OBJS-$(CONFIG_TINTERLACE_FILTER) += vf_tinterlace.o diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index f56b390..8ae5aa6 100644 --- a/libavfilter/allfilters.c +++ b/libavfilter/allfilters.c @@ -265,6 +265,7 @@ void avfilter_register_all(void) REGISTER_FILTER(SWAPUV, swapuv, vf); REGISTER_FILTER(TBLEND, tblend, vf); REGISTER_FILTER(TELECINE, telecine, vf); +REGISTER_FILTER(THRESHOLD, threshold, vf); REGISTER_FILTER(THUMBNAIL, thumbnail, vf); REGISTER_FILTER(TILE, tile, vf); REGISTER_FILTER(TINTERLACE, tinterlace, vf); diff --git a/libavfilter/vf_threshold.c b/libavfilter/vf_threshold.c new file mode 100644 index 000..78aa1c9 --- /dev/null +++ b/libavfilter/vf_threshold.c @@ -0,0 +1,323 @@ +/* + * Copyright (c) 2016 Paul B Mahol + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/** + * @file + * threshold video filter + */ + +#include "libavutil/imgutils.h" +#include "libavutil/internal.h" +#include "libavutil/opt.h" +#include "libavutil/pixdesc.h" +#include "avfilter.h" +#include "fr
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On Sat, 6 Feb 2016 18:15:37 +0100 Andreas Cadhalpun wrote: > On 06.02.2016 18:02, wm4 wrote: > > On Sat, 6 Feb 2016 17:48:17 +0100 > > Andreas Cadhalpun wrote: > > > >> On 06.02.2016 17:42, wm4 wrote: > >>> On Sat, 6 Feb 2016 17:38:45 +0100 > >>> Andreas Cadhalpun wrote: > >>> > On 06.02.2016 17:35, wm4 wrote: > > On Sat, 6 Feb 2016 17:32:12 +0100 > > Andreas Cadhalpun wrote: > >> So what do you suggest instead to get VLC's hwaccels working again > >> soon? > > > > Send a patch to VLC. > > Writing such a patch is not easy. > Feel free to prove me wrong by doing it. > >>> > >>> We don't give in to blackmail (which is pretty what that VLC dev did) > >> > >> I think you misunderstood something. > >> We shouldn't gratuitously break API users. > > > > It's not an API break. > > > >>> just because it's more convenient for you. > >> > >> This has nothing to do with my convenience. It is about fixing an > >> important regression caused by a commit you reviewed. > > > > It's not a regression in FFmpeg or its API. > > That's splitting hairs. > VLC's hwaccels worked before that commit and don't work after it, > which is a clear regression. A regression in VLC. Make them fix it. > All of that has been said before. Indeed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On 02/06/2016 06:25 PM, wm4 wrote: A regression in VLC. Make them fix it. VLC = Very Lame Crap. Just kidding. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On 06.02.2016 18:25, wm4 wrote: > On Sat, 6 Feb 2016 18:15:37 +0100 > Andreas Cadhalpun wrote: > >> On 06.02.2016 18:02, wm4 wrote: >>> On Sat, 6 Feb 2016 17:48:17 +0100 >>> Andreas Cadhalpun wrote: This has nothing to do with my convenience. It is about fixing an important regression caused by a commit you reviewed. >>> >>> It's not a regression in FFmpeg or its API. >> >> That's splitting hairs. >> VLC's hwaccels worked before that commit and don't work after it, >> which is a clear regression. > > A regression in VLC. Make them fix it. You're not constructive. I doubt you'd like being told that when a change in ffmpeg broke mpv in a similar way and couldn't easily be fixed there. >> All of that has been said before. > > Indeed. Thus nothing changed and I still intend to apply these patches soon. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On 2/6/16, Andreas Cadhalpun wrote: > On 06.02.2016 18:25, wm4 wrote: >> On Sat, 6 Feb 2016 18:15:37 +0100 >> Andreas Cadhalpun wrote: >> >>> On 06.02.2016 18:02, wm4 wrote: On Sat, 6 Feb 2016 17:48:17 +0100 Andreas Cadhalpun wrote: > This has nothing to do with my convenience. It is about fixing an > important regression caused by a commit you reviewed. It's not a regression in FFmpeg or its API. >>> >>> That's splitting hairs. >>> VLC's hwaccels worked before that commit and don't work after it, >>> which is a clear regression. >> >> A regression in VLC. Make them fix it. > > You're not constructive. I doubt you'd like being told that when a > change in ffmpeg broke mpv in a similar way and couldn't easily be > fixed there. > >>> All of that has been said before. >> >> Indeed. > > Thus nothing changed and I still intend to apply these patches soon. Even when everybody is against? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On Sat, 6 Feb 2016 18:46:59 +0100 Andreas Cadhalpun wrote: > On 06.02.2016 18:25, wm4 wrote: > > On Sat, 6 Feb 2016 18:15:37 +0100 > > Andreas Cadhalpun wrote: > > > >> On 06.02.2016 18:02, wm4 wrote: > >>> On Sat, 6 Feb 2016 17:48:17 +0100 > >>> Andreas Cadhalpun wrote: > This has nothing to do with my convenience. It is about fixing an > important regression caused by a commit you reviewed. > >>> > >>> It's not a regression in FFmpeg or its API. > >> > >> That's splitting hairs. > >> VLC's hwaccels worked before that commit and don't work after it, > >> which is a clear regression. > > > > A regression in VLC. Make them fix it. > > You're not constructive. Even if that is true, neither are you. You want to revert a change that was often discussed and found to be the best way to go about the issue, just because it's the way of least resistance for you. While we normally would very much try not to break API users, including VLC, this case has a bit of a history. Don't forget the behavior of the VLC dev, who was never constructive about this either. On the Libav side he AFAIK kept claiming it was not his problem. When the change was made on the FFmpeg side, he just changed the VLC configure script to reject FFmpeg, instead of bringing up this issue anywhere. > I doubt you'd like being told that when a > change in ffmpeg broke mpv in a similar way and couldn't easily be > fixed there. I doubt I could get a debian maintainer to waste the time of FFmpeg developers just because I don't want to adapt in a specific case. > >> All of that has been said before. > > > > Indeed. > > Thus nothing changed and I still intend to apply these patches soon. No, you won't. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On 2/6/2016 2:46 PM, Andreas Cadhalpun wrote: > Thus nothing changed and I still intend to apply these patches soon. No you wont, that's not how it works. This patch has one person in favor and more than one against. It can't be applied. How to solve this? Convince those against, either with arguments or by presenting a more acceptable solution, or raise the issue downstream where it belongs. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
wm4 googlemail.com> writes: > You want to revert a change that was often discussed > and found to be the best way to go about the issue, Please remind me again how I can reproduce the "issue", I seem to have forgotten. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On 06.02.2016 18:52, Paul B Mahol wrote: > On 2/6/16, Andreas Cadhalpun wrote: >> On 06.02.2016 18:25, wm4 wrote: >>> On Sat, 6 Feb 2016 18:15:37 +0100 >>> Andreas Cadhalpun wrote: All of that has been said before. >>> >>> Indeed. >> >> Thus nothing changed and I still intend to apply these patches soon. > > Even when everybody is against? Even Hendrik agreed with this approach as long as the vp9 hwaccel is taken care of. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On 06.02.2016 18:55, wm4 wrote: > On Sat, 6 Feb 2016 18:46:59 +0100 > Andreas Cadhalpun wrote: >> You're not constructive. > > Even if that is true, neither are you. I try to be constructive. The problem is that all proposed alternative ways (change VLC to use one thread for hwaccel and fall back to more threads if hwaccel fails; make libavcodec do this automatically) are rather difficult to implement. While I would prefer such a solution, it can't be used until it exists. > You want to revert a change that > was often discussed and found to be the best way to go about the issue, No, this is not the best way. libavcodec automatically doing the right thing would be. > just because it's the way of least resistance for you. I don't think arguing with you can be called 'way of least resistance'. > While we normally would very much try not to break API users, including > VLC, this case has a bit of a history. Don't forget the behavior of the > VLC dev, who was never constructive about this either. On the Libav > side he AFAIK kept claiming it was not his problem. When the change was > made on the FFmpeg side, he just changed the VLC configure script to > reject FFmpeg, instead of bringing up this issue anywhere. So bad behavior of one developer justifies breaking the setup of thousands of users? >> I doubt you'd like being told that when a >> change in ffmpeg broke mpv in a similar way and couldn't easily be >> fixed there. > > I doubt I could get a debian maintainer to waste the time of FFmpeg > developers just because I don't want to adapt in a specific case. Just don't waste the time and become constructive. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 02/12] avutil/parseutils: accept everything in av_parse_time that ff_iso8601_to_unix_time accepts
Signed-off-by: Marton Balint
---
libavutil/parseutils.c| 8 ++--
tests/ref/fate/parseutils | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
index fd8cf2b..0efc608 100644
--- a/libavutil/parseutils.c
+++ b/libavutil/parseutils.c
@@ -565,7 +565,7 @@ int av_parse_time(int64_t *timeval, const char *timestr,
int duration)
int today = 0, negative = 0, microseconds = 0;
int i;
static const char * const date_fmt[] = {
-"%Y-%m-%d",
+"%Y - %m - %d",
"%Y%m%d",
};
static const char * const time_fmt[] = {
@@ -600,8 +600,11 @@ int av_parse_time(int64_t *timeval, const char *timestr,
int duration)
}
p = q;
-if (*p == 'T' || *p == 't' || *p == ' ')
+if (*p == 'T' || *p == 't')
p++;
+else
+while (av_isspace(*p))
+p++;
/* parse the hour-minute-second part */
for (i = 0; i < FF_ARRAY_ELEMS(time_fmt); i++) {
@@ -860,6 +863,7 @@ int main(void)
"now",
"12:35:46",
"2000-12-20 0:02:47.5z",
+"2012 - 02-22 17:44:07",
"2000-12-20T010247.6",
};
static const char * const duration_string[] = {
diff --git a/tests/ref/fate/parseutils b/tests/ref/fate/parseutils
index 176140c..8ba20b3 100644
--- a/tests/ref/fate/parseutils
+++ b/tests/ref/fate/parseutils
@@ -74,6 +74,7 @@ Testing av_parse_time()
now -> 1331972053.20 = 2012-03-17T08:14:13Z
12:35:46 -> 1331984146.00 = 2012-03-17T11:35:46Z
2000-12-20 0:02:47.5z-> 977270567.50 = 2000-12-20T00:02:47Z
+2012 - 02-22 17:44:07 -> 1329929047.00 = 2012-02-22T16:44:07Z
2000-12-20T010247.6 -> 977270567.60 = 2000-12-20T00:02:47Z
2:34:56.79 -> +929679
-1:23:45.67 -> -502567
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 04/12] avformat/asfenc: use ff_parse_creation_time_metadata
Signed-off-by: Marton Balint
---
libavformat/asfenc.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/libavformat/asfenc.c b/libavformat/asfenc.c
index a6a8242..14f92e2 100644
--- a/libavformat/asfenc.c
+++ b/libavformat/asfenc.c
@@ -388,7 +388,7 @@ static int asf_write_header1(AVFormatContext *s, int64_t
file_size,
{
ASFContext *asf = s->priv_data;
AVIOContext *pb = s->pb;
-AVDictionaryEntry *tags[5], *t;
+AVDictionaryEntry *tags[5];
int header_size, n, extra_size, extra_size2, wav_extra_size;
int has_title, has_aspect_ratio = 0;
int metadata_count;
@@ -408,12 +408,9 @@ static int asf_write_header1(AVFormatContext *s, int64_t
file_size,
duration = asf->duration + PREROLL_TIME * 1;
has_title = tags[0] || tags[1] || tags[2] || tags[3] || tags[4];
-if (!file_size && (t = av_dict_get(s->metadata, "creation_time", NULL,
0))) {
-if (av_parse_time(&asf->creation_time, t->value, 0) < 0) {
-av_log(s, AV_LOG_WARNING, "Failed to parse creation_time %s\n",
t->value);
-asf->creation_time = 0;
-}
-av_dict_set(&s->metadata, "creation_time", NULL, 0);
+if (!file_size) {
+if (ff_parse_creation_time_metadata(s, &asf->creation_time, 0) != 0)
+av_dict_set(&s->metadata, "creation_time", NULL, 0);
}
metadata_count = av_dict_count(s->metadata);
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 01/12] avutil/parseutils: use microsecond precision when parsing "now" in av_parse_time()
Use av_gettime() instead of time(0) for querying current time.
Signed-off-by: Marton Balint
---
libavutil/parseutils.c| 12 +++-
tests/ref/fate/parseutils | 4 ++--
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
index 9fb8d0a..fd8cf2b 100644
--- a/libavutil/parseutils.c
+++ b/libavutil/parseutils.c
@@ -31,13 +31,14 @@
#include "random_seed.h"
#include "time_internal.h"
#include "parseutils.h"
+#include "time.h"
#ifdef TEST
#define av_get_random_seed av_get_random_seed_deterministic
static uint32_t av_get_random_seed_deterministic(void);
-#define time(t) 1331972053
+#define av_gettime() 133197205320
#endif
@@ -558,7 +559,7 @@ time_t av_timegm(struct tm *tm)
int av_parse_time(int64_t *timeval, const char *timestr, int duration)
{
const char *p, *q;
-int64_t t;
+int64_t t, now64;
time_t now;
struct tm dt = { 0 }, tmbuf;
int today = 0, negative = 0, microseconds = 0;
@@ -576,10 +577,11 @@ int av_parse_time(int64_t *timeval, const char *timestr,
int duration)
q = NULL;
*timeval = INT64_MIN;
if (!duration) {
-now = time(0);
+now64 = av_gettime();
+now = now64 / 100;
if (!av_strcasecmp(timestr, "now")) {
-*timeval = (int64_t) now * 100;
+*timeval = now64;
return 0;
}
@@ -870,7 +872,7 @@ int main(void)
av_log_set_level(AV_LOG_DEBUG);
putenv(tzstr);
-printf("(now is 2012-03-17 09:14:13 +0100, local time is UTC+1)\n");
+printf("(now is 2012-03-17 09:14:13.2 +0100, local time is UTC+1)\n");
for (i = 0; i < FF_ARRAY_ELEMS(time_string); i++) {
printf("%-24s -> ", time_string[i]);
if (av_parse_time(&tv, time_string[i], 0)) {
diff --git a/tests/ref/fate/parseutils b/tests/ref/fate/parseutils
index 1482452..176140c 100644
--- a/tests/ref/fate/parseutils
+++ b/tests/ref/fate/parseutils
@@ -70,8 +70,8 @@ fmt:'%Y-%m-%d %H:%M:%S' spec:'2012-12-21 20:12:21' ->
2012-12-21 20:12:21
fmt:' %Y - %m - %d %H : %M : %S' spec:' 2012 - 12 - 21 20 : 12 : 21' ->
2012-12-21 20:12:21
Testing av_parse_time()
-(now is 2012-03-17 09:14:13 +0100, local time is UTC+1)
-now -> 1331972053.00 = 2012-03-17T08:14:13Z
+(now is 2012-03-17 09:14:13.2 +0100, local time is UTC+1)
+now -> 1331972053.20 = 2012-03-17T08:14:13Z
12:35:46 -> 1331984146.00 = 2012-03-17T11:35:46Z
2000-12-20 0:02:47.5z-> 977270567.50 = 2000-12-20T00:02:47Z
2000-12-20T010247.6 -> 977270567.60 = 2000-12-20T00:02:47Z
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 06/12] avformat/ffmenc: use ff_parse_creation_time_metadata
FYI this muxer bails out on parse error and not just warn the user.
Signed-off-by: Marton Balint
---
libavformat/ffmenc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavformat/ffmenc.c b/libavformat/ffmenc.c
index f0b5743..bbab1db 100644
--- a/libavformat/ffmenc.c
+++ b/libavformat/ffmenc.c
@@ -221,17 +221,13 @@ static int ffm_write_recommended_config(AVIOContext *pb,
AVCodecContext *ctx, un
static int ffm_write_header(AVFormatContext *s)
{
FFMContext *ffm = s->priv_data;
-AVDictionaryEntry *t;
AVStream *st;
AVIOContext *pb = s->pb;
AVCodecContext *codec;
int bit_rate, i, ret;
-if (t = av_dict_get(s->metadata, "creation_time", NULL, 0)) {
-ret = av_parse_time(&ffm->start_time, t->value, 0);
-if (ret < 0)
-return ret;
-}
+if ((ret = ff_parse_creation_time_metadata(s, &ffm->start_time, 0) < 0))
+return ret;
ffm->packet_size = FFM_PACKET_SIZE;
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 10/12] avformat/matroskaenc: use ff_parse_creation_time_metadata
Also increase precision to microsecs, and avoid writing creation_time as a
simple tag metadata item.
Signed-off-by: Marton Balint
---
libavformat/matroskaenc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index f7fb5c3..f42434b 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1211,6 +1211,7 @@ static int mkv_write_tag(AVFormatContext *s, AVDictionary
*m, unsigned int eleme
while ((t = av_dict_get(m, "", t, AV_DICT_IGNORE_SUFFIX))) {
if (av_strcasecmp(t->key, "title") &&
av_strcasecmp(t->key, "stereo_mode") &&
+av_strcasecmp(t->key, "creation_time") &&
av_strcasecmp(t->key, "encoding_tool") &&
(elementid != MATROSKA_ID_TAGTARGETS_TRACKUID ||
av_strcasecmp(t->key, "language"))) {
@@ -1383,6 +1384,7 @@ static int mkv_write_header(AVFormatContext *s)
ebml_master ebml_header, segment_info;
AVDictionaryEntry *tag;
int ret, i, version = 2;
+int64_t creation_time;
if (!strcmp(s->oformat->name, "webm"))
mkv->mode = MODE_WEBM;
@@ -1469,9 +1471,9 @@ static int mkv_write_header(AVFormatContext *s)
put_ebml_string(pb, MATROSKA_ID_WRITINGAPP, ident);
}
-if (tag = av_dict_get(s->metadata, "creation_time", NULL, 0)) {
+if (ff_parse_creation_time_metadata(s, &creation_time, 0) > 0) {
// Adjust time so it's relative to 2001-01-01 and convert to
nanoseconds.
-int64_t date_utc = (ff_iso8601_to_unix_time(tag->value) - 978307200) *
10;
+int64_t date_utc = (creation_time - 9783072LL) * 1000;
uint8_t date_utc_buf[8];
AV_WB64(date_utc_buf, date_utc);
put_ebml_binary(pb, MATROSKA_ID_DATEUTC, date_utc_buf, 8);
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 08/12] avformat/movenc: use ff_parse_creation_time_metadata
Signed-off-by: Marton Balint
---
libavformat/movenc.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index c6fba21..eeb893b 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5370,13 +5370,7 @@ static int mov_write_header(AVFormatContext *s)
mov_write_mdat_tag(pb, mov);
}
-if (t = av_dict_get(s->metadata, "creation_time", NULL, 0)) {
-mov->time = ff_iso8601_to_unix_time(t->value);
-if (mov->time < 0) {
-av_log(s, AV_LOG_WARNING, "Failed to parse creation_time %s\n",
t->value);
-mov->time = 0;
-}
-}
+ff_parse_creation_time_metadata(s, &mov->time, 1);
if (mov->time)
mov->time += 0x7C25B080; // 1970 based -> 1904 based
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 11/12] avformat/utils: remove ff_iso8601_to_unix_time
Signed-off-by: Marton Balint
---
libavformat/internal.h | 5 -
libavformat/utils.c| 12
2 files changed, 17 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index f88cc9a..67fffa0 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -321,11 +321,6 @@ void ff_reduce_index(AVFormatContext *s, int stream_index);
enum AVCodecID ff_guess_image2_codec(const char *filename);
/**
- * Convert a date string in ISO8601 format to Unix timestamp.
- */
-int64_t ff_iso8601_to_unix_time(const char *datestr);
-
-/**
* Perform a binary search using av_index_search_timestamp() and
* AVInputFormat.read_timestamp().
*
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 73b1c29..f2245b0 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4232,18 +4232,6 @@ int ff_find_stream_index(AVFormatContext *s, int id)
return -1;
}
-int64_t ff_iso8601_to_unix_time(const char *datestr)
-{
-struct tm time1 = { 0 }, time2 = { 0 };
-const char *ret1, *ret2;
-ret1 = av_small_strptime(datestr, "%Y - %m - %d %T", &time1);
-ret2 = av_small_strptime(datestr, "%Y - %m - %dT%T", &time2);
-if (ret2 && !ret1)
-return av_timegm(&time2);
-else
-return av_timegm(&time1);
-}
-
int avformat_query_codec(const AVOutputFormat *ofmt, enum AVCodecID codec_id,
int std_compliance)
{
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 03/12] avformat/utils: add ff_parse_creation_time_metadata
Signed-off-by: Marton Balint
---
libavformat/internal.h | 11 +++
libavformat/utils.c| 17 +
2 files changed, 28 insertions(+)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 2cb3481..f88cc9a 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -548,4 +548,15 @@ int ffio_open2_wrapper(struct AVFormatContext *s,
AVIOContext **pb, const char *
*/
#define FFERROR_REDO FFERRTAG('R','E','D','O')
+/**
+ * Parse creation_time in AVFormatContext metadata if exists and warn if the
+ * parsing fails.
+ *
+ * @param s AVFormatContext
+ * @param timestamp parsed timestamp in microseconds, only set on successful
parsing
+ * @param return_seconds set this to get the number of seconds in timestamp
instead of microseconds
+ * @return 1 if OK, 0 if the metadata was not present, AVERROR(EINVAL) on
parse error
+ */
+int ff_parse_creation_time_metadata(AVFormatContext *s, int64_t *timestamp,
int return_seconds);
+
#endif /* AVFORMAT_INTERNAL_H */
diff --git a/libavformat/utils.c b/libavformat/utils.c
index f8846b7..73b1c29 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4742,3 +4742,20 @@ int av_apply_bitstream_filters(AVCodecContext *codec,
AVPacket *pkt,
}
return ret;
}
+
+int ff_parse_creation_time_metadata(AVFormatContext *s, int64_t *timestamp,
int return_seconds)
+{
+AVDictionaryEntry *entry;
+int64_t parsed_timestamp;
+int ret;
+if ((entry = av_dict_get(s->metadata, "creation_time", NULL, 0))) {
+if ((ret = av_parse_time(&parsed_timestamp, entry->value, 0)) >= 0) {
+*timestamp = return_seconds ? parsed_timestamp / 100 :
parsed_timestamp;
+return 1;
+} else {
+av_log(s, AV_LOG_WARNING, "Failed to parse creation_time %s\n",
entry->value);
+return ret;
+}
+}
+return 0;
+}
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 05/12] avformat/dvenc: use ff_parse_creation_time_metadata
Signed-off-by: Marton Balint
---
libavformat/dvenc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/dvenc.c b/libavformat/dvenc.c
index 502cc26..6cefe8b 100644
--- a/libavformat/dvenc.c
+++ b/libavformat/dvenc.c
@@ -302,7 +302,6 @@ static DVMuxContext* dv_init_mux(AVFormatContext* s)
{
DVMuxContext *c = s->priv_data;
AVStream *vst = NULL;
-AVDictionaryEntry *t;
int i;
/* we support at most 1 video and 2 audio streams */
@@ -363,8 +362,7 @@ static DVMuxContext* dv_init_mux(AVFormatContext* s)
c->frames = 0;
c->has_audio = 0;
c->has_video = 0;
-if (t = av_dict_get(s->metadata, "creation_time", NULL, 0))
-c->start_time = ff_iso8601_to_unix_time(t->value);
+ff_parse_creation_time_metadata(s, &c->start_time, 1);
for (i=0; i < c->n_ast; i++) {
if (c->ast[i] && !(c->audio_data[i]=av_fifo_alloc_array(100,
MAX_AUDIO_FRAME_SIZE))) {
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 09/12] avformat/mxfenc: use ff_parse_creation_time_metadata
Signed-off-by: Marton Balint
---
libavformat/mxfenc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 6da8b10..cd13f89 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2041,7 +2041,6 @@ static int mxf_write_header(AVFormatContext *s)
int i, ret;
uint8_t present[FF_ARRAY_ELEMS(mxf_essence_container_uls)] = {0};
const MXFSamplesPerFrame *spf = NULL;
-AVDictionaryEntry *t;
int64_t timestamp = 0;
if (!s->nb_streams)
@@ -2212,9 +2211,7 @@ static int mxf_write_header(AVFormatContext *s)
sc->order = AV_RB32(sc->track_essence_element_key+12);
}
-if (t = av_dict_get(s->metadata, "creation_time", NULL, 0))
-timestamp = ff_iso8601_to_unix_time(t->value);
-if (timestamp)
+if (ff_parse_creation_time_metadata(s, ×tamp, 1) > 0)
mxf->timestamp = mxf_parse_timestamp(timestamp);
mxf->duration = -1;
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 07/12] avformat/gxfenc: use ff_parse_creation_time_metadata
Signed-off-by: Marton Balint --- libavformat/gxfenc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/libavformat/gxfenc.c b/libavformat/gxfenc.c index 12031f7..8229fe9 100644 --- a/libavformat/gxfenc.c +++ b/libavformat/gxfenc.c @@ -436,13 +436,11 @@ static int gxf_write_umf_material_description(AVFormatContext *s) AVIOContext *pb = s->pb; int timecode_base = gxf->time_base.den == 6 ? 60 : 50; int64_t timestamp = 0; -AVDictionaryEntry *t; uint64_t nb_fields; uint32_t timecode_in; // timecode at mark in uint32_t timecode_out; // timecode at mark out -if (t = av_dict_get(s->metadata, "creation_time", NULL, 0)) -timestamp = ff_iso8601_to_unix_time(t->value); +ff_parse_creation_time_metadata(s, ×tamp, 1); timecode_in = GXF_TIMECODE(gxf->tc.color, gxf->tc.drop, gxf->tc.hh, gxf->tc.mm, -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 12/12] ffmpeg: remove hardcoded 'now' creation_time support
Every date parsing routine now uses av_parse_time which handles 'now' and
provides greater precision as well. This change also enables the segmenter
muxer to set the proper 'now' creation time at the beginning of each segment.
Signed-off-by: Marton Balint
---
ffmpeg_opt.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 669976b..7451e21 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -2430,17 +2430,6 @@ loop_end:
}
*val++ = 0;
-if (!strcmp(o->metadata[i].u.str, "creation_time") &&
-!strcmp(val, "now")) {
-time_t now = time(0);
-struct tm *ptm, tmbuf;
-ptm = localtime_r(&now, &tmbuf);
-if (ptm) {
-if (strftime(now_time, sizeof(now_time), "%Y-%m-%d %H:%M:%S",
ptm))
-val = now_time;
-}
-}
-
parse_meta_type(o->metadata[i].specifier, &type, &index, &stream_spec);
if (type == 's') {
for (j = 0; j < oc->nb_streams; j++) {
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mp3enc: Assert that the header we assembled is valid
Hi, On Sat, Feb 6, 2016 at 10:50 AM, Nicolas George wrote: > L'octidi 18 pluviôse, an CCXXIV, James Almer a écrit : > > The couple times i dealt with a trac ticket that wasn't a bug i used > > "addressed" instead of "fixed". > > I would say it "addresses" a ticket if the ticket is valid but the commit > does not really fix the issue, for example print a helpful specific error > message instead of a generic one. > > Maybe "silence CID #XXX"? I like "silences", yes. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On Sat, Feb 06, 2016 at 06:37:56PM +0100, Mats Peterson wrote: > On 02/06/2016 06:25 PM, wm4 wrote: > >A regression in VLC. Make them fix it. > > > > > VLC = Very Lame Crap. Just kidding. > Please refrain from such comment, even for "kidding". Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] build: use a link instead of changing current directory when compiling
On Sat, Feb 06, 2016 at 04:26:43PM +0100, Andreas Cadhalpun wrote: > On 03.02.2016 00:41, Andreas Cadhalpun wrote: > > I see, it passes '-b $(SRC_PATH)' to lcov, which is now unnecessary/harmful > > for out-of-tree builds using the src link. > > The first attached patch changes it to simply use the current directory in > > that case. > > The second patch was necessary to fix the following error: > > lcov: ERROR: cannot write to coverage.info! > > > > Does it work for you without that patch? > > I'd still be interested in an answer, but I've pushed the patches now to > unbreak coverage.ffmpeg.org. > I'm really sorry, I didn't have time to try out this week. Thanks for the fix, coverage.ffmpeg.org is up again. About providing more information than a 404 when there is an error, that would indeed be better, but I lack time currently, and this is really not a priority for me. I'll check if both patches are necessary in a moment. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add conditional filter
On 2/5/16, Paul B Mahol wrote:
> On 2/5/16, Paul B Mahol wrote:
>> Hi,
>>
>> patch attached.
>>
>
> Improved version attached.
>
Much better version attached.
From 9d9cbbb1c92bbd415bcfb45b4b93346ed66ee88e Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 5 Feb 2016 12:54:06 +0100
Subject: [PATCH] avfilter: add conditional filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 30
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_conditional.c | 402 +++
4 files changed, 434 insertions(+)
create mode 100644 libavfilter/vf_conditional.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 664ebe8..ee1bac2 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4662,6 +4662,36 @@ For example to convert from BT.601 to SMPTE-240M, use the command:
colormatrix=bt601:smpte240m
@end example
+@section conditional
+
+Conditionaly pass video frames to different filtergraph depending on
+result of expression evaluation.
+
+The filter accepts the following options:
+
+@table @option
+@item expr
+Specify expression evaluation. Default is always true.
+
+@item true
+Set filtergraph to be used when expression evaluation is true.
+By default it is to do absolutely nothing with frames.
+
+@item false
+Set filtergraph to be used when expression evaluation is false.
+By default it is to do absolutely nothing with frames.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Apply negate and vflip filter for frames with PTS greater than 10.
+@example
+conditional='gte(PTS,10)':'negate,vflip':null
+@end example
+@end itemize
+
@section convolution
Apply convolution 3x3 or 5x5 filter.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e76d18e..8ffd693 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -123,6 +123,7 @@ OBJS-$(CONFIG_COLORCHANNELMIXER_FILTER) += vf_colorchannelmixer.o
OBJS-$(CONFIG_COLORKEY_FILTER) += vf_colorkey.o
OBJS-$(CONFIG_COLORLEVELS_FILTER)+= vf_colorlevels.o
OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o
+OBJS-$(CONFIG_CONDITIONAL_FILTER)+= vf_conditional.o
OBJS-$(CONFIG_CONVOLUTION_FILTER)+= vf_convolution.o
OBJS-$(CONFIG_COPY_FILTER) += vf_copy.o
OBJS-$(CONFIG_COVER_RECT_FILTER) += vf_cover_rect.o lavfutils.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 27d54bc..d4d37c9 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -144,6 +144,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(COLORKEY, colorkey, vf);
REGISTER_FILTER(COLORLEVELS,colorlevels,vf);
REGISTER_FILTER(COLORMATRIX,colormatrix,vf);
+REGISTER_FILTER(CONDITIONAL,conditional,vf);
REGISTER_FILTER(CONVOLUTION,convolution,vf);
REGISTER_FILTER(COPY, copy, vf);
REGISTER_FILTER(COVER_RECT, cover_rect, vf);
diff --git a/libavfilter/vf_conditional.c b/libavfilter/vf_conditional.c
new file mode 100644
index 000..0c5542d
--- /dev/null
+++ b/libavfilter/vf_conditional.c
@@ -0,0 +1,402 @@
+/*
+ * Copyright (c) 2016 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * conditional video filter
+ */
+
+#include "libavutil/attributes.h"
+#include "libavutil/avstring.h"
+#include "libavutil/avassert.h"
+#include "libavutil/eval.h"
+#include "libavutil/opt.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/internal.h"
+#include "libavutil/time.h"
+#include "libavutil/timestamp.h"
+#include "libavformat/avformat.h"
+#include "audio.h"
+#include "avfilter.h"
+#include "buffersink.h"
+#include "buffersrc.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+static const char *const var_names[] = {
+"FRAME_RATE", ///< defined only for constant frame-rate video
+"INTERLACED", ///< tell if the current frame is interlaced
+"N_IN",///< number of consumed frame, starting at zero
+"N_OUT", ///< number of returned frame, starting at zero
+"POS", ///< original position in the file of the frame
+"PTS", ///< original pts in the file of
Re: [FFmpeg-devel] [FFmpeg-cvslog] build: use a link instead of changing current directory when compiling
On Wed, Feb 03, 2016 at 12:41:01AM +0100, Andreas Cadhalpun wrote: [...] > The second patch was necessary to fix the following error: > lcov: ERROR: cannot write to coverage.info! > > Does it work for you without that patch? > I confirm it fails the same way as you without the second patch. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add metadata filters
On 2/6/16, Moritz Barsnick wrote:
> On Sat, Feb 06, 2016 at 12:47:25 +0100, Paul B Mahol wrote:
>> patch attached.
>
> Nice. (Untested.)
>
>
>
>> +Manipulate frames metadata.
> Either:
> frame metadata [using this as a generic term]
> or:
> frames' metadata
>
> I prefer the former.
>
>> +If both @code{value} and @code{key} is set, select frame
> ^ frames (plural)
>> +every frame that have such key in metadata.
> has (singular)
>
>> +Print key and value if metadata was found.
> I'm not sure I've understood whether this can apply to only matching
> metadata (key, key/value), or to any metadata.
>
>> +Set metadata value which will be used. This option is mandatory for
>> modify
>> +and add mode.
> for 'modify' and 'add' modes (note the quoting and the plural).
>
>> +Set length of how much characters of two metadata values need to match to
>> be
> many
All should be resolved in newer version. Thanks for feedback.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add metadata filters
On 2/6/16, Paul B Mahol wrote:
> Hi,
>
> patch attached.
>
Improved version attached.
From 46283dd6b38ce8f1346249707986212546026e39 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sat, 6 Feb 2016 11:19:45 +0100
Subject: [PATCH] avfilter: add metadata filters
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 65 +++
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 2 +
libavfilter/f_metadata.c | 282 +++
4 files changed, 351 insertions(+)
create mode 100644 libavfilter/f_metadata.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 664ebe8..fa33491 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8444,6 +8444,71 @@ format=rgb24,mergeplanes=0x000102:yuv444p
@end example
@end itemize
+@section metadata, ametadata
+
+Manipulate frame metadata.
+
+This filter accepts the following options:
+
+@table @option
+@item m
+Set mode of operation of the filter.
+
+Can be one of the following:
+
+@table @samp
+@item select
+If both @code{value} and @code{key} is set, select frames
+which have such metadata. If only @code{key} is set, select
+every frame that has such key in metadata.
+
+@item add
+Add new metadata @code{key} and @code{value}. If key is already available
+do nothing.
+
+@item modify
+Modify value of already present key.
+
+@item delete
+If @code{value} is set, delete only keys that have such value.
+Otherwise, delete key.
+
+@item print
+Print key and value if metadata was found.
+@end table
+
+@item key
+Set key used with all modes, Must be set.
+
+@item value
+Set metadata value which will be used. This option is mandatory for
+@code{modify} and @code{add} mode.
+
+@item length
+Set length of how many characters of two metadata values need to match to be
+considered same. Default is all available characters.
+
+@item function
+Which function to use when comparing metadata value and @code{value}.
+
+Can be one of following:
+
+@table @samp
+@item string
+Values are interpreted as strings, returns true if @code{value} is same as metadata value up
+to N chars as set in @code{length} option.
+
+@item less
+Values are interpreted as floats, returns true if @code{value} is less than metadata value.
+
+@item equal
+Values are interpreted as floats, returns true if @code{value} is equal with metadata value.
+
+@item greater
+Values are interpreted as floats, returns true if @code{value} is greater than metadata value.
+@end table
+@end table
+
@section mpdecimate
Drop frames that do not differ greatly from the previous frame in
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e76d18e..852b60d 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -39,6 +39,7 @@ OBJS-$(CONFIG_AINTERLEAVE_FILTER)+= f_interleave.o
OBJS-$(CONFIG_ALIMITER_FILTER) += af_alimiter.o
OBJS-$(CONFIG_ALLPASS_FILTER)+= af_biquads.o
OBJS-$(CONFIG_AMERGE_FILTER) += af_amerge.o
+OBJS-$(CONFIG_AMETADATA_FILTER) += f_metadata.o
OBJS-$(CONFIG_AMIX_FILTER) += af_amix.o
OBJS-$(CONFIG_ANULL_FILTER) += af_anull.o
OBJS-$(CONFIG_APAD_FILTER) += af_apad.o
@@ -185,6 +186,7 @@ OBJS-$(CONFIG_LUTYUV_FILTER) += vf_lut.o
OBJS-$(CONFIG_MASKEDMERGE_FILTER)+= vf_maskedmerge.o framesync.o
OBJS-$(CONFIG_MCDEINT_FILTER)+= vf_mcdeint.o
OBJS-$(CONFIG_MERGEPLANES_FILTER)+= vf_mergeplanes.o framesync.o
+OBJS-$(CONFIG_METADATA_FILTER) += f_metadata.o
OBJS-$(CONFIG_MPDECIMATE_FILTER) += vf_mpdecimate.o
OBJS-$(CONFIG_NEGATE_FILTER) += vf_lut.o
OBJS-$(CONFIG_NNEDI_FILTER) += vf_nnedi.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 27d54bc..a904402 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -59,6 +59,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(ALIMITER, alimiter, af);
REGISTER_FILTER(ALLPASS,allpass,af);
REGISTER_FILTER(AMERGE, amerge, af);
+REGISTER_FILTER(AMETADATA, ametadata, af);
REGISTER_FILTER(AMIX, amix, af);
REGISTER_FILTER(ANEQUALIZER,anequalizer,af);
REGISTER_FILTER(ANULL, anull, af);
@@ -206,6 +207,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(MASKEDMERGE,maskedmerge,vf);
REGISTER_FILTER(MCDEINT,mcdeint,vf);
REGISTER_FILTER(MERGEPLANES,mergeplanes,vf);
+REGISTER_FILTER(METADATA, metadata, vf);
REGISTER_FILTER(MPDECIMATE, mpdecimate, vf);
REGISTER_FILTER(NEGATE, negate, vf);
REGISTER_FILTER(NNEDI, nnedi, vf);
diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c
new file mode 100644
index 000..f7195f1
--- /dev/null
+++ b/libavfilter/f_metadata.c
@@ -0,0 +1
Re: [FFmpeg-devel] [PATCH] avformat/mp3enc: Assert that the header we assembled is valid
On Sat, Feb 06, 2016 at 02:46:19PM -0500, Ronald S. Bultje wrote: > Hi, > > On Sat, Feb 6, 2016 at 10:50 AM, Nicolas George wrote: > > > L'octidi 18 pluviôse, an CCXXIV, James Almer a écrit : > > > The couple times i dealt with a trac ticket that wasn't a bug i used > > > "addressed" instead of "fixed". > > > > I would say it "addresses" a ticket if the ticket is valid but the commit > > does not really fix the issue, for example print a helpful specific error > > message instead of a generic one. > > > > Maybe "silence CID #XXX"? > > > I like "silences", yes. ok, applied with silences and a few more words for verbosity thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/12] avformat/ffmenc: use ff_parse_creation_time_metadata
On Sat, Feb 06, 2016 at 08:13:17PM +0100, Marton Balint wrote:
> FYI this muxer bails out on parse error and not just warn the user.
>
> Signed-off-by: Marton Balint
> ---
> libavformat/ffmenc.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/ffmenc.c b/libavformat/ffmenc.c
> index f0b5743..bbab1db 100644
> --- a/libavformat/ffmenc.c
> +++ b/libavformat/ffmenc.c
> @@ -221,17 +221,13 @@ static int ffm_write_recommended_config(AVIOContext
> *pb, AVCodecContext *ctx, un
> static int ffm_write_header(AVFormatContext *s)
> {
> FFMContext *ffm = s->priv_data;
> -AVDictionaryEntry *t;
> AVStream *st;
> AVIOContext *pb = s->pb;
> AVCodecContext *codec;
> int bit_rate, i, ret;
>
> -if (t = av_dict_get(s->metadata, "creation_time", NULL, 0)) {
> -ret = av_parse_time(&ffm->start_time, t->value, 0);
> -if (ret < 0)
> -return ret;
> -}
> +if ((ret = ff_parse_creation_time_metadata(s, &ffm->start_time, 0) < 0))
the () is wrongly placed
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- 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 01/12] avutil/parseutils: use microsecond precision when parsing "now" in av_parse_time()
On Sat, Feb 06, 2016 at 08:13:12PM +0100, Marton Balint wrote: > Use av_gettime() instead of time(0) for querying current time. > > Signed-off-by: Marton Balint > --- > libavutil/parseutils.c| 12 +++- > tests/ref/fate/parseutils | 4 ++-- > 2 files changed, 9 insertions(+), 7 deletions(-) after this (whole) patchset ./ffmpeg -i lena.pnm -timestamp "2016-01-01 01:01:01" test.mp4 exiftool test.mp4 results in Create Date : 1904:01:01 00:00:00 Modify Date : 1904:01:01 00:00:00 before it does: Create Date : 2016:01:01 00:01:01 Modify Date : 2016:01:01 00:01:01 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette
On 02/06/2016 05:17 AM, Mats Peterson wrote: On 02/06/2016 05:05 AM, Mats Peterson wrote: This patch removes the monowhite switching code for 1 bpp raw AVI without a palette. I don't see any reason to keep it, since it's semantically incorrect to use monowhite for palettized data in my book, it adds unnecessary noise to the code, and it's inconsistent with the rest of the code in FFmpeg. Regarding not being able to produce a working nut file with "ffmpeg -i in.avi -vcodec rawvideo out.nut", it's no more of a regression than not being able to produce a working nut file with the same command line from a 2, 4 or 8 bpp file, since nut currently doesn't have a pal8 mode. In order to produce a working nut file from a 1, 2, 4 or 8 bpp AVI or QuickTime file, force the pixel format with "-pix_fmt rgb24" or similar. For black & white files in order to save space, use "-pix_fmt monow" or "-pix_fmt monob". I have also updated the 1 bpp FATE test files (once again). Mats And I deliberately kept the pal8 placeholders for the future in case you wonder, Michael. Mats Yet another argument for removing this code is that AVI (and BMP indirectly) doesn't have a dedicated grayscale mode like PNG, or explicit black & white mode like TIFF's bilevel mode. Hence it should not use monowhite under any circumstances in my book. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette
On 02/07/2016 02:39 AM, Mats Peterson wrote: On 02/06/2016 05:17 AM, Mats Peterson wrote: On 02/06/2016 05:05 AM, Mats Peterson wrote: This patch removes the monowhite switching code for 1 bpp raw AVI without a palette. I don't see any reason to keep it, since it's semantically incorrect to use monowhite for palettized data in my book, it adds unnecessary noise to the code, and it's inconsistent with the rest of the code in FFmpeg. Regarding not being able to produce a working nut file with "ffmpeg -i in.avi -vcodec rawvideo out.nut", it's no more of a regression than not being able to produce a working nut file with the same command line from a 2, 4 or 8 bpp file, since nut currently doesn't have a pal8 mode. In order to produce a working nut file from a 1, 2, 4 or 8 bpp AVI or QuickTime file, force the pixel format with "-pix_fmt rgb24" or similar. For black & white files in order to save space, use "-pix_fmt monow" or "-pix_fmt monob". I have also updated the 1 bpp FATE test files (once again). Mats And I deliberately kept the pal8 placeholders for the future in case you wonder, Michael. Mats Yet another argument for removing this code is that AVI (and BMP indirectly) doesn't have a dedicated grayscale mode like PNG, or explicit black & white mode like TIFF's bilevel mode. Hence it should not use monowhite under any circumstances in my book. Mats The BMP code in FFmpeg handles this correctly by using pal8 exclusively for 1 bpp. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette
On 02/07/2016 02:45 AM, Mats Peterson wrote: The BMP code in FFmpeg handles this correctly by using pal8 exclusively for 1 bpp. Speaking of BMP, "ffmpeg -i 1bpp.bmp -vcodec rawvideo out.nut" will fail as well (since BMP correctly uses pal8), so if there ever was a "regression", it was there before my patch. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86/cpu: set avxslow cpuflag on bdver4 and btver2 CPUs
They are also slow when using 256 bit wide registers Signed-off-by: James Almer --- See https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=3a33f4ce8ea1efdebec7f7138d00e9be9a12d630 libavutil/x86/cpu.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/libavutil/x86/cpu.c b/libavutil/x86/cpu.c index f57d72d..bb63daa 100644 --- a/libavutil/x86/cpu.c +++ b/libavutil/x86/cpu.c @@ -182,13 +182,11 @@ int ff_get_cpu_flags_x86(void) /* Similar to the above but for AVX functions on AMD processors. This is necessary only for functions using YMM registers on Bulldozer - based CPUs as they lack 256-bits execution units. SSE/AVX functions - using XMM registers are always faster on them. + and Jaguar based CPUs as they lack 256-bits execution units. SSE/AVX + functions using XMM registers are always faster on them. AV_CPU_FLAG_AVX and AV_CPU_FLAG_AVXSLOW are both set so that AVX is - used unless explicitly disabled by checking AV_CPU_FLAG_AVXSLOW. - TODO: Confirm if Excavator is affected or not by this once it's - released, and update the check if necessary. Same for btver2. */ -if (family == 0x15 && (rval & AV_CPU_FLAG_AVX)) + used unless explicitly disabled by checking AV_CPU_FLAG_AVXSLOW. */ +if ((family == 0x15 || family == 0x16) && (rval & AV_CPU_FLAG_AVX)) rval |= AV_CPU_FLAG_AVXSLOW; } -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/12] avutil/parseutils: use microsecond precision when parsing "now" in av_parse_time()
On Sun, 7 Feb 2016, Michael Niedermayer wrote: On Sat, Feb 06, 2016 at 08:13:12PM +0100, Marton Balint wrote: Use av_gettime() instead of time(0) for querying current time. Signed-off-by: Marton Balint --- libavutil/parseutils.c| 12 +++- tests/ref/fate/parseutils | 4 ++-- 2 files changed, 9 insertions(+), 7 deletions(-) after this (whole) patchset ./ffmpeg -i lena.pnm -timestamp "2016-01-01 01:01:01" test.mp4 exiftool test.mp4 results in Create Date : 1904:01:01 00:00:00 Modify Date : 1904:01:01 00:00:00 Hmm, apparently I missed the fact iso 8601 time specs can have timezone specifiers as well, even if they were not parsed but silently ignored by the existing function. I will rework the second patch to fix that. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette
On 02/07/2016 03:26 AM, Mats Peterson wrote: On 02/07/2016 02:45 AM, Mats Peterson wrote: The BMP code in FFmpeg handles this correctly by using pal8 exclusively for 1 bpp. Speaking of BMP, "ffmpeg -i 1bpp.bmp -vcodec rawvideo out.nut" will fail as well (since BMP correctly uses pal8), so if there ever was a "regression", it was there before my patch. The same goes for any input file that is stored as pal8 internally. Since nut doesn't have a pal8 mode, it will incorrectly use the RGB[15] codec tag for some reason, but the data in the file will still be 8 bpp. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
