On Fri, Dec 09, 2016 at 03:21:11PM +, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> Sample is here:
> https://trac.ffmpeg.org/attachment/ticket/5458/nondeterministic_cut.h264
> ---
> tests/fate/h264.mak | 2 ++
> tests/ref/fate/h264-missing-frame | 35 +
On Fri, Dec 09, 2016 at 11:42:59PM +0100, Andreas Cadhalpun wrote:
> On 09.12.2016 15:23, Michael Niedermayer wrote:
> > On Fri, Dec 09, 2016 at 12:08:10AM +0100, Andreas Cadhalpun wrote:
> >> Signed-off-by: Andreas Cadhalpun
> >> ---
> >> libavcodec/opus_parser.c | 2 +-
> >> 1 file changed, 1 i
On Fri, Dec 09, 2016 at 03:21:11PM +, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> Sample is here:
> https://trac.ffmpeg.org/attachment/ticket/5458/nondeterministic_cut.h264
> ---
> tests/fate/h264.mak | 2 ++
> tests/ref/fate/h264-missing-frame | 35 +
On Sat, Dec 10, 2016 at 12:11:35AM +0100, Andreas Cadhalpun wrote:
> On 09.12.2016 02:50, Michael Niedermayer wrote:
> > On Fri, Dec 09, 2016 at 01:02:08AM +0100, Andreas Cadhalpun wrote:
> >> On 08.12.2016 22:53, Michael Niedermayer wrote:
> >>> This decreases the amount of computations and memory
On Fri, Dec 9, 2016 at 11:46 PM, Andreas Cadhalpun
wrote:
> On 09.12.2016 15:02, Hendrik Leppkes wrote:
>> On Fri, Dec 9, 2016 at 12:09 AM, Andreas Cadhalpun
>> wrote:
>>> The former expects priv_data to be the ParseContext directly, so using
>>> it does not work.
>>>
>>
>> As an alternative re-o
On 09.12.2016 15:55, Stefano Sabatini wrote:
> On date Friday 2016-11-25 11:58:42 +0100, Nicolas George encoded:
>> Le quintidi 5 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
>>> I think a better idea would be to require '-strict experimental',
>>> as code disabled by default does neither get bu
On 09.12.2016 10:26, wm4 wrote:
> On Fri, 9 Dec 2016 00:30:24 +0100
> Andreas Cadhalpun wrote:
>
>> On 08.12.2016 15:53, wm4 wrote:
>>> (I'm still waiting for related work to be merged from Libav).
>>
>> Why don't you merge it yourself instead of waiting for others?
>
> The commit to be merged
On 09.12.2016 02:50, Michael Niedermayer wrote:
> On Fri, Dec 09, 2016 at 01:02:08AM +0100, Andreas Cadhalpun wrote:
>> On 08.12.2016 22:53, Michael Niedermayer wrote:
>>> This decreases the amount of computations and memory needed for analysing
>>> mpeg1/2 streams
>>>
>>> Signed-off-by: Michael N
On 09.12.2016 15:02, Hendrik Leppkes wrote:
> On Fri, Dec 9, 2016 at 12:09 AM, Andreas Cadhalpun
> wrote:
>> The former expects priv_data to be the ParseContext directly, so using
>> it does not work.
>>
>
> As an alternative re-order the OpusParseContext so that ParseContext
> comes first, it th
On 09.12.2016 15:23, Michael Niedermayer wrote:
> On Fri, Dec 09, 2016 at 12:08:10AM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/opus_parser.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/opus_parser.c b/libavc
On Fri, Dec 09, 2016 at 08:33:29PM +0100, Marton Balint wrote:
>
> On Fri, 9 Dec 2016, Michael Niedermayer wrote:
>
> >On Thu, Dec 08, 2016 at 09:47:53PM +0100, Nicolas George wrote:
> >>L'octidi 18 frimaire, an CCXXV, Michael Niedermayer a écrit :
> >>>A. Is a heap limit for av_*alloc*() accepta
In an automated build system, where valgrind and ffmpeg get updated in
parallel, a race condition may occur in which valgrind/valgrind.h is
available when configure runs but not if libavutil/log.c gets compiled.
Using CONFIG_VALGRIND_BACKTRACE helps to avoid this problem, because
it allows to prev
On Fri, Dec 09, 2016 at 12:45:22AM +0100, Andreas Cadhalpun wrote:
> On 08.12.2016 19:30, Michael Niedermayer wrote:
> > TODO: split into 2 patches (one per lib), docs & bump
> >
> > This allows preventing some OOM and "slow decoding" cases by limiting the
> > maximum resolution
> > this may be u
On 12/9/16, Michael Niedermayer wrote:
> Adds av_image_check_size2() with max_pixels and pix_fmt parameters.
> pix_fmt is unused and is added to avoid a 2nd API change later
>
> The old function uses AVOptions to obtain the max_pixels value to simplify
> the transition.
>
> TODO: split into 2 patc
On Fri, 9 Dec 2016, Michael Niedermayer wrote:
Adds av_image_check_size2() with max_pixels and pix_fmt parameters.
pix_fmt is unused and is added to avoid a 2nd API change later
The old function uses AVOptions to obtain the max_pixels value to simplify
the transition.
TODO: split into 2 patch
On Fri, 9 Dec 2016, Michael Niedermayer wrote:
On Thu, Dec 08, 2016 at 09:47:53PM +0100, Nicolas George wrote:
L'octidi 18 frimaire, an CCXXV, Michael Niedermayer a écrit :
A. Is a heap limit for av_*alloc*() acceptable ?
B. Are case based limits acceptable ?
No. This is the task of the ope
Adds av_image_check_size2() with max_pixels and pix_fmt parameters.
pix_fmt is unused and is added to avoid a 2nd API change later
The old function uses AVOptions to obtain the max_pixels value to simplify
the transition.
TODO: split into 2 patches (one per lib), docs & bump
This allows preventi
On Fri, 9 Dec 2016 14:11:30 +0100
Michael Niedermayer wrote:
> On Fri, Dec 09, 2016 at 10:14:14AM +0100, wm4 wrote:
> > On Thu, 8 Dec 2016 19:30:25 +0100
> > Michael Niedermayer wrote:
> >
> > > TODO: split into 2 patches (one per lib), docs & bump
> > >
> > > This allows preventing some OO
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
On Fri, 9 Dec 2016 14:33:08 +0100
Michael Niedermayer wrote:
> On Fri, Dec 09, 2016 at 09:55:52AM +0100, wm4 wrote:
> > On Fri, 9 Dec 2016 03:48:39 +0100
> > Michael Niedermayer wrote:
> >
> > > On Thu, Dec 08, 2016 at 11:13:16AM -0900, Lou Logan wrote:
> > > > On Mon, 5 Dec 2016 13:52:50
On Fri, 9 Dec 2016 14:45:24 +0100
Michael Niedermayer wrote:
> On Fri, Dec 09, 2016 at 09:53:00AM +0100, wm4 wrote:
> > On Mon, 5 Dec 2016 21:10:00 +0100
> > Michael Niedermayer wrote:
> >
> > > On Mon, Dec 05, 2016 at 01:52:50PM +0100, Michael Niedermayer wrote:
> > > > This should make it
On Fri, Dec 09, 2016 at 03:22:52PM +, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> Happened to notice this when adding a FATE test.
> ---
> libavcodec/tests/.gitignore | 1 +
> 1 file changed, 1 insertion(+)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147
Signed-off-by: Derek Buitenhuis
---
Happened to notice this when adding a FATE test.
---
libavcodec/tests/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/tests/.gitignore b/libavcodec/tests/.gitignore
index d8ab947abe..0ab029696d 100644
--- a/libavcodec/tests/.gitignore
Signed-off-by: Michael Niedermayer
---
libavcodec/flacdec.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
index af81115ff8..0fffc2dd94 100644
--- a/libavcodec/flacdec.c
+++ b/libavcodec/flacdec.c
@@ -259,7 +259,13 @@ static
Signed-off-by: Derek Buitenhuis
---
Sample is here:
https://trac.ffmpeg.org/attachment/ticket/5458/nondeterministic_cut.h264
---
tests/fate/h264.mak | 2 ++
tests/ref/fate/h264-missing-frame | 35 +++
2 files changed, 37 insertions(+)
create mode 1
On Fri, Dec 9, 2016 at 3:59 PM, Nicolas George wrote:
> Le nonidi 19 frimaire, an CCXXV, Stefano Sabatini a écrit :
>> -strict is for codecs, there is no such thing at the moment for
>> muxers/demuxers (so it should be implemented for muxers/demuxers).
>
> AVFormatContext has strict_std_compliance
On 12/9/2016 2:29 PM, Michael Niedermayer wrote:
> this looks reasonable
Pushed.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Le nonidi 19 frimaire, an CCXXV, Stefano Sabatini a écrit :
> -strict is for codecs, there is no such thing at the moment for
> muxers/demuxers (so it should be implemented for muxers/demuxers).
AVFormatContext has strict_std_compliance too.
Regards,
--
Nicolas George
On date Friday 2016-11-25 11:58:42 +0100, Nicolas George encoded:
> Le quintidi 5 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
> > I think a better idea would be to require '-strict experimental',
> > as code disabled by default does neither get build- nor FATE-tested
> > much.
>
> That is an e
On Thu, Dec 08, 2016 at 01:12:07PM -0800, Christopher Snowhill wrote:
> ---
> libavformat/mp3dec.c | 70
> +++-
> 1 file changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 56c7f8c..47f4028
On Thu, Dec 08, 2016 at 04:55:49PM +, Derek Buitenhuis wrote:
> This could happen when there was a frame number gap and frame threading was
> used.
>
> This fixes #5458.
>
> Debugging-by: Ronald S. Bultje
> Debugging-by: Justin Ruggles
> Signed-off-by: Derek Buitenhuis
> ---
> Extra help
On Fri, Dec 09, 2016 at 12:08:10AM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/opus_parser.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/opus_parser.c b/libavcodec/opus_parser.c
> index c30fd7b..21a73ee 100644
> --
On 12/9/2016 9:18 AM, Michael Niedermayer wrote:
> On Thu, Dec 08, 2016 at 03:11:03PM -0300, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> tests/fate/mov.mak | 20 +---
>> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> should be ok
Set pushed, thanks.
___
On Fri, Dec 09, 2016 at 11:35:08AM +0100, Nicolas George wrote:
> Le nonidi 19 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > > > A. Is a heap limit for av_*alloc*() acceptable ?
>
> > moving the threshold of where to declare something OOM or hang around
> > will not solve this.
>
> Yet th
On Fri, Dec 9, 2016 at 12:09 AM, Andreas Cadhalpun
wrote:
> The former expects priv_data to be the ParseContext directly, so using
> it does not work.
>
As an alternative re-order the OpusParseContext so that ParseContext
comes first, it then would work, and thats basically how its done in
the ot
On Fri, Dec 09, 2016 at 09:53:00AM +0100, wm4 wrote:
> On Mon, 5 Dec 2016 21:10:00 +0100
> Michael Niedermayer wrote:
>
> > On Mon, Dec 05, 2016 at 01:52:50PM +0100, Michael Niedermayer wrote:
> > > This should make it less ambigous that these are URLs
> > >
> > > Signed-off-by: Michael Niederma
On Fri, Dec 09, 2016 at 09:55:52AM +0100, wm4 wrote:
> On Fri, 9 Dec 2016 03:48:39 +0100
> Michael Niedermayer wrote:
>
> > On Thu, Dec 08, 2016 at 11:13:16AM -0900, Lou Logan wrote:
> > > On Mon, 5 Dec 2016 13:52:50 +0100, Michael Niedermayer wrote:
> > >
> > > > This should make it less amb
On Fri, Dec 09, 2016 at 10:14:14AM +0100, wm4 wrote:
> On Thu, 8 Dec 2016 19:30:25 +0100
> Michael Niedermayer wrote:
>
> > TODO: split into 2 patches (one per lib), docs & bump
> >
> > This allows preventing some OOM and "slow decoding" cases by limiting the
> > maximum resolution
> > this ma
On Thu, Dec 08, 2016 at 03:11:03PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> tests/fate/mov.mak | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
should be ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it i
On Thu, Dec 08, 2016 at 03:11:04PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> Sample can be found in http://0x0.st/Lpj.mkv
>
> tests/fate/matroska.mak| 4
> tests/ref/fate/matroska-spherical-mono | 16
> 2 files changed, 20 insertions(+)
Hi,
Attached patch fixes issue #6007 for me.
I think it could improved / extended because the "if (s->seekable == -1 &&
(!s->is_akamai || s->content_range_len != 2147483647))" is probably better
placed http_read_header along with the similar is_mediagateway workaround. I
wasn't sure whether the
Hi,
On Thu, Dec 8, 2016 at 7:03 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 08.12.2016 22:59, Carl Eugen Hoyos wrote:
> > 2016-12-08 18:37 GMT+01:00 Michael Niedermayer :
> >
> >> -{"max_streams", "maximum number of streams", OFFSET(max_streams),
> AV_OPT_TYPE_INT, { .i6
L'octidi 18 frimaire, an CCXXV, Marton Balint a écrit :
> Since the default in the libav fork is to only allow known layouts, making
> unknown layouts allowed by default here can be a security risk for filters
> directly merged from libav. However, usually it is simple to detect such
> cases,
> us
Le nonidi 19 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > > A. Is a heap limit for av_*alloc*() acceptable ?
> moving the threshold of where to declare something OOM or hang around
> will not solve this.
Yet this is your "A" proposal. Or am I misunderstanding you?
Regards,
--
Nicola
On Fri, 9 Dec 2016 00:30:24 +0100
Andreas Cadhalpun wrote:
> On 08.12.2016 15:53, wm4 wrote:
> > (I'm still waiting for related work to be merged from Libav).
>
> Why don't you merge it yourself instead of waiting for others?
The commit to be merged next appears to have some intrusive h264 de
On Thu, 8 Dec 2016 19:30:25 +0100
Michael Niedermayer wrote:
> TODO: split into 2 patches (one per lib), docs & bump
>
> This allows preventing some OOM and "slow decoding" cases by limiting the
> maximum resolution
> this may be useful to avoid fuzzers getting stuck in boring cases
>
> Signe
On Thu, 8 Dec 2016 20:57:05 +0100
Michael Niedermayer wrote:
> On Thu, Dec 08, 2016 at 07:48:46PM +0100, wm4 wrote:
> > On Thu, 8 Dec 2016 19:36:20 +0100
> > Michael Niedermayer wrote:
> >
> > > On Thu, Dec 08, 2016 at 07:25:59PM +0100, wm4 wrote:
> > > > On Thu, 8 Dec 2016 18:37:42 +0100
On Fri, 9 Dec 2016 02:44:11 +0100
Michael Niedermayer wrote:
> On Thu, Dec 08, 2016 at 09:47:53PM +0100, Nicolas George wrote:
> > L'octidi 18 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > > A. Is a heap limit for av_*alloc*() acceptable ?
> > > B. Are case based limits acceptable ?
>
On Fri, 9 Dec 2016 03:48:39 +0100
Michael Niedermayer wrote:
> On Thu, Dec 08, 2016 at 11:13:16AM -0900, Lou Logan wrote:
> > On Mon, 5 Dec 2016 13:52:50 +0100, Michael Niedermayer wrote:
> >
> > > This should make it less ambigous that these are URLs
> > >
> > > Signed-off-by: Michael Niede
On Mon, 5 Dec 2016 21:10:00 +0100
Michael Niedermayer wrote:
> On Mon, Dec 05, 2016 at 01:52:50PM +0100, Michael Niedermayer wrote:
> > This should make it less ambigous that these are URLs
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/ffmpeg.texi | 18 +-
> > doc
50 matches
Mail list logo
