---
libavformat/udp.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index f8c861d..3cafb32 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -64,6 +64,14 @@
#define HAVE_PTHREAD_CANCEL 0
#endif
+#if HAVE_THREA
On Sun, 11 Dec 2016 17:39:58 +0100
Nicolas George wrote:
> This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.
would you rather the people doing the fuzzing use this feature as a
separate patch so it does not contaminate master?
-compn
___
f
Signed-off-by: James Almer
---
TODO: APIChanges entry and version bump.
libavutil/replaygain.c | 38 ++
libavutil/replaygain.h | 10 ++
2 files changed, 48 insertions(+)
create mode 100644 libavutil/replaygain.c
diff --git a/libavutil/replaygain.c b/
Signed-off-by: James Almer
---
libavformat/replaygain.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavformat/replaygain.c b/libavformat/replaygain.c
index 707d3cd..b8658d6 100644
--- a/libavformat/replaygain.c
+++ b/libavformat/replaygain.c
@@ -71,12 +71,1
On Sun, Dec 11, 2016 at 12:33:05AM -0300, James Almer wrote:
> Also deprecate av_stereo3d_alloc().
>
> This new alloc function optionally returns the size of the AVStereo3D struct.
>
> Signed-off-by: James Almer
> ---
> libavutil/stereo3d.c | 12
> libavutil/stereo3d.h | 14 +++
On Sun, Dec 11, 2016 at 12:33:07AM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavformat/isom.h | 1 +
> libavformat/mov.c | 6 +++---
> 2 files changed, 4 insertions(+), 3 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B
On Sun, Dec 11, 2016 at 12:33:08AM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/mjpegdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Rewriting code that is poo
On Mon, Dec 12, 2016 at 01:54:12AM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #6014.
>
> Please comment, Carl Eugen
> isom.c |1 +
> 1 file changed, 1 insertion(+)
> d9c95ca1ee86b780a596b39f0170cb176945a5a3
> 0001-lavf-isom-Support-EVRC-in-pvAuthor-files.patch
>
On Mon, Dec 12, 2016 at 01:31:47AM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun
> ---
> libavutil/opt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/opt.c b/libavutil/opt.c
> index f855ccb..6ae2af6 100644
> --- a/libavutil/opt.c
> +++ b
On Sun, Dec 11, 2016 at 10:51:08PM -0300, James Almer wrote:
> On 12/11/2016 10:29 PM, Michael Niedermayer wrote:
> > On Sat, Dec 10, 2016 at 09:52:08PM -0300, James Almer wrote:
> >> On 12/10/2016 9:23 PM, Michael Niedermayer wrote:
> >>> On Sat, Dec 10, 2016 at 08:31:57PM -0300, James Almer wrote
On 12/11/2016 10:29 PM, Michael Niedermayer wrote:
> On Sat, Dec 10, 2016 at 09:52:08PM -0300, James Almer wrote:
>> On 12/10/2016 9:23 PM, Michael Niedermayer wrote:
>>> On Sat, Dec 10, 2016 at 08:31:57PM -0300, James Almer wrote:
On 12/10/2016 7:01 PM, Michael Niedermayer wrote:
> [...]
>
>
On Sat, Dec 10, 2016 at 09:52:08PM -0300, James Almer wrote:
> On 12/10/2016 9:23 PM, Michael Niedermayer wrote:
> > On Sat, Dec 10, 2016 at 08:31:57PM -0300, James Almer wrote:
> >> On 12/10/2016 7:01 PM, Michael Niedermayer wrote:
[...]
> > And also theres more work for us to maintain seperate i
Hi!
Attached patch fixes ticket #6014.
Please comment, Carl Eugen
From 8878744426cdaf31227786a07743d06cc6ef8995 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 12 Dec 2016 01:52:12 +0100
Subject: [PATCH] lavf/isom: Support EVRC in pvAuthor files.
Fixes ticket #6014.
---
libavformat/
Signed-off-by: Andreas Cadhalpun
---
libavutil/opt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index f855ccb..6ae2af6 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -97,7 +97,7 @@ static int read_number(const AVOption *o, const vo
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/imgutils.h
+++ b/libavutil/imgutils.h
@@ -193,7 +193,8 @@ int av_image_
On Sun, Dec 11, 2016 at 03:29:32PM +0100, Hendrik Leppkes wrote:
> On Sat, Dec 10, 2016 at 11:36 PM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sat, Dec 10, 2016 at 5:24 PM, Carl Eugen Hoyos
> > wrote:
> >
> >> 2016-12-10 14:07 GMT+01:00 Ronald S. Bultje :
> >> > Hi,
> >> >
> >> > On Sat, Dec 10,
On 11.12.2016 22:03, Ronald S. Bultje wrote:
> On Sun, Dec 11, 2016 at 1:41 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>> This trivial news patch already got way more comments than the original
>> patch series, which gives me the impression that people care more about
>> the
On Sun, Dec 11, 2016 at 02:00:04PM +0100, wm4 wrote:
> On Sun, 11 Dec 2016 00:33:03 -0300
[...]
> Here are some brainstormed alternative ideas to adding those ...2()
> functions:
> - add functions to add side data by type to AVFrames etc.
> - provide a generic function that allocates side data by p
On Sun, 11 Dec 2016 13:38:00 -0300
James Almer wrote:
> On 12/11/2016 10:00 AM, wm4 wrote:
> > On Sun, 11 Dec 2016 00:33:03 -0300
> > James Almer wrote:
> >
> >> Also deprecate av_mastering_display_metadata_alloc().
> >>
> >> This new alloc function optionally returns the size of the
> >> AV
On 12/11/2016 3:41 PM, Andreas Cadhalpun wrote:
> On 10.12.2016 23:22, Carl Eugen Hoyos wrote:
>> 2016-12-10 19:47 GMT+01:00 Andreas Cadhalpun
>> :
>>> Suggested-by: Carl Eugen Hoyos
>>> Signed-off-by: Andreas Cadhalpun
>>> ---
>>> src/index | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
On Sun, 11 Dec 2016 17:44:31 +0100
Michael Niedermayer wrote:
> On Sun, Dec 11, 2016 at 05:39:58PM +0100, Nicolas George wrote:
> > This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.
> >
> > It was rushed and not properly designed.
>
> I strongly object to this patchset
>
> we nee
Hi,
On Sun, Dec 11, 2016 at 1:41 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 10.12.2016 23:22, Carl Eugen Hoyos wrote:
> > 2016-12-10 19:47 GMT+01:00 Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com>:
> >> Suggested-by: Carl Eugen Hoyos
> >> Signed-off-by: Andreas
On 11.12.2016 21:03, Hendrik Leppkes wrote:
> On Sun, Dec 11, 2016 at 7:48 PM, Andreas Cadhalpun
> wrote:
>> On 11.12.2016 10:04, Hendrik Leppkes wrote:
>>> I still see the problem that this option code does not know which
>>> pix_fmt the numbers relate to and as such would keep the old limit in
>
On Sun, Dec 11, 2016 at 7:48 PM, Andreas Cadhalpun
wrote:
> On 11.12.2016 10:04, Hendrik Leppkes wrote:
>> On Sat, Dec 10, 2016 at 6:53 PM, Andreas Cadhalpun
>> wrote:
>>> On 10.12.2016 18:40, Hendrik Leppkes wrote:
and just adds extra burden when these limits are
changed/improved (say
On Sun, Dec 11, 2016 at 07:27:26PM +0100, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > Well, we need these options for efficient fuzzing
>
> We need SOMETHING, maybe, but not specifically THESE.
>
> > There are multiple independant things these optio
On 11.12.2016 20:19, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
>> No, that doesn't solve the problem. It takes much more time until the
>> address space limit is reached than checking the resolution before
>> starting to allocate the memory.
>
> So basic
Le primidi 21 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
> No, that doesn't solve the problem. It takes much more time until the
> address space limit is reached than checking the resolution before
> starting to allocate the memory.
So basically, this option solves the problem of fuzzers runn
On 11.12.2016 19:27, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
>> Fuzzers search and find issues like out of array accesses but also
>> hangs and oom conditions.
>> Fuzzers find hangs and OOM conditions by executing code until it runs
>> out of memory o
Le primidi 21 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
> It was tested and works well for its purpose.
Unfortunately, the purpose itself is wrong.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 11.12.2016 17:39, Nicolas George wrote:
> This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.
I'm against reverting this.
> It was rushed and not properly designed.
It was tested and works well for its purpose.
Best regards,
Andreas
___
f
On 12/11/16, Agneet Chatterjee wrote:
> Hello everyone. I'm a second year CS undergrad willing to contribute to
> this organisation. Could somebody help me get started?
Anything you are interested to work on?
There are numerous possibilities.
>
> Thank you.
> Agneet Chatterjee.
> ___
On 11.12.2016 10:04, Hendrik Leppkes wrote:
> On Sat, Dec 10, 2016 at 6:53 PM, Andreas Cadhalpun
> wrote:
>> On 10.12.2016 18:40, Hendrik Leppkes wrote:
>>> and just adds extra burden when these limits are
>>> changed/improved (say by making them pixfmt aware as discussed in
>>> another thread, wh
On 10.12.2016 23:22, Carl Eugen Hoyos wrote:
> 2016-12-10 19:47 GMT+01:00 Andreas Cadhalpun
> :
>> Suggested-by: Carl Eugen Hoyos
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> src/index | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/src/index b/src/index
>> index c203676..8f
Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> Well, we need these options for efficient fuzzing
We need SOMETHING, maybe, but not specifically THESE.
> There are multiple independant things these options solve
> I belive i explained all already, but
You were vague. We only st
Hello everyone. I'm a second year CS undergrad willing to contribute to
this organisation. Could somebody help me get started?
Thank you.
Agneet Chatterjee.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-d
On Sun, Dec 11, 2016 at 05:47:34PM +0100, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > we need these limit paramters for fuzzing to be practical.
>
> Maybe, but we can take a few days to do it properly instead of rushing a
> badly-designed "fix" that
Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> we need these limit paramters for fuzzing to be practical.
Maybe, but we can take a few days to do it properly instead of rushing a
badly-designed "fix" that does not fix anything and then being forced
into a maintenance nightmare b
On Sun, Dec 11, 2016 at 05:39:58PM +0100, Nicolas George wrote:
> This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.
>
> It was rushed and not properly designed.
I strongly object to this patchset
we need these limit paramters for fuzzing to be practical.
[...]
--
Michael GnuPG
This reverts commit 1296f844955e513d19051c962656f829479d4fb9.
It was rushed and not properly designed.
Signed-off-by: Nicolas George
---
doc/formats.texi| 4
libavformat/avformat.h | 7 ---
libavformat/options_table.h | 1 -
libavformat/utils.c | 2 +-
libavfor
This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.
It was rushed and not properly designed.
Signed-off-by: Nicolas George
---
doc/codecs.texi | 4
libavcodec/avcodec.h | 8
libavcodec/options_table.h | 1 -
libavcodec/ut
This reverts commit f542b152aa2086b30d1089162d79f5c136905c0c.
Signed-off-by: Nicolas George
---
doc/APIchanges | 3 ---
libavutil/imgutils.c | 29 +
libavutil/imgutils.h | 14 --
libavutil/version.h | 2 +-
4 files changed, 6 insertions(+), 42 del
On 12/11/2016 10:00 AM, wm4 wrote:
> On Sun, 11 Dec 2016 00:33:03 -0300
> James Almer wrote:
>
>> Also deprecate av_mastering_display_metadata_alloc().
>>
>> This new alloc function optionally returns the size of the
>> AVMasteringDisplayMetadata
>> struct.
>>
>> Signed-off-by: James Almer
>> -
Le tridi 13 frimaire, an CCXXV, Nicolas George a écrit :
> Anybody intends to look at the code beyond the private fields issue? If
> not, I could as well push now and start working on the next step and
> making the structure private.
I will do so after the end of this week if I see no news.
Regar
Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> As long as it is not documented that you need to run libavcodec/format
> in a seperate process it is a security issue if you crash.
This is not specific to FFmpeg and documented in books and courses on
development in general.
> iam
On Sun, Dec 11, 2016 at 04:06:00PM +0100, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > Its explained in the patch comment above
> >
> > max_pixels should to be backported as it allows users to control memory
> > use from large images better, avoid som
Le primidi 21 frimaire, an CCXXV, wm4 a écrit :
> Right. I looked and font data is in extradata. That doesn't seem very
> ideal. Rather than making extradata refcounted, this should probably be
> a new AVPacket* field.
It feels like a round peg in a square hole: use the existing structures
even wh
On Sun, 11 Dec 2016 16:50:00 +0100
Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, wm4 a écrit :
> > Attachment contents are AVPackets
>
> That is true for attached pictures but not other kinds of attachments.
>
> Regards,
>
Right. I looked and font data is in extradata. That does
Le primidi 21 frimaire, an CCXXV, wm4 a écrit :
> Attachment contents are AVPackets
That is true for attached pictures but not other kinds of attachments.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mai
On Sun, 11 Dec 2016 16:19:03 +0100
Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, wm4 a écrit :
> > Subtitle streams, font attachments, attached images, and other things
> > could also inflate the number of streams, so 1000 seems a bit low.
>
> As a side note, attachments are presen
Le primidi 21 frimaire, an CCXXV, wm4 a écrit :
> Subtitle streams, font attachments, attached images, and other things
> could also inflate the number of streams, so 1000 seems a bit low.
As a side note, attachments are presented in the streams' extradata, and
as such loaded immediately.
A playe
On Sun, 11 Dec 2016 16:06:41 +0100
Michael Niedermayer wrote:
> On Sun, Dec 11, 2016 at 04:02:27PM +0100, Hendrik Leppkes wrote:
> > On Sun, Dec 11, 2016 at 3:59 PM, Michael Niedermayer
> > wrote:
> > > On Sun, Dec 11, 2016 at 01:54:28PM +0100, wm4 wrote:
> > >> On Sat, 10 Dec 2016 23:01:04
On Sun, 11 Dec 2016 15:29:32 +0100
Hendrik Leppkes wrote:
> On Sat, Dec 10, 2016 at 11:36 PM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sat, Dec 10, 2016 at 5:24 PM, Carl Eugen Hoyos
> > wrote:
> >
> >> 2016-12-10 14:07 GMT+01:00 Ronald S. Bultje :
> >> > Hi,
> >> >
> >> > On Sat, Dec 10,
On Sun, Dec 11, 2016 at 04:02:27PM +0100, Hendrik Leppkes wrote:
> On Sun, Dec 11, 2016 at 3:59 PM, Michael Niedermayer
> wrote:
> > On Sun, Dec 11, 2016 at 01:54:28PM +0100, wm4 wrote:
> >> On Sat, 10 Dec 2016 23:01:04 +0100
> >> Michael Niedermayer wrote:
> >>
> >> > When we will backport this,
Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> Its explained in the patch comment above
>
> max_pixels should to be backported as it allows users to control memory
> use from large images better, avoid some OOMs and fixes issues which
> some people consider security bugs
> if it
On Sun, Dec 11, 2016 at 3:59 PM, Michael Niedermayer
wrote:
> On Sun, Dec 11, 2016 at 01:54:28PM +0100, wm4 wrote:
>> On Sat, 10 Dec 2016 23:01:04 +0100
>> Michael Niedermayer wrote:
>>
>> > When we will backport this, it will be inevitably in a different location
>> > in AVCodecContext in each r
On Sun, Dec 11, 2016 at 01:54:28PM +0100, wm4 wrote:
> On Sat, 10 Dec 2016 23:01:04 +0100
> Michael Niedermayer wrote:
>
> > When we will backport this, it will be inevitably in a different location
> > in AVCodecContext in each release and master. 3.0, 3.1, 3.2 and master
> > use the same soname
On Sat, Dec 10, 2016 at 11:36 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Dec 10, 2016 at 5:24 PM, Carl Eugen Hoyos
> wrote:
>
>> 2016-12-10 14:07 GMT+01:00 Ronald S. Bultje :
>> > Hi,
>> >
>> > On Sat, Dec 10, 2016 at 7:11 AM, Carl Eugen Hoyos
>> > wrote:
>> >
>> >> 2016-12-09 12:56 GMT+01:00
2016-12-10 23:36 GMT+01:00 Ronald S. Bultje :
> Hi,
>
> On Sat, Dec 10, 2016 at 5:24 PM, Carl Eugen Hoyos
> wrote:
>
>> 2016-12-10 14:07 GMT+01:00 Ronald S. Bultje :
>> > Hi,
>> >
>> > On Sat, Dec 10, 2016 at 7:11 AM, Carl Eugen Hoyos
>> > wrote:
>> >
>> >> 2016-12-09 12:56 GMT+01:00 Ronald S. Bu
On 12/11/16, Nicolas George wrote:
> Le decadi 20 frimaire, an CCXXV, Ronald S. Bultje a ecrit :
>> > The news entry is needed for this change.
>>
>> ... according to you...
>>
>> Right?
>
> Are we starting a world war against a news entry, now?
>
Yes, Carl is our revolution leader/dictator.
On Sun, 11 Dec 2016 00:33:03 -0300
James Almer wrote:
> Also deprecate av_mastering_display_metadata_alloc().
>
> This new alloc function optionally returns the size of the
> AVMasteringDisplayMetadata
> struct.
>
> Signed-off-by: James Almer
> ---
> libavutil/mastering_display_metadata.c |
On Sat, 10 Dec 2016 23:01:04 +0100
Michael Niedermayer wrote:
> When we will backport this, it will be inevitably in a different location
> in AVCodecContext in each release and master. 3.0, 3.1, 3.2 and master
> use the same soname though and must have a binary compatible interface.
> It thus ca
On Sat, 10 Dec 2016 22:36:50 +0100
Michael Niedermayer wrote:
> Personally if i would be doing this i would use avoptions as
> that means less code to backport that is less work
Less changes doesn't make it right. Anyway, you don't need to listen to
me. I'm just arguing this way because I think
Le decadi 20 frimaire, an CCXXV, Ronald S. Bultje a écrit :
> > The news entry is needed for this change.
>
> ... according to you...
>
> Right?
Are we starting a world war against a news entry, now?
signature.asc
Description: Digital signature
___
f
On Sat, Dec 10, 2016 at 6:53 PM, Andreas Cadhalpun
wrote:
> On 10.12.2016 18:40, Hendrik Leppkes wrote:
>> On Sat, Dec 10, 2016 at 6:20 PM, Andreas Cadhalpun
>> wrote:
>>> On 10.12.2016 17:29, Hendrik Leppkes wrote:
On Sat, Dec 10, 2016 at 4:55 PM, Andreas Cadhalpun
wrote:
> If tha
On 11 December 2016 at 00:21, Carl Eugen Hoyos wrote:
> 2016-12-07 7:04 GMT+01:00 Matt Oliver :
>
> > -#if HAVE_PTHREAD_CANCEL
> > -#include
> > -#endif
> > -
>
> > #ifndef HAVE_PTHREAD_CANCEL
> > #define HAVE_PTHREAD_CANCEL 0
> > #endif
>
I have no idea why that line is there as configure s
65 matches
Mail list logo
