It's more consistent with other similar checks in the decoder, and should
help with fuzzing.
Signed-off-by: James Almer
---
I could also add an AV_EF_EXPLODE check before aborting, but i figured
that with a frame header crc failure it's pretty much guaranteed the
file will be unplayable.
libav
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,
use of av_get_channel_layout_nb_channels is a good indicator, so I su
On 07.12.2016 03:18, Michael Niedermayer wrote:
> On Mon, Dec 05, 2016 at 11:08:44PM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/yuv4mpegdec.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/yuv4mpegdec.c b
On Wed, Dec 7, 2016 at 2:07 PM, James Darnley wrote:
> Because a few instructions using 3 operand form should be quicker. The
> fact that it doesn't show is no doubt down to the out of order execution
> managing to do the moves earlier than written.
Register-register moves are handled in the reg
32-bit msvc.
---
libavcodec/x86/h264_deblock_10bit.asm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/x86/h264_deblock_10bit.asm
b/libavcodec/x86/h264_deblock_10bit.asm
index 56cf4d6..c295364 100644
--- a/libavcodec/x86/h264_deblock_10bit.asm
+++ b/libavcodec/x
On 12/7/2016 3:45 PM, Carl Eugen Hoyos wrote:
> 2016-12-05 16:03 GMT+01:00 James Almer :
>
>>> Which reasons were not adressed?
>>
>> <@wbs>
>
> I am unfortunately unable to express how offensive and mean I
> consider your answer.
Thanks for not expressing it. I'm not interested in hearing about
Le septidi 17 frimaire, an CCXXV, Ronald S. Bultje a écrit :
> I believe you missed Carl Eugen's vote (or at least I read it as a vote):
> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/203915.html
Indeed, thanks for noticing. I belive it counts as "keep (slightly
invalid)".
Regards,
--
Hi,
On Wed, Dec 7, 2016 at 1:29 PM, Nicolas George wrote:
> keepAndreas Cadhalpun
> keepMarton Balint
> keepMichael Niedermayer (slightly invalid)
> keepNicolas George
> keepReynaldo H. Verdejo Pinochet (slightly invalid)
I believe you missed Carl Eugen's vote (or at least
On 12/7/2016 8:10 PM, Michael Niedermayer wrote:
> this deadlocks on some samples
> ill try to find one that i can share
I have a vague idea maybe why, but I'd need a sample, yes.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmp
On Wed, Dec 07, 2016 at 06:06:32PM +, 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
> ---
> This fixes
On 12/7/2016 6:43 PM, Carl Eugen Hoyos wrote:
> 2016-12-07 19:06 GMT+01:00 Derek Buitenhuis :
>> This could happen when there was a frame number
>> gap and frame threading was used.
>>
>> This fixes #5458.
>
> Does this patch have a speed impact on valid streams?
> I ask because the sample stream
2016-12-05 16:03 GMT+01:00 James Almer :
>> Which reasons were not adressed?
>
> <@wbs>
I am unfortunately unable to express how offensive and mean I
consider your answer.
It's really extraordinarily disappointing.
Carl Eugen
___
ffmpeg-devel mailing l
2016-12-07 19:06 GMT+01:00 Derek Buitenhuis :
> This could happen when there was a frame number
> gap and frame threading was used.
>
> This fixes #5458.
Does this patch have a speed impact on valid streams?
I ask because the sample stream is invalid so I thought
ex falso quodlibet would apply.
C
Le quintidi 15 frimaire, an CCXXV, Rostislav Pehlivanov a écrit :
> I need more time to decide.
You supported dropping ffserver since before the vote started, and now
you are hesitating? Seriously?
Arriving at the last minute when it became obvious the tide turned to
ensure a longer delay. Where
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
---
This fixes a ton of samples that had frame num gaps and were decoding using
large
numbers of thr
Le septidi 17 frimaire, an CCXXV, Hendrik Leppkes a écrit :
> I'm not sure you can safely avoid that in this design when dealing
> with a fully generic library and no information or control whats going
> on in other threads.
You are right, I had not realized there was a race condition here.
What
On 2016-12-07 11:07, Carl Eugen Hoyos wrote:
> 2016-12-05 19:32 GMT+01:00 James Darnley :
>
>> - sse2: 2.47x (170 vs. 69 cycles)
>> - avx: 2.47x (170 vs. 69 cycles)
>
> Please elaborate on why this was committed.
Because writing it cost almost zero time. All it needed was writing the
dsp p
On Wed, Dec 7, 2016 at 12:25 PM, Matt Oliver wrote:
> On 7 December 2016 at 21:19, Mark Thompson wrote:
>
>> On 07/12/16 06:05, Matt Oliver wrote:
>> > Signed-off-by: Matt Oliver
>> > ---
>> > libavformat/udp.c | 19 +--
>> > 1 file changed, 17 insertions(+), 2 deletions(-)
>> >
On 7 December 2016 at 21:19, Mark Thompson wrote:
> On 07/12/16 06:05, Matt Oliver wrote:
> > Signed-off-by: Matt Oliver
> > ---
> > libavformat/udp.c | 19 +--
> > 1 file changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/udp.c b/libavformat/udp.c
> > in
On 7 December 2016 at 21:32, Hendrik Leppkes wrote:
> On Wed, Dec 7, 2016 at 7:04 AM, Matt Oliver wrote:
> > Signed-off-by: Matt Oliver
> > ---
> > compat/os2threads.h | 24
> > compat/w32pthreads.h | 50
> > ++
> > liba
On Wed, Dec 7, 2016 at 7:04 AM, Matt Oliver wrote:
> Signed-off-by: Matt Oliver
> ---
> compat/os2threads.h | 24
> compat/w32pthreads.h | 50
> ++
> libavutil/thread.h | 6 ++
> 3 files changed, 80 insertions(+)
>
On Wed, Dec 7, 2016 at 7:13 AM, Matt Oliver wrote:
> On 30 October 2016 at 17:57, Michael Forney wrote:
>
>> On 10/29/16, Matt Oliver wrote:
>> > This also seems a bit odd, why is libreSSL setting an openssl version
>> > number of 1.1.0 or higher when it doesnt actually conform to the
>> > corre
On 07/12/16 06:05, Matt Oliver wrote:
> Signed-off-by: Matt Oliver
> ---
> libavformat/udp.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index f8c861d..0e4766f 100644
> --- a/libavformat/udp.c
> +++ b/libav
2016-12-05 19:32 GMT+01:00 James Darnley :
> - sse2: 2.47x (170 vs. 69 cycles)
> - avx: 2.47x (170 vs. 69 cycles)
Please elaborate on why this was committed.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailma
24 matches
Mail list logo
