On Wed, Dec 14, 2016 at 7:27 PM, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> libavfilter/af_atempo.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
> index 59b08ec..93a9c05 100644
> --- a/libav
From: Pavel Koshevoy
---
libavcodec/utils.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 44ecc09..2ad96e4 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2788,8 +2788,6 @@ static int do_decode(AVCodecContext *avctx, AVPacket *pkt
Signed-off-by: Marton Balint
---
libavfilter/af_amerge.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavfilter/af_amerge.c b/libavfilter/af_amerge.c
index 4a8c6d5..3bc7d89 100644
--- a/libavfilter/af_amerge.c
+++ b/libavfilter/af_amerge.c
@@ -93,10 +93,15 @@
This is the right thing to do, but I am afraid this will break too many
existing filter chains. How can we implement this properly? Ideas/options:
- change it, break it, users will fix it
- add a guess_output_layout option which will be true for now, false after a
major bump, and mention this in
On Wed, Dec 14, 2016 at 03:39:59PM -0800, Matthew Wolenetz wrote:
> MPEG Audio frame header must be 4 bytes. If we fail to read
> 4 bytes bail early to avoid Use-of-uninitialized-value msan error.
> Reference https://crbug.com/666874.
> mp3dec.c |3 ++-
> 1 file changed, 2 insertions(+), 1 de
On Wed, Dec 14, 2016 at 03:38:18PM -0800, Matthew Wolenetz wrote:
> In ff_index_search_timestamp(), if b == num_entries,
> m == num_entries - 1, and entries[m].flags & AVINDEX_DISCARD_FRAME is
> true, then the search for the next non-discarded packet could access
> entries[nb_entries], exceeding it
On 12/14/2016 10:39 PM, Andreas Cadhalpun wrote:
> On 15.12.2016 00:34, Matthew Wolenetz wrote:
>>
>> From fd878457cd55690d4a27d74411b68a30c9fb2313 Mon Sep 17 00:00:00 2001
>> From: Matt Wolenetz
>> Date: Fri, 2 Dec 2016 18:10:39 -0800
>> Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in
On 2016/12/15 7:02, Mark Thompson wrote:
> On 14/12/16 01:55, Jun Zhao wrote:
>> From 03030392ec2458679cdfb14802b80cbb196eae40 Mon Sep 17 00:00:00 2001
>> From: Yi A Wang
>> Date: Tue, 13 Dec 2016 10:50:54 +0800
>> Subject: [PATCH] lavc/vaapi_encode_h264: add option to indicate the h264
>> enco
Signed-off-by: Marton Balint
---
libavfilter/af_atempo.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index 59b08ec..93a9c05 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -74,6 +74,7 @@ typ
On 2016/12/15 7:13, Hendrik Leppkes wrote:
> On Thu, Dec 15, 2016 at 12:02 AM, Mark Thompson wrote:
>> On 14/12/16 01:55, Jun Zhao wrote:
>>> From 03030392ec2458679cdfb14802b80cbb196eae40 Mon Sep 17 00:00:00 2001
>>> From: Yi A Wang
>>> Date: Tue, 13 Dec 2016 10:50:54 +0800
>>> Subject: [PATCH]
On 15.12.2016 00:39, Matthew Wolenetz wrote:
> From 141e56ccf7fc56646424484d357b6c74a486d2e2 Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz
> Date: Mon, 21 Nov 2016 17:30:50 -0800
> Subject: [PATCH] lavc/libopusdec.c Fix ff_vorbis_channel_layouts OOB
>
> Similar to existing lavc/vorbisdec.c code
On 15.12.2016 00:37, Matthew Wolenetz wrote:
> From 8622f9398e7c89a664c4c2ceff9d35b89ff17bb5 Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz
> Date: Tue, 6 Dec 2016 12:54:23 -0800
> Subject: [PATCH] lavf/mov.c: Avoid heap allocation wraps and OOB in
> mov_read_{senc,saiz,udta_string}()
>
> Core o
On 15.12.2016 00:36, Matthew Wolenetz wrote:
> From 9d45f272a682b0ea831c20e36f696e15cc0c55fe Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz
> Date: Tue, 6 Dec 2016 12:33:08 -0800
> Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
>
> Core of patch is from p...@paulmehta.co
On 15.12.2016 00:34, Matthew Wolenetz wrote:
>
> From fd878457cd55690d4a27d74411b68a30c9fb2313 Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz
> Date: Fri, 2 Dec 2016 18:10:39 -0800
> Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
>
> Core of patch is from p...@paulmehta
On 11.12.2016 22:51, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/imgutils.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/imgutils.h b/libavutil/imgutils.h
> index 19f34deced..40aee8b98e 100644
> --- a/libavutil/imgutil
Signed-off-by: Andreas Cadhalpun
---
libavformat/pvfdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/pvfdec.c b/libavformat/pvfdec.c
index b9f6d4f..5eecc22 100644
--- a/libavformat/pvfdec.c
+++ b/libavformat/pvfdec.c
@@ -56,6 +56,11 @@ static int pvf_read_header(AVFormat
Signed-off-by: Andreas Cadhalpun
---
libavformat/ircamdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/ircamdec.c b/libavformat/ircamdec.c
index 59f3a49..3efc2b4 100644
--- a/libavformat/ircamdec.c
+++ b/libavformat/ircamdec.c
@@ -96,6 +96,11 @@ static int ircam_read_hea
Signed-off-by: Andreas Cadhalpun
---
libavformat/nistspheredec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/nistspheredec.c b/libavformat/nistspheredec.c
index 782d1df..9472e47 100644
--- a/libavformat/nistspheredec.c
+++ b/libavformat/nistspheredec.c
@@ -80,6 +80,11 @@
Signed-off-by: Andreas Cadhalpun
---
libavformat/4xm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/4xm.c b/libavformat/4xm.c
index 2758b69..308d889 100644
--- a/libavformat/4xm.c
+++ b/libavformat/4xm.c
@@ -187,6 +187,11 @@ static int parse_strk(AVFormatContext *s,
s
Signed-off-by: Andreas Cadhalpun
---
libavformat/electronicarts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index 30eb723..35a7363 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@
Signed-off-by: Andreas Cadhalpun
---
libavformat/genh.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/genh.c b/libavformat/genh.c
index b683e02..5684352 100644
--- a/libavformat/genh.c
+++ b/libavformat/genh.c
@@ -74,6 +74,11 @@ static int genh_read_header(AVFormatContext *
On 14.12.2016 11:16, Moritz Barsnick wrote:
> On Wed, Dec 14, 2016 at 01:02:41 +0100, Andreas Cadhalpun wrote:
>> On 13.12.2016 08:11, Paul B Mahol wrote:
-st->codecpar->bit_rate= samplerate * framesize * 8 / 2048;
+st->codecpar->bit_rate= samplerate * framesize /
Per spec, if cts_offset is negative, the trun box version needs to be set
to 1. Yet I see no corresponding condition around this in
libavformat/movenc.c; version is hardcoded to 0 and the *signed int32*
typed value (track->cluster[i].cts) is written out (with a conversion to
unsigned int32 with sam
This fixes ubsan warnings in non debug builds by using unsigned operations
in debug builds the correct signed operations are retained so that overflows
(which should not occur in valid files and may indicate problems in the DSP code
or decoder) can be detected.
Alternatively they can be changed t
On 14.12.2016 13:34, Michael Niedermayer wrote:
> On Wed, Dec 14, 2016 at 12:57:12AM +0100, Andreas Cadhalpun wrote:
>> tiff.c | 13 +++--
>> 1 file changed, 11 insertions(+), 2 deletions(-)
>> 96297593c98fcbce7395cb13627fae080f1e2cbc
>> 0001-tiff-fix-overflows-when-calling-av_reduce.p
On 14.12.2016 13:36, Michael Niedermayer wrote:
> On Wed, Dec 14, 2016 at 01:58:17AM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/cafdec.c | 9 +++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> probably ok
Pushed.
Best regards,
Andrea
On 14.12.2016 04:24, Michael Niedermayer wrote:
> On Wed, Dec 14, 2016 at 01:58:35AM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/mov.c | 15 ++-
>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/mov.c b/liba
On 14.12.2016 03:54, Michael Niedermayer wrote:
> On Wed, Dec 14, 2016 at 01:57:54AM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/4xm.c | 8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> LGTM
Pushed.
Best regards,
Andreas
_
On Wed, 14 Dec 2016 11:44:13 +0100
wm4 wrote:
> On Wed, 14 Dec 2016 09:30:35 +
> Stève Lhomme wrote:
>
> > On Tue, Dec 13, 2016 at 2:35 PM, wm4 wrote:
> > > On Tue, 13 Dec 2016 14:19:35 +0100
> > > Steve Lhomme wrote:
>
> > >
> > > I'm pretty much against this, since it duplicates the pr
On 14.12.2016 02:46, Ronald S. Bultje wrote:
> Not wanting to discourage you, but I wonder if there's really a point to
> this...?
These patches are prerequisites for enforcing the validity of codec
parameters [1].
> I don't see how the user experience changes.
Users won't see ffmpeg claiming no
Some toolchains failed to link a dynamic library containing wavdec.c,
but with either CONFIG_SPDIF_DEMUXER or CONFIG_W64_DEMUXER disabled.
This change adds #if's to explicitly exclude code rather than depend on
toolchain code elision of same condition using "if".
Reference https://crbug.com/591845.
MPEG Audio frame header must be 4 bytes. If we fail to read
4 bytes bail early to avoid Use-of-uninitialized-value msan error.
Reference https://crbug.com/666874.
From 5ed6e20c09840320784c43b86b75b3ede69742f6 Mon Sep 17 00:00:00 2001
From: Chris Cunningham
Date: Tue, 22 Nov 2016 13:54:50 -0800
Sub
Similar to existing lavc/vorbisdec.c code which first checks that
avc->channels is valid for accessing ff_vorbis_channel_layouts, this
change adds protection to libopusdec.c to prevent accessing that
array with a negative index. Reference https://crbug.com/666794.
From 141e56ccf7fc56646424484d357b6
In ff_index_search_timestamp(), if b == num_entries,
m == num_entries - 1, and entries[m].flags & AVINDEX_DISCARD_FRAME is
true, then the search for the next non-discarded packet could access
entries[nb_entries], exceeding its bounds. This change adds a protection
against that scenario. Reference:
Core of patch is from p...@paulmehta.com
Reference https://crbug.com/643952
From 8622f9398e7c89a664c4c2ceff9d35b89ff17bb5 Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Tue, 6 Dec 2016 12:54:23 -0800
Subject: [PATCH] lavf/mov.c: Avoid heap allocation wraps and OOB in
mov_read_{senc,saiz,udta_
Core of patch is from p...@paulmehta.com
Reference https://crbug.com/643951
From 9d45f272a682b0ea831c20e36f696e15cc0c55fe Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Tue, 6 Dec 2016 12:33:08 -0800
Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
Core of patch is fro
Core of patch is from p...@paulmehta.com
Reference https://crbug.com/643950
From fd878457cd55690d4a27d74411b68a30c9fb2313 Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Fri, 2 Dec 2016 18:10:39 -0800
Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
Core of patch is fro
On Thu, Dec 15, 2016 at 12:02 AM, Mark Thompson wrote:
> On 14/12/16 01:55, Jun Zhao wrote:
>> From 03030392ec2458679cdfb14802b80cbb196eae40 Mon Sep 17 00:00:00 2001
>> From: Yi A Wang
>> Date: Tue, 13 Dec 2016 10:50:54 +0800
>> Subject: [PATCH] lavc/vaapi_encode_h264: add option to indicate the
On 14/12/16 01:55, Jun Zhao wrote:
> From 03030392ec2458679cdfb14802b80cbb196eae40 Mon Sep 17 00:00:00 2001
> From: Yi A Wang
> Date: Tue, 13 Dec 2016 10:50:54 +0800
> Subject: [PATCH] lavc/vaapi_encode_h264: add option to indicate the h264
> encode profile
>
> add h264 encode profile option and
Hi,
I found one bug, where ffmpeg functions can't get precise audio sample rate
when receiving rtmp stream.
1st method:
If avformat_open_input() and avformat_find_stream_info() is used to parse rtmp
stream, audio sample rate can be calculated correctly.
2nd method:
But if av_format_set_audi
As of version 1.6, libopenh264 saves (in the output video file)
information about the color primaries, transfer characteristics,
and color matrix used when the video pixel data was created.
This patch sets the required libopenh264 data structures using
the FFmpeg colorspace information so that vide
Am 14.12.16 um 13:56 schrieb Michael Niedermayer:
> On Tue, Dec 13, 2016 at 08:35:43PM +0100, Thilo Borgmann wrote:
>> Am 12.12.16 um 22:18 schrieb Michael Niedermayer:
>>> Hi all
>>>
>>> The panda arm board iam using as fate client for fate.ffmpeg.org seems
>>> not really able to handle the load.
The libopenh264 library allows the client to enable or disable
load balancing when running multi-threaded. When enabled, the
slice sizes are dynamically adjusted in order to use the
multiple threads more efficiently. However, this can also lead
to valid but slightly different results from run to
On Wed, 14 Dec 2016 14:37:47 +, Andrey Utkin wrote:
> * Added mention of @var{max_glyph_a} to "Note that..." phrase
>(is the markup used for this correct?)
It's basically author's preference since the usage in the docs is
mixed and inconsistent, and we don't have any specific guidelines
On Wed, Dec 14, 2016 at 03:11:45PM +, Gregory J Wolfe wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf Of Michael Niedermayer
> > Sent: Tuesday, December 13, 2016 2:28 PM
> > To: FFmpeg development discussions and patches > de.
> > It has. It points to the position in the options buffer which is going to be
> filled with the command line being parsed. So it's not redundant.
>
> Then what does buffer_filled do?
It keeps track on the number of characters written in the options buffer so
far. I appreciate this could have
- This patch contains the changes to interface the Turing codec
(http://turingcodec.org/) with ffmpeg. The patch was modified to address
the comments in the review as follows:
- Added a pkg-config file to list all dependencies required by
libturing. This should address the issue pointed out
From: Steve Lhomme
Without any optimization flags, MSVC does no dead code elimination (DCE) at
all, even for the most trivial cases. DCE is a prerequisite for building ffmpeg
correctly, otherwise there are undefined references to functions for other
architectures and disabled components.
-Os -Og
On Wed, Dec 14, 2016 at 14:23:05 +, Matteo Naccari wrote:
> Ok, point taken on the av_* functions. On the handling bit, I was
> thinking to flag the error via av_log and then call exit_program(1),
> after, of course, having released the memory allocated up to that
> point. Would that be ok?
C
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf Of Michael Niedermayer
> Sent: Tuesday, December 13, 2016 2:28 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] Allow client to enable/d
Height of canvas produced by drawtext varies depending on symbols in
text, so add example for printing separate texts aligned horizontally.
Wording suggested by Lou Logan
Signed-off-by: Andrey Utkin
---
Changes in v2:
* Taken the wording of example and description Lou proposed
* Added mention
On Wed, 14 Dec 2016 14:23:05 +
Matteo Naccari wrote:
> > Missing error handling, and maybe overflow handling. Also, we don't use
> > malloc/realloc/free, but av_malloc/av_realloc/av_free. I'm not sure why we
> > do this (it doesn't have much of a justification for realloc at least), but
> >
On Wed, Dec 14, 2016 at 3:23 PM, Matteo Naccari
wrote:
>> Missing error handling, and maybe overflow handling. Also, we don't use
>> malloc/realloc/free, but av_malloc/av_realloc/av_free. I'm not sure why we
>> do this (it doesn't have much of a justification for realloc at least), but
>> it's
>>
> Missing error handling, and maybe overflow handling. Also, we don't use
> malloc/realloc/free, but av_malloc/av_realloc/av_free. I'm not sure why we
> do this (it doesn't have much of a justification for realloc at least), but
> it's
> probably better to be consistent.
Ok, point taken on the av
On Tue, Dec 13, 2016 at 08:35:43PM +0100, Thilo Borgmann wrote:
> Am 12.12.16 um 22:18 schrieb Michael Niedermayer:
> > Hi all
> >
> > The panda arm board iam using as fate client for fate.ffmpeg.org seems
> > not really able to handle the load.
> > Iam not sure why, but increasing number of fate
On Wed, Dec 14, 2016 at 01:58:17AM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/cafdec.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
probably ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Thos
On Wed, Dec 14, 2016 at 12:57:12AM +0100, Andreas Cadhalpun wrote:
> On 13.12.2016 01:32, Michael Niedermayer wrote:
> > On Tue, Dec 13, 2016 at 12:50:19AM +0100, Andreas Cadhalpun wrote:
> >> The arguments of av_reduce are signed, so the cast to uint64_t is
> >> misleading.
> >>
> >> Signed-off-b
On Tue, 13 Dec 2016 14:19:35 +0100
Steve Lhomme wrote:
> +static int d3d11va_transfer_data(AVHWFramesContext *ctx, AVFrame *dst,
> + const AVFrame *src)
> +{
> +ID3D11VideoDecoderOutputView *surface;
> +D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESCsurfaceDesc;
On Wed, Dec 14, 2016 at 1:02 AM, Andreas Cadhalpun
wrote:
> On 13.12.2016 08:11, Paul B Mahol wrote:
>> On 12/13/16, Andreas Cadhalpun wrote:
>>> Signed-off-by: Andreas Cadhalpun
>>> ---
>>> libavformat/omadec.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/
On Wed, Dec 14, 2016 at 08:46:28AM +0100, Paul B Mahol wrote:
> On 12/14/16, Michael Niedermayer wrote:
> > On Tue, Dec 13, 2016 at 10:23:48PM +0100, Martin Vignali wrote:
> >> 2016-11-24 21:35 GMT+01:00 Martin Vignali :
> >>
> >> > Hello
> >> >
> >> > New patchs in attach
> >> >
> >> > I changed
On Wed, 14 Dec 2016 09:30:35 +
Stève Lhomme wrote:
> On Tue, Dec 13, 2016 at 2:35 PM, wm4 wrote:
> > On Tue, 13 Dec 2016 14:19:35 +0100
> > Steve Lhomme wrote:
> >
> > I'm pretty much against this, since it duplicates the profile selection
> > code all over again, even if it could be share
On Wed, Dec 14, 2016 at 01:02:41 +0100, Andreas Cadhalpun wrote:
> On 13.12.2016 08:11, Paul B Mahol wrote:
> >> -st->codecpar->bit_rate= samplerate * framesize * 8 / 2048;
> >> +st->codecpar->bit_rate= samplerate * framesize / 256;
>
> Why multiply with 8 when dividing by
On Wed, Dec 14, 2016 at 10:30 AM, Stève Lhomme wrote:
>>
>> I'm pretty much against this, since it duplicates the profile selection
>> code all over again, even if it could be shared. (And this code should
>> be in libavcodec in the first place.) Someone adding such code would
>> have to refactor
On Tue, Dec 13, 2016 at 2:35 PM, wm4 wrote:
> On Tue, 13 Dec 2016 14:19:35 +0100
> Steve Lhomme wrote:
>
>> From: Steve Lhomme
>>
>> The code is similar to ffmpeg_dxva2. The decoded output needs to be copied
>> into
>> a staging texture that can be accessed by the CPU as the decoder texture
>>
64 matches
Mail list logo
