d is strictly a
feature patch. There are no API changes. Behavior does not change for
any previously valid inputs.
Signed-off-by: Kevin Mark
---
libavfilter/scale.c | 72 ++---
1 file changed, 68 insertions(+), 4 deletions(-)
diff --git a/libavf
Update the filters documentation to include the new scale2ref
constants.
Signed-off-by: Kevin Mark
---
doc/filters.texi | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index a0ab2fb0c7..ff41402f7e 100644
--- a
Signed-off-by: Kevin Mark
---
doc/filters.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index ff41402f7e..948e43deca 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12459,7 +12459,7 @@ is 1.
@itemize
@item
-Scale a
ssed.
On Sat, May 27, 2017 at 10:49 AM, Gyan wrote:
> On Sat, May 27, 2017 at 7:40 PM, Kevin Mark wrote:
>
> > Variables pertaining to the non-reference video are now available when
> > using the scale2ref filter. This allows scaling a video with another
> > as a referenc
On Sat, May 27, 2017 at 8:30 PM, Michael Niedermayer
wrote:
> should be merged with the patch that adds these constants
>
> thx
I'll include this with the other updated patch.
Thanks,
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://f
On Sat, May 27, 2017 at 1:36 PM, Gyan wrote:
> It's weird, given those uses cases - overlays - to override the operand's
> native aspect ratio. I'd say, a design oversight, at least.
I agree. I'm not aware of any common workflow that you would have
subtitles (transparent PNGs or something) that w
On Sat, May 27, 2017 at 8:29 PM, Michael Niedermayer
wrote:
> main_*
> and
> ref_*
>
> are maybe prefixes that would work without conflicting with the
> existing ones
I'm partial to main_* since when I think of ref_* that makes me think
of the input being used "as basis" (in the words of the docu
On Sun, May 28, 2017 at 12:14 PM, Gyan wrote:
> If you do, I suggest 'mdar' for main_dar which is the only one that ought
> to be required.
>
> The scale filter adjusts the SAR of the result so that the DAR is preserved
> i.e. when a 100x100 canvas w/ SAR of 2.0 is scaled to 50x100, the result
> w
The applicable documentation has also been updated.
Signed-off-by: Kevin Mark
---
doc/filters.texi| 26 ++-
libavfilter/scale.c | 72 ++---
2 files changed, 93 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi
I'm hoping this is the proper means of submitting an updated patch. I
used git send-email with the --in-reply-to option set to the
Message-Id of my original patch. It looks like it created a new patch
in Patchwork (instead of updating the old one) and I'm not sure if
that's what we want it to do. T
On Tue, May 30, 2017 at 10:40 AM, Kevin Mark wrote:
> +const AVFilterLink *main;
Unfortunately that line results in a warning on GCC (but not LLVM):
libavfilter/scale.c: In function ‘ff_scale_eval_dimensions’:
libavfilter/scale.c:121:25: warning: ‘main’ is usually a function [-Wm
The applicable documentation has also been updated.
Signed-off-by: Kevin Mark
---
doc/filters.texi| 26 ++-
libavfilter/scale.c | 72 ++---
2 files changed, 93 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi
On Fri, Jun 2, 2017 at 9:16 PM, James Almer wrote:
> This broke 820 tests with Valgrind. All of them seem to point to
>
> ==1253== Invalid read of size 8
> ==1253==at 0x697ECA: ff_scale_eval_dimensions (scale.c:118)
scale.c:118:
const char scale2ref = outlink->src->inputs[1] == inlink;
I be
On Fri, Jun 2, 2017 at 9:37 PM, Kevin Mark wrote:
> On Fri, Jun 2, 2017 at 9:16 PM, James Almer wrote:
>> This broke 820 tests with Valgrind.
Patch has been submitted. Thanks again for the report!
___
ffmpeg-devel mailing list
ffmpeg-devel@f
scale2ref check that
makes certain two inputs are actually available before attempting to
access the second one.
Thanks to James Almer for reporting this bug. This should fix the 820
Valgrind tests I single-handedly managed to break.
Signed-off-by: Kevin Mark
---
libavfilter/scale.c | 2 +-
1
nt.
This is currently the only test for scale2ref.
Signed-off-by: Kevin Mark
---
tests/fate/filter-video.mak | 4
tests/filtergraphs/scale2ref_keep_aspect| 5 +
tests/ref/fate/filter-scale2ref_keep_aspect | 14 ++
3 files changed, 23 insertions(+
On Thu, Jun 1, 2017 at 5:37 PM, Michael Niedermayer
wrote:
> applied
>
> can you add a fate test that uses the new identifers ?
>
> Thanks
Certainly. Submitted a patch for a scale2ref-specific test.
Thanks,
Kevin
___
ffmpeg-devel mailing list
ffmpeg-de
On Sun, Jun 4, 2017 at 4:19 AM, Gyan wrote:
> Now that this feature has been applied, it may be helpful to check if one
> of the W/H arguments is of the form '-n' and log a warning that this will
> force the ref's display aspect ratio. The warning should also convey the
> expression to use: 'oh*m
rgb24 sar:1/1 flags:0xc
New format for scale2ref:
in w:320 h:240 fmt:rgb24 sar:1/1
ref w:640 h:360 fmt:rgb24 sar:1/1
out w:160 h:120 fmt:rgb24 sar:4/3 flags:0x2
The increase in clarity is self-evident.
Signed-off-by: Kevin Mark
---
libavfilter/vf_scale.c | 15 ---
1 fil
* 320) / (160 * 240)) * (1 / 1) = 1 / 1
DAR: (160 / 120) * (1 / 1) = 4 / 3
(main out same DAR as main in)
The scale2ref FATE test has also been updated.
Signed-off-by: Kevin Mark
---
libavfilter/vf_scale.c | 6 +++---
tests/ref/fate/filter-scale2ref_keep_aspect | 2 +-
2
We have floor, ceil, and trunc. Let's add round.
Signed-off-by: Kevin Mark
---
doc/utils.texi | 3 +++
libavutil/eval.c | 5 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/doc/utils.texi b/doc/utils.texi
index 1734439459..d65bdf0b0e 100644
--- a/doc/utils.texi
+++
According to libavfilter/scale.c, if the width and height are both
less than or equal to 0 then the input size is used for both
dimensions. It does not need to be -1. -1:-1 is the same as 0:0 which
is the same as -10:-42, etc.
if (w < 0 && h < 0)
eval_w = eval_h = 0;
Signed
On Tue, Jun 6, 2017 at 11:49 AM, Michael Niedermayer
wrote:
> yes but its much harder to grep for as its not a single line anymore
I agree that it's not going to be as pretty a regular expression to
grep through, as there is 33% more data, but it should still be doable
without too much effort. Ho
Hey Moritz,
Thanks for the feedback.
On Tue, Jun 6, 2017 at 7:59 AM, Moritz Barsnick wrote:
> This makes it obvious that the paragraph following the one you fixed is
> a bit misleading (to me):
>
> If one of the values is -n with n > 1, the scale filter will also
> use a value that maint
s
not need to handle 0 input. w/h will always be > 0 or < 0.
Signed-off-by: Kevin Mark
---
libavfilter/scale.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
index 03745ddcb8..cc2bea5caf 100644
--- a/libavfilter/s
Unfortunately I have to withdraw this patch. I'll be submitting an
updated one shortly. The below lines allow through values that are 0
when casted/truncated to an integer but are not zero as doubles (like
-0.1).
On Wed, Jun 7, 2017 at 2:11 AM, Kevin Mark wrote:
> -eval_w = va
s
not need to handle 0 input. w/h will always be > 0 or < 0.
Signed-off-by: Kevin Mark
---
libavfilter/scale.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
index 03745ddcb8..a6c32e3978 100644
--- a/libavfilter/s
I also have to wonder if it would be advantageous to add the cast on
the right side as well. That way the var_values variables will have
the proper truncated values on future evaluations. Open to comments on
that.
On Wed, Jun 7, 2017 at 3:45 AM, Kevin Mark wrote:
> -eval_w = var_val
scale and scale2ref)
and I can't find a case of my own where the regex I proposed would be
troublesome.
Thanks,
Kevin
On Tue, Jun 6, 2017 at 4:17 PM Kevin Mark wrote:
> On Tue, Jun 6, 2017 at 11:49 AM, Michael Niedermayer
> wrote:
> > yes but its much harder to grep for as its not
I've been using this patch for the past week now and I believe it's
good to go. Does someone want to take a second look before merging?
On Mon, Jun 5, 2017 at 6:55 AM, Kevin Mark wrote:
> The scale2ref filter will now maintain the DAR of the main input and
> not the DAR of the
I screwed up my git-send-email. Please ignore this patch as I already
submitted what should be an identical one on June 7th. My apologies.
On Mon, Jun 12, 2017 at 1:51 AM, Kevin Mark wrote:
> The input width and height is known at parse time so there's no
> reason ow/oh should not be
umentation for the zscale filter has also been updated since the
behavior is identical.
Signed-off-by: Kevin Mark
---
doc/filters.texi | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 65eef89d
s
not need to handle 0 input. w/h will always be > 0 or < 0.
Signed-off-by: Kevin Mark
---
libavfilter/scale.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
index 03745ddcb8..a6c32e3978 100644
--- a/libavfilter/s
Still interested in thoughts on this patch/discussion.
Thanks,
Kevin
On Wed, Jun 7, 2017 at 3:54 AM, Kevin Mark wrote:
> I also have to wonder if it would be advantageous to add the cast on
> the right side as well. That way the var_values variables will have
> the proper truncated
On Mon, Jun 12, 2017 at 9:42 PM, Michael Niedermayer
wrote:
> why is there a cast at all ?
The cast is there because if you run this:
ffmpeg -frames:v 5 -filter_complex
"sws_flags=+accurate_rnd+bitexact;testsrc=size=320x240
[main];testsrc=size=640x360 [ref];[main][ref]
scale2ref=0:print(ow/641)
On Tue, Jun 13, 2017 at 10:04 PM, Michael Niedermayer
wrote:
> ok, makes sense
> i agree the 2nd cast seems a good idea
Great, thanks Michael. I'll submit an updated patch with the additional cast.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
s
not need to handle 0 input. w/h will always be > 0 or < 0.
The second explicit (int) cast ensures that ow/oh appear as integers
as a user might expect when dealing with pixel dimensions.
Signed-off-by: Kevin Mark
---
libavfilter/scale.c | 13 +
1 file changed, 5 insertions(+
Ronald Bultje via IRC recommended I ask on the mailing list for push access
to the FFmpeg repository so that I may push my own patches once approved.
If someone with the access to do so could please consider this request it
would be greatly appreciated.
Thank you,
Kevin
___
On Tue, Jun 20, 2017 at 7:14 AM, Michael Niedermayer
wrote:
> If you want push access, please send a patch that adds you to the
> MAINTAINERs file
> after the patch has been applied, you get push access
>
> (by going throgh this extra step changes to the git access list are
> public, are logged a
Hey Ronald,
Was this able to solve the issue for you?
On Mon, Jul 24, 2017 at 6:27 AM, Kevin Mark wrote:
> Hi Ronald,
>
> On Wed, Jul 19, 2017 at 3:44 AM, Ronald S. Bultje wrote:
>> But my grep (Mac) has no -P option... I'd encourage you to keep things
>> simple
Hi Ronald,
On Sat, Sep 23, 2017 at 11:54 AM, Ronald S. Bultje wrote:
>
> Yes, -E works on Mac.
Thanks! Are there any remaining blockers for a potential merge?
Best regards,
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/
Ping :)
On Mon, Jun 12, 2017 at 1:08 AM, Kevin Mark wrote:
> I've been using this patch for the past week now and I believe it's
> good to go. Does someone want to take a second look before merging?
>
> On Mon, Jun 5, 2017 at 6:55 AM, Kevin Mark wrote:
>> The scale2
Hello all,
Just wondering if anyone had any thoughts on the grepability issue,
which I believe is the only potential issue/breaking change with this
patch.
Thanks,
Kevin
On Sun, Jun 11, 2017 at 9:59 PM, Kevin Mark wrote:
> Hi Michael,
>
> Hoping to get your thoughts on the grepabil
On Tue, Jun 6, 2017 at 1:17 PM, Kevin Mark wrote:
> It also works with BSD grep 2.5.1-FreeBSD included in macOS if you use
> the -E option instead of -P.
Thanks,
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
44 matches
Mail list logo
