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-off-by: Kevin Mark
Dear Moritz,
On Mon, Jun 5, 2017 at 3:21 PM, Moritz Barsnick wrote:
> I can't comment on the rest (and still really like the concept), but
> just this:
>
>> +Allowed values are positive integers between @code{1} and @code{65535}.
>
> This maximum value is no longer correct.
It's correct as far a
On 03.06.2017 08:41, Steven Liu wrote:
2017-06-03 0:30 GMT+08:00 Nicolas George :
Le quintidi 15 prairial, an CCXXV, Steven Liu a écrit :
add time info into every line of log report
the time info can be used to find out error message occur time.
Signed-off-by: Steven Liu
---
cmdutils.c | 8
On date Saturday 2017-05-27 00:07:38 +0200, Michael Niedermayer encoded:
> On Wed, May 24, 2017 at 10:31:10AM +0200, Stefano Sabatini wrote:
[...]
> > mpegvideo_enc.c |6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> > 0fa1dff6e9dbb5122cbea81ba56eb1892a0bb398
> > 0003-lavc-mpe
On Tue, Jun 06, 2017 at 10:09:04 +0100, Matthias Troffaes wrote:
> > This maximum value is no longer correct.
> It's correct as far as I can tell. From the code:
Sorry, you're right and I'm wrong. I missed the change to int64.
> > Just wondering: Isn't this also useful for a slideshow-like
> > tr
On Tue, Jun 06, 2017 at 03:27:06 -0400, Kevin Mark wrote:
> 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.
This
On Tue, Jun 06, 2017 at 11:42:10 +0200, Tobias Rapp wrote:
> And it would be good if the timestamp prefix would be made optional
> similar to the AV_LOG_PRINT_LEVEL flag.
Yes indeed, please. It's already hard diff'ing two logfiles, this would
require even more awk-ward stuff on the command line (
Hi,
On Mon, Jun 5, 2017 at 4:08 PM, Vittorio Giovara wrote:
> Signed-off-by: Vittorio Giovara
> ---
> libavfilter/vf_colorspace.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> index 0024505a44..0b1bc81f99 1006
Hi,
On Mon, Jun 5, 2017 at 1:41 PM, James Almer wrote:
> On 6/4/2017 2:52 PM, Ilia Valiakhmetov wrote:
> > vp9_diag_downleft_32x32_8bpp_c: 580.2
> > vp9_diag_downleft_32x32_8bpp_sse2: 75.6
> > vp9_diag_downleft_32x32_8bpp_ssse3: 73.7
> > vp9_diag_downleft_32x32_8bpp_avx: 72.7
> > vp9_diag_downle
Hi,
On Mon, Jun 5, 2017 at 8:02 AM, Ronald S. Bultje wrote:
> On Mon, Jun 5, 2017 at 7:23 AM, James Darnley wrote:
>
>> I forgot to mention in my cover letter that although the dct test
>> passes, fate does not. As I mentioned on IRC, changing them causes
>> errors elsewhere in fate. I am cur
On Sat, 3 Jun 2017 19:31:37 -0700
Sasi Inguva wrote:
> > -// Offset the DTS by ctts[0] to make the PTS of the first frame 0
> > -if (ctts_data_old && ctts_count_old > 0) {
> > -edit_list_dts_entry_end -= ctts_data_old[0].duration;
> > -av_log(mov->fc, AV_LOG_DEBUG, "Offset
On Tue, 6 Jun 2017 04:59:58 +0200
Michael Niedermayer wrote:
> I disagree that the issue is minor and far fetched.
>
> The exploit that i have was successfully used against multiple
> companies (it was a demonstration and AFAIK no harm was done).
> That same attack works against all recent relea
On Sun, 4 Jun 2017 02:25:46 +0200
Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/utils.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index c5f1eac185..bbc7a7b547 100644
>
On Sat, 3 Jun 2017 10:54:08 -0700
Aaron Levinson wrote:
> On 6/2/2017 7:11 AM, wm4 wrote:
> > On Fri, 2 Jun 2017 15:29:07 +0200
> > Hugo Beauzée-Luyssen wrote:
> >
> >> ---
> >> compat/w32dlfcn.h | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/compat/w32dlfcn.h b/com
Switches temporary samples for processing to be stored in the encoder's
context, avoids memory leaks if any errors occur while encoding a frame.
Fixes CID1412026
Signed-off-by: Tyler Jones
---
libavcodec/vorbisenc.c | 49 -
1 file changed, 12 inser
On 6/1/2017 8:10 PM, James Almer wrote:
> Meant for DSP functions returning a float or double, as they'd fail if emms
> is called after every run on x86_32.
>
> Signed-off-by: James Almer
> ---
> tests/checkasm/checkasm.h | 11 +++
> tests/checkasm/x86/checkasm.asm | 13 +++
On Tue, Jun 06, 2017 at 03:57:22PM +0200, wm4 wrote:
> On Sun, 4 Jun 2017 02:25:46 +0200
> Michael Niedermayer wrote:
>
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/utils.c | 11 ++-
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavformat
On Tue, Jun 06, 2017 at 12:43:13AM -0400, Kevin Mark wrote:
> 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(-)
applied
thx
[...]
--
Michael GnuPG
On Mon, Jun 05, 2017 at 06:55:20AM -0400, Kevin Mark wrote:
> This change makes it more clear when using the scale and scale2ref
> filters what is actually happening. The old format did not
> differentiate between scale and scale2ref which would make it seem
> that, when using scale2ref, the ref wa
On Mon, Jun 5, 2017 at 1:22 PM, Aman Gupta wrote:
> From: Aman Gupta
>
> Android TV and FireOS hardware supports mpeg2 hardware decoding via
> MediaCodec.
>
I tested this patch on an NVIDIA SHIELD, FireTV gen1 and FireTV Stick gen2
and they all worked as expected.
Let me know if you want me to
On 6 June 2017 at 15:06, Tyler Jones wrote:
> Switches temporary samples for processing to be stored in the encoder's
> context, avoids memory leaks if any errors occur while encoding a frame.
> Fixes CID1412026
>
> Signed-off-by: Tyler Jones
> ---
> libavcodec/vorbisenc.c | 49
Fixes t/6421. If the videos starts with B frame, then the minimum composition
time as computed by stts + ctts will be non-zero. Hence we need to shift the
DTS, so that the first pts is zero. This was the intention of that code-block.
However it was subtracting by the wrong amount.
For example, f
Got it. Added to the description.
On Tue, Jun 6, 2017 at 6:51 AM, wm4 wrote:
> On Sat, 3 Jun 2017 19:31:37 -0700
> Sasi Inguva wrote:
>
> > > -// Offset the DTS by ctts[0] to make the PTS of the first frame 0
> > > -if (ctts_data_old && ctts_count_old > 0) {
> > > -edit_list_dts
On Tue, 6 Jun 2017, Michael Niedermayer wrote:
On Mon, Jun 05, 2017 at 05:33:29PM +0200, Nicolas George wrote:
Le septidi 17 prairial, an CCXXV, Michael Niedermayer a écrit :
[...]
You dont need to convince me that the extension check or changes
within just hls are not a complete solution. I
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
ff_mpeg1_encode_picture_header: Add support for AV_FRAME_DATA_A53_CC
frame: Add av_frame_get_side_data_at() to allow retrival of multiple side
data of the same type.
---
libavcodec/mpeg12enc.c | 52 ++
libavutil/frame.c | 8
libavu
On Tue, 6 Jun 2017, John Poet wrote:
ff_mpeg1_encode_picture_header: Add support for AV_FRAME_DATA_A53_CC
frame: Add av_frame_get_side_data_at() to allow retrival of multiple side
data of the same type.
As far as I remember multiple side data of the same type is not something
we wanted to
On Tue, Jun 6, 2017 at 11:45 PM, Marton Balint wrote:
>
> On Tue, 6 Jun 2017, John Poet wrote:
>
>> ff_mpeg1_encode_picture_header: Add support for AV_FRAME_DATA_A53_CC
>> frame: Add av_frame_get_side_data_at() to allow retrival of multiple side
>>data of the same type.
>
>
> As far as I remem
On Tue, Jun 6, 2017 at 3:59 PM Hendrik Leppkes wrote:
> On Tue, Jun 6, 2017 at 11:45 PM, Marton Balint wrote:
> >
> > On Tue, 6 Jun 2017, John Poet wrote:
> >
> >> ff_mpeg1_encode_picture_header: Add support for AV_FRAME_DATA_A53_CC
> >> frame: Add av_frame_get_side_data_at() to allow retrival o
>
> The cc_count is only 5 bits, which mean that only 31 3-byte "closed caption
> constructs" will fit in a "block".Testing this with 1080i60 material, I
> found that 2 or 3 blocks was often necessary to hold all of the CC data.
>
> I tried ignoring that limit of 31 "constructs" per block, and
Indeed, multiple entries of the same type are really a bad idea and we
basically made them impossible with stream sidedata, although maybe
not with frame side data yet. We should not add API for them or
encourage their use.
If there is a real need for multiple of the same type, maybe the type
sh
On Tue, Jun 6, 2017 at 4:40 PM Kieran Kunhya wrote:
> >
> > The cc_count is only 5 bits, which mean that only 31 3-byte "closed
> caption
> > constructs" will fit in a "block".Testing this with 1080i60
> material, I
> > found that 2 or 3 blocks was often necessary to hold all of the CC data.
From 5c88956e36e7318cf1d1b7c41a9d4108fcf9d0a5 Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Fri, 12 May 2017 08:30:43 +0800
Subject: [PATCH] lavc/vaapi_encode_h26[45]: respect "slices" in h26[45] vaapi
encoder.
Enable multi-slice support in AVC/HEVC vaapi encoder.
Signed-off-by: Wang, Yi A
Sig
On Mon, Jun 05, 2017 at 08:43:35AM +0800, Jun Zhao wrote:
> V2: Add Add set_ue_golomb_long() to support 32bits UE golomb and update the
> unit test.
> golomb.h | 20 +++-
> put_bits.h | 35 +++
> tests/golomb.c | 19
On 2017/6/7 9:22, Michael Niedermayer wrote:
> On Mon, Jun 05, 2017 at 08:43:35AM +0800, Jun Zhao wrote:
>> V2: Add Add set_ue_golomb_long() to support 32bits UE golomb and update the
>> unit test.
>
>> golomb.h | 20 +++-
>> put_bits.h | 35 ++
The input width and height is known at parse time so there's no
reason ow/oh should not be usable when using 0 as the width or
height expression.
Previously in "scale=0:ow" ow would be set to "0" which works,
conveniently, as "scale=0:0" is perfectly valid input but this breaks
down when you do so
37 matches
Mail list logo
